draft-ietf-bfd-seamless-use-case-00.txt   draft-ietf-bfd-seamless-use-case-01.txt 
INTERNET-DRAFT Sam Aldrin INTERNET-DRAFT Sam Aldrin
Intended Status: Informational (Huawei) Intended Status: Informational (Huawei)
Expires: December 13, 2014 Manav Bhatia Expires: June 13, 2015 Manav Bhatia
(Ionos) (Ionos)
Greg Mirsky Greg Mirsky
(Ericsson) (Ericsson)
Nagendra Kumar Nagendra Kumar
(Cisco) (Cisco)
Satoru Matsushima Satoru Matsushima
(Softbank) (Softbank)
June 11, 2014 December 10, 2014
Seamless Bidirectional Forwarding Detection (BFD) Use Case Seamless Bidirectional Forwarding Detection (BFD) Use Case
draft-ietf-bfd-seamless-use-case-00 draft-ietf-bfd-seamless-use-case-01
Abstract Abstract
This document provides various use cases for Bidirectional Forwarding This document provides various use cases for Bidirectional Forwarding
Detection (BFD) such that simplified solution and extensions could be Detection (BFD) such that simplified solution and extensions could be
developed for detecting forwarding failures. developed for detecting forwarding failures.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
skipping to change at page 2, line 36 skipping to change at page 2, line 36
3.4. BFD in Centralized Segment Routing . . . . . . . . . . . . 6 3.4. BFD in Centralized Segment Routing . . . . . . . . . . . . 6
3.5. BFD to Efficiently Operate under Resource Constraints . . . 6 3.5. BFD to Efficiently Operate under Resource Constraints . . . 6
3.6. BFD for Anycast Address . . . . . . . . . . . . . . . . . . 7 3.6. BFD for Anycast Address . . . . . . . . . . . . . . . . . . 7
3.7. BFD Fault Isolation . . . . . . . . . . . . . . . . . . . . 7 3.7. BFD Fault Isolation . . . . . . . . . . . . . . . . . . . . 7
3.8. Multiple BFD Sessions to Same Target . . . . . . . . . . . 7 3.8. Multiple BFD Sessions to Same Target . . . . . . . . . . . 7
3.9. MPLS BFD Session Per ECMP Path . . . . . . . . . . . . . . 8 3.9. MPLS BFD Session Per ECMP Path . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . . 9
7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Bidirectional Forwarding Detection (BFD) is a lightweight protocol, Bidirectional Forwarding Detection (BFD) is a lightweight protocol,
as defined in [RFC5880], used to detect forwarding failures. Various as defined in [RFC5880], used to detect forwarding failures. Various
protocols and applications rely on BFD for failure detection. Even protocols and applications rely on BFD for failure detection. Even
though the protocol is simple and lightweight, there are certain use though the protocol is simple and lightweight, there are certain use
cases, where a much faster setting up of sessions and continuity cases, where a much faster setting up of sessions and continuity
skipping to change at page 4, line 46 skipping to change at page 4, line 46
establishment with preserving benefits of forwarding failure establishment with preserving benefits of forwarding failure
detection using existing BFD specifications. detection using existing BFD specifications.
3.1. Unidirectional Forwarding Path Validation 3.1. Unidirectional Forwarding Path Validation
Even though bidirectional verification of forwarding path is useful, Even though bidirectional verification of forwarding path is useful,
there are scenarios when only one side of the BFD, not both, is there are scenarios when only one side of the BFD, not both, is
interested in verifying continuity of the data plane between a pair interested in verifying continuity of the data plane between a pair
of nodes. One such case is, when a static route uses BFD to validate of nodes. One such case is, when a static route uses BFD to validate
reachability to the next-hop IP router. In this case, the static reachability to the next-hop IP router. In this case, the static
route is established from one network entity to another. The route is established from one network entity to another. The
requirement in this case is only to validate the forwarding path for requirement in this case is only to validate the forwarding path for
that statically established path. Validating the reverse direction is that statically established path, and validation by the target entity
not required in this case. Many of these network scenarios are being to the originating entity is not required. Many LSPs have the same
proposed as part of segment routing [TBD]. Another example is when a unidirectional characteristics and unidirectional validation
unidirectional tunnel uses BFD to validate reachability to the egress requirements. Such LSPs are common in Segment Routing and LDP based
node. networks. Another example is when a unidirectional tunnel uses BFD
to validate reachability to the egress node.
If the traditional BFD is to be used, the target network entity has If the traditional BFD is to be used, the target network entity has
to be provisioned as well, even though the reverse path validation to be provisioned as well, even though the reverse path validation
with BFD session is not required. But with unidirectional BFD, the with BFD session is not required. But with unidirectional BFD, the
need to provision on the target network entity is not needed. Once need to provision on the target network entity is not needed. Once
the mechanism within the BFD protocol is in place, where the source the mechanism within the BFD protocol is in place, where the source
network entity knows the target network entity's discriminator, it network entity knows the target network entity's discriminator, it
starts the session right away. When the targeted network entity starts the session right away. When the targeted network entity
receives the packet, it knows that BFD packet, based on the receives the packet, it knows that BFD packet, based on the
discriminator and processes it. That do not require to have a bi- discriminator and processes it. That do not require to have a bi-
skipping to change at page 9, line 17 skipping to change at page 9, line 17
There are no new security considerations introduced by this draft. There are no new security considerations introduced by this draft.
5. IANA Considerations 5. IANA Considerations
There are no new IANA considerations introduced by this draft There are no new IANA considerations introduced by this draft
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures", RFC 4379, Label Switched (MPLS) Data Plane Failures", RFC 4379,
February 2006. February 2006.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC5880, June 2010. (BFD)", RFC5880, June 2010.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC5881, June 2010. (BFD)", RFC5881, June 2010.
[RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD) for Multihop Paths", RFC5883, June 2010. (BFD) for Multihop Paths", RFC5883, June 2010.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label "Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC5884, June 2010. Switched Paths (LSPs)", RFC5884, June 2010.
6.2. Informative References
[I-D.geib-spring-oam-usecase] Geib, R., Filsfils, C., Pignataro, C.
and Kumar, N., "SR MPLS monitoring use case", draft-geib-
spring-oam-usecase-03(work in progress), October 2014.
7. Authors' Addresses 7. Authors' Addresses
Sam Aldrin Sam Aldrin
Huawei Technologies Huawei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95051 Santa Clara, CA 95051
EMail: aldrin.ietf@gmail.com EMail: aldrin.ietf@gmail.com
Manav Bhatia Manav Bhatia
 End of changes. 8 change blocks. 
12 lines changed or deleted 17 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/