< draft-raza-mpls-ldp-applicability-label-adv-01.txt   draft-raza-mpls-ldp-applicability-label-adv-02.txt >
Network Working Group Kamran Raza MPLS Working Group Kamran Raza
Internet Draft Sami Boutros Internet Draft Sami Boutros
Updates: 5036, 4447 (if approved) Luca Martini Updates: 5036, 4447 (if approved) Luca Martini
Intended status: Standards Track Cisco Systems, Inc. Intended status: Standards Track Cisco Systems, Inc.
Expires: January 10, 2012 Expires: July 12, 2012
Nicolai Leymann Nicolai Leymann
Deutsche Telekom Deutsche Telekom
July 11, 2011 January 13, 2012
Applicability of LDP Label Advertisement Mode Applicability of LDP Label Advertisement Mode
draft-raza-mpls-ldp-applicability-label-adv-01.txt draft-raza-mpls-ldp-applicability-label-adv-02.txt
Abstract Abstract
An LDP speaker negotiates the label advertisement mode with its LDP An LDP speaker negotiates the label advertisement mode with its LDP
peer at the time of session establishment. Although different peer at the time of session establishment. Although different
applications sharing the same LDP session may need different modes applications sharing the same LDP session may need different modes
of label distribution and advertisement, there is only one type of of label distribution and advertisement, there is only one type of
label advertisement mode that is negotiated and used per LDP label advertisement mode that is negotiated and used per LDP
session. This document clarifies the use and the applicability of session. This document clarifies the use and the applicability of
session's negotiated label advertisement mode, and categorizes LDP session's negotiated label advertisement mode, and categorizes LDP
applications into two broad categories of negotiated mode-bound and applications into two broad categories of negotiated mode-bound and
mode-independent applications. This document proposal and mode-independent applications. The document also suggests an update
clarification thus updates [RFC5036] and [RFC4447]. to RFC5036 and RFC4447 to remove any ambiguity and conflict in the
area of using correct label advertisement mode for a given
application.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 46 skipping to change at page 2, line 4
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 10, 2012. This Internet-Draft will expire on July 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction 3 1. Introduction ................................................... 3
2. Conventions used in this document 3 2. Conventions used in this document .............................. 3
3. Label Advertisement Mode Applicability 4 3. Label Advertisement Mode Applicability ......................... 4
3.1. Label Advertisement Mode Negotiation 4 3.1. Label Advertisement Mode Negotiation ...................... 4
3.2. LDP Applications Categorization 4 3.2. Mode-based Categorization of LDP Applications ............. 4
3.2.1. Session mode-bound Applications 5 3.2.1. Session mode-bound Applications .................... 5
3.2.2. Session mode-independent Applications 5 3.2.2. Session mode-independent Applications .............. 5
3.3. Update to RFC-5036 6 4. Clarification on Mode Applicability ............................ 6
3.4. Update to RFC-4447 6 4.1. Update to RFC-5036 ........................................ 6
4. Future Work 6 4.2. Update to RFC-4447 ........................................ 6
5. Security Considerations 6 5. Future Work .................................................... 7
6. IANA Considerations 7 6. Security Considerations ........................................ 7
7. References 7 7. IANA Considerations ............................................ 7
7.1. Normative References 7 8. References ..................................................... 7
7.2. Informative References 7 8.1. Normative References ...................................... 7
8. Acknowledgments 7 8.2. Informative References .................................... 7
9. Acknowledgments ................................................ 8
1. Introduction 1. Introduction
The MPLS architecture [RFC3031] defines two modes of label The MPLS architecture [RFC3031] defines two modes of label
advertisement for an LSR: advertisement for an LSR:
1. Downstream-on-Demand 1. Downstream-on-Demand
2. Unsolicited Downstream 2. Unsolicited Downstream
The "Downstream-on-Demand" mode requires an LSR to explicitly The "Downstream-on-Demand" mode requires an LSR to explicitly
request the label binding for FECs from its peer, whereas request the label binding for FECs from its peer, whereas
"Unsolicited Downstream" mode allows an LSR to distribute the label "Unsolicited Downstream" mode allows an LSR to distribute the label
binding for FECs unsolicitedly to LSR peers that have not explicitly binding for FECs unsolicitedly to LSR peers that have not explicitly
requested them. The MPLS architecture [RFC3031] also specifies that requested them. The MPLS architecture also specifies that on any
on any given label distribution adjacency, the upstream LSR and the given label distribution adjacency, the upstream LSR and the
downstream LSR must agree to using a single label advertisement downstream LSR must agree to using a single label advertisement
mode. mode.
Label Distribution Protocol (LDP) [RFC5036] allows label Label Distribution Protocol (LDP) [RFC5036] allows label
advertisement mode negotiation at the session establishment time advertisement mode negotiation at the session establishment time
(section 3.5.3 [RFC5036]). To comply with MPLS architecture, LDP (section 3.5.3 [RFC5036]). To comply with MPLS architecture, LDP
specification also dictates that only one label advertisement mode specification also dictates that only single label advertisement
is agreed and used on a given LDP session between two LSRs. mode is agreed and used on a given LDP session between two LSRs.
With the advent of new applications, such as L2VPN [RFC4447], mLDP With the advent of new LDP applications, such as L2VPN [RFC4447],
[MLDP], ICCP [ICCP], running on top of LDP, there are situations mLDP [RFC6388], ICCP [ICCP], there are situations when an LDP
when an LDP session is shared across more than one application to session is shared across more than one application to exchange label
exchange label bindings for different type of FECs. Although bindings for different types of FEC. Although different applications
different applications sharing the same LDP session may need sharing the same LDP session may need a different type of label
different type of label advertisement mode negotiated, there is only advertisement mode negotiated, there is only one type of label
one type of label advertisement mode that is negotiated and agreed advertisement mode that is negotiated and agreed at the time of
at the time of establishment of LDP session. establishment of LDP session.
This document clarifies the use and the applicability of session's This document clarifies the use and the applicability of session's
label advertisement mode for each application using the session. It label advertisement mode for each application using the session. It
also categorizes LDP applications into two broad categories of also categorizes LDP applications into two broad categories of mode-
negotiated mode-bound and mode-independent applications. This bound and mode-independent applications.
document proposal and clarification thus updates [RFC5036] and
[RFC4447]. The document also suggests an update to RFC-5036 and RFC-4447 to
remove any ambiguity and conflict in the area of using correct label
advertisement mode for a given LDP application.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC-2119 [RFC2119].
The unqualified term "mode" used in document refers to "label The unqualified term "mode" used in document refers to "label
advertisement mode". advertisement mode".
Please also note that LDP specification [RFC5036] uses the term Please also note that LDP specification [RFC5036] uses the term
"Downstream Unsolicited" to refer to "Unsolicited Downstream", as "Downstream Unsolicited" to refer to "Unsolicited Downstream". The
well as uses the terms "label distribution" and "label LDP specification also uses the terms "label distribution mode" and
advertisement" interchangeably. This document also uses these "label advertisement mode" interchangeably. Like LDP specification
terms interchangeably. document, this document also uses these terms interchangeably.
3. Label Advertisement Mode Applicability 3. Label Advertisement Mode Applicability
3.1. Label Advertisement Mode Negotiation 3.1. Label Advertisement Mode Negotiation
Label advertisement mode is negotiated between participating LSR Label advertisement mode is negotiated between LSR peers at the time
peers at the time of session establishment. The label advertisement of session establishment. The label advertisement mode is specified
mode is specified in LDP Initialization message's "Common Session in LDP Initialization message's "Common Session Parameter" TLV by
Parameter" TLV by setting A-bit (Label Advertisement Discipline bit) setting A-bit (Label Advertisement Discipline bit) to 1 or 0 for
to 1 or 0 for Downstream-on-Demand or Downstream-Unsolicited modes Downstream-on-Demand or Downstream-Unsolicited modes respectively.
respectively [RFC5036]. The negotiation of the A-bit is specified in The negotiation of the A-bit is specified in section 3.5.3 of
section 3.5.3 of [RFC5036] as follows: [RFC5036] as follows:
"If one LSR proposes Downstream Unsolicited and the other proposes "If one LSR proposes Downstream Unsolicited and the other proposes
Downstream on Demand, the rules for resolving this difference is: Downstream on Demand, the rules for resolving this difference is:
- If the session is for a label-controlled ATM link or a label- - If the session is for a label-controlled ATM link or a
controlled Frame Relay link, then Downstream on Demand MUST be label- controlled Frame Relay link, then Downstream on Demand
used. MUST be used.
- Otherwise, Downstream Unsolicited MUST be used." - Otherwise, Downstream Unsolicited MUST be used."
Once label advertisement mode has been negotiated and agreed, both Once label advertisement mode has been negotiated and agreed, both
LSRs must use the same mode for label binding exchange. LSR peers must use the same mode for label binding exchange.
3.2. LDP Applications Categorization 3.2. Mode-based Categorization of LDP Applications
At the time of standardization of LDP base specification RFC-3036, The earlier applications, defined and identified at the time of
the earlier applications using LDP to exchange their FEC bindings standardization of LDP base specification RFC-3036, using LDP to
were: exchange their FEC bindings were:
. Dynamic Label Switching for IP Prefixes . Dynamic Label Switching for IP Prefixes
. Label-controlled ATM/FR . Label-controlled ATM/FR
Since then, several new applications have emerged that use LDP to Since then, several new applications have emerged that use LDP to
signal their FEC bindings and/or application data: signal their FEC bindings and/or application data. These include:
. L2VPN P2P PW ([RFC4447]) . L2VPN P2P PW ([RFC4447])
. L2VPN P2MP PW ([P2MP-PW]) . L2VPN P2MP PW ([P2MP-PW])
. mLDP ([MLDP]) . mLDP ([RFC6388])
. ICCP ([ICCP]) . ICCP ([ICCP])
We divide these LDP applications into two broad categories from We divide the LDP applications into two broad categories from label
label advertisement mode usage point of view: advertisement mode usage point of view:
1. Session mode-bound Applications (i.e. use the negotiated label 1. Session mode-bound Applications
advertisement mode)
2. Session mode-independent Applications (i.e. do not care about the 2. Session mode-independent Applications
negotiated label advertisement mode)
3.2.1. Session mode-bound Applications 3.2.1. Session mode-bound Applications
The FEC label binding exchange for such LDP applications MUST use the We define a "session mode-bound application" to be an application
negotiated label advertisement mode. which uses the negotiated label advertisement mode. This means that
the FEC-label binding exchange for such an LDP applications MUST use
the label advertisement mode negotiated for the LDP session.
The early LDP applications "Dynamic Label Switching for IP Prefixes" The early LDP applications "Dynamic Label Switching for IP Prefixes"
and "Label-controlled ATM/FR" fall into this category. and "Label-controlled ATM/FR" fall into this category.
3.2.2. Session mode-independent Applications 3.2.2. Session mode-independent Applications
The FEC label binding, or any other application data, exchange for We define a "session mode-independent application" to be an
such LDP applications does not care about, nor tied to the application which does not care about the negotiated label
negotiated label advertisement mode of the session; rather, the advertisement mode. This means that the FEC-label binding, or any
information exchange is driven by the application need and other application data, exchange for such an LDP application does
procedures as described by their respective specifications. For not care about, nor tied to the "negotiated" label advertisement
example, [MLDP] specifies procedures to advertise P2MP FEC label mode of the session; rather, the information exchange is driven by
binding in an unsolicited manner, irrespective of the negotiated the application need and procedures as described by its
label advertisement mode of the session. specification document. For example, [RFC6388] specifies procedures
to advertise P2MP FEC label binding in an unsolicited manner,
irrespective of the negotiated label advertisement mode of the
session.
The applications, PW (P2P and P2MP), MLDP, and ICCP, fall into this The applications, PW (P2P and P2MP), MLDP, and ICCP, fall into this
category of LDP application. category of LDP application.
3.2.2.1. Upstream Label Assignment 3.2.2.1. Upstream Label Assignment
As opposed to downstream assigned label advertisement defined by As opposed to downstream assigned label advertisement defined by
[RFC3031], [LDP-UPSTREAM] specification defines new mode of label [RFC3031], [RFC6389] specification defines new mode of label
advertisement where label advertisement and distribution occurs for advertisement where label advertisement and distribution occurs for
upstream assigned labels. upstream assigned labels.
As stated in earlier section 3.1 of this document, [RFC5036] only As stated in earlier section 3.1 of this document, LDP base
allows specifying Downstream-Unsolicited or Downstream-on-Demand specification RFC-5036 only allows specifying Downstream-Unsolicited
mode. This means that any LDP application that requires upstream or Downstream-on-Demand mode. This means that any LDP application
assigned label advertisement also falls under the category of Session that requires upstream assigned label advertisement also falls under
mode-independent application. the category of Session mode-independent application.
3.3. Update to RFC-5036 4. Clarification on Mode Applicability
For clarification reasons, section 3.5.3 of [RFC5036] is updated to To remove any ambiguity and conflict amongst different
add following two statements under the description of "A, Label specifications with regards to the use of LDP session's label
Advertisement Discipline": advertisement mode, we propose an update to LDP base specification
RFC-5036 to clarify the applicability of session's negotiated mode.
Furthermore, RFC-4447 specifies LDP extensions and procedures to
exchange label bindings for P2P PW FECs [RFC4447], and dictates the
use of Downstream-Unsolicited mode for an LDP session related to
L2VPN PW. This mode dictation creates a direct conflict in
situations when a PW LDP session is shared with an LDP application
with Downstream-on-Demand mode (such as Label switching Application
for IP prefixes). To remove such a conflict, we also propose an
update to a section of RFC-4447.
4.1. Update to RFC-5036
The section 3.5.3 of [RFC5036] is updated to add following two
statements under the description of "A, Label Advertisement
Discipline":
- The negotiated label advertisement discipline only applies to FEC - The negotiated label advertisement discipline only applies to FEC
label binding advertisement of "Address Prefix" FECs; label binding advertisement of "Address Prefix" FECs;
- Any document specifying a new FEC SHOULD state the applicability - Any document specifying a new FEC SHOULD state the applicability
of the negotiated label advertisement discipline for that FEC. of the negotiated label advertisement discipline for that FEC.
3.4. Update to RFC-4447 4.2. Update to RFC-4447
[RFC4447] specifies LDP extensions and procedures to exchange label The section 3 of [RFC4447] states:
bindings for P2P PW FECs. The section 3 of [RFC4447] states:
"LDP MUST be used in its downstream unsolicited mode." "LDP MUST be used in its downstream unsolicited mode."
Since PW application falls under session mode-independent Since PW application falls under session mode-independent
application category, the above statement in [RFC4447] should be application category, the above statement in [RFC4447] should be
read to mean as follows: read to mean as follows:
"LDP MUST exchange PW FEC label bindings in downstream unsolicited "LDP MUST exchange PW FEC label bindings in downstream unsolicited
manner, independent of the negotiated label advertisement mode of manner, independent of the negotiated label advertisement mode of
the LDP session." the LDP session".
4. Future Work 5. Future Work
This document only clarifies the existing behavior for LDP label This document only clarifies the existing behavior for LDP label
advertisement mode for different applications without defining any advertisement mode for different applications without defining any
protocol extensions. In future, a new LDP capability [RFC5561] based protocol extensions. In future, a new LDP capability [RFC5561] based
mechanism can be defined to signal/negotiate label advertisement mechanism can also be defined to signal/negotiate label
mode per FEC/application. advertisement mode per FEC/application.
5. Security Considerations Moreover, it is RECOMMENDED to clearly categorize any new LDP
application in future with regards to the advertisement mode (as per
section 3.2. ). The specification document of such an application
SHOULD explicitly state the application category.
6. Security Considerations
This document specification only clarifies the applicability of LDP This document specification only clarifies the applicability of LDP
session's label advertisement mode, and hence does not add any LDP session's label advertisement mode, and hence does not add any LDP
security mechanics and considerations to those already defined in security mechanics and considerations to those already defined in
LDP specification [RFC5036]. LDP specification [RFC5036].
6. IANA Considerations 7. IANA Considerations
None. None.
7. References 8. References
7.1. Normative References 8.1. Normative References
[RFC5036] Andersson, L., Minei, I., and Thomas, B., Editors, "LDP [RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP
Specification", RFC 5036, September 2007. Specification", RFC 5036, September 2007.
[RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001.
7.2. Informative References
[RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. [RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G.
Heron, "Pseudowire Setup and Maintenance using the Label Heron, "Pseudowire Setup and Maintenance using the Label
Distribution Protocol", RFC 4447, April 2006. Distribution Protocol", RFC 4447, April 2006.
[P2MP-PW] Boutros, S., Martini, L., Sivabalan, S., Del Vecchio, G., [RFC3031] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol
Kamite, Jin, L., "Signaling Root-Initiated P2MP PWs using Label Switching Architecture", RFC 3031, January 2001.
LDP", draft-ietf-pwe3-p2mp-pw-02.txt, Work in Progress,
March 2011.
[MLDP] Minei, I., Kompella, K., Wijnands, I., and Thomas, B., [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
"LDP Extensions for Point-to-Multipoint and Multipoint-to-
Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp
-14.txt, Work in Progress, June 2011.
[ICCP] Martini, L., Salam, S., Sajassi, A., and Matsushima, S., Requirement Levels", BCP 14, RFC2119, March 1997.
8.2. Informative References
[P2MP-PW] S. Boutros, L. Martini, S. Sivabalan, G. Del Vecchio,
Kamite, L. Jin, "Signaling Root-Initiated P2MP PWs using
LDP", draft-ietf-pwe3-p2mp-pw-03.txt, Work in Progress,
October 2011.
[RFC6388] I. Minei, I. Wijnand, K. Kompella, B., "LDP Extensions for
P2MP and MP2MP LSPs", RFC 6388, November 2011.
[ICCP] L. Martini, S. Salam, A. Sajassi, and S. Matsushima,
"Inter-Chassis Communication Protocol for L2VPN PE "Inter-Chassis Communication Protocol for L2VPN PE
Redundancy", draft-ietf-pwe3-iccp-05.txt, Work in Redundancy", draft-ietf-pwe3-iccp-06.txt, Work in
Progress, April 2011. Progress, July 2011.
[UPSTREAM-LDP] Aggarwal, R., and Le Roux, J.L., "MPLS Upstream Label [RFC6389] R. Aggarwal, and J.L. Le Roux, "MPLS Upstream Label
Assignment for LDP", draft-ietf-mpls-ldp-upstream-10.txt, Assignment for LDP", RFC 6389, November 2011.
Work in Progress, February 2011.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and Le [RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, and J.L. Le
Roux, JL., "LDP Capabilities", RFC 5561, July 2009. Roux, "LDP Capabilities", RFC 5561, July 2009.
8. Acknowledgments 9. Acknowledgments
The authors would like to acknowledge Eric Rosen and Rajiv Asati for We acknowledge the authors of [RFC5036] and [RFC4447] since some of
their review and input. the text in this document is borrowed from their specification. We
also acknowledge Eric Rosen and Rajiv Asati for their review and
input.
This document was prepared using 2-Word-v2.0.template.dot. 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,
Kanata, ON K2K-3E8, Canada. Ottawa, ON K2K-3E8, Canada.
E-mail: skraza@cisco.com Email: skraza@cisco.com
Sami Boutros Sami Boutros
Cisco Systems, Inc. Cisco Systems, Inc.
3750 Cisco Way, 3750 Cisco Way,
San Jose, CA 95134, USA. San Jose, CA 95134, USA.
E-mail: sboutros@cisco.com Email: sboutros@cisco.com
Luca Martini Luca Martini
Cisco Systems, Inc. Cisco Systems, Inc.
9155 East Nichols Avenue, Suite 400, 9155 East Nichols Avenue, Suite 400,
Englewood, CO 80112, USA. Englewood, CO 80112, USA.
E-mail: lmartini@cisco.com Email: lmartini@cisco.com
Nicolai Leymann Nicolai Leymann
Deutsche Telekom, Deutsche Telekom,
Winterfeldtstrae 21-27,
10781 Berlin, Germany.
Email: N.Leymann@telekom.de Email: N.Leymann@telekom.de
 End of changes. 52 change blocks. 
134 lines changed or deleted 165 lines changed or added

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