Applicability of LDP Label Advertisement Mode
draft-ietf-mpls-ldp-applicability-label-adv-01

The information below is for an old version of the document
Document Type Active Internet-Draft (mpls WG)
Authors Kamran Raza  , Sami Boutros  , Luca Martini  , Nicolai Leymann 
Last updated 2013-09-04 (latest revision 2013-02-14)
Replaces draft-raza-mpls-ldp-applicability-label-adv
Stream Internet Engineering Task Force (IETF)
Formats pdf htmlized (tools) htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Other - see Comment Log
Document shepherd Loa Andersson
Shepherd write-up Show (last changed 2013-07-10)
IESG IESG state AD Evaluation::Revised I-D Needed
Consensus Boilerplate Unknown
Telechat date
Responsible AD Adrian Farrel
Send notices to mpls-chairs@tools.ietf.org, draft-ietf-mpls-ldp-applicability-label-adv@tools.ietf.org
MPLS Working Group                                          Kamran Raza 
Internet Draft                                             Sami Boutros 
Updates: 5036, 4447 (if approved)                          Luca Martini 
Intended status: Standards Track                    Cisco Systems, Inc.
Expires: August 14, 2013                                            
                                                        Nicolai Leymann 
                                                       Deutsche Telekom 
                                                            
                                                      February 15, 2013 

                                      
               Applicability of LDP Label Advertisement Mode 
                                      
            draft-ietf-mpls-ldp-applicability-label-adv-01.txt 
                                      
Abstract 

   An LDP speaker negotiates the label advertisement mode with its LDP 
   peer at the time of session establishment. Although different 
   applications sharing the same LDP session may need different modes 
   of label distribution and advertisement, there is only one type of 
   label advertisement mode that is negotiated and used per LDP 
   session. This document clarifies the use and the applicability of 
   session's negotiated label advertisement mode, and categorizes LDP 
   applications into two broad categories of negotiated mode-bound and 
   mode-independent applications. The document updates 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 

   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 
   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 
   http://www.ietf.org/ietf/1id-abstracts.txt 

 
 
 
Raza, et. al                 Expires August 2013               [Page 1] 

Internet-Draft  Applicability of LDP Label Advertisement Mode Feb 2013 
      
   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html 

   This Internet-Draft will expire on August 14, 2013. 

Copyright Notice 

   Copyright (c) 2013 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                                                    3 
  2. Conventions used in this document                               3 
  3. Label Advertisement Mode Applicability                          4 
     3.1. Label Advertisement Mode Negotiation                       4 
     3.2. Mode-based Categorization of LDP Applications              4 
          3.2.1. Session mode-bound Applications                     5 
          3.2.2. Session mode-independent Applications               5 
     3.3. Unacceptable label advertisement mode                      6 
  4. Clarification on Mode Applicability                             6 
     4.1. Update to RFC-5036                                         7 
     4.2. Update to RFC-4447                                         7 
  5. Security Considerations                                         7 
  6. IANA Considerations                                             7 
  7. References                                                      7 
     7.1. Normative References                                       7 
     7.2. Informative References                                     8 
  8. Acknowledgments                                                 8 
    

    

    
 
 
Raza, et. al                 Expires August 2013               [Page 2] 


Internet-Draft  Applicability of LDP Label Advertisement Mode Feb 2013 
 
1. Introduction 

   The MPLS architecture [RFC3031] defines two modes of label 
   advertisement for an LSR: 

     1. Downstream-on-Demand 

     2. Unsolicited Downstream 

   The "Downstream-on-Demand" mode requires an LSR to explicitly 
   request the label binding for FECs from its peer, whereas 
   "Unsolicited Downstream" mode allows an LSR to distribute the label 
   binding for FECs to LSR peers that have not explicitly requested 
   them. The MPLS architecture also specifies that on any given label 
   distribution adjacency, the upstream LSR and the downstream LSR must 
   agree to use a single label advertisement mode.  

   Label Distribution Protocol (LDP) [RFC5036] allows label 
   advertisement mode negotiation at time of session establishment 
   (section 3.5.3 [RFC5036]). To comply with MPLS architecture, LDP 
   specification also dictates that only single label advertisement 
   mode is agreed and used for a given LDP session between two LSRs.  

   With the advent of new LDP applications, such as L2VPN [RFC4447], 
   mLDP [RFC6388], ICCP [ICCP], there are situations when an LDP 
   session is shared across more than one application to exchange label 
   bindings for different types of FEC. Although different applications 
   sharing the same LDP session may need a different type of label 
   advertisement mode negotiated, there is only one type of label 
   advertisement mode that is negotiated and agreed at the time of 
   establishment of LDP session.  

   This document clarifies the use and the applicability of label 
   advertisement mode of a session for each application using the 
   session. It also categorizes LDP applications into two broad 
   categories of mode-bound and mode-independent applications.  

   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 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
   document are to be interpreted as described in RFC-2119 [RFC2119]. 

 
 
Raza, et. al                 Expires August 2013               [Page 3] 
         

Internet-Draft  Applicability of LDP Label Advertisement Mode Feb 2013 
      
   The unqualified term "mode" used in document refers to "label 
   advertisement mode".  

   Please also note that LDP specification [RFC5036] uses the term 
   "Downstream Unsolicited" to refer to "Unsolicited Downstream". The 
   LDP specification also uses the terms "label distribution mode" and 
   "label advertisement mode" interchangeably. Like LDP specification 
   document, this document also uses these terms interchangeably.  

3. Label Advertisement Mode Applicability 

3.1. Label Advertisement Mode Negotiation 

   Label advertisement mode is negotiated between LSR peers at the time 
   of session establishment. The label advertisement mode is specified 
   in LDP Initialization message's "Common Session Parameter" TLV by 
   setting A-bit (Label Advertisement Discipline bit) to 1 or 0 for 
   Downstream-on-Demand or Downstream-Unsolicited modes respectively. 
   The negotiation of the A-bit is specified in section 3.5.3 of 
   [RFC5036] as follows: 

     "If one LSR proposes Downstream Unsolicited and the other proposes 
     Downstream on Demand, the rules for resolving this difference is: 

        -  If the session is for a label-controlled ATM link or a 
         label- controlled Frame Relay link, then Downstream on Demand 
         MUST be used. 

       -  Otherwise, Downstream Unsolicited MUST be used." 

   Once label advertisement mode has been negotiated and agreed, both 
   LSR peers must use the same mode for label binding exchange. 

3.2. Mode-based Categorization of LDP Applications 

   The earlier applications, defined and identified at the time of 
   standardization of LDP base specification RFC-3036, using LDP to 
   exchange their FEC bindings were: 

     .  Dynamic Label Switching for IP Prefixes 

     .  Label-controlled ATM/FR  

   Since then, several new applications have emerged that use LDP to 
   signal their FEC bindings and/or application data. These include: 

     .  L2VPN P2P PW   ([RFC4447]) 

 
 
Raza, et. al                 Expires August 2013               [Page 4] 


Internet-Draft  Applicability of LDP Label Advertisement Mode Feb 2013 
      
     .  L2VPN P2MP PW  ([P2MP-PW]) 

     .  mLDP           ([RFC6388]) 

     .  ICCP           ([ICCP]) 

   We divide the LDP applications into two broad categories from label 
   advertisement mode usage point of view: 

   1. Session mode-bound Applications 

   2. Session mode-independent Applications 

3.2.1. Session mode-bound Applications 

  We define a "session mode-bound application" to be an application 
  which uses the negotiated label advertisement mode. This means that 
  the FEC-label binding exchange for such an LDP application MUST use 
  the label advertisement mode negotiated for the LDP session.  

   The early LDP applications "Dynamic Label Switching for IP Prefixes" 
   and "Label-controlled ATM/FR" are included into this category. 

3.2.2. Session mode-independent Applications 

   We define a "session mode-independent application" to be an 
   application which does not care about the negotiated label 
   advertisement mode. This means that the FEC-label binding, or any 
   other application data, exchange for such an LDP application does 
   not care about, nor tied to the "negotiated" label advertisement 
   mode of the session; rather, the information exchange is driven by 
   the application need and procedures as described by its 
   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, are included 
   into this category of LDP applications. 

3.2.2.1. Upstream Label Assignment 

  As opposed to downstream assigned label advertisement defined by 
  [RFC3031], [RFC6389] specification defines new mode of label 
  advertisement where label advertisement and distribution occurs for 
  upstream assigned labels.  

 
 
Raza, et. al                 Expires August 2013               [Page 5] 


Internet-Draft  Applicability of LDP Label Advertisement Mode Feb 2013 
      
  As stated earlier in this document, LDP base specification RFC-5036 
  only allows specifying Downstream-Unsolicited or Downstream-on-Demand 
  mode. This means that any LDP application that requires upstream 
  assigned label advertisement also falls under the category of Session 
  mode-independent application. 

3.3. Unacceptable label advertisement mode 

  The procedures related to unacceptable label advertisement mode, as 
  defined in RFC-5036 section 3.5.3, continue to apply for any "mode-
  bound" FEC/application. For a "mode-independent" FEC/application, 
  mode negotiation does not apply and hence both LSRs MUST operate in 
  the mode specified for the given application by the respective 
  specification.  

  If a session is jointly shared amongst mode-bound and mode-
  independent FEC/applications, session will not be established if the 
  label advertisement mode is unacceptable (between the LSRs) for a 
  given mode-bound FEC/application type. This is inline with RFC-5036 
  section 3.5.3 specification for unacceptable mode. 

4. Clarification on Mode Applicability 

   To remove any ambiguity and conflict amongst different 
   specifications with regards to the use of LDP session's label 
   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. 

 
 
Raza, et. al                 Expires August 2013               [Page 6] 


Internet-Draft  Applicability of LDP Label Advertisement Mode Feb 2013 
      
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 
     label binding advertisement of "Address Prefix" FECs;  

   -  Any new document specifying a new FEC MUST state the 
     applicability of the negotiated label advertisement discipline for 
     that FEC. 

4.2. Update to RFC-4447 

   The section 3 of [RFC4447] states: 

     "LDP MUST be used in its downstream unsolicited mode." 

   Since PW application falls under session mode-independent 
   application category, the above statement in [RFC4447] should be 
   read to mean as follows: 

   "LDP MUST exchange PW FEC label bindings in downstream unsolicited 
   manner, independent of the negotiated label advertisement mode of 
   the LDP session". 

5. Security Considerations 

   This document specification only clarifies the applicability of 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]. 

6. IANA Considerations 

  None. 
   
7. References 

7.1. Normative References 

   [RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP 
             Specification", RFC 5036, September 2007. 

 
 
Raza, et. al                 Expires August 2013               [Page 7] 


Internet-Draft  Applicability of LDP Label Advertisement Mode Feb 2013 
      
   [RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. 
             Heron,  "Pseudowire Setup and Maintenance using the Label 
             Distribution Protocol", RFC 4447, April 2006. 

   [RFC3031] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol 
             Label Switching Architecture", RFC 3031, January 2001. 

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 
             Requirement Levels", BCP 14, RFC 2119, March 1997. 

7.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-04.txt, Work in Progress, 
             March 2012. 

   [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 
             Redundancy", draft-ietf-pwe3-iccp-09.txt, Work in 
             Progress, July 2012. 

   [RFC6389] R. Aggarwal, and J.L. Le Roux, "MPLS Upstream Label 
             Assignment for LDP", RFC 6389, November 2011. 

8. Acknowledgments 

   We acknowledge the authors of [RFC5036] and [RFC4447] since some of 
   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. 

Authors' Addresses 

  Kamran Raza 
  Cisco Systems, Inc. 
  2000 Innovation Drive, 
  Ottawa, ON K2K-3E8, Canada. 
  E-mail: skraza@cisco.com 
 
 

 
 
Raza, et. al                 Expires August 2013               [Page 8] 
         

Internet-Draft  Applicability of LDP Label Advertisement Mode Feb 2013 
      
  Sami Boutros 
  Cisco Systems, Inc. 
  3750 Cisco Way, 
  San Jose, CA 95134, USA. 
  E-mail: sboutros@cisco.com 
        
  Luca Martini 
  Cisco Systems, Inc. 
  9155 East Nichols Avenue, Suite 400, 
  Englewood, CO 80112, USA. 
  E-mail: lmartini@cisco.com 
      
  Nicolai Leymann 
  Deutsche Telekom AG, 
  Winterfeldtstrasse 21, 
  Berlin 10781, Germany. 
  E-mail: N.Leymann@telekom.de 
      

      
      
Raza, et. al                 Expires August 2013               [Page 9]