Internet DRAFT - draft-chen-mpls-bfd-enhancement

draft-chen-mpls-bfd-enhancement







Network Working Group                                            M. Chen
Internet-Draft                                                    Huawei
Intended status: Standards Track                                 S. Ning
Expires: July 3, 2015                                Tata Communications
                                                           V. Hallivuori
                                                     Tellabs Sinimaentie
                                                       December 30, 2014


                     BFD for MPLS LSPs Enhancement
                   draft-chen-mpls-bfd-enhancement-03

Abstract

   This document defines extensions to BFD for MPLS LSPs that can be
   used to specify the return path of BFD control packets for a specific
   BFD session.  Specifically, it re-uses the Reply Path TLV defined in
   RFC7110 to specify the return path.  Specifying congruent or more
   reliable return path increases robustness of BFD failure detection
   and reduces false positives.

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 July 3, 2015.








Chen, et al.              Expires July 3, 2015                  [Page 1]

Internet-Draft          Return Path Specified BFD          December 2014


Copyright Notice

   Copyright (c) 2014 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
   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.  Session Establishment . . . . . . . . . . . . . . . . . . . .   3
   3.  Using of Tunnel sub-TLVs  . . . . . . . . . . . . . . . . . .   3
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   7.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .   4
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   Bi-directional Forwarding Detection (BFD) [RFC5880] for Multiprotocol
   Label Switching (MPLS) is defined in [RFC5884], where Label Switched
   Path (LSP) Ping [RFC4379] is used to bootstrap the BFD session.

   In traffic engineered networks, LSPs usually do not follow IP routing
   or there are multiple LSPs between same nodes.  There is requirement
   to specify return path for a BFD session.  For example, selecting a
   more reliable return path (e.g., TE LSP with Fast ReRoute (FRR)
   protection) could improve the reliability of reply BFD control
   packets or selecting co-routed LSP would ensure that failures in
   other return paths (e.g.  shortest path for IP routing) do not cause
   BFD failure detection for the forward path.

   This document defines extensions to BFD for MPLS LSPs that can be
   used to specify the return path of BFD control packets for a specific
   BFD session.




Chen, et al.              Expires July 3, 2015                  [Page 2]

Internet-Draft          Return Path Specified BFD          December 2014


2.  Session Establishment

   All the procedures for session establishment defined in [RFC5884]
   apply here.  In addition to that, a RP TLV defined in [RFC7110] MUST
   be carried in the echo request and the reply mode MUST be set to
   "Reply via specified path".  This is used to notify the egress LSR to
   select the desired return path of the BFD session.

   The specific return path is identified by the FEC sub-TLV encoded in
   the RP TLV.  When the return path is required to follow the reverse
   direction of a bidirectional LSP (co-routed or associated).  It just
   needs to set the B bit of RP TLV, no specific reply path FEC sub-TLV
   is carried.

   When received an echo request with the reply mode set to "Reply via
   specified path" [RFC7110], if the receiver does not know the reply
   mode, an echo reply with the return code set to "Malformed echo
   request" and the Subcode set to zero SHOULD be send back to the
   initiator.  The BFD session will not be established in this case.

   When provisioning a single BFD to a bidirectional LSP, in case of the
   forwarding direction of session is OK but the reverse direction is
   not, the initiator MUST not send BFD control packets on the session
   until the echo reply is received from the terminator.  And the
   terminator MUST not send BFD control packets onto the BFD session
   until the first BFD control packet is received from the initiator.

3.  Using of Tunnel sub-TLVs

   IPv4/IPv6 RSVP and Static Tunnel sub-TLVs are defined in [RFC7110],
   which are used to notify the egress LSR of a specific LSP how to
   choose the return path for an echo reply.

   In this document, these sub-TLVs are re-used to notify the egress LSR
   of a specific LSP how to choose the return path of a BFD session.

   As stated above, it is possible to have multiple parallel LSPs
   between the ingress and egress LSRs.  In a typical network, a group
   of parallel LSPs have the same tunnel ID but different LSP IDs.
   There is one primary and one or more secondary LSPs in each
   direction.  When establishing a BFD session for an LSP, it is common
   for the primary LSP to choose the primary as the return path and the
   secondary LSP to choose the secondary as the return path.  With the
   IPv4/IPv6 Tunnel sub-TLVs, operators don't have to specify a specific
   return LSP.  They just need to specify from which tunnel the return
   LSP should be chosen, and specify the type (e.g., primary or
   secondary) of the return LSP.  The egress LSR will then choose the
   proper return path.



Chen, et al.              Expires July 3, 2015                  [Page 3]

Internet-Draft          Return Path Specified BFD          December 2014


   Use of IPv4/IPv6 RSVP and Static Tunnel sub-TLVs permits Make-Before-
   Break (MBB) on return path of BFD session.  If a specific LSP other
   than Tunnel would be selected, return path would be interrupted if
   egress node would do MBB for the return path.  This is due to the
   fact that MBB is based on signaling new LSP with different LSP ID and
   then deleting old LSP - after MBB selected return path would no
   longer be available.

4.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

5.  Security Considerations

   Security considerations discussed in [RFC5884], [RFC5880], [RFC5883],
   [RFC4379] and [RFC7110] apply to this document.

6.  Acknowledgements

   The authors would like to thank Greg Mirsky, Xinchun Guo and Wei Cao
   for their review and comments to this document.

7.  Contributors

   Vishwas Manral

   IP Infusion

   Almora, Uttarakhand India

   EMail: vishwas@ipinfusion.com

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5884]  Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
              "Bidirectional Forwarding Detection (BFD) for MPLS Label
              Switched Paths (LSPs)", RFC 5884, June 2010.






Chen, et al.              Expires July 3, 2015                  [Page 4]

Internet-Draft          Return Path Specified BFD          December 2014


   [RFC7110]  Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord,
              "Return Path Specified Label Switched Path (LSP) Ping",
              RFC 7110, January 2014.

8.2.  Informative References

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              February 2006.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, June 2010.

   [RFC5883]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for Multihop Paths", RFC 5883, June 2010.

Authors' Addresses

   Mach(Guoyi) Chen
   Huawei

   Email: mach.chen@huawei.com


   So Ning
   Tata Communications

   Email: ning.so@tatacommunications.com


   Ville Hallivuori
   Tellabs Sinimaentie

   Email: ville.hallivuori@tellabs.com

















Chen, et al.              Expires July 3, 2015                  [Page 5]