Internet DRAFT - draft-li-pce-bfd

draft-li-pce-bfd






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,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              DOI 10.17487/RFC4379, February 2006,
              <http://www.rfc-editor.org/info/rfc4379>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <http://www.rfc-editor.org/info/rfc5440>.






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,
              <http://www.rfc-editor.org/info/rfc5880>.

   [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, <http://www.rfc-editor.org/info/rfc5884>.

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]