draft-ietf-mpls-ldp-applicability-label-adv-00.txt   draft-ietf-mpls-ldp-applicability-label-adv-01.txt 
MPLS 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: February 7, 2013 Expires: August 14, 2013
Nicolai Leymann Nicolai Leymann
Deutsche Telekom Deutsche Telekom
August 8, 2012 February 15, 2013
Applicability of LDP Label Advertisement Mode Applicability of LDP Label Advertisement Mode
draft-ietf-mpls-ldp-applicability-label-adv-00.txt draft-ietf-mpls-ldp-applicability-label-adv-01.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. The document also suggests an update mode-independent applications. The document updates RFC5036 and
to RFC 5036 and RFC 4447 to remove any ambiquity and conflict in the RFC4447 to remove any ambiguity and conflict in the area of using
area of using correct label advertisement mode for a given correct label advertisement mode for a given application.
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 2, line 7 skipping to change at page 2, line 7
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 February 7, 2013. This Internet-Draft will expire on August 14, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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. Mode-based Categorization of LDP Applications 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. Unacceptable label advertisement mode 6 3.3. Unacceptable label advertisement mode 6
4. Clarification on Mode Applicability 6 4. Clarification on Mode Applicability 6
4.1. Update to RFC-5036 7 4.1. Update to RFC-5036 7
4.2. Update to RFC-4447 7 4.2. Update to RFC-4447 7
5. Security Considerations 7 5. Security Considerations 7
6. IANA Considerations 7 6. IANA Considerations 7
7. References 7 7. References 7
7.1. Normative References 7 7.1. Normative References 7
7.2. Informative References 8 7.2. Informative References 8
8. Acknowledgments 8 8. 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
skipping to change at page 5, line 21 skipping to change at page 5, line 21
advertisement mode usage point of view: advertisement mode usage point of view:
1. Session mode-bound Applications 1. Session mode-bound Applications
2. Session mode-independent Applications 2. Session mode-independent Applications
3.2.1. Session mode-bound Applications 3.2.1. Session mode-bound Applications
We define a "session mode-bound application" to be an application We define a "session mode-bound application" to be an application
which uses the negotiated label advertisement mode. This means that which uses the negotiated label advertisement mode. This means that
the FEC-label binding exchange for such an LDP applications MUST use the FEC-label binding exchange for such an LDP application MUST use
the label advertisement mode negotiated for the LDP session. 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" are included into this category. and "Label-controlled ATM/FR" are included into this category.
3.2.2. Session mode-independent Applications 3.2.2. Session mode-independent Applications
We define a "session mode-independent application" to be an We define a "session mode-independent application" to be an
application which does not care about the negotiated label application which does not care about the negotiated label
advertisement mode. This means that the FEC-label binding, or any advertisement mode. This means that the FEC-label binding, or any
skipping to change at page 7, line 22 skipping to change at page 7, line 22
label binding advertisement of "Address Prefix" FECs; label binding advertisement of "Address Prefix" FECs;
- Any new document specifying a new FEC MUST state the - Any new document specifying a new FEC MUST state the
applicability of the negotiated label advertisement discipline for applicability of the negotiated label advertisement discipline for
that FEC. that FEC.
4.2. Update to RFC-4447 4.2. Update to RFC-4447
The section 3 of [RFC4447] states: 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".
5. Security Considerations 5. 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]. the LDP specification [RFC5036].
6. IANA Considerations 6. IANA Considerations
None. None.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP [RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP
Specification", RFC 5036, September 2007. Specification", RFC 5036, September 2007.
[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.
[RFC3031] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol [RFC3031] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References 7.2. Informative References
[P2MP-PW] S. Boutros, L. Martini, S. Sivabalan, G. Del Vecchio, [P2MP-PW] S. Boutros, L. Martini, S. Sivabalan, G. Del Vecchio,
Kamite, L. Jin, "Signaling Root-Initiated P2MP PWs using Kamite, L. Jin, "Signaling Root-Initiated P2MP PWs using
LDP", draft-ietf-pwe3-p2mp-pw-04.txt, Work in Progress, LDP", draft-ietf-pwe3-p2mp-pw-04.txt, Work in Progress,
March 2012. March 2012.
[RFC6388] I. Minei, I. Wijnand, K. Kompella, B., "LDP Extensions for [RFC6388] I. Minei, I. Wijnand, K. Kompella, B., "LDP Extensions for
P2MP and MP2MP LSPs", RFC 6388, November 2011. P2MP and MP2MP LSPs", RFC 6388, November 2011.
[ICCP] L. Martini, S. Salam, A. Sajassi, and S. Matsushima, [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-08.txt, Work in Redundancy", draft-ietf-pwe3-iccp-09.txt, Work in
Progress, June 2012. Progress, July 2012.
[RFC6389] R. Aggarwal, and J.L. Le Roux, "MPLS Upstream Label [RFC6389] R. Aggarwal, and J.L. Le Roux, "MPLS Upstream Label
Assignment for LDP", RFC 6389, November 2011. Assignment for LDP", RFC 6389, November 2011.
8. Acknowledgments 8. Acknowledgments
We acknowledge the authors of [RFC5036] and [RFC4447] since some of We acknowledge the authors of [RFC5036] and [RFC4447] since some of
the text in this document is borrowed from their specification. We the text in this document is borrowed from their specification. We
also acknowledge Eric Rosen and Rajiv Asati for their review and also acknowledge Eric Rosen and Rajiv Asati for their review and
input. input.
skipping to change at page 9, line 17 skipping to change at page 9, line 17
San Jose, CA 95134, USA. San Jose, CA 95134, USA.
E-mail: sboutros@cisco.com E-mail: 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 E-mail: lmartini@cisco.com
Nicolai Leymann Nicolai Leymann
Deutsche Telekom, Deutsche Telekom AG,
Winterfeldtstrasse 21-27, Winterfeldtstrasse 21,
10781 Berlin, Germany. Berlin 10781, Germany.
E-mail: N.Leymann@telekom.de E-mail: N.Leymann@telekom.de
 End of changes. 13 change blocks. 
35 lines changed or deleted 34 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/