Controlling State Advertisements Of Non-negotiated LDP Applications
draft-ietf-mpls-ldp-ip-pw-capability-07

MPLS Working Group                                          Kamran Raza 
Internet Draft                                             Sami Boutros 
Intended status: Standards Track                                        
Expires: October 26, 2014                                 Cisco Systems 
 
                                                         April 27, 2014 
 
                                      
    Controlling State Advertisements Of Non-negotiated LDP Applications 
                                      
                draft-ietf-mpls-ldp-ip-pw-capability-07.txt 
 

 

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 

   The list of Internet-Draft Shadow Directories can be accessed at 
   http://www.ietf.org/shadow.html 

   This Internet-Draft will expire on October 26, 2014. 

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 
 
 
 
Raza, et. al             Expires October 2014                  [Page 1] 

      
Internet-Draft    draft-ietf-mpls-ldp-ip-pw-capability       Apr 2014 
 

   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. 

Abstract 

   There is no capability negotiation done for Label Distribution 
   Protocol (LDP) applications that setup Label Switched Paths (LSPs) 
   for IP prefixes or that signal Point-to-point (P2P) Pseudowires 
   (PWs) for Layer 2 Virtual Private Networks (L2VPNs). When an LDP 
   session comes up, an LDP speaker may unnecessarily advertise its 
   local state for such LDP applications even when the peer session is 
   established for some other applications like Multipoint LDP (mLDP) 
   or Inter-Chassis Communication Protocol (ICCP). This document 
   defines a solution by which an LDP speaker announces to its peer its 
   disinterest in such non-negotiated applications, thus disabling the 
   unnecessary advertisement of corresponding application state, which 
   would have otherwise be advertised over the established LDP session. 

Table of Contents 

  1. Introduction                                                     3 
  2. Conventions used in this document                                4 
  3. Non-negotiated LDP applications                                  4 
    3.1. Non-interesting State                                        5 
  4. Controlling State Advertisement                                  5 
    4.1. State Advertisement Control Capability                       5 
    4.2. Capabilities Procedures                                      8 
       4.2.1. State Control Capability in an Initialization message   9 
       4.2.2. State Control capability in a Capability message        9 
  5. Operational Examples                                             9 
    5.1. Disabling Prefix-LSPs and P2P-PWs apps on an ICCP session    9 
    5.2. Disabling Prefix-LSPs app on a PW Targeted LDP session      10 
    5.3. Disabling Prefix-LSPs app dynamically on an LDP session     10 
    5.4. Disabling Prefix-LSPs app on an mLDP-only session           11
    5.5. Disabling IPv4 or IPv6 Prefix-LSPs app on an dual-stack LSR 11
  6. Security Considerations                                         11 
  7. IANA Considerations                                             12 
  8. References                                                      12 
    8.1. Normative References                                        12 
    8.2. Informative References                                      12 
  9. Acknowledgments                                                 13 
    
 
Raza, et. al             Expires October 2014                  [Page 2] 

      
Internet-Draft    draft-ietf-mpls-ldp-ip-pw-capability       Apr 2014 
 

1. Introduction 

  LDP Capabilities specification [RFC5561] introduced a mechanism to 
  negotiate LDP capabilities for a given feature between peer Label 
  Switching Routers (LSRs). The capability mechanism insures that no 
  unnecessary state is exchanged between peer LSRs unless the 
  corresponding feature capability is successfully negotiated between 
  the peers.  
   
  Newly defined LDP features and applications, such as Typed Wildcard 
  Forwarding Equivalence Class (FEC) [RFC5918], Inter-Chassis 
  Communication Protocol [ICCP], mLDP [RFC6388], and L2VPN Point-to-
  multipoint (P2MP) PW [P2MP-PW] make use of LDP capabilities framework 
  for their feature negotiation. However, the earlier LDP application 
  to establish LSPs for IP unicast prefixes, and application to signal 
  L2VPN P2P PW [RFC4447] [RFC4762] allowed LDP speakers to exchange 
  application state without any capability negotiation, thus causing 
  unnecessary state advertisement when a given application is not 
  enabled on one of the LDP speakers participating in a given session. 
  For example, when bringing up and using an LDP peer session with a 
  remote Provider Edge (PE) LSR for purely ICCP signaling reasons, an 
  LDP speaker may unnecessarily advertise labels for IP (unicast) 
  prefixes to this ICCP related LDP peer.  
   
  Another example of unnecessary state advertisement can be cited when 
  LDP is to be deployed in an IP dual-stack environment. For instance, 
  an LSR that is locally enabled to setup LSPs for both IPv4 and IPv6 
  prefixes may advertise (address and label) bindings for both IPv4 and 
  IPv6 address families towards an LDP peer that is interested in IPv4 
  bindings only. In this case, the advertisement of IPv6 bindings to 
  the peer is unnecessary, as well as wasteful, from the point of view 
  of LSR memory/CPU and network resource consumption.  
   
  To avoid this unnecessary state advertisement and exchange, currently 
  an operator is typically required to configure and define filtering 
  policies on the LSR, which introduces unnecessary operational 
  overhead and complexity for such deployments.  
   
  This document defines an LDP Capabilities [RFC5561] based solution by 
  which an LDP speaker may announce to its peer(s) its disinterest (or 
  non-support) for state to setup IP Prefix LSPs and/or to signal L2VPN 
   
 
Raza, et. al             Expires October 2014                  [Page 3] 

      
Internet-Draft    draft-ietf-mpls-ldp-ip-pw-capability       Apr 2014 
 

  P2P PW at the time of session establishment. This capability helps in 
  avoiding unnecessary state advertisement for such feature 
  applications. This document also states the mechanics to dynamically 
  disable or enable the state advertisement for such applications 
  during the session lifetime. The non-interesting state of an 
  application depends on the type of application and is described later 
  in section 3.1.   
   
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].  

   The term "IP" in this document refers to both IPv4 and IPv6 unicast 
   address families. 

3. Non-negotiated LDP applications 

   For the applications that existed prior to the definition of LDP 
   Capabilities framework [RFC5561], an LDP speaker typically 
   advertises, without waiting for any capabilities exchange and 
   negotiation, its corresponding application state to its peers after 
   the session establishment. These early LDP applications include: 

   o  IPv4/IPv6 Prefix LSPs Setup 

   o  L2VPN P2P FEC128 and FEC129 PWs signaling 

   This document onward uses following shorthand terms for these 
   earlier LDP applications: 

     o "Prefix-LSPs": Refers to an application that sets up LDP LSPs 
        corresponding to IP routes/prefixes by advertising label 
        bindings for Prefix FEC (as defined in RFC-5036).
  
     o "P2P-PWs": Refers to an application that signals FEC 128 and/or 
        FEC 129 L2VPN P2P Pseudowires using LDP (as defined in 
        RFC-4447).  

   To disable unnecessary state exchange for such LDP applications over 
   an established LDP session, a new capability is being introduced in 
   this document. This new capability controls the advertisement of 
   application state and enables an LDP speaker to notify its peer its 
   disinterest in the state of one or more of these "Non-negotiated" 
   LDP applications at the time of session establishment. Upon receipt 
   of such capability, the receiving LDP speaker, if supporting the 
   capability, disables the advertisement of the state related to the 

 
 
Raza, et. al             Expires October 2014                  [Page 4] 

      
Internet-Draft    draft-ietf-mpls-ldp-ip-pw-capability       Apr 2014 
 

   application towards the sender of the capability. This new 
   capability can also be sent later in a Capability message to either 
   disable a previously enabled application's state advertisement or to 
   enable a previously disabled application's state advertisement. 

3.1. Non-interesting State 

   A non-interesting state of a non-negotiated LDP application: 

     - is the application state which is of a no interest to an LSR 
        and need not be advertised to the LSR; 
     - need not be advertised in any of the LDP protocol messages; 
     - is dependent on application type and specified accordingly. 

   For Prefix-LSPs application type, the non-interesting state refers 
   to any state related to IP Prefix FEC (such as FEC label bindings, 
   LDP Status). This document, however, does not classify IP address 
   bindings as a non-interesting state and allows the advertisement of 
   IP Address bindings to facilitate other LDP applications (such as 
   mLDP) that depend on learning of peer addresses over an LDP session 
   for their correct operation. 

   For P2P-PWs application type, the non-interesting state refers to 
   any state related to P2P PW FEC128/FEC129 (such as FEC label 
   bindings, MAC [address] withdrawal, and LDP PW Status). 

   From now onward in this document, the term "state" will mean to 
   refer to the "non-interesting state" for an application, as defined 
   in this section. 

4. Controlling State Advertisement 

   To control advertisement of non-interesting state related to non-
   negotiated LDP applications defined in section 3, a new capability 
   TLV is defined as follows. 

4.1. State Advertisement Control Capability 

   The "State Advertisement Control Capability" is a new Capability 
   Parameter TLV defined in accordance with section 3 of LDP 
   Capabilities specification [RFC5561]. The format of this new TLV is 
   as follows: 

    

    

 
 
Raza, et. al             Expires October 2014                  [Page 5] 

      
Internet-Draft    draft-ietf-mpls-ldp-ip-pw-capability       Apr 2014 
 

 

    0                   1                   2                   3 
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1   
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |U|F| State Adv. Ctrl Cap.(IANA)|           Length              | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |S|  Reserved   |                                               | 
   +-+-+-+-+-+-+-+-+ 
   |                                                               | 
   ~            State Advertisement Control Element(s)             ~  
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
  Figure 1: Format of an "State Advertisement Control Capability" TLV 
    
   The value of the U-bit for the TLV MUST be set to 1 so that a 
   receiver MUST silently ignore this TLV if unknown to it, and 
   continue processing the rest of the message. Whereas, The value of 
   F-bit MUST be set to 0. Once advertised, this capability cannot be 
   withdrawn; thus S-bit MUST be set to 1 in an Initialization and 
   Capability message.  
    
   The capability data associated with this State Advertisement Control 
   (SAC) Capability TLV is one or more State Advertisement Control 
   Elements, where each element indicates enabling/disabling of 
   advertisement of non-interesting state for a given application. The 
     format of a SAC Element is defined as follows: 
 
                              0 1 2 3 4 5 6 7  
                             +-+-+-+-+-+-+-+-+ 
                             |D| App |Unused | 
                             +-+-+-+-+-+-+-+-+ 
    
       Figure 2: Format of "State Advertisement Control Element" 
    
   Where: 
    
   D bit: Controls the advertisement of the state specified in "App" 
    field: 
       1: Disable state advertisement 
       0: Enable state advertisement 
      When sent in an Initialization message, D bit MUST be set to 1. 
   
  App: Defines the application type whose state advertisement is to be 

 
 
Raza, et. al             Expires October 2014                  [Page 6] 

      
Internet-Draft    draft-ietf-mpls-ldp-ip-pw-capability       Apr 2014  
 

      controlled. The value of this field is defined as follows: 
   
       1: IPv4 Prefix-LSPs (LSPs for IPv4 prefixes) 
       2: IPv6 Prefix-LSPs (LSPs for IPv6 prefixes) 
       3: FEC128 P2P-PW (L2VPN PWid FEC signaling) 
       4: FEC129 P2P-PW (L2VPN Generalized PWid FEC signaling) 
       
      Any other value in this field MUST be treated as an error. 
    
   Unused: MBZ on transmit and ignored on receipt. 
 
   The "Length" field of SAC Capability TLV depends on the number of 
   SAC Elements present in the TLV. For example, if there are two 
   elements present, then the Length field is set to 3 octets. A 
   receiver of this capability TLV can deduce number of elements 
   present in the TLV by using the Length field.  
    
   From now onward, this document uses the term "element" to refer to a 
   SAC Element. 
     
   As described earlier, SAC Capability TLV MAY be included by an LDP 
   speaker in an Initialization message to signal to its peer LSR that 
   state exchange for one or more application(s) need to be disabled on 
   the given peer session. This TLV can also be sent later in a 
   Capability message to selectively enable or disable these 
   applications. If there are more than one elements present in a SAC 
   Capability TLV, the elements MUST belong to distinct app types and 
   an app type MUST NOT appear more than once. If a receiver 
   receives such a malformed TLV, it SHOULD discard this TLV and 
   continue processing rest of the message. If an LSR receives a 
   message with a SAC capability TLV containing an element with "App" 
   field set to a value other than defined above, the receiver MUST 
   ignore and discard the element and continue processing the rest of 
   the TLV. 

   To control more than one application state, a sender LSR can either 
   send a single capability TLV in a message with multiple elements 
   present, or can send separate messages with capability TLV 
   specifying one or more elements. A receiving LSR, however, MUST 
   treat each incoming capability TLV with an element corresponding to 
   a given application type as an update to its existing policy for the 
   given type.  

   To understand capability updates from an example, let us consider 2 
   LSRs, S (LDP speaker) and P (LDP peer), both of which support all 
   the non-negotiated applications listed earlier. By default, these 
 
 
Raza, et. al             Expires October 2014                  [Page 7] 

      
Internet-Draft    draft-ietf-mpls-ldp-ip-pw-capability       Apr 2014 
 

   LSR will advertise state for these applications, as configured, to 
   their peer as soon as an LDP session is established. Now assume that 
   P receives from S a SAC capability in an Initialization message with 
   "IPv6 Prefix-LSPs" and "FEC129 P2P-PW" applications disabled. This 
   updates P's outbound policy towards S to advertise state related to 
   only IPv4 Prefix-LSPs and FEC128 P2P-PW applications.  Later, P 
   receives another capability update from S via a Capability message 
   with "IPv6 Prefix-LSPs" enabled and "FEC128 P2P-PWs" disabled. This 
   results in P's outbound policy towards S to advertise both IPv4 and 
   IPv6 Prefix-LSPs application state, and disable both FEC128 and 
   FEC129 P2P-PWs signaling. Finally, P receives another update from S 
   via a Capability message that specifies to disable all four non-
   negotiated applications state, resulting in P outbound policy 
   towards S to block/disable state for all these applications, and 
   only advertise state for any other application, as applicable. 

  4.2. Capabilities Procedures 

   The SAC capability conveys the desire of an LSR to disable the 
   receipt of unwanted/unnecessary state from its LDP peer. This 
   capability is unilateral and unidirectional in nature, and a 
   receiving LSR is not required to send a similar capability TLV in an 
   Initialization or Capability message towards the sender of this 
   capability. This unilateral behavior conforms to the procedures 
   defined in the Section 6 of LDP Capabilities [RFC5561]. 

   After this capability is successfully negotiated (i.e. sent by an 
   LSR and received/understood by its peer), then the receiving LSR 
   MUST NOT advertise any state related to the disabled applications 
   towards the capability sending LSR until and unless these 
   application states are explicitly enabled again via a capability 
   update. Upon receipt of a capability update to disable an enabled 
   application [state] during the lifetime of a session, the receiving 
   LSR MUST also withdraw from the peer any previously advertised state 
   corresponding to the disabled application. 

   If a receiving LDP speaker does not understand the SAC capability 
   TLV, then it MUST respond to the sender with "Unsupported TLV" 
   notification as described in LDP Capabilities [RFC5561]. If a 
   receiving LDP speaker does not understand or does not support an 
   application specified in an application control element, it SHOULD 
   silently ignore/skip such an element and continue processing rest of 
   the TLV. 

 
 
Raza, et. al             Expires October 2014                  [Page 8] 

      
Internet-Draft    draft-ietf-mpls-ldp-ip-pw-capability       Apr 2014 
 

4.2.1. State Control Capability in an Initialization message 

   LDP Capabilities [RFC5561] framework dictates that the S-bit of 
   capability parameter in an Initialization message MUST be set to 1 
   and SHOULD be ignored on receipt.   

   An LDP speaker determines (e.g. via some local configuration or 
   default policy) if it needs to disable Prefix-LSPs and/or P2P-PWs 
   applications with a peer LSR. If there is a need to disable, then 
     the SAC TLV needs to be included in the Initialization message with 
   respective SAC elements included with their D bit set to 1.   

   An LDP speaker that supports the SAC capability MUST interpret the 
   capability TLV in a received Initialization message such that it 
   disables the advertisement of the application state towards the 
   capability sending LSR for Prefix-LSPs and/or P2P-PWs applications 
   if their SAC element's D bit is set to 1.  

4.2.2. State Control capability in a Capability message 

   If the LDP peer supports "Dynamic Announcement Capability" 
   [RFC5561], then an LDP speaker may send SAC capability in a 
   Capability message towards the peer. Once advertised, these 
   capabilities cannot be withdrawn and hence the S-bit of the TLV MUST 
   be set to 1 when sent in a Capability message.  

   An LDP speaker may decide to send this TLV towards an LDP peer if 
   one or more of its Prefix-LSPs and/or P2P-PWs applications get 
   disabled, or if previously disabled application gets enabled again. 
   In this case, the LDP speaker constructs the TLV with appropriate 
   SAC element(s) and sends the corresponding capability TLV in a 
   Capability message.  

   Upon receipt of this TLV in a Capability message, the receiving LDP 
   speaker reacts in the same manner as it reacts upon the receipt of 
   this TLV in an Initialization message. Additionally, the peer 
   withdraws/advertises the application state from/to the capability 
   sending LDP speaker according to the capability update.  

5. Operational Examples 

5.1. Disabling Prefix-LSPs and P2P-PWs applications on an ICCP session 

   Consider two PE routers, LSR1 and LSR2, which understand/support SAC 
   capability TLV, and have an established LDP session to exchange ICCP 
   state related to dual-homed devices connected to these LSRs. Let us 

 
 
Raza, et. al             Expires October 2014                  [Page 9] 

      
Internet-Draft    draft-ietf-mpls-ldp-ip-pw-capability       Apr 2014 
 

   assume that both LSRs are provisioned not to exchange any state for 
   Prefix-LSPs (IPv4/IPv6) and P2P-PWs (FEC128/129) application. 
     To indicate their disinterest in these applications, the LSRs will 
   include a SAC capability TLV (with 4 SAC elements corresponding to 
   these 4 applications with D bit set to 1 for each one) in the 
   Initialization message. Upon receipt of this TLV in Initialization 
   message, the receiving LSR will disable the advertisement of 
   IPv4/IPv6 label bindings, as well as P2P PW FEC128/129 signaling, 
   towards its peer after session establishment. 

5.2. Disabling Prefix-LSPs application on a PW Targeted LDP session 

   Now, consider LSR1 and LSR2 have an established Targeted LDP (T-LDP)
   session for P2P-PWs application to exchange label bindings for 
   FEC 128/129. Given that there is no need to exchange IP Prefix label 
   bindings amongst the PE LSRs over a PW T-LDP session in most typical 
   deployments, let us assume that LSRs are provisioned to disable 
   IPv4/IPv6 Prefix-LSPs application state on the given PW session.  

   To indicate their disinterest in Prefix-LSPs application over a PW 
   T-LDP session, the LSRs will follow/apply the same procedures as 
   described in previous section. As a result, only P2P-PWs related 
   state will be exchanged between these LSRs over this T-LDP session. 

5.3. Disabling Prefix-LSPs application dynamically on an established 
   LDP session 

   Assume that LSRs from previous sections were initially provisioned 
   to exchange both Prefix-LSPs and P2P-PWs state over the session 
   between them, and also support "Dynamic Announcement" Capability 
   [RFC5561]. Now, assume that LSR1 is dynamically provisioned to 
   disable (IPv4/IPv6) Prefix-LSPs over T-LDP session with LSR2. In 
   this case, LSR1 will send SAC capability TLV in a Capability message 
   towards LSR2 with application control elements defined for IPv4 and 
   IPv6 Prefix-LSPs with D bit set to 1. Upon receipt of this TLV, LSR2 
   will disable Prefix-LSPs application state(s) towards LSR1 and 
   withdraw all previously advertised application state from LSR1. To 
   withdraw label bindings from its peer, LSR2 MAY use a single Prefix 
   FEC Typed Wildcard Label Withdraw message [RFC5918] if the peer 
   supports Typed Wildcard FEC capability.  

   This dynamic disability of Prefix-LSPs application does not impact 
   L2VPN P2P-PWs application on the given session, and both LSRs should 
   continue to exchange PW Signaling application related state. 

 
 
Raza, et. al             Expires October 2014                 [Page 10] 

      
Internet-Draft    draft-ietf-mpls-ldp-ip-pw-capability       Apr 2014 
 

5.4. Disabling Prefix-LSPs application on an mLDP-only session 

   Now assume that LSR1 and LSR2 have formed an LDP session to exchange 
   mLDP state only. In typical deployments, LSR1 and LSR2 also exchange 
   bindings for IP (unicast) prefixes upon mLDP session, which is 
   unnecessary and wasteful for an mLDP-only LSR.  

   Using the procedures defined earlier, an LSR can indicate its 
   disinterest in Prefix-LSPs application state to its peer upon 
   session establishment time or dynamically later via LDP capabilities 
   update. 

   Reference to section 3.1, the peer disables the advertisement of any 
   state related to IP Prefix FECs, but still advertises IP address 
   bindings that are required for the correct operation of mLDP.    

5.5. Disabling IPv4 or IPv6 Prefix-LSPs application on an dual-stack LSR 

   In IP dual-stack scenarios, LSR2 may advertise unnecessary state 
   (e.g. IPv6 prefix label bindings) towards peer LSR1 corresponding to 
   IPv6 Prefix-LSPs application once a session is established mainly 
   for exchanging state for IPv4. The similar scenario also applies 
   when advertising IPv4 Prefix-LSPs state on a session meant for IPv6. 
   The SAC capability and its procedures defined in this document can 
   help to avoid such unnecessary state advertisement. 

   Consider IP dual-stack environment where LSR2 is enabled for Prefix-
   LSPs application for both IPv4 and IPv6, but LSR1 is enabled for (or 
   interested in) only IPv4 Prefix-LSPs. To avoid receiving unwanted 
   state advertisement for IPv6 Prefix-LSPs application from LSR2, LSR1 
   can send SAC capability with element for IPv6 Prefix-LSPs with D bit 
   set to 1 in the Initialization message towards LSR2 at the time of 
   session establishment. Upon receipt of this capability, LSR2 will 
   disable all IPv6 label binding advertisement towards LSR1. If IPv6 
   Prefix-LSPs application is later enabled on LSR1, LSR1 can update 
   the capability by sending SAC capability in a Capability message 
   towards LSR2 to enable this application dynamically. 

6. Security Considerations 

  The proposal introduced in this document does not introduce any new 
  security considerations beyond that already apply to the base LDP 
  specification [RFC5036] and [RFC5920]. 
   

 
 
Raza, et. al             Expires October 2014                 [Page 11] 

      
Internet-Draft    draft-ietf-mpls-ldp-ip-pw-capability       Apr 2014 
 

7. IANA Considerations 

  This document defines a new LDP capability parameter TLV. IANA is
  requested to assign the lowest available value after 0x0500 from
  "TLV Type Name Space" in the "Label Distribution Protocol (LDP)
  Parameters" registry as the new code point for the new LDP
  capability TLV code point.

  +-----+---------------------+---------------+-----------------------+
  |Value| Description         | Reference     |Notes/Registration Date|
  +-----+---------------------+---------------+-----------------------+
  | TBA | State Advertisement | This document |                       |
  |     | Control Capability  |               |                       |
  +-----+---------------------+---------------+-----------------------+
  
 
8. References 

8.1. Normative References 

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

   [RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, and JL. Le 
             Roux, "LDP Capabilities", RFC 5561, July 2009. 

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

8.2. Informative References 

   [RFC5918] R. Asati, I. Minei, and B. Thomas, "Label Distribution 
             Protocol Typed Wildcard FEC", RFC 5918, August 2010. 

   [RFC4447] L. Martini, E. Rosen, El-Aawar, T. Smith, and G. Heron,  
             "Pseudowire Setup and Maintenance using the Label 
             Distribution Protocol", RFC 4447, April 2006. 

   [RFC4762] M. Lasserre, and V. Kompella,  "Virtual Private LAN Service   
             (VPLS) Using Label Distribution Protocol (LDP) Signaling", 
             RFC 4762, January 2007. 

   [P2MP-PW] Martini, L. et. al, "Signaling Root-Initiated Point-to-
             Multipoint Pseudowires using LDP", draft-ietf-pwe3-p2mp-pw-
             04.txt, Work in Progress, March 2012. 

   [ICCP]    L. Martini, S. Salam, A. Sajassi, and S. Matsushima, 
             "Inter-Chassis Communication Protocol for L2VPN PE 
             Redundancy", draft-ietf-pwe3-iccp-16.txt, Work in 
             Progress, March 2014. 

 
 
Raza, et. al             Expires October 2014                 [Page 12] 

      
Internet-Draft    draft-ietf-mpls-ldp-ip-pw-capability       Apr 2014 
 

   [RFC6388] I. Minei, I. Wijnands, K. Kompella, and B. Thomas, "LDP 
             Extensions for P2MP and MP2MP LSPs", RFC 6388, November 
             2011. 

   [RFC5920] L. Fang, et al., "Security Framework for MPLS and GMPLS 
             Networks", RFC 5920, July 2010. 

9. Acknowledgments 

   The authors would like to thank Eric Rosen for his valuable input 
   and comments. We also acknowledge Karthik Subramanian and IJsbrand 
   Wijnands for bringing up mLDP use case.  

   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 
 
  Sami Boutros 
  Cisco Systems, Inc. 
  3750 Cisco Way, 
  San Jose, CA 95134, USA. 
  E-mail: sboutros@cisco.com 

 
 
Raza, et. al             Expires October 2014                 [Page 13]