MPLS Working Group Kamran Raza Internet Draft Sami Boutros Intended status: Standards Track Expires: February 17, 2013 Cisco Systems August 18, 2012 Disabling IPoMPLS and P2P PW LDP Applications draft-ietf-mpls-ldp-ip-pw-capability-02.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 February 17, 2013. Copyright Notice Copyright (c) 2012 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 February 2013 [Page 1] Internet-Draft Disabling IPoMPLS and P2P PW LDP Applications August 2012 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 its disinterest in such non-negotiated application. 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 7 5.2. Application Control capability in a Capability message 8 6. Operational Examples 8 6.1. Disabling IPoMPLS and P2P PW application on an ICCP session 8 6.2. Disabling IPoMPLS application on a L2VPN/PW T-LDP session 9 6.3. Disabling IPoMPLS appl. dynamically on an IP/PW session 9 6.4. Disabling unwanted state advert. by an IP dual-stack LSR 10 7. Security Considerations 10 8. IANA Considerations 10 9. Conclusions 11 10. References 11 10.1. Normative References 11 10.2. Informative References 11 11. Acknowledgments 12 Raza, et. al Expires February 2013 [Page 2] Internet-Draft Disabling IPoMPLS and P2P PW LDP Applications August 2012 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 corresponding feature capability is successfully negotiated between peers. While new LDP features and applications, such as Typed Wildcard FEC [RFC5918], Inter-Chassis Communication Protocol [ICCP], mLDP [RFC6388], and 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 unnecessary state exchange between LDP peers 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 purposes, the 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 used 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 IPv4 prefix labels to the peer is unnecessary, as well as wasteful from LSR memory/CPU and network resource consumption point of view. 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 box for LDP state exchange, which introduces operational overhead and complexity. This document proposes an LDP Capabilities [RFC5561] based solution by which an LDP speaker may announce its disinterest (or non- support/disability) to its peer 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 February 2013 [Page 3] Internet-Draft Disabling IPoMPLS and P2P PW LDP Applications August 2012 applications. The proposal also states the mechanics to disable or enable an application dynamically 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 unicast" 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 PWs. 3. Non-negotiated LDP applications For the applications that existed before LDP Capabilities [RFC5561] procedures were defined, an LDP speaker typically advertises relevant application state to its peers after session establishment without waiting for any capabilities exchange and negotiation. These LDP applications are: 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 LDP 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, MUST disable the advertisement of any state related to the application towards the sender. Moreover, the sender LSR SHOULD also disable the advertisement of corresponding application state towards the peer. This new capability can also be sent later in a Capability message to either disable these applications, or to enable previously disabled applications dynamically. Raza, et. al Expires February 2013 [Page 4] Internet-Draft Disabling IPoMPLS and P2P PW LDP Applications August 2012 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 TLVs 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 and hence the S-bit MUST be set to 1 both in Initialization message and Capability message. The capability data associated with this TLV is one or more Application Control Elements, where each element defines 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | App |D|Rsvd1| Rsvd2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Format of an "Application Control Element" Raza, et. al Expires February 2013 [Page 5] Internet-Draft Disabling IPoMPLS and P2P PW LDP Applications August 2012 Where: App: Defines the (non-negotiated) application type. The value of this field is defined as: 0: IPv4 Label switching 1: IPv6 Label switching 2: P2P PW FEC128 signaling 3: P2P PW FEC129 signaling 4-15: Reserved. D bit: Controls the advertisement of state for the application as follows 1: Disable state advertisement 0: Enable state advertisement 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. For now onward, this document uses 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 a 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. 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 message with capability TLV as an incremental update to the existing control. To understand capability updates from an example, let us consider 2 LSR peers, R1 (sender) and R2 (receiver), both of which support all the non-negotiated applications listed earlier. By default, these LSR will advertise state for these applications to their peer as soon as Raza, et. al Expires February 2013 [Page 6] Internet-Draft Disabling IPoMPLS and P2P PW LDP Applications August 2012 an LDP session is established. Now assume that R2 receives an Application Control capability in the Initialization message with "IPv6 Label switching" and "P2P PW FEC129" applications disabled. This updates R2's outbound policy towards R1 to advertise state related to only "IPv4 Label switching" and "P2P PW FEC 128" applications. Now, R2 receives a capability update from R1 via a Capability message with "IPv6 Label switching" enabled and "P2P PW FEC128" disabled. This updates R2's outbound policy towards R1 to advertise both IPv4 and IPv6 Label switching state, and disable both P2P PW FEC128 and FEC 129 signaling. Finally, R2 receives another update from R1 via Capability message that specifies to disable all 4 non-negotiated applications, resulting R2 outbound policy towards R1 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 a sending LSR to disable receipt of unwanted/unnecessary state from a peer. Hence, this capability is unilateral 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 also conforms to the procedures defined in the Section 6 of LDP Capabilities [RFC5561]. After this capability is successfully negotiated (i.e. sent by a sender and received/understood by the receiver), then both participating LSRs MUST NOT exchange any state related to the disabled applications 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]. Upon receipt of such Notification, the sender MAY still continue to block/disable its outbound state advertisement towards the peer for the requested disabled applications. 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. 5.1. Application Control Capability in an Initialization message LDP Capabilities [RFC5561] dictate that the S-bit of capability parameter in an Initialization message MUST be set to 1 and SHOULD be ignored on receipt. Raza, et. al Expires February 2013 [Page 7] Internet-Draft Disabling IPoMPLS and P2P PW LDP Applications August 2012 An LDP speaker determines (e.g. via some local configuration or default policy) if they need 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 sender 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 any of its IPoMPLS and/or P2P PW signaling applications get disabled, or if previously disabled application gets enabled again. In this case, LDP speaker constructs the TLV with appropriate application control elements and sends the corresponding capability TLV in a Capability message. Furthermore, the LDP speaker also withdraws/advertises application(s) related state (such as address/label bindings) from/to its peer according to the capability update. 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 receiving LDP speaker withdraws/advertises application state from/to the sending peer according to the capability update. 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 due to ICCP application in order to exchange ICCP state related to dual-homed devices connected to these LSRs. Let us assume that LSR1 is provisioned not to exchange any state for IPoMPLS (IPv4/IPv6) and P2P PW (FEC128/129) application with LSR2. Raza, et. al Expires February 2013 [Page 8] Internet-Draft Disabling IPoMPLS and P2P PW LDP Applications August 2012 To indicate its disinterest in these applications, the LSR1 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 LSR2 will disable advertisement of IPv4/IPv6 bindings (addresses and labels), as well as P2P PW FEC128/129 signaling, towards LSR1 after session establishment. The LSR1 will also disable similar state advertisement for these applications towards LSR2 independently, irrespective of the fact whether or not LSR2 could disable the corresponding application state advertisement towards LSR1. 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 just to exchange label bindings for FEC 128/129. Since in most typical deployments, there is no need to exchange IP (v4/v6) address/label bindings amongst the PE LSRs, let us assume that LSR1 is provisioned to disable IPoMPLS (IPv4/IPv6)application on given PW session towards LSR2. To indicate its disinterest in IPoMPLS application over PW T-LDP session, the LSR1 will follow/apply the same procedures to disable IPv4 and IPv6 label switching as described in previous section. Similarly, LSR2 will behave accordingly by disabling state advertisement for IPoMPLS application towards LSR1. 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 first disable its future outbound application state towards LSR2, and also withdraw all its previously advertised IPoMPLS state (labels and addresses) by sending a single Prefix FEC Typed Wildcard Label Withdraw message [RFC5918], and an Address Withdraw message respectively towards LSR2. LSR1 will also 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, LSR2 will also disable IPoMPLS applications towards LSR1 and withdraw all previous IP label/address state using the same mechanics as described earlier for LSR1. This Raza, et. al Expires February 2013 [Page 9] Internet-Draft Disabling IPoMPLS and P2P PW LDP Applications August 2012 dynamic disability of IPoMPLS application will 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 following a new capability parameter TLV and requests following LDP TLV code point assignment by IANA from LDP "TLV Type Name Space" registry: o "Application Control Capability" TLV (requested codepoint: 0x50C) Raza, et. al Expires February 2013 [Page 10] Internet-Draft Disabling IPoMPLS and P2P PW LDP Applications August 2012 9. Conclusions The document proposed a solution using LDP Capabilities [RFC5561] mechanics to disable unnecessary state exchange, if/as desired, between LDP peers for currently non-negotiated IP/PW LDP applications. 10. References 10.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. 10.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, October 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. [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 February 2013 [Page 11] Internet-Draft Disabling IPoMPLS and P2P PW LDP Applications August 2012 [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. 11. 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 February 2013 [Page 12]