Internet DRAFT - draft-zhang-bfd-new-use-cases

draft-zhang-bfd-new-use-cases



 



INTERNET-DRAFT                                              Mingui Zhang
Intended Status: Informational                              Zuliang Wang
                                                               Mach Chen
                                                                  Huawei
Expires: January 5, 2015                                    July 4, 2014

                Use Cases Requiring New Features of BFD
                  draft-zhang-bfd-new-use-cases-00.txt

Abstract

   This document describes some use cases arising from the deployment of
   BFD. These use cases are expected by ISPs but not supported by
   current BFD yet. Requirements are developed on basis of these use
   cases so that they can be taken into consideration in the future
   update of the BFD protocol. 

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.

   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
 


Mingui Zhang, et al     Expires January 5, 2015                 [Page 1]

INTERNET-DRAFT    Use Cases Requiring New BFD Features      July 4, 2014


   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  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2. Acronyms and Terminology  . . . . . . . . . . . . . . . . . . .  3
     2.1. Acronyms  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . .  3
   3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     3.1. Use Case #1: Reliable Detection for Multipath . . . . . . .  3
     3.2. Use Case #2: Application Consistence  . . . . . . . . . . .  4
     3.3. Use Case #3: Capability Inquiry and Feedback  . . . . . . .  5
     3.4. Use Case #4: State Relay  . . . . . . . . . . . . . . . . .  6
     3.5. Use Case #5: Detection of Asymmetric LSPs . . . . . . . . .  7
   4. Security Considerations . . . . . . . . . . . . . . . . . . . .  7
   5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  7
   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . .  7
   6. References  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
     6.1. Normative References  . . . . . . . . . . . . . . . . . . .  7
     6.2. Informative References  . . . . . . . . . . . . . . . . . .  8
   Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9






















 


Mingui Zhang, et al     Expires January 5, 2015                 [Page 2]

INTERNET-DRAFT    Use Cases Requiring New BFD Features      July 4, 2014


1. Introduction

   BFD is able to detect a network fault with a very low latency. It is
   designed to be independent of any media, data protocols, and routing
   protocols [RFC5880]. Today, it has been widely deployed in ISPs'
   networks and used by various applications. 

   Requirements for those BFD core use cases used to be generally
   fulfilled. However, there are also some use cases that do not fit
   current BFD. This document reveals five use cases arising from the
   real deployment of BFD but not supported yet. From these use cases,
   some basic requirements are extracted to be considered in the future
   when BFD is to be updated. This document aims to provide some
   information for the discussion on whether these use cases can be
   handled with a smooth update of the BFD protocol. 

2. Acronyms and Terminology

2.1. Acronyms

   BFD: Bidirectional Forwarding Detection

2.2. Terminology

   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].

   Familiarity with [RFC5880] is assumed in this document. 

3. Use Cases

3.1. Use Case #1: Reliable Detection for Multipath

                 +----+      +----+      +----+      +----+
                 |    +------+ R2 +------+ R3 +------+    |
                 |    |      +----+      +----+      |    |
                 | R1 |                              | R5 |
                 |    |      +----+                  |    |
                 |    +------+ R4 +------------------+    |
                 +----+      +----+                  +----+

          Figure 3.1. An example topology of BFD for OSPF ECMP

   Carrier networks widely adopt multipath techniques between two
   endpoints for the purpose of higher bandwidth and resilience, such as
   ECMP in OSPF/ISIS, Ethernet Link Aggregation (LAG), and MPLS Link
   Bundling [RFC4201]. If BFD is deployed on network devices, the
 


Mingui Zhang, et al     Expires January 5, 2015                 [Page 3]

INTERNET-DRAFT    Use Cases Requiring New BFD Features      July 4, 2014


   interface cards will be the components sending and receiving BFD
   control packets. If just one BFD session is set up for the pair of
   endpoints of the multipath, it's likely that the sending and
   receiving interface cards of data packets assigned by the flow-based
   load balance are not corresponding to those of BFD packets. Figure
   3.1 shows an example of BFD for OSPF ECMP. Suppose BFD is detecting
   the data path R1-R2-R3-R5 while R1 chooses the data path R1-R4-R5 as
   the forwarding path. The detection can't be accurate.

   In [RFC7130], for each enabled address family and each member link, a
   micro-BFD session is set up. Then the BFD packets can be
   demultiplexed based on the "Your Discriminator" field. However, this
   technique is only applicable for LAG links. For a plain multipath,
   logical member links usually can't be one-to-one mapped to those
   pairs of interface cards. Take the following figure for example, the
   head node R1 has three interface cards attached to the multipath,
   while the tail node R5 has two interface cards attached to the
   multipath.

               +----+      +----+      +----+      +----+
               |    +------+ R2 +------+ R3 +------+    |
               |    |      +----+      +----+      |    |
               | R1 |      +----+                  | R5 |
               |    +------+    |                  |    |
               |    |      | R4 +------------------+    |
               |    +------+    |                  +----+
               +----+      +----+

       Figure 3.2. Another example topology of BFD for OSPF ECMP

   Some operators have BFD running on the Master Board Card of the two
   endpoints. This introduces extra overhead to the Master Board and
   brings new security risk to client applications. The Master Board
   Card may change to slave mode, which will be mistakenly detected as a
   failure of the multipath. 

   In this use case, unless all interface cards fail at one end,
   carriers expect the multipath works, therefore BFD should not report
   a failure. Hence, BFD is required to be able to identify active
   interface cards on two endpoints. The endpoints should set up one
   session for the multipath based on any pair of active interface
   cards.

3.2. Use Case #2: Application Consistence




 


Mingui Zhang, et al     Expires January 5, 2015                 [Page 4]

INTERNET-DRAFT    Use Cases Requiring New BFD Features      July 4, 2014


               +----+ IGP/PIM/RSVP    IGP/PIM/RSVP +----+
               | R1 +------------------------------+ R2 |
               +----+                              +----+

      Figure 3.3. Client applications of the BFD are inconsistent

   Endpoint subscribes the BFD detection locally. If the two endpoints
   subscribing one BFD session with different applications while
   different applications claim different detection requirements, the
   BFD may malfunction. Take Figure 3.3 as an example, the pair of
   interface cards on R1 and R2 are multiply configured with
   IGP/PIM/RSVP. Assume IGP requires a transmit interval of 10
   milliseconds and a detection multiplier of 3 while PIM requires a
   transmit interval of 100 milliseconds and a multiplier of 5. Finally,
   the BFD session may achieve a detection time of 500 milliseconds. 

   The two endpoints are required to negotiate the detection
   requirements of the applications subscribing the same BFD session. If
   these requirements are inconsistent, the BFD session SHOULD not be
   established before the inconsistence is resolved.

3.3. Use Case #3: Capability Inquiry and Feedback

   If the local system restarts, it may resume the BFD session. Suppose
   the link has been failed or the peer has no resources to create the
   BFD session or the peer had been taken down administratively during
   the absence of the local system. Since no BFD control packets will be
   received from the peer system, the BFD will report a Down state.
   Rather, the real state of the forwarding path can either be Down or
   Up.

               +----+     capability inquiry->     +----+
               | R1 +------------------------------+ R2 |
               +----+   <-able/unable/no response  +----+

            Figure 3.4. BFD capability inquiry and feedback

   The local system is required to inquire the peer's BFD capability
   when the BFD session is resumed after the system reboots. The peer is
   required to feedback whether the BFD is able to be created as
   required. If the peer can establish the BFD session as required, the
   remote system MUST send a BFD Control packet in the detection time
   with the State field set to anything other than Up. This is shown in
   Figure 3.4. 

   o If the peer cannot establish the BFD session because it does not
     support the detection as required or it does not have the resource
     anymore to establish the BFD session or the BFD has been taken down
 


Mingui Zhang, et al     Expires January 5, 2015                 [Page 5]

INTERNET-DRAFT    Use Cases Requiring New BFD Features      July 4, 2014


     administratively, the peer MUST feedback it is unable to establish
     the session. If the feedback is received, the BFD MUST not report a
     Down state of the forwarding path. It's up to the application to
     determine the state of the forwarding path.

   o If no feedback is received from the peer in the detection time, the
     BFD will continue to report to the application that the forwarding
     path is in Down state.

   It's required that the above update is supported by both peering
   systems. In other words, this update is not backward compatible.

3.4. Use Case #4: State Relay

               +----+  L2VPN    +----+   L3VPN     +----+
               | R1 +-----------+ R2 +-------------+ R3 |
               +----+<-BFD S1-->+----+<--BFD S2--->+----+
                    |                              |
                    |<--------BFD S1+S2----------->|

                 Figure 3.5. BFD session concatenation

   End to end forwarding paths mixed with L2VPN and L3VPN tunnels are
   widely adopted in IPRAN. As shown in Figure 3.5, the tunnel between
   R1 and R2 and the tunnel between R2 and R3 are connected end-to-end
   in series. These three endpoints can establish two separate BFD
   sessions to detect the whole forwarding path. However, it's
   impossible for R1 and R3 to establish a single BFD session between
   each other.

   When the L2VPN tunnel fails, R1 and R2 are disconnected but R3 is
   unaware of the failure. R2 has to resort to the control plane of
   L3VPN to disseminate the failure. For example, R2 can withdraw the
   VPN route through BGP [RFC4364]. This will trigger the reconvergence
   of L3VPN. Usually, the reconvergence is slow and traffic being sent
   from R3 to R1 will suffer from a long time period of interruption. 

   Section 6.8.17 of [RFC5880] provides the Concatenated Paths
   mechanism. R2 can propagate the state of the BFD session S1 to S2
   through the diagnostic code. However, the indication of the failure
   requires the participation of the interworking system R2, which may
   become a heavy overhead when lots of paths need be concatenated.
   While this happens often in IPRAN.

   In this use case, carriers expect the state change of BFD session S1
   is relayed to R3 without the participation of the interworking system
   R2. R3 can immediately sense that R1 is not reachable and stop
   sending traffic to an obvious black-hole. It's also required that the
 


Mingui Zhang, et al     Expires January 5, 2015                 [Page 6]

INTERNET-DRAFT    Use Cases Requiring New BFD Features      July 4, 2014


   relations of the concatenation paths are relayed to R3 by R2 as well.
   In other words, R2 need transmit the correspondence (mapping) between
   the concatenated BFD sessions to R3 through the BFD control packet.

3.5. Use Case #5: Detection of Asymmetric LSPs

   A bidirectional LSP is probably adopting different forwarding paths
   for different directions. Suppose the ingress LSR set up the BFD
   session with Echo function enabled. When the echo packets are looped
   back, the other system chooses the forwarding path by default
   according to the IP forwarding path. If this forwarding path is
   different to the reverse forwarding path of the LSP, the BFD
   detection will be inaccurate. 

   The ingress LSR should be able to advertise in the BFD control
   packets whether the LSP reverse forwarding path should be used as the
   forwarding path for echo packets. If the ingress LSR is requiring the
   LSP reverse path as the forwarding path for echo packets, the egress
   LSR MUST loop back the echo packets according to the reverse path
   rather than the default IP forwarding path.

4. Security Considerations

   This document raises no new security issues.

5. IANA Considerations

   This document requires no IANA actions. RFC Editor: please remove
   this section before publication.

Acknowledgements

   Authors would like to thank the comments and suggestions from Marc
   Binderberger and Xudong Zhang.

6. References 

6.1. Normative References

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

   [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in
             MPLS Traffic Engineering (TE)", RFC 4201, October 2005.

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

 


Mingui Zhang, et al     Expires January 5, 2015                 [Page 7]

INTERNET-DRAFT    Use Cases Requiring New BFD Features      July 4, 2014


   [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
             (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June 2010.

   [RFC5882] Katz, D. and D. Ward, "Generic Application of Bidirectional
             Forwarding Detection (BFD)", RFC 5882, June 2010.

   [RFC7130] M. Bhatia, Ed., M. Chen, Ed., S. Boutros, Ed., M.
             Binderberger, Ed., J. Haas, Ed., "Bidirectional Forwarding
             Detection (BFD) on Link Aggregation Group (LAG)
             Interfaces", RFC 7130, February 2014.

6.2. Informative References

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

































 


Mingui Zhang, et al     Expires January 5, 2015                 [Page 8]

INTERNET-DRAFT    Use Cases Requiring New BFD Features      July 4, 2014


Author's Addresses


   Mingui Zhang
   Huawei Technologies
   No. 156 Beiqing Rd. Haidian District,
   Beijing 100095 
   P.R. China
   	
   Email: zhangmingui@huawei.com

   Zuliang Wang
   Huawei Technologies
   No. 156 Beiqing Rd. Haidian District,
   Beijing 100095 
   P.R. China
   	
   Email: zuni.wang@huawei.com

   Mach(Guoyi) Chen
   Huawei Technologies
   No. 156 Beiqing Rd. Haidian District,
   Beijing 100095 
   P.R. China

   EMail: mach@huawei.com

























Mingui Zhang, et al     Expires January 5, 2015                 [Page 9]