Network Working Group Z. Li Internet-Draft X. Chen Intended status: Informational Huawei Technologies Expires: September 19, 2016 March 18, 2016 PCEP Extensions for Bidirectional Forwarding Detection draft-li-pce-bfd-00 Abstract This document describes the extensions to the PCEP to notify BFD parameters for LSPs from PCE to PCC for PCE-initiated LSP. The extensions include BFD protocol parameters and allow PCC to support BFD for PCE-Initiated LSP whose BFD session is a bi-directional co- routed channel. Requirements Language 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]. 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). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 19, 2016. Copyright Notice Copyright (c) 2016 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 Li & Chen Expires September 19, 2016 [Page 1] Internet-Draft PCEP Extensions for BFD March 2016 publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Bootstrapping Bi-directional Co-routed BFD Session . . . . . 3 3.1. Bootstrapping BFD session without LSP Ping . . . . . . . 3 3.2. Bootstrapping BFD session with LSP Ping . . . . . . . . . 4 4. TLVs of PCEP Extensions for BFD . . . . . . . . . . . . . . . 4 4.1. BFD Reverse Path TLV . . . . . . . . . . . . . . . . . . 4 4.2. BFD Generic TLV . . . . . . . . . . . . . . . . . . . . . 5 4.3. BFD Authentication TLV . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction RFC 5884 [RFC5884] describes the applicability of BFD in relation to LSP Ping for detecting rapidly a Multiprotocol Label Switching (MPLS) Label Switched Path (LSP) data plane failure. It also describes procedures for using BFD in MPLS environment. The LSP BFD detecting can be bidirectional LSP or unidirectional LSP(so long as there is some return path). If the path from ingress LSR to egress LSR is not co-routed with the path from egress LSR to ingress LSR, the failure to deliver BFD control packets from egress LSR to ingress LSR can lead to false negatives, making ingress LSR deduces that the LSP has failed. I-D.ietf-pce-pce-initiated-lsp [I-D.ietf-pce-pce-initiated-lsp] introduces the procedure of PCE-initiated LSPs under the stateful PCE model. PCC will automatically set up the MPLS RSVP-TE LSP according to the explicit path PCE provides. BFD session for the PCE-initiated LSP can also be created dynamically and the return path is implicitly the shortest path. Such BFD session whose forward and reverse paths are possibly not co-routed has the same problem as mentioned above. This document describes the extensions to the PCEP to notify BFD parameters for LSPs from PCE to PCC for PCE-initiated LSP. The extensions allow PCC to set up BFD session for PCE-Initiated LSP. Li & Chen Expires September 19, 2016 [Page 2] Internet-Draft PCEP Extensions for BFD March 2016 The BFD control packets can be exchanged over a bi-directional co- routed channel. The BFD protocol parameters such as detection time multiplier, desired Min TX Interval, required Min RX Interval for PCE-initiated LSP come from the public template or global configuration on PCC. The extensions of PCEP include generic BFD protocol parameters too. It can be used to notify PCC by PCE to adjust these parameters for special LSP. 2. Terminology BFD: Bidirectional Forwarding Detection LSP: Label Switching Path This document uses the following terms defined in RFC 5440 [RFC5440]: PCC, PCE, PCEP. The following term is defined in I-D.ietf-pce-pce-initiated-lsp [I-D.ietf-pce-pce-initiated-lsp]: PCE-initiated LSP: LSP that is instantiated as a result of a request from the PCE. 3. Bootstrapping Bi-directional Co-routed BFD Session PCE computes the path for one LSP from the ingress LSR to egress LSR and initiates the creation of this LSP on ingress LSR. The LSP is called as LSP1. PCE can initiate the creation of LSP on egress LSR according to the co-routed path from egress LSR to ingress LSR. The LSP is called as LSP2. To make the BFD session for LSP1 over the co-routed path to avoid the false detection there are two solutions as below: 3.1. Bootstrapping BFD session without LSP Ping BFD for MPLS LSP uses LSP Ping carrying local descriminator to bootstrapping BFD session in order to associate the FEC representing the LSP with the BFD session indicated by descriminators. But PCE knows the two co-routed LSPs and can allocate the pair of descriminators for the co-routed LSPs. PCE notify ingress LSR and egress LSR to set up BFD session for LSP1 by the BFD extensions of PCEP the pair of descriminators and notify PCC not necessary to send LSP ping message and directly to set up BFD Li & Chen Expires September 19, 2016 [Page 3] Internet-Draft PCEP Extensions for BFD March 2016 session. My descriminator in BFD control packets along LSP1 is your descriminator in BFD control packets along LSP2 and vice versa. By this method the same BFD session is set up not only for LSP1 but also LSP2. How to guarantee the descriminators allocated by PCE and PCC are not the same is out of scope of this document. 3.2. Bootstrapping BFD session with LSP Ping I-D.ietf-mpls-bfd-directed [I-D.ietf-mpls-bfd-directed] defines the BFD Reverse Path TLV as an extension to LSP Ping RFC 4379 [RFC4379] and proposes that it to be used to instruct the egress BFD peer to use specified path for its BFD control packets associated with the particular BFD session. After PCE initiates PCC to set up the LSP PCC delegates the MPLS RSVP-LSP with LSP-IDENTIFIERS TLV including FEC information to PCE. Therefore after ingress LSR and egress LSR set up the LSP1 and LSP2 independently they will delegate the LSP1 and LSP2 FEC information to PCE independently. PCE notify ingress LSR to set up BFD session for LSP1 carrying the FEC information about the reverse LSP, LSP2. The information received by ingress LSR via PCEP can be set to the BFD Reverse Path TLV in the LSP Ping message. Following the procedure defined in [draft-ietf-mpls-bfd-directed-02] the BFD session would be a bi- directional co-routed channel and no false detection would be notified. PCE notify Egress LSR to set up BFD session for LSP2 following the same process above. By this method two BFD sessions are set up for LSP1 and LSP2 independently. 4. TLVs of PCEP Extensions for BFD 4.1. BFD Reverse Path TLV The BFD Reverse Path TLV provides BFD parameters used to indicate the reverse path for BFD session. This is an optional TLV defined for the LSPA Object. This TLV is included in the LSPA Object with PCUpd message. Li & Chen Expires September 19, 2016 [Page 4] Internet-Draft PCEP Extensions for BFD March 2016 The format of the BFD Reverse Path TLV is shown in the following figure: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Reverse Path TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reverse Path | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BFD Reverse Path TLV BFD Reverse Path TLV Type is 2 octets in length and the value is to be assigned by IANA. Length is 2 octets in length and defines the length in octets of the Reverse Path field. Reverse Path refers to Reverse Path defined in BFD Reverse Path TLV in I-D.ietf-mpls-bfd-directed [I-D.ietf-mpls-bfd-directed]. 4.2. BFD Generic TLV The BFD Generic TLV provides BFD generic parameters of BFD session. This is an optional TLV defined for the LSPA Object. This TLV is included in the LSPA Object with PCInitiate or PCUpd message. The format of the BFD Generic TLV is shown in the following figure: Li & Chen Expires September 19, 2016 [Page 5] Internet-Draft PCEP Extensions for BFD March 2016 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Generic TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Detect Mult | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | My Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Your Discriminator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Desired Min TX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Required Min Echo RX Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BFD Generic TLV BFD Generic Path TLV Type is 2 octets in length and the value is to be assigned by IANA. Length is 2 octets in length and defines the fixed length 20. The value of TLV refers to Generic BFD Control Packet Format in RFC 5880 [RFC5880]. 4.3. BFD Authentication TLV The BFD Authentication TLV provides BFD authentication parameters of BFD session. This is an optional TLV defined for the LSPA Object. This TLV is included in the LSPA Object with PCInitiate or PCUpd message. The format of the BFD Generic Path TLV is shown in the following figure: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BFD Authentication TLV Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Auth Len | Authentication Data... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ BFD Authentication TLV Li & Chen Expires September 19, 2016 [Page 6] Internet-Draft PCEP Extensions for BFD March 2016 BFD Authentication TLV Type is 2 octets in length and the value is to be assigned by IANA. Length is 2 octets in length and defines the length in octets of the value of BFD Authentication TLV. The value of TLV refers to the optional Authentication Section in RFC 5880 [RFC5880]. 5. IANA Considerations TBD. 6. Security Considerations TBD. 7. Normative References [I-D.ietf-mpls-bfd-directed] Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, "Bidirectional Forwarding Detection (BFD) Directed Return Path", draft-ietf-mpls-bfd-directed-02 (work in progress), March 2016. [I-D.ietf-pce-pce-initiated-lsp] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP Extensions for PCE-initiated LSP Setup in a Stateful PCE Model", draft-ietf-pce-pce-initiated-lsp-05 (work in progress), October 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, DOI 10.17487/RFC4379, February 2006, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . Li & Chen Expires September 19, 2016 [Page 7] Internet-Draft PCEP Extensions for BFD March 2016 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, "Bidirectional Forwarding Detection (BFD) for MPLS Label Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, June 2010, . Authors' Addresses Zhenbin Li Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Xia Chen Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: jescia.chenxia@huawei.com Li & Chen Expires September 19, 2016 [Page 8]