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]
