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/