< draft-ietf-mpls-bfd-directed-00.txt   draft-ietf-mpls-bfd-directed-01.txt >
MPLS Working Group G. Mirsky MPLS Working Group G. Mirsky
Internet-Draft J. Tantsura Internet-Draft J. Tantsura
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: March 3, 2016 I. Varlashkin Expires: March 11, 2016 I. Varlashkin
Google Google
M. Chen M. Chen
Huawei Huawei
August 31, 2015 September 8, 2015
Bidirectional Forwarding Detection (BFD) Directed Return Path Bidirectional Forwarding Detection (BFD) Directed Return Path
draft-ietf-mpls-bfd-directed-00 draft-ietf-mpls-bfd-directed-01
Abstract Abstract
Bidirectional Forwarding Detection (BFD) is expected to monitor bi- Bidirectional Forwarding Detection (BFD) is expected to monitor bi-
directional paths. When a BFD session monitors in its forward directional paths. When a BFD session monitors in its forward
direction an explicitly routed path there is a need to be able to direction an explicitly routed path there is a need to be able to
direct egress BFD peer to use specific path as reverse direction of direct egress BFD peer to use specific path as reverse direction of
the BFD session. the BFD session.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 March 3, 2016. This Internet-Draft will expire on March 11, 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 27 skipping to change at page 2, line 27
3.1. Case of MPLS Data Plane . . . . . . . . . . . . . . . . . 4 3.1. Case of MPLS Data Plane . . . . . . . . . . . . . . . . . 4
3.1.1. BFD Reverse Path TLV . . . . . . . . . . . . . . . . 4 3.1.1. BFD Reverse Path TLV . . . . . . . . . . . . . . . . 4
3.1.2. Static and RSVP-TE sub-TLVs . . . . . . . . . . . . . 5 3.1.2. Static and RSVP-TE sub-TLVs . . . . . . . . . . . . . 5
3.1.3. Segment Routing Tunnel sub-TLV . . . . . . . . . . . 5 3.1.3. Segment Routing Tunnel sub-TLV . . . . . . . . . . . 5
3.2. Case of IPv6 Data Plane . . . . . . . . . . . . . . . . . 6 3.2. Case of IPv6 Data Plane . . . . . . . . . . . . . . . . . 6
3.3. Bootstrapping BFD session with BFD Reverse Path over 3.3. Bootstrapping BFD session with BFD Reverse Path over
Segment Routed tunnel . . . . . . . . . . . . . . . . . . 6 Segment Routed tunnel . . . . . . . . . . . . . . . . . . 6
3.4. Return Codes . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Return Codes . . . . . . . . . . . . . . . . . . . . . . 7
4. Use Case Scenario . . . . . . . . . . . . . . . . . . . . . . 7 4. Use Case Scenario . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
5.1. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Return Codes . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Return Codes . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. Normative References . . . . . . . . . . . . . . . . . . . . 9 8. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
RFC 5880 [RFC5880], RFC 5881 [RFC5881], and RFC 5883 [RFC5883] RFC 5880 [RFC5880], RFC 5881 [RFC5881], and RFC 5883 [RFC5883]
skipping to change at page 3, line 42 skipping to change at page 3, line 42
2. Problem Statement 2. Problem Statement
BFD is best suited to monitor bi-directional co-routed paths. In BFD is best suited to monitor bi-directional co-routed paths. In
most cases, given stable environments, the forward and reverse most cases, given stable environments, the forward and reverse
direction between two nodes is likely to be co-routed, this direction between two nodes is likely to be co-routed, this
fulfilling the implicit BFD requirements. If BFD is used to monitor fulfilling the implicit BFD requirements. If BFD is used to monitor
unidirectional explicitly routed paths, e.g. MPLS-TE LSPs, its unidirectional explicitly routed paths, e.g. MPLS-TE LSPs, its
control packets in forward direction would be in-band using the control packets in forward direction would be in-band using the
mechanism defined in [RFC5884] and [RFC5586]. But the reverse mechanism defined in [RFC5884] and [RFC5586]. But the reverse
direction of the BFD session would still follow the shortest path direction of the BFD session would still follow the shortest path
route and that might lead to the following problems detecting route and that might lead to the following problem in detecting
failures on the unidirectional explicit path: failures on the unidirectional explicit path:
o detection of a failure on the reverse path cannot reliably be o a failure detection by ingress node on the reverse path cannot be
interpreted as bi-directional defect and thus trigger, for interpreted as bi-directional failure with all the certainty and
example, protection switchover of the forward direction; thus trigger, for example, protection switchover of the forward
direction without possibility of being false positive or false
o if a failure of the reverse path had been ignored, the ingress negative.
node would not receive indication of forward direction failure
from its egress peer.
To address these challenges the egress BFD peer should be instructed To address these challenges the egress BFD peer should be instructed
to use specific path for its control packets. to use specific path for its control packets.
3. Direct Reverse BFD Path 3. Direct Reverse BFD Path
3.1. Case of MPLS Data Plane 3.1. Case of MPLS Data Plane
LSP ping, defined in [RFC4379], uses BFD Discriminator TLV [RFC5884] LSP ping, defined in [RFC4379], uses BFD Discriminator TLV [RFC5884]
to bootstrap a BFD session over an MPLS LSP. This document defines a to bootstrap a BFD session over an MPLS LSP. This document defines a
 End of changes. 7 change blocks. 
13 lines changed or deleted 11 lines changed or added

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