LDP FEC Advertisement: Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs)
Clarifies that the kind of FEC, not only the session's negotiated mode, decides how an LDP speaker advertises labels.
Raza, K., Boutros, S., Martini, L., and N. Leymann, "Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs)", RFC 7358, DOI 10.17487/RFC7358, October 2014, <https://www.rfc-editor.org/info/rfc7358>.
@misc{rfc7358,
series = {Request for Comments},
number = 7358,
howpublished = {RFC 7358},
publisher = {RFC Editor},
doi = {10.17487/RFC7358},
url = {https://www.rfc-editor.org/info/rfc7358},
author = {K. Raza and S. Boutros and L. Martini and N. Leymann},
title = {{Label Advertisement Discipline for LDP Forwarding Equivalence Classes (FECs)}},
pagetotal = 8,
year = 2014,
month = oct,
} RFC text
Contents
Internet Engineering Task Force (IETF) K. Raza
Request for Comments: 7358 S. Boutros
Updates: 3212, 4447, 5036, 5918, 6388, 7140 L. Martini
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 N. Leymann
Deutsche Telekom
October 2014
Label Advertisement Discipline
for LDP Forwarding Equivalence Classes (FECs)
Abstract
The label advertising behavior of an LDP speaker for a given
Forwarding Equivalence Class (FEC) is governed by the FEC type and
not necessarily by the LDP session's negotiated label advertisement
mode. This document updates RFC 5036 to make that fact clear. It
also updates RFCs 3212, 4447, 5918, 6388, and 7140 by specifying the
label advertisement mode for all currently defined LDP FEC types.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7358.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction ....................................................2
2. Label Advertisement Discipline ..................................3
2.1. Update to RFC 5036 .........................................3
2.2. Specification for LDP FECs .................................4
3. Security Considerations .........................................4
4. IANA Considerations .............................................4
5. References ......................................................6
5.1. Normative References .......................................6
5.2. Informative References .....................................7
Acknowledgments ....................................................8
Authors' Addresses .................................................8
1. Introduction
The Label Distribution Protocol (LDP) [RFC5036] allows label
advertisement mode negotiation at the time of session establishment.
The LDP specification also dictates that only a single label
advertisement mode be negotiated, agreed upon, and used for a given
LDP session between two Label Switching Routers (LSRs).
The negotiated label advertisement mode defined in RFC 5036 and
carried in the LDP Initialization message is only indicative. It
indicates how the LDP speakers on a session will advertise labels for
some Forwarding Equivalence Classes (FECs), but it is not a rule that
restricts the speakers to behave in a specific way. Furthermore, for
some FEC types the advertising behavior of the LDP speaker is
governed by the FEC type and not by the negotiated behavior.
This document updates [RFC5036] to make that fact clear. It also
updates [RFC3212], [RFC4447], [RFC5918], [RFC6388], and [RFC7140] to
indicate, for each FEC type that has already been defined, whether
the label binding advertisements for the FEC are constrained by the
negotiated label advertisement mode or not. Furthermore, this
document specifies the label advertisement mode to be used for all
currently defined FECs.
2. Label Advertisement Discipline
To remove any ambiguity and conflict regarding a label advertisement
discipline among different FEC types sharing a common LDP session,
this document specifies a label advertisement discipline for FEC
types.
This document introduces the following types for specifying a label
advertisement discipline for a FEC type:
- DU (Downstream Unsolicited)
- DoD (Downstream on Demand)
- As negotiated (DU or DoD)
- Upstream ([RFC6389])
- Not applicable
- Unknown
2.1. Update to RFC 5036
Section 3.5.3 of [RFC5036] is updated to add the following two
statements under the description of "A, Label Advertisement
Discipline":
- Each document defining an LDP FEC must state the applicability of
the negotiated label advertisement discipline for label binding
advertisements for that FEC. If the negotiated label
advertisement discipline does not apply to the FEC, the document
must also explicitly state the discipline to be used for the FEC.
- This document defines the label advertisement discipline for the
following FEC types:
+----------+----------+--------------------------------+
| FEC Type | FEC Name | Label Advertisement Discipline |
+----------+----------+--------------------------------+
| 0x01 | Wildcard | Not applicable |
| 0x02 | Prefix | As negotiated (DU or DoD) |
+----------+----------+--------------------------------+
2.2. Specification for LDP FECs
The label advertisement discipline for currently defined LDP FEC
types is listed in Section 4.
This document updates the respective RFCs in which these FECs are
introduced and defined.
3. Security Considerations
This document only clarifies the applicability of an LDP session's
label advertisement mode and hence does not add any LDP security
mechanics and considerations to those already defined in the LDP
specification [RFC5036].
4. IANA Considerations
This document mandates the specification of a label advertisement
discipline for each defined FEC type and hence IANA's "Forwarding
Equivalence Class (FEC) Type Name Space" registry under IANA's "Label
Distribution Protocol (LDP) Parameters" registry has been extended as
follows:
- Added a new column titled "Label Advertisement Discipline" with
the following possible values:
o DU
o DoD
o As negotiated (DU or DoD)
o Upstream
o Not applicable
o Unknown
- Made this document an additional reference for the registry itself
and for all affected registrations.
- Kept other columns of the registry in place and populated as they
were.
For the currently assigned FEC types, the updated registry looks
like:
+=====+====+===============+==============+===========+============+
|Value|Hex | Name |Label | Reference |Notes/ |
| | | |Advertisement | |Registration|
| | | |Discipline | |Date |
+=====+====+===============+==============+===========+============+
| 0 |0x00|Reserved | | | |
+-----+----+---------------+--------------+-----------+------------+
| 1 |0x01|Wildcard |Not applicable| [RFC5036] | |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 2 |0x02|Prefix |As negotiated | [RFC5036] | |
| | | |(DU or DoD) | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 4 |0x04|CR-LSP |DoD | [RFC3212] | |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 5 |0x05|Typed Wildcard |Not applicable| [RFC5918] | |
| | |FEC Element | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 6 |0x06|P2MP |DU | [RFC6388] | |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 7 |0x07|MP2MP-up |DU | [RFC6388] | |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 8 |0x08|MP2MP-down |DU | [RFC6388] | |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 9 |0x09|HSMP-upstream |DU | [RFC7140] | 2014-01-09 |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 10 |0x0A|HSMP-downstream|DU, Upstream | [RFC7140] | 2014-01-09 |
| | | | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 128 |0x80|PWid |DU | [RFC4447] | |
| | |FEC Element | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 129 |0x81|Generalized |DU | [RFC4447] | |
| | |PWid | | [RFC7358] | |
| | |FEC Element | | | |
+-----+----+---------------+--------------+-----------+------------+
| 130 |0x82|P2MP PW |Upstream | [P2MP-PW] | 2009-06-03 |
| | |Upstream | | [RFC7358] | |
| | |FEC Element | | | |
+-----+----+---------------+--------------+-----------+------------+
+-----+----+---------------+--------------+-----------+------------+
| 131 |0x83|Protection |DU |[FAST-PROT]| 2010-02-26 |
| | |FEC Element | | [RFC7358] | |
+-----+----+---------------+--------------+-----------+------------+
| 132 |0x84|P2MP PW |DU | [P2MP-PW] | 2014-04-04 |
| | |Downstream | | [RFC7358] | |
| | |FEC Element | | | |
+-----+----+---------------+--------------+-----------+------------+
5. References
5.1. Normative References
[RFC3212] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R.,
Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette,
A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A.
Malis, "Constraint-Based LSP Setup using LDP", RFC 3212,
January 2002, <http://www.rfc-editor.org/info/rfc3212>.
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
G. Heron, "Pseudowire Setup and Maintenance Using the
Label Distribution Protocol (LDP)", RFC 4447, April 2006,
<http://www.rfc-editor.org/info/rfc4447>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, October 2007,
<http://www.rfc-editor.org/info/rfc5036>.
[RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution
Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
(FEC)", RFC 5918, August 2010,
<http://www.rfc-editor.org/info/rfc5918>.
[RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Thomas, "Label Distribution Protocol Extensions for
Point-to-Multipoint and Multipoint-to-Multipoint Label
Switched Paths", RFC 6388, November 2011,
<http://www.rfc-editor.org/info/rfc6388>.
[RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label
Assignment for LDP", RFC 6389, November 2011,
<http://www.rfc-editor.org/info/rfc6389>.
[RFC7140] Jin, L., Jounay, F., Wijnands, IJ., and N. Leymann, "LDP
Extensions for Hub and Spoke Multipoint Label Switched
Path", RFC 7140, March 2014,
<http://www.rfc-editor.org/info/rfc7140>.
5.2. Informative References
[FAST-PROT] Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang,
"PW Endpoint Fast Failure Protection", Work in Progress,
draft-ietf-pwe3-endpoint-fast-protection-01, July 2014.
[P2MP-PW] Sivabalan, S., Ed., Boutros, S., Ed., Martini, L.,
Konstantynowicz, M., Del Vecchio, G., Nadeau, T., Jounay,
F., Niger, P., Kamite, Y., Jin, L., Vigoureux, M.,
Ciavaglia, L., Delord, S., and K. Raza, "Signaling
Root-Initiated Point-to-Multipoint Pseudowire using LDP",
Work in Progress, draft-ietf-pwe3-p2mp-pw-04, March 2012.
Acknowledgments
We acknowledge Eric Rosen and Rajiv Asati for their initial review
and input on the document.
Authors' Addresses
Kamran Raza
Cisco Systems, Inc.
2000 Innovation Drive
Ottawa, ON K2K-3E8
Canada
EMail: skraza@cisco.com
Sami Boutros
Cisco Systems, Inc.
3750 Cisco Way
San Jose, CA 95134
United States
EMail: sboutros@cisco.com
Luca Martini
Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400
Englewood, CO 80112
United States
EMail: lmartini@cisco.com
Nicolai Leymann
Deutsche Telekom AG
Winterfeldtstrasse 21
Berlin 10781
Germany
EMail: N.Leymann@telekom.de
ISO Plain Language
On this page
§1Why the Negotiated Mode Is Only a Hint
The Label Distribution Protocol (LDP) (RFC 5036) allows label advertisement mode negotiation at the time of session establishment. The LDP specification also dictates that only a single label advertisement mode be negotiated, agreed upon, and used for a given LDP session between two Label Switching Routers (LSRs).
RFC 7358 explains that the negotiated mode defined in RFC 5036 and carried in the LDP Initialization message is only indicative. It indicates how the LDP speakers on a session will advertise labels for some Forwarding Equivalence Classes (FECs), but it is not a rule that restricts the speakers to behave in a specific way. For some FEC types, the advertising behavior of the LDP speaker is governed by the FEC type and not by the negotiated behavior.
The document updates RFC 5036 to make that fact clear. It also updates RFC 3212, RFC 4447, RFC 5918, RFC 6388 and RFC 7140 by specifying, for each FEC type that has already been defined, whether the label binding advertisements for that FEC are constrained by the negotiated label advertisement mode or not. It also specifies the label advertisement mode to be used for all currently defined FECs.
Two routers agree on one way of handing out labels when they start a session. That agreement does not settle everything, because some kinds of traffic always behave in a fixed way. This document says which is which.
| Aspect | Before this document | After this document |
|---|---|---|
| The negotiated label advertisement mode | A single mode is negotiated, agreed upon and used for the session | Indicative only; it is not a rule that restricts the speakers to behave in a specific way |
| Where the advertising behavior comes from | The negotiated mode of the LDP session | For some FEC types the FEC type governs the behavior, not the negotiated mode |
§2The Six Label Advertisement Disciplines
To remove any ambiguity and conflict regarding a label advertisement discipline among different FEC types sharing a common LDP session, the document introduces a set of types for specifying the label advertisement discipline of a FEC type.
There are six. DU stands for Downstream Unsolicited, DoD for Downstream on Demand, and As negotiated (DU or DoD) for the cases where the mode agreed for the session applies. Upstream refers to upstream label assignment, as defined in RFC 6389. Not applicable covers a FEC type for which the negotiated discipline does not apply, and Unknown covers a FEC type whose discipline has not been stated.
The document defines these six as the vocabulary for stating a discipline. The behavior behind each FEC type itself comes from the RFC that defines that FEC type, which is recorded as the reference for that entry in the registry.
Every kind of traffic now has to be given one of six labels describing how its labels are offered. Some follow what the two routers agreed. Others have a fixed rule, such as only offering labels when asked, or offering them whether asked or not.
- One mode per sessionRFC 5036 dictates that a single label advertisement mode is negotiated, agreed upon and used for a session.
- The mode is indicativeThe mode in the Initialization message indicates how labels are advertised, but does not restrict the speakers.
- The type can decideFor some FEC types the advertising behavior is governed by the FEC type, not by the negotiated mode.
- Every FEC document must state itEach document defining an LDP FEC must say whether the negotiated discipline applies and, if not, which discipline to use.
- Six possible valuesDU, DoD, As negotiated (DU or DoD), Upstream, Not applicable and Unknown.
- The registry grew a columnThe IANA FEC Type Name Space registry now carries the discipline for each assigned type.
§2.1The Update to RFC 5036
Section 3.5.3 of RFC 5036 is updated with two added statements under the description of A, Label Advertisement Discipline.
The first says that each document defining an LDP FEC must state the applicability of the negotiated label advertisement discipline for the label binding advertisements for that FEC. If the negotiated label advertisement discipline does not apply to the FEC, the document must also explicitly state the discipline to be used for the FEC. The second statement gives the discipline for two FEC types: the Wildcard FEC, type 0x01, is Not applicable, and the Prefix FEC, type 0x02, is As negotiated, that is DU or DoD.
The rule for future FEC definitions is therefore short: say whether the negotiated discipline applies, and if it does not, say which discipline to use instead.
The main LDP specification now requires every document that defines a new kind of traffic to state which rule applies to it, and to name a different rule when the session's agreement does not apply.
§2.2The Discipline for Each FEC Type
The label advertisement discipline for the currently defined LDP FEC types is listed in the registry reproduced in the next section, and the document updates the respective RFCs in which those FECs are introduced and defined.
Reading the list, the Wildcard FEC and the Typed Wildcard FEC Element are Not applicable, since the negotiated discipline does not apply to them. The Prefix FEC follows the negotiated mode. The CR-LSP FEC is Downstream on Demand. The point-to-multipoint and multipoint-to-multipoint FECs, the hub-and-spoke FECs, the pseudowire FEC elements and the protection FEC element are Downstream Unsolicited, with the downstream half of the hub-and-spoke FEC also allowing Upstream. The two point-to-multipoint pseudowire FEC elements are Upstream and Downstream Unsolicited respectively.
The list assigns a rule to each kind of traffic. Prefix traffic follows what the routers agreed. Traffic for a constraint-based path is labelled only when asked. Most multicast traffic is labelled whether asked or not.
- 0x01Wildcard — Not applicable.
- 0x02Prefix — As negotiated (DU or DoD).
- 0x04CR-LSP — DoD.
- 0x05Typed Wildcard FEC Element — Not applicable.
- 0x06P2MP — DU.
- 0x07MP2MP-up — DU.
- 0x08MP2MP-down — DU.
- 0x09HSMP-upstream — DU.
- 0x0AHSMP-downstream — DU, Upstream.
- 0x80PWid FEC Element — DU.
- 0x81Generalized PWid FEC Element — DU.
- 0x82P2MP PW Upstream FEC Element — Upstream.
- 0x83Protection FEC Element — DU.
- 0x84P2MP PW Downstream FEC Element — DU.
§4The Updated IANA Registry
The document mandates the specification of a label advertisement discipline for each defined FEC type, so the IANA Forwarding Equivalence Class (FEC) Type Name Space registry, under the Label Distribution Protocol (LDP) Parameters registry, has been extended. A new column titled Label Advertisement Discipline was added, with the possible values DU, DoD, As negotiated (DU or DoD), Upstream, Not applicable and Unknown. This document was made an additional reference for the registry itself and for all affected registrations, and the other columns were kept in place and populated as they were.
The updated registry lists the FEC types already assigned: 0x01 Wildcard, 0x02 Prefix, 0x04 CR-LSP, 0x05 Typed Wildcard FEC Element, 0x06 P2MP, 0x07 MP2MP-up, 0x08 MP2MP-down, 0x09 HSMP-upstream, 0x0A HSMP-downstream, 0x80 PWid FEC Element, 0x81 Generalized PWid FEC Element, 0x82 P2MP PW Upstream FEC Element, 0x83 Protection FEC Element and 0x84 P2MP PW Downstream FEC Element. Value 0 is reserved.
The official list of traffic kinds gained a column showing the rule for each one, and this document is now cited as the source for that column.
§3Security Considerations
This document only clarifies the applicability of an LDP session's label advertisement mode. It therefore adds no LDP security mechanics and no new considerations to those already defined in the LDP specification (RFC 5036).
The document changes no security behavior. It only says which rule applies, so the security considerations stay exactly as they were in the main LDP specification.