PALS Working Group Patrice Brissette Internet Draft Kamran Raza Intended Status: Proposed Standard Sami Boutros Expires: April 26, 2015 Cisco Systems, Inc. Nick Del Regno Matthew Turlington Verizon June 29, 2015 Handling Incoming Label Request for PW FEC Types draft-brissette-pals-pw-fec-label-request-01 Abstract This document clarifies the behavior of an LSR PE upon receiving an LDP Label Request message for Pseudowire (PW) FEC types. Furthermore, this document specifies the procedures to be followed by the LSR PE in order to answer such requests for a given PW FEC type. Status of this Memo This Internet-Draft is submitted to IETF 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Brissette, et. al Expires April 26, 2015 [Page 1] Internet-Draft draft-pwe3-pw-fec-label-request June 20, 2015 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. Convention 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 [RFC2119]. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 PWid FEC (FEC128) . . . . . . . . . . . . . . . . . . . . . 5 3.2 Generalized PWid FEC (FEC129): . . . . . . . . . . . . . . . 5 3.3 Common to PWid and Generalized PWid FEC . . . . . . . . . . 5 3.4 P2MP PW Upstream FEC (FEC130): . . . . . . . . . . . . . . . 5 3.5 P2MP PW Downstream FEC (FEC132): . . . . . . . . . . . . . . 5 3.5 PW Typed Wildcard FEC . . . . . . . . . . . . . . . . . . . 5 4 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 5 5 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7.1 Normative References . . . . . . . . . . . . . . . . . . . 7 7.2 Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Brissette, et. al Expires April 26, 2015 [Page 2] Internet-Draft draft-pwe3-pw-fec-label-request June 20, 2015 1 Introduction Label Distribution Protocol (LDP) base specification [RFC5036] defines different LDP message types and their procedures for advertising label bindings. These procedures are generic and inherited by any FEC type that is advertised using these message types. For a given FEC type, any difference in behavior, compared to what is already specified in RFC 5036, needs to be spelled out clearly in the corresponding specification in which the FEC type is being introduced or extended. [RFC4447] specifies mechanisms to setup pseudowires (PWs) using LDP. [RFC4447] does not specify any behavior change with regards to label binding distribution for PW FEC types in response to a corresponding Label Request message from a peer LSR PE. This implies that [RFC4447] inherits the base procedures defined in [RFC5036] for Label Request and associated response for a PW FEC type. The lack of specification in the area of Label Request in [RFC4447] has led to some interoperability issues between vendors due to different interpretation. For example, there are some implementations which do not honor and do not respond to an incoming Label Request for a PW FEC type, resulting in functionality impact. Some of these problems are very critical for the deployment of PW technologies. The following is a non-exhaustive list of some of the problems and potential breakages that may result due to the lack of support of incoming Label Request for a PW FEC: - An LSR PE can not restart forwarding of packet with sequence number 1 as specified in section 4.1 of [RFC4385] with regards to Control Word Sequencing. - An LSR PE may not be able to perform a PW consistency check as defined in section 4.1 of [RFC6667], resulting in LSR PEs becoming out-of-sync. - Some implementations of LSR PE do not checkpoint PW label bindings learnt from peer(s) in their persistent memory and hence are not able to recover any peer state after their own restarts or switchovers. Such implementations typically require re-learning of peer's label bindings after their own failure and rely on Label Request mechanisms. - The combination of Downstream Unsolicited mode and Conservative Label retention (used due to memory limitations) can lead to a situation where an LSR PE releases the label learnt from a peer for a PW that it may need later. Label Request is used to solve this issue. For example, consider an LSR PE operating in Label Conservative mode receiving a label binding for a Brissette, et. al Expires April 26, 2015 [Page 3] Internet-Draft draft-pwe3-pw-fec-label-request June 20, 2015 non-locally configured/known PW. This LSR PE ignores such a label binding and later tries to re-learn it via Label Request procedure once PW is locally configured. The authors will like to remind the readers about the following fact: [RFC4447] does not mandate to use Label Liberal mode. Therefore it is possible that some implementation used Label Conservative mode. This document clarifies the use of Label Request message and its procedures for PW FEC types and re-enforces the acceptable behavior to be implemented by an LSR PE. 2. Requirements This document recommends the following action to be implemented by an LSR PE that supports a PW FEC Type (P2P or P2MP type): - An LSR PE MUST respond to an incoming Label Request message for a PW FEC by sending its local binding for the PW via a Label Mapping message. If no such binding is available, the LSR PE SHOULD respond by sending a new status code "No PW" in a Notification message. - An LSR PE MUST respond to an incoming Label Request message for a Wildcard FEC [RFC5036] by sending its local bindings for all its PWs via Label Mapping messages. This is in addition to label bindings corresponding to any other LDP FEC types configured and available at the LSR. - An LSR PE MUST respond to an incoming Label Request message for a Typed Wildcard PW FEC [RFC6667] by sending its local bindings for all its PWs for the given FEC type via Label Mapping messages. For a given PW FEC type, this advertisement is to be scoped either for a specific PW type or for all PW types according to the received PW Typed Wildcard FEC. 3. Procedures This document re-enforces the Label Request generic procedures, as defined by RFC 5036, for PW FEC types, and hence strongly recommends that an LSR PE receiving the PW Label Request message should respond either by sending its label binding in Label Mapping message(s) or with a Notification message indicating why it cannot satisfy the request. An LSR PE should respond to a Label Request when corresponding PW FEC is resolved locally. The following sub sections define the meaning of a "resolution" for a given PW FEC type. Brissette, et. al Expires April 26, 2015 [Page 4] Internet-Draft draft-pwe3-pw-fec-label-request June 20, 2015 3.1 PWid FEC (FEC128) A PWid FEC is resolved when a local label binding has been allocated after local configuration application. [RFC6073] does not preclude setting up MS-PWs using FEC-128, therefore this procedure is also applicable to PEs acting as S-PEs. 3.2 Generalized PWid FEC (FEC129): A Generalized PWid FEC is resolved at an ST-PE when SAII is locally configured, TAII is learnt statically or dynamically via discovery mechanisms, and a local label binding has been allocated. This FEC is resolved at an TT-PE when SAII is locally configured, TAII is learnt statically or dynamically via discovery mechanisms, remote label binding is received, and a local label binding has been allocated. Whereas, this FEC is resolved at an S-PE when remote label binding is received for PW segment, TAII is learnt statically or dynamically via discovery mechanisms, and a local label binding has been allocated. 3.3 Common to PWid and Generalized PWid FEC A FEC is resolved at an S-PE when remote label binding is received for PW segment. In the case of Generalized PWid FEC, TAII is learnt statically or dynamically via discovery mechanisms, and a local label binding has been allocated. Whereas PWid FEC is resolved when a local binding has been allocated. 3.4 P2MP PW Upstream FEC (FEC130): Editor Note: Deferred for further study. 3.5 P2MP PW Downstream FEC (FEC132): Editor Note: Deferred for further study. 3.5 PW Typed Wildcard FEC The rules defined for individual PW FEC types apply equally when they are used under a PW Typed Wildcard FEC [RFC6667]. 4 Acknowledgements Brissette, et. al Expires April 26, 2015 [Page 5] Internet-Draft draft-pwe3-pw-fec-label-request June 20, 2015 The authors would like to thank for Alexander Vainshtein its reviews and comments of this document. 5 Security Considerations This document does not introduce any additional security constraints. 6 IANA Considerations This document requires the assignment of a new LDP Status Code to be used in a Notification message to notify a peer LSR if lookup fails at receiving LSR for a PW FEC received in a Label Request message. The value requested from the IANA managed LDP registry "LDP Status Code Name Space" is: Brissette, et. al Expires April 26, 2015 [Page 6] Internet-Draft draft-pwe3-pw-fec-label-request June 20, 2015 Range/Value E Description ----------- --- ----------- 0x00000032 0 No PW 7 References 7.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007. [RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006. [RFC6667] Raza, K., Boutros, S., and Pignataro, C., "LDP Typed Wildcard FEC for PWid and Generalized PWid FEC", RFC 6667, July 2012. 7.2 Informative References Authors' Addresses Patrice Brissette Cisco Systems, Inc. 2000 Innovation Drive Kanata, ON K2K-3E8, Canada. EMail: pbrisset@cisco.com Kamran Raza Cisco Systems, Inc. 2000 Innovation Drive Kanata, ON K2K-3E8, Canada. EMail: skraza@cisco.com Sami Boutros Cisco Systems, Inc. 3750 Cisco Way, San Jose, CA 95134, USA. E-mail: sboutros@cisco.com Nick Del Regno Brissette, et. al Expires April 26, 2015 [Page 7] Internet-Draft draft-pwe3-pw-fec-label-request June 20, 2015 Verizon 400 International Pkwy Richardson, TX 75081, USA. E-mail: nick.delregno@verizon.com Matthew Turlington Verizon 400 International Pkwy Richardson, TX 75081, USA. E-mail: matt.turlington@verizon.com Brissette, et. al Expires April 26, 2015 [Page 8]