| draft-ietf-bfd-seamless-use-case-02.txt | draft-ietf-bfd-seamless-use-case-03.txt | |||
|---|---|---|---|---|
| Network Working Group A. Aldrin | Network Working Group S. Aldrin | |||
| Internet-Draft | Internet-Draft Google, Inc | |||
| Intended status: Informational M. Bhatia | Intended status: Informational M. Bhatia | |||
| Expires: October 30, 2015 Ionos Networks | Expires: February 1, 2016 Ionos Networks | |||
| S. Matsushima | S. Matsushima | |||
| Softbank | Softbank | |||
| G. Mirsky | G. Mirsky | |||
| Ericsson | Ericsson | |||
| N. Kumar | N. Kumar | |||
| Cisco | Cisco | |||
| April 28, 2015 | July 31, 2015 | |||
| Seamless Bidirectional Forwarding Detection (BFD) Use Case | Seamless Bidirectional Forwarding Detection (BFD) Use Case | |||
| draft-ietf-bfd-seamless-use-case-02 | draft-ietf-bfd-seamless-use-case-03 | |||
| Abstract | Abstract | |||
| This document provides various use cases for Bidirectional Forwarding | This document provides various use cases for Bidirectional Forwarding | |||
| Detection (BFD) such that extensions could be developed to allow for | Detection (BFD) such that extensions could be developed to allow for | |||
| simplified detection of forwarding failures. | simplified detection of forwarding failures. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| skipping to change at page 1, line 39 | skipping to change at page 1, line 39 | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on October 30, 2015. | This Internet-Draft will expire on February 1, 2016. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 2, line 21 | skipping to change at page 2, line 21 | |||
| 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
| 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Introduction to Seamless BFD . . . . . . . . . . . . . . . . 3 | 2. Introduction to Seamless BFD . . . . . . . . . . . . . . . . 3 | |||
| 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3.1. Unidirectional Forwarding Path Validation . . . . . . . . 4 | 3.1. Unidirectional Forwarding Path Validation . . . . . . . . 4 | |||
| 3.2. Validation of forwarding path prior to traffic switching 5 | 3.2. Validation of forwarding path prior to traffic switching 5 | |||
| 3.3. Centralized Traffic Engineering . . . . . . . . . . . . . 5 | 3.3. Centralized Traffic Engineering . . . . . . . . . . . . . 5 | |||
| 3.4. BFD in Centralized Segment Routing . . . . . . . . . . . 6 | 3.4. BFD in Centralized Segment Routing . . . . . . . . . . . 6 | |||
| 3.5. BFD Efficient Operation Under Resource Constraints . . . 6 | 3.5. BFD Efficient Operation Under Resource Constraints . . . 6 | |||
| 3.6. BFD for Anycast Address . . . . . . . . . . . . . . . . . 6 | 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 . . . . . . . . . . . . . 7 | 3.9. MPLS BFD Session Per ECMP Path . . . . . . . . . . . . . 7 | |||
| 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
| 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 | 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
| 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 | 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| 8. Normative References . . . . . . . . . . . . . . . . . . . . 9 | 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 | 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 | |||
| 8.2. Informative References . . . . . . . . . . . . . . . . . 10 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 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 faster setting up of sessions and continuity check of | cases, where faster setting up of sessions and continuity check of | |||
| the data forwarding paths is necessary. This document identifies use | the data forwarding paths is necessary. This document identifies use | |||
| cases such that necessary enhancements could be made to BFD protocol | cases such that necessary enhancements could be made to BFD protocol | |||
| skipping to change at page 3, line 21 | skipping to change at page 3, line 23 | |||
| enhancement proposals are outside the scope of this document as well. | enhancement proposals are outside the scope of this document as well. | |||
| 1.1. Terminology | 1.1. Terminology | |||
| The reader is expected to be familiar with the BFD, IP, MPLS and | The reader is expected to be familiar with the BFD, IP, MPLS and | |||
| Segment Routing (SR) terminology and protocol constructs. This | Segment Routing (SR) terminology and protocol constructs. This | |||
| section identifies only the new terminology introduced. | section identifies only the new terminology introduced. | |||
| 2. Introduction to Seamless BFD | 2. Introduction to Seamless BFD | |||
| BFD, as defined in standard [RFC5880], requires two network nodes, to | BFD, as defined in [RFC5880], requires two network nodes, to exchange | |||
| exchange locally allocated discriminators. The discriminator enables | locally allocated discriminators. The discriminator enables | |||
| identification of the sender and receiver of BFD packets of the | identification of the sender and receiver of BFD packets of the | |||
| particular session and proactive continuity monitoring of the | particular session and proactive continuity monitoring of the | |||
| forwarding path between the two. [RFC5881] defines single hop BFD | forwarding path between the two. [RFC5881] defines single hop BFD | |||
| whereas [RFC5883] and [RFC5884] defines multi-hop BFD. | whereas [RFC5883] defines multi-hop BFD, [RFC5884] BFD for MPLS | |||
| LSPs, and [RFC5885] - BFD for PWs. | ||||
| Currently, BFD is best suited to verify that two end points are | Currently, BFD is best suited to verify that two end points are | |||
| reachable or that an existing connection continues to be valid. In | reachable or that an existing connection continues to be valid. In | |||
| order for BFD to be able to initially verify that a connection is | order for BFD to be able to initially verify that a connection is | |||
| valid and that it connects the expected set of end points, it is | valid and that it connects the expected set of end points, it is | |||
| necessary to provide the node information associated with the | necessary to provide the node information associated with the | |||
| connection at each end point prior to initiating BFD sessions, such | connection at each end point prior to initiating BFD sessions, such | |||
| that this information can be used to verify that the connection is | that this information can be used to verify that the connection is | |||
| valid. | valid. | |||
| skipping to change at page 8, line 46 | skipping to change at page 9, line 4 | |||
| Email: gh1691@att.com | Email: gh1691@att.com | |||
| Santosh P K | Santosh P K | |||
| Juniper | Juniper | |||
| Email: santoshpk@juniper.net | Email: santoshpk@juniper.net | |||
| Mach Chen | Mach Chen | |||
| Huawei | Huawei | |||
| Email: mach.chen@huawei.com | Email: mach.chen@huawei.com | |||
| Nobo Akiya | Nobo Akiya | |||
| Cisco Systems | Cisco Systems | |||
| Email: nobo@cisco.com | Email: nobo@cisco.com | |||
| 7. Acknowledgements | 7. Acknowledgements | |||
| The authors would like to thank Eric Gray for his useful comments. | The authors would like to thank Eric Gray for his useful comments. | |||
| 8. Normative References | 8. References | |||
| [I-D.geib-spring-oam-usecase] | 8.1. Normative References | |||
| ?, "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.", 1900. | ||||
| [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. | DOI 10.17487/RFC4379, February 2006, | |||
| <http://www.rfc-editor.org/info/rfc4379>. | ||||
| [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | |||
| (BFD)", RFC 5880, June 2010. | (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, | |||
| <http://www.rfc-editor.org/info/rfc5880>. | ||||
| [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | |||
| (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June | (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, | |||
| 2010. | DOI 10.17487/RFC5881, June 2010, | |||
| <http://www.rfc-editor.org/info/rfc5881>. | ||||
| [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | |||
| (BFD) for Multihop Paths", RFC 5883, June 2010. | (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, | |||
| June 2010, <http://www.rfc-editor.org/info/rfc5883>. | ||||
| [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)", RFC 5884, June 2010. | Switched Paths (LSPs)", RFC 5884, DOI 10.17487/RFC5884, | |||
| June 2010, <http://www.rfc-editor.org/info/rfc5884>. | ||||
| [RFC5885] Nadeau, T., Ed. and C. Pignataro, Ed., "Bidirectional | ||||
| Forwarding Detection (BFD) for the Pseudowire Virtual | ||||
| Circuit Connectivity Verification (VCCV)", RFC 5885, | ||||
| DOI 10.17487/RFC5885, June 2010, | ||||
| <http://www.rfc-editor.org/info/rfc5885>. | ||||
| 8.2. Informative References | ||||
| [I-D.geib-spring-oam-usecase] | ||||
| Geib, R., Filsfils, C., Pignataro, C., and N. Kumar, "Use | ||||
| case for a scalable and topology aware MPLS data plane | ||||
| monitoring system", draft-geib-spring-oam-usecase-06 (work | ||||
| in progress), July 2015. | ||||
| Authors' Addresses | Authors' Addresses | |||
| Sam Aldrin | Sam Aldrin | |||
| 2330 Central Expressway | Google, Inc | |||
| 1600 Amphitheatre Parkway | ||||
| Mountain View, CA | ||||
| Email: aldrin.ietf@gmail.com | Email: aldrin.ietf@gmail.com | |||
| Manav Bhatia | Manav Bhatia | |||
| Ionos Networks | Ionos Networks | |||
| Email: manav@ionosnetworks.com | Email: manav@ionosnetworks.com | |||
| Satoru Matsushima | Satoru Matsushima | |||
| Softbank | Softbank | |||
| Email: satoru.matsushima@g.softbank.co.jp | Email: satoru.matsushima@g.softbank.co.jp | |||
| Greg Mirsky | Greg Mirsky | |||
| Ericsson | Ericsson | |||
| Email: gregory.mirsky@ericsson.com | Email: gregory.mirsky@ericsson.com | |||
| End of changes. 20 change blocks. | ||||
| 25 lines changed or deleted | 47 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||