| 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/ | ||||