draft-ietf-mpls-ldp-applicability-label-adv-03.txt   rfc7358.txt 
MPLS Working Group Kamran Raza
Internet Draft Sami Boutros
Updates: 3212, 4447, 5036, 5918, 6388, 7140 Luca Martini
Intended status: Standards Track Cisco Systems, Inc.
Expires: October 01, 2014
Nicolai Leymann
Deutsche Telekom
April 02, 2014
Label Advertisement Discipline for LDP FECs 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
draft-ietf-mpls-ldp-applicability-label-adv-03.txt Label Advertisement Discipline
for LDP Forwarding Equivalence Classes (FECs)
Abstract Abstract
The label advertising behavior of an LDP speaker for a given FEC is The label advertising behavior of an LDP speaker for a given
governed by the FEC type and not necessarily by the LDP session's Forwarding Equivalence Class (FEC) is governed by the FEC type and
negotiated label advertisement mode. This document updates RFC 5036 not necessarily by the LDP session's negotiated label advertisement
to make that fact clear, as well as updates RFC 3212, RFC 4447, RFC mode. This document updates RFC 5036 to make that fact clear. It
5918, RFC 6388, and RFC 7140 by specifying the label advertisement also updates RFCs 3212, 4447, 5918, 6388, and 7140 by specifying the
mode for all currently defined LDP FEC types. label advertisement mode for all currently defined LDP FEC types.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Status of This Memo
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This is an Internet Standards Track document.
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/shadow.html (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.
This Internet-Draft will expire on October 01, 2014. 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 Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction 2 1. Introduction ....................................................2
2. Label Advertisement Discipline 3 2. Label Advertisement Discipline ..................................3
2.1. Update to RFC-5036 3 2.1. Update to RFC 5036 .........................................3
2.2. Specification for LDP FECs 4 2.2. Specification for LDP FECs .................................4
3. Security Considerations 4 3. Security Considerations .........................................4
4. IANA Considerations 5 4. IANA Considerations .............................................4
5. References 7 5. References ......................................................6
5.1. Normative References 7 5.1. Normative References .......................................6
5.2. Informative References 7 5.2. Informative References .....................................7
6. Acknowledgments 8 Acknowledgments ....................................................8
Authors' Addresses .................................................8
1. Introduction 1. Introduction
Label Distribution Protocol (LDP) [RFC5036] allows label The Label Distribution Protocol (LDP) [RFC5036] allows label
advertisement mode negotiation at the time of session establishment. advertisement mode negotiation at the time of session establishment.
LDP specification also dictates that only single label advertisement The LDP specification also dictates that only a single label
mode is negotiated, agreed and used for a given LDP session between advertisement mode be negotiated, agreed upon, and used for a given
two LSRs. LDP session between two Label Switching Routers (LSRs).
The negotiated label advertisement mode defined in RFC 5036 and The negotiated label advertisement mode defined in RFC 5036 and
carried in the LDP Initialization message is only indicative. It carried in the LDP Initialization message is only indicative. It
indicates how the LDP speakers on a session will advertise labels for indicates how the LDP speakers on a session will advertise labels for
some FECs, but it is not a rule that restricts the speakers to behave some Forwarding Equivalence Classes (FECs), but it is not a rule that
in a specific way. Furthermore, for some FEC types the advertising restricts the speakers to behave in a specific way. Furthermore, for
behavior of the LDP speaker is governed by the FEC type and not by some FEC types the advertising behavior of the LDP speaker is
the negotiated behavior. governed by the FEC type and not by the negotiated behavior.
This document updates [RFC5036] to make that fact clear, as well as This document updates [RFC5036] to make that fact clear. It also
updates [RFC3212], [RFC4447], [RFC5918], [RFC6388], and [RFC7140] to updates [RFC3212], [RFC4447], [RFC5918], [RFC6388], and [RFC7140] to
indicate for each FEC type that has already been defined whether the indicate, for each FEC type that has already been defined, whether
label binding advertisements for the FEC are constrained by the the label binding advertisements for the FEC are constrained by the
negotiated label advertisement mode or not. Furthermore, this negotiated label advertisement mode or not. Furthermore, this
document specifies the label advertisement mode to be used for all document specifies the label advertisement mode to be used for all
currently defined FECs. currently defined FECs.
2. Label Advertisement Discipline 2. Label Advertisement Discipline
To remove any ambiguity and conflict regarding label advertisement To remove any ambiguity and conflict regarding a label advertisement
discipline amongst different FEC types sharing a common LDP session, discipline among different FEC types sharing a common LDP session,
this document specifies a label advertisement disciplines for FEC this document specifies a label advertisement discipline for FEC
types. types.
This document introduces following types for specifying a label This document introduces the following types for specifying a label
advertisement discipline for a FEC type: advertisement discipline for a FEC type:
- DU (Downstream Unsolicited) - DU (Downstream Unsolicited)
- DoD (Downstream On Demand) - DoD (Downstream on Demand)
- As negotiated (DU or DoD) - As negotiated (DU or DoD)
- Upstream ([RFC6389]) - Upstream ([RFC6389])
- Not Applicable - Not applicable
- Unknown - Unknown
2.1. Update to RFC-5036 2.1. Update to RFC 5036
The section 3.5.3 of [RFC5036] is updated to add following two Section 3.5.3 of [RFC5036] is updated to add the following two
statements under the description of "A, Label Advertisement statements under the description of "A, Label Advertisement
Discipline": Discipline":
- Each document defining an LDP FEC must state the applicability - Each document defining an LDP FEC must state the applicability of
of the negotiated label advertisement discipline for label the negotiated label advertisement discipline for label binding
binding advertisements for that FEC. If the negotiated label advertisements for that FEC. If the negotiated label
advertisement discipline does not apply to the FEC, the advertisement discipline does not apply to the FEC, the document
document must also explicitly state the discipline to be used must also explicitly state the discipline to be used for the FEC.
for the FEC.
- This document defines the label advertisement discipline for
the following FEC types:
+----------+----------+--------------------------------+ - This document defines the label advertisement discipline for the
| FEC Type | FEC Name | Label advertisement discipline | following FEC types:
+----------+----------+--------------------------------+
| 0x01 | Wildcard | Not applicable |
| 0x02 | Prefix | As negotiated (DU or DoD) |
+----------+----------+--------------------------------+
2.2. Specification for LDP FECs +----------+----------+--------------------------------+
| FEC Type | FEC Name | Label Advertisement Discipline |
+----------+----------+--------------------------------+
| 0x01 | Wildcard | Not applicable |
| 0x02 | Prefix | As negotiated (DU or DoD) |
+----------+----------+--------------------------------+
Following is the specification of label advertisement disciplines to 2.2. Specification for LDP FECs
be used for currently defined LDP FEC types.
FEC FEC Label advertisement Notes The label advertisement discipline for currently defined LDP FEC
Type Name discipline types is listed in Section 4.
---- ---------------- ------------------- ----------------------
0x01 Wildcard Not applicable
0x02 Prefix As negotiated
(DU or DoD)
0x04 CR-LSP DoD
0x05 Typed Wildcard Not applicable
0x06 P2MP DU
0x07 MP2MP-up DU
0x08 MP2MP-down DU
0x09 HSMP-upstream DU
0x10 HSMP-downstream DU, Upstream [RFC7140] Section 4
0x80 PWid DU
0x81 Gen. PWid DU
0x82 P2MP PW Upstream Upstream [ID.pwe3-p2mp-pw]
0x84 P2MP PW Downstream DU [ID.pwe3-p2mp-pw]
0x83 Protection DU [ID.pwe3-endpoint-
fast-protection]
This document updates the RFCs in which above FECs are defined. This document updates the respective RFCs in which these FECs are
introduced and defined.
3. Security Considerations 3. Security Considerations
This document specification only clarifies the applicability of LDP This document only clarifies the applicability of an LDP session's
session's label advertisement mode, and hence does not add any LDP label advertisement mode and hence does not add any LDP security
security mechanics and considerations to those already defined in mechanics and considerations to those already defined in the LDP
the LDP specification [RFC5036]. specification [RFC5036].
4. IANA Considerations 4. IANA Considerations
This document mandates the specification of a label advertisement This document mandates the specification of a label advertisement
discipline for each defined FEC type, and hence extends IANA's discipline for each defined FEC type and hence IANA's "Forwarding
"Forwarding Equivalence Class (FEC) Type Name Space" registry under Equivalence Class (FEC) Type Name Space" registry under IANA's "Label
IANA's "Label Distribution Protocol (LDP) Parameters" as follows: Distribution Protocol (LDP) Parameters" registry has been extended as
follows:
- Add a new column titled "Label Advertisement Discipline" with - Added a new column titled "Label Advertisement Discipline" with
following possible values: the following possible values:
o DU
o DoD
o As negotiated (DU or DoD)
o Upstream
o Not applicable
o Unknown
- For the existing FEC types, populate this column with the o DU
values listed under section 2.2. o DoD
o As negotiated (DU or DoD)
o Upstream
o Not applicable
o Unknown
- Keep all other columns of the registry in place and populated - Made this document an additional reference for the registry itself
as currently. and for all affected registrations.
For the currently assigned FEC types, the updated registry looks - Kept other columns of the registry in place and populated as they
like: were.
+=====+====+===============+==============+=========+============+ For the currently assigned FEC types, the updated registry looks
|Value|Hex | Name |Label |Reference|Notes/ | like:
| | | |Advertisement | |Registration|
| | | |Discipline | |Date |
+=====+====+===============+==============+=========+============+
| 0 |0x00|Reserved | | | |
+-----+----+---------------+--------------+---------+------------+
| 1 |0x01|Wildcard |Not applicable|[RFC5036]| |
| | | | |[thisRFC]| |
+-----+----+---------------+--------------+---------+------------+
| 2 |0x02|Prefix |As negotiated |[RFC5036]| |
| | | |(DU or DoD) |[thisRFC]| |
+-----+----+---------------+--------------+---------+------------+
| 4 |0x04|CR-LSP |DoD |[RFC3212]| |
| | | | |[thisRFC]| |
+-----+----+---------------+--------------+---------+------------+
+-----+----+---------------+--------------+---------+------------+
| 5 |0x05|Typed Wildcard |Not applicable|[RFC5918]| |
| | |FEC Element | |[thisRFC]| |
+-----+----+---------------+--------------+---------+------------+
| 6 |0x06|P2MP |DU |[RFC6388]| |
| | | | |[thisRFC]| |
+-----+----+---------------+--------------+---------+------------+
| 7 |0x07|MP2MP-up |DU |[RFC6388]| |
| | | | |[thisRFC]| |
+-----+----+---------------+--------------+---------+------------+
| 8 |0x08|MP2MP-down |DU |[RFC6388]| |
| | | | |[thisRFC]| |
+-----+----+---------------+--------------+---------+------------+
| 9 |0x09|HSMP-upstream |DU |[RFC7140]| |
| | | | |[thisRFC]| |
+-----+----+---------------+--------------+---------+------------+
| 10 |0x0A|HSMP-downstream|DU, Upstream |[RFC7140]| |
| | | | |[thisRFC]| |
+-----+----+---------------+--------------+---------+------------+
| 128 |0x80|PWid |DU |[RFC4447]| |
| | |FEC Element | |[thisRFC]| |
+-----+----+---------------+--------------+---------+------------+
| 129 |0x81|Generalized |DU |[RFC4447]| |
| | |PWid | |[thisRFC]| |
| | |FEC Element | | | |
+-----+----+---------------+--------------+---------+------------+
| 130 |0x82|P2MP PW |Upstream |[draft- | |
| | |Upstream | |ietf-pwe3| |
| | |FEC Element | |-p2mp-pw]| |
| | | | |[thisRFC]| |
+-----+----+---------------+--------------+---------+------------+
| 131 |0x83|Protection |DU |[draft-ietf| |
| | |FEC Element | |-pwe3-end | |
| | | | |point-fast | |
| | | | |protection]| |
| | | | |[thisRFC] | |
+-----+----+---------------+--------------+---------+------------+
| 132 |0x84|P2MP PW |DU |[draft- | |
| | |Downstream | |ietf-pwe3| |
| | |FEC Element | |-p2mp-pw]| |
| | | | |[thisRFC]| |
+-----+----+---------------+--------------+---------+------------+
5. References +=====+====+===============+==============+===========+============+
|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.1. Normative References 5. References
[RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP 5.1. Normative References
Specification", RFC 5036, September 2007.
[RFC3212] B. Jamoussi, et al., "Constraint-Based LSP Setup using [RFC3212] Jamoussi, B., Ed., Andersson, L., Callon, R., Dantu, R.,
LDP", RFC 3212, January 2002 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] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and
Heron, "Pseudowire Setup and Maintenance using the Label G. Heron, "Pseudowire Setup and Maintenance Using the
Distribution Protocol", RFC 4447, April 2006. Label Distribution Protocol (LDP)", RFC 4447, April 2006,
<http://www.rfc-editor.org/info/rfc4447>.
[RFC5918] R. Asati, I. Minei, and B. Thomas, "Label Distribution [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
Protocol Typed Wildcard FEC", RFC 5918, August 2010. "LDP Specification", RFC 5036, October 2007,
<http://www.rfc-editor.org/info/rfc5036>.
[RFC6388] I. Minei, I. Wijnands, K. Kompella, and B. Thomas, "LDP [RFC5918] Asati, R., Minei, I., and B. Thomas, "Label Distribution
Extensions for P2MP and MP2MP LSPs", RFC 6388, November Protocol (LDP) 'Typed Wildcard' Forward Equivalence Class
2011. (FEC)", RFC 5918, August 2010,
<http://www.rfc-editor.org/info/rfc5918>.
[RFC6389] R. Aggarwal, and JL. Le Roux, "MPLS Upstream Label [RFC6388] Wijnands, IJ., Ed., Minei, I., Ed., Kompella, K., and B.
Assignment for LDP", RFC 6389, November 2011. 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>.
[RFC7140] L. Jin, F. Jounay, I. Wijnands , and N. Leymann, "LDP [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label
Extensions for Hub and Spoke Multipoint Label Switched Assignment for LDP", RFC 6389, November 2011,
Path", RFC 7140, March 2014. <http://www.rfc-editor.org/info/rfc6389>.
[ID.pwe3-p2mp-pw] S. Sivabalan et al., "Signaling Root-Initiated [RFC7140] Jin, L., Jounay, F., Wijnands, IJ., and N. Leymann, "LDP
Point-to-Multipoint PseudoWire using LDP", draft-ietf- Extensions for Hub and Spoke Multipoint Label Switched
pwe3-p2mp-pw-04, Work in progress, March 2012. Path", RFC 7140, March 2014,
<http://www.rfc-editor.org/info/rfc7140>.
[ID.pwe3-endpoint-fast-protection] Y. Shen, R. Aggarwal, W. 5.2. Informative References
Henderickx, and Y. Jiang, "PW Endpoint Fast Failure
Protection", draft-ietf-pwe3-endpoint-fast-protection-00,
Work in progress, December 2013.
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.
None. [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.
6. Acknowledgments Acknowledgments
We acknowledge Eric Rosen and Rajiv Asati for their initial review We acknowledge Eric Rosen and Rajiv Asati for their initial review
and input on the document. and input on the document.
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses Authors' Addresses
Kamran Raza Kamran Raza
Cisco Systems, Inc. Cisco Systems, Inc.
2000 Innovation Drive, 2000 Innovation Drive
Ottawa, ON K2K-3E8, Canada. Ottawa, ON K2K-3E8
E-mail: skraza@cisco.com Canada
Sami Boutros EMail: skraza@cisco.com
Cisco Systems, Inc.
3750 Cisco Way,
San Jose, CA 95134, USA.
E-mail: sboutros@cisco.com
Luca Martini Sami Boutros
Cisco Systems, Inc. Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400, 3750 Cisco Way
Englewood, CO 80112, USA. San Jose, CA 95134
E-mail: lmartini@cisco.com United States
Nicolai Leymann EMail: sboutros@cisco.com
Deutsche Telekom AG,
Winterfeldtstrasse 21, Luca Martini
Berlin 10781, Germany. Cisco Systems, Inc.
E-mail: N.Leymann@telekom.de 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
 End of changes. 55 change blocks. 
252 lines changed or deleted 224 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/