Disabling IPoMPLS and P2P PW LDP Applications
draft-ietf-mpls-ldp-ip-pw-capability-03

MPLS Working Group                                          Kamran Raza 
Internet Draft                                             Sami Boutros 
Intended status: Standards Track                                        
Expires: August 18, 2013                                  Cisco Systems 
 
                                                      February 19, 2013 
 
                                      
               Disabling IPoMPLS and P2P PW LDP Applications  
                                      
                draft-ietf-mpls-ldp-ip-pw-capability-03.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 August 18, 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 
 
 
 
Raza, et. al             Expires August 2013                   [Page 1] 

      
Internet-Draft  Disabling IPoMPLS and P2P PW LDP Applications  Feb 2013 
 

   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 

   Currently, no LDP capability is exchanged for LDP applications like 
   IP Label Switching and L2VPN P2P PW signaling. When an LDP session 
   comes up, an LDP speaker may unnecessarily advertise its local state 
   for such LDP applications even when the peer session may be 
   established for some other applications like ICCP. This document 
   proposes a solution by which an LDP speaker announces to its peer its 
   disinterest in such non-negotiated applications. This, in turn, 
   disables the advertisement of corresponding application state, which 
   would have otherwise be advertised by default, over the established 
   LDP session. 

Table of Contents 

  1. Introduction                                                      3 
  2. Conventions used in this document                                 4 
  3. Non-negotiated LDP applications                                   4 
  4. Controlling State Exchange for Non-negotiated LDP Applications    5 
     4.1. Application Control Capability                               5 
  5. Capabilities Procedures                                           7 
     5.1. Application Control Capability in an Initialization message  8 
     5.2. Application Control capability in a Capability message       8 
  6. Operational Examples                                              8 
     6.1. Disabling IPoMPLS and P2P PW apps. on an ICCP session        9 
     6.2. Disabling IPoMPLS application on a L2VPN/PW T-LDP session    9 
     6.3. Disabling IPoMPLS app.dynamically on an estab. IP/PW session 9 
     6.4. Disabling unwanted state advertisement by a dual-stack LSR  10 
  7. Security Considerations                                          10 
  8. IANA Considerations                                              10 
  9. References                                                       11 
     9.1. Normative References                                        11 
     9.2. Informative References                                      11 
  10. Acknowledgments                                                 12 
    

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

            
Internet-Draft  Disabling IPoMPLS and P2P PW LDP Applications  Feb 2013 
 

1. Introduction 

  LDP Capabilities [RFC5561] introduced a mechanism to negotiate LDP 
  capabilities for a given feature amongst peer 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.  
   
  While new LDP features and applications, such as Typed Wildcard FEC 
  [RFC5918], Inter-Chassis Communication Protocol [ICCP], mLDP 
  [RFC6388], and L2VPN P2MP PW [P2MP-PW] make use of LDP capabilities 
  framework for their feature negotiation, the earlier LDP features and 
  applications like IP Label Switching and L2VPN P2P PW signaling 
  [RFC4447] [RFC4762] may cause LDP speakers to exchange application 
  state unnecessarily even when the 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 
  PE LSR for purely ICCP signaling reasons, an LDP speaker may 
  unnecessarily advertise labels for IP (unicast) prefixes to this ICCP 
  related LDP peer as per its default behavior.  
   
  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 for both IPv4 and IPv6 label switching 
  may advertise address/label bindings for both IPv4 and IPv6 address 
  families towards an LDP peer that is interested in IPv4 only. In this 
  case, the advertisement of IPv6 addresses and IPv6 prefix labels 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 some sort 
  of filtering policies on the LSR for exchanging LDP applications 
  state, which introduces operational overhead and complexity.  
   
  This document proposes an LDP Capabilities [RFC5561] based solution 
  by which an LDP speaker may announce to its peer(s) its disinterest 
  (or non-support/disability) for IP Label Switching and/or L2VPN P2P 
  PW Signaling application at the time of session establishment. This 
  helps avoiding unnecessary state exchange for such feature 
   
 
Raza, et. al             Expires August 2013                   [Page 3] 

            
Internet-Draft  Disabling IPoMPLS and P2P PW LDP Applications  Feb 2013 
 

  applications. The proposal also states the mechanics to dynamically 
  disable or enable such an application during the session lifetime. 
  The document introduces a new LDP capability to implement this 
  proposal.  
   
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. 

   This document uses shorthand terms "IPoMPLS" to refer to IP Label 
   Switching application, and "P2P PW" to refer to L2VPN PW signaling 
   for FEC 128 and FEC 129 P2P Pseudowires.  

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 right 
   after the session establishment. These early LDP applications 
   include: 

   o  IPv4/IPv6 Label Switching ("IPoMPLS") 

   o  L2VPN P2P PW signaling ("P2P PW") 

   To disable unnecessary state exchange for such LDP applications, 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 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 any state related to the application towards the sender. This new 
     capability can also be sent later in a Capability message to either 
   disable enabled applications or to enable previously disabled 
   applications. 

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

            
Internet-Draft  Disabling IPoMPLS and P2P PW LDP Applications  Feb 2013 
 

4. Controlling State Exchange for Non-negotiated LDP Applications 

   To control advertisement of state related to non-negotiated LDP 
   applications, namely IPoMPLS and P2P PW signaling, a new capability 
   TLV is defined as follows. 

4.1. Application Control Capability 

   The "Application 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: 

    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| App Control Cap.  (IANA)  |           Length              | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
   |S|  Reserved   |                                               | 
   +-+-+-+-+-+-+-+-+ 
   |                                                               | 
   ~               Application Control Element(s)                  ~  
   |                                                               | 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
      Figure 1: Format of an "Application 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 both in an Initialization and Capability 
   message.  
    
     The capability data associated with this TLV is one or more 
   Application Control Elements, where each element indicates 
   enabling/disabling of state advertisement for a given application. 
   The format of an Application Control Element is defined as follows: 
 
                      0                   1 
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
                     |AppType|D|Rsvd1|    Rsvd2      | 
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
    
          Figure 2: Format of an "Application Control Element"
 
 
Raza, et. al             Expires August 2013                   [Page 5] 

            
Internet-Draft  Disabling IPoMPLS and P2P PW LDP Applications  Feb 2013 
 

    
   Where: 
    
  AppType: Defines the (non-negotiated) application type. The value of 
    this field is defined as:  
       1: IPv4 Label switching 
       2: IPv6 Label switching 
       3: P2P PW FEC128 signaling 
       4: P2P PW FEC129 signaling 
    0, 5-15: Reserved. 
    
   D bit: Controls the advertisement of state for the application: 
       1: Disable state advertisement 
       0: Enable state advertisement 
      When sent in an Initialization message, D bit MUST be set to 1. 
    
   Rsvd1, Rsvd2: Reserved for future use. MBZ on transmit and ignored on 
    receipt. 
 
   The "Length" field of "Application Control Capability" TLV depends on 
   the number of Application Control Elements present in the TLV. For 
   example, if there are two elements present, then the Length field is 
   set to 5 octets. A receiver of this capability TLV can deduce number 
   of application control elements present in the TLV by using Length 
   field.  
    
   From now onward, this document uses the term "element" to refer to an 
   Application Control Element. 
     
   As described earlier, "Application Control 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. An "Application Control Capability" TLV MUST contain 
   elements with distinct application types and the TLV MUST NOT contain 
   the same application type more than once. If a receiver receives such 
   a malformed TLV, it SHOULD discard this TLV and continue processing 
   rest of the message. 

   To control more than one application, 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 for a given application type as an update to its 
   existing policy for given type.  
 
 
Raza, et. al             Expires August 2013                   [Page 6] 

                     
Internet-Draft  Disabling IPoMPLS and P2P PW LDP Applications  Feb 2013 
 

   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 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 an Application Control capability in the Initialization 
   message with "IPv6 Label switching" and "P2P PW FEC129" applications 
   disabled. This updates P's outbound policy towards S to advertise 
   state related to only "IPv4 Label switching" and "P2P PW FEC 128" 
   applications.  Later, P receives another capability update from S via 
   a Capability message with "IPv6 Label switching" enabled and "P2P PW 
   FEC128" disabled. This results in P's outbound policy towards S to 
   advertise both IPv4 and IPv6 Label switching state, and disable both 
   P2P PW FEC128 and FEC 129 signaling. Finally, P receives another 
   update from S via a Capability message that specifies to disable all 
   four non-negotiated applications, resulting P outbound policy towards 
   S to block/disable state for all these applications, and only 
   advertise state for any other application, if present. 

  5. Capabilities Procedures 

   The "Application Control" capability conveys the desire of an LSR to 
   disable receipt of unwanted/unnecessary state from its LDP peer. This 
   capability is uni-lateral and uni-directional in nature, and a 
   receiving LSR is not required to send a similar capability TLV in an 
   Initialization or Capability message towards the sender. 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 applications are 
   explicitly enabled again via a capability update.  

   If a receiving LDP speaker does not understand the Application 
   Control 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 August 2013                   [Page 7] 

            
Internet-Draft  Disabling IPoMPLS and P2P PW LDP Applications  Feb 2013 
 

5.1. Application 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 IPoMPLS and/or P2P PW 
   applications with a peer LSR. If there is a need to disable, then the 
   "Application Control Capability" TLV needs to be included in the 
   Initialization message with respective application control elements 
   included with their D bit set to 1.   
     An LDP speaker that supports the "Application Control" 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 IPoMPLS and/or P2P PW 
   applications if their application control element's D bit is set to 
   1.  

5.2. Application Control capability in a Capability message 

   If the LDP peer supports "Dynamic Announcement Capability" [RFC5561], 
   then an LDP speaker may send Application Control 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 IPoMPLS and/or P2P PW signaling applications get 
   disabled, or if previously disabled application gets enabled again. 
   In this case, the LDP speaker constructs the TLV with appropriate 
   application control 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 application state from/to the capability sending 
   LDP speaker according to the capability update.  

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

            
Internet-Draft  Disabling IPoMPLS and P2P PW LDP Applications  Feb 2013 
 

6. Operational Examples 

6.1. Disabling IPoMPLS and P2P PW applications on an ICCP session 

   Consider two PE routers, LSR1 and LSR2, which understand/support 
   "Application Control" capability TLV, and have an established LDP 
     session to exchange ICCP state related to dual-homed devices 
   connected to these LSRs. Let us assume that both LSRs are 
   provisioned not to exchange any state for IPoMPLS (IPv4/IPv6) and 
   P2P PW (FEC128/129) application. 

   To indicate their disinterest in these applications, the LSRs will 
   include an "Application Control" capability TLV (with 4 application 
   control 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 advertisement of IPv4/IPv6 bindings (addresses and labels), 
   as well as P2P PW FEC128/129 signaling, towards its peer after 
   session establishment. 

6.2. Disabling IPoMPLS application on a L2VPN/PW T-LDP session 

   Now, consider LSR1 and LSR2 have an established T-LDP session for 
   P2P PW application to exchange label bindings for FEC 128/129. Given 
   that there is no need to exchange IP (v4/v6) address/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 
   IPoMPLS (IPv4/IPv6)application on given PW session.  

   To indicate their disinterest in IPoMPLS application over PW T-LDP 
   session, the LSRs will follow/apply the same procedures to disable 
   IPv4 and IPv6 label switching as described in previous section. As a 
   result, only P2P PW related state will be exchanged between these 
   LSRs over this T-LDP session. 

6.3. Disabling IPoMPLS application dynamically on an established IP/PW 
   session 

   Assume that LSRs from previous sections were initially provisioned to 
   exchange both IPoMPLS and P2P PW state over the session between them, 
   and also support "Dynamic Announcement" Capability [RFC5561]. Now, 
   assume that LSR1 is dynamically provisioned to disable IPoMPLS 
   (IPv4/IPv6) over T-LDP session with LSR2. In this case, LSR1 will 
   send Application Control capability TLV in a Capability message 
   towards LSR2 with application control elements defined for IPv4 and 
   IPv6 label switching with D bit set to 1. Upon receipt of this TLV, 
 
 
Raza, et. al             Expires August 2013                   [Page 9] 

            
Internet-Draft  Disabling IPoMPLS and P2P PW LDP Applications  Feb 2013 
 
     LSR2 will disable IPoMPLS application(s) towards LSR1 and withdraw 
   all previous IP label/address state from LSR1. To withdraw label and 
   address bindings from its peer, LSR2 MAY use a single Prefix FEC 
   Typed Wildcard Label Withdraw message [RFC5918] and an Address 
   Withdraw message respectively.  

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

6.4. Disabling unwanted state advertisement by an IP dual-stack LSR 

   In IP dual-stack scenarios, an LSR2 may advertise unnecessary state 
   (label/address bindings) towards peer LSR1 corresponding to IPv6 
   label switching application once a session is established mainly for 
   exchanging state for IPv4. The similar scenario also applies when 
   advertising IPv4 label switching state on a session meant for IPv6. 
   The Application Control 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 IPoMPLS 
   application for both IPv4 and IPv6, but LSR1 is enabled for (or 
   interested in) only IPv4oMPLS. To avoid receiving unwanted state 
   advertisement for IPv6oMPLS application from LSR2, LSR1 can send 
   "Application Control" capability with element for IPv6 label 
   switching 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 and address binding 
   advertisement towards LSR1. If IPv6oMPLS is later enabled on LSR1, 
   LSR1 can update the capability by sending Application Control 
   capability in Capability message towards LSR2 to enable IPv6oMPLS 
   application dynamically. 

   [LDPv6] specification section 7 also suggests an alternate way to 
   avoid the unnecessary state advertisement in the above scenario.  

7. 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]. 
   
8. IANA Considerations 

  The document defines a new capability parameter TLV and requests 
 
 
Raza, et. al             Expires August 2013                  [Page 10] 

            
Internet-Draft  Disabling IPoMPLS and P2P PW LDP Applications  Feb 2013 
 

  following LDP TLV code point assignment by IANA from LDP "TLV Type 
  Name Space" registry: 
   
   o  "Application Control Capability" TLV (requested codepoint: 0x50C) 

 
9. References 

9.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. 

9.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-09.txt, Work in Progress, 
             July 2012. 

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

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

     
Internet-Draft  Disabling IPoMPLS and P2P PW LDP Applications  Feb 2013 
 

   [LDPv6]   R. Asati, et al., "Updates to LDP for IPv6", draft-ietf-
             mpls-ldp-ipv6-07.txt, Work in Progress, June 2012. 

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

10. Acknowledgments 

   The authors would like to thank Eric Rosen for his valuable input and 
   comments. 

   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 August 2013                  [Page 12]