< draft-mirsky-mpls-bfd-directed-03.txt   draft-mirsky-mpls-bfd-directed-04.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: September 6, 2015 I. Varlashkin Expires: February 6, 2016 I. Varlashkin
Google Google
M. Chen M. Chen
Huawei Huawei
March 5, 2015 August 5, 2015
Bidirectional Forwarding Detection (BFD) Directed Return Path Bidirectional Forwarding Detection (BFD) Directed Return Path
draft-mirsky-mpls-bfd-directed-03 draft-mirsky-mpls-bfd-directed-04
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 September 6, 2015. This Internet-Draft will expire on February 6, 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 19 skipping to change at page 2, line 19
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions used in this document . . . . . . . . . . . . 3 1.1. Conventions used in this document . . . . . . . . . . . . 3
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
3. Direct Reverse BFD Path . . . . . . . . . . . . . . . . . . . 4 3. Direct Reverse BFD Path . . . . . . . . . . . . . . . . . . . 4
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. Segment Routing Tunnel sub-TLV . . . . . . . . . . . 5 3.1.2. Static and RSVP-TE sub-TLVs . . . . . . . . . . . . . 5
3.2. Case of IPv6 Data Plane . . . . . . . . . . . . . . . . . 5 3.1.3. Segment Routing Tunnel sub-TLV . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . 8
5.1. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Sub-TLV . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.3. Return Codes . . . . . . . . . . . . . . . . . . . . . . 8 5.3. Return Codes . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 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]
established the BFD protocol for IP networks and RFC 5884 [RFC5884] established the BFD protocol for IP networks and RFC 5884 [RFC5884]
set rules of using BFD asynchronous mode over IP/MPLS LSPs. All set rules of using BFD asynchronous mode over IP/MPLS LSPs. All
standards implicitly assume that the egress BFD peer will use the standards implicitly assume that the egress BFD peer will use the
skipping to change at page 5, line 18 skipping to change at page 5, line 20
specified in the Reverse Path TLV is not known, the egress MAY specified in the Reverse Path TLV is not known, the egress MAY
establish the BFD session over IP network [RFC5884] and MAY send Echo establish the BFD session over IP network [RFC5884] and MAY send Echo
Reply with the Reverse Path TLV received and the return code set to Reply with the Reverse Path TLV received and the return code set to
"Failed to establish the BFD session". The specified reverse path "Failed to establish the BFD session". The specified reverse path
was not found" (TBD4) Section 3.4. If the egress LSR cannot find was not found" (TBD4) Section 3.4. If the egress LSR cannot find
path specified in the Reverse Path TLV and does not establish BFD path specified in the Reverse Path TLV and does not establish BFD
session per RFC 5884, it MUST send Echo Reply with the Reverse Path session per RFC 5884, it MUST send Echo Reply with the Reverse Path
TLV received and the return code set to "Failed to establish the BFD TLV received and the return code set to "Failed to establish the BFD
session. The specified reverse path was not found". session. The specified reverse path was not found".
3.1.2. Segment Routing Tunnel sub-TLV 3.1.2. Static and RSVP-TE sub-TLVs
With MPLS data plane explicit path can be either Static or RSVP-TE When explicit path on MPLS data plane set either as Static or RSVP-TE
LSP, or Segment Routing tunnel. In case of Static or RSVP-TE LSP LSP respective sub-TLVs defined in [RFC7110] identify explicit return
[RFC7110] defined sub-TLVs to identify explicit return path. For the path.
Segment Routing with MPLS data plane case a new sub-TLV is defined in
this document as presented in Figure 2. 3.1.3. Segment Routing Tunnel sub-TLV
In addition to Static and RSVP-TE, Segment Routing with MPLS data
plane can be used to set explicit path. In this case a new sub-TLV
is defined in this document as presented in Figure 2.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SegRouting MPLS sub-TLV Type | Length | | SegRouting MPLS sub-TLV Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Stack Element | | Label Stack Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label Stack Element | | Label Stack Element |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~ ~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Segment Routing MPLS Tunnel sub-TLV Figure 2: Segment Routing MPLS Tunnel sub-TLV
The Segment Routing Tunnel sub-TLV Type is two octets in length, and The Segment Routing Tunnel sub-TLV Type is two octets in length, and
will be allocated by IANA. will be allocated by IANA.
The egress LSR MUST use the Value field as label stack for BFD
control packets for the BFD session identified by source IP address
and value in BFD Discriminator TLV.
The Segment Routing Tunnel sub-TLV MAY be used in Reply Path TLV The Segment Routing Tunnel sub-TLV MAY be used in Reply Path TLV
defined in [RFC7110] defined in [RFC7110]
3.2. Case of IPv6 Data Plane 3.2. Case of IPv6 Data Plane
IPv6 can be data plane of choice for Segment Routed tunnels IPv6 can be data plane of choice for Segment Routed tunnels
[I-D.previdi-6man-segment-routing-header]. In such networks the BFD [I-D.previdi-6man-segment-routing-header]. In such networks the BFD
Reverse Path TLV described in Section 3.1.1 can be used as well. IP Reverse Path TLV described in Section 3.1.1 can be used as well. IP
networks, unlike IP/MPLS, do not require use of LSP ping with BFD networks, unlike IP/MPLS, do not require use of LSP ping with BFD
Discriminator TLV[RFC4379] to bootstrap BFD session. But to specify Discriminator TLV[RFC4379] to bootstrap BFD session. But to specify
skipping to change at page 6, line 42 skipping to change at page 7, line 5
As discussed in [I-D.kumarkini-mpls-spring-lsp-ping] introduction of As discussed in [I-D.kumarkini-mpls-spring-lsp-ping] introduction of
Segment Routing network domains with MPLS dataplane adds three new Segment Routing network domains with MPLS dataplane adds three new
sub-TLVs that may be used with Target FEC TLV. Section 6.1 addresses sub-TLVs that may be used with Target FEC TLV. Section 6.1 addresses
use of new sub-TLVs in Target FEC TLV in LSP ping and LSP traceroute. use of new sub-TLVs in Target FEC TLV in LSP ping and LSP traceroute.
For the case of LSP ping the [I-D.kumarkini-mpls-spring-lsp-ping] For the case of LSP ping the [I-D.kumarkini-mpls-spring-lsp-ping]
states that: states that:
"Initiator MUST include FEC(s) corresponding to the destination "Initiator MUST include FEC(s) corresponding to the destination
segment. segment.
Initiator MAY include FECs corresponding to some or all of segments Initiator, i.e. ingress LSR, MAY include FECs corresponding to some
imposed in the label stack by the initiator to communicate the or all of segments imposed in the label stack by the ingress LSR to
segments traversed. " communicate the segments traversed. "
When LSP ping is used to bootstrap BFD session this document updates When LSP ping is used to bootstrap BFD session this document updates
this and defines that LSP Ping MUST include the FEC corresponding to this and defines that LSP Ping MUST include the FEC corresponding to
the destination segment and SHOULD NOT include FECs corresponding to the destination segment and SHOULD NOT include FECs corresponding to
some or all of segment imposed by the initiator. Operationally such some or all of segment imposed by the ingress LSR. Operationally
restriction would not cause any problem or uncertainty as LSP ping such restriction would not cause any problem or uncertainty as LSP
with FECs corresponding to some or all segments or traceroute may ping with FECs corresponding to some or all segments or traceroute
preceed the LSP ping that bootstraps the BFD session. may preceed the LSP ping that bootstraps the BFD session.
3.4. Return Codes 3.4. Return Codes
This document defines the following Return Codes: This document defines the following Return Codes:
o Failed to establish the BFD session. The specified reverse path o "Failed to establish the BFD session. The specified reverse path
was not found, (TBD4) - the specified reverse path was not found, was not found", (TBD4). When a specified reverse path is not
failed to establish the BFD session. When a specified reverse available at the egress LSR, an Echo Reply with the return code
path is not available at the egress LSR, an Echo Reply with the set to "Failed to establish the BFD session. The specified
return code set to "Failed to establish the BFD session. The reverse path was not found" MAY be sent back to the ingress LSR .
specified reverse path was not found." MAY be sent back to the (Section 3.1.1)
initiator . (Section 3.1.1)
4. Use Case Scenario 4. Use Case Scenario
In network presented in Figure 4 node A monitors two tunnels to node In network presented in Figure 4 node A monitors two tunnels to node
H: A-B-C-D-G-H and A-B-E-F-G-H. To bootstrap BFD session to monitor H: A-B-C-D-G-H and A-B-E-F-G-H. To bootstrap BFD session to monitor
the first tunnel, node A MUST include BFD Discriminator TLV with the first tunnel, node A MUST include BFD Discriminator TLV with
Discriminator value N and MAY include BFD Reverse Path TLV that Discriminator value foobar-1 and MAY include BFD Reverse Path TLV
references H-G-D-C-B-A tunnel. To bootstrap BFD session to monitor that references H-G-D-C-B-A tunnel. To bootstrap BFD session to
the second tunnel, node A MUST include BFD Discriminator TLV with monitor the second tunnel, node A MUST include BFD Discriminator TLV
Discriminator value M and MAY include BFD Reverse Path TLV that with Discriminator value foobar-2 and MAY include BFD Reverse Path
references H-G-F-E-B-A tunnel. TLV that references H-G-F-E-B-A tunnel.
C---------D C---------D
| | | |
A-------B G-----H A-------B G-----H
| | | |
E---------F E---------F
Figure 4: Use Case for BFD Reverse Path TLV Figure 4: Use Case for BFD Reverse Path TLV
If an operator needs node H to monitor path to node A, e.g. If an operator needs node H to monitor path to node A, e.g.
skipping to change at page 9, line 13 skipping to change at page 9, line 28
[RFC4379], apply to this document. [RFC4379], apply to this document.
7. Acknowledgements 7. Acknowledgements
8. Normative References 8. Normative References
[I-D.kumarkini-mpls-spring-lsp-ping] [I-D.kumarkini-mpls-spring-lsp-ping]
Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini, Kumar, N., Swallow, G., Pignataro, C., Akiya, N., Kini,
S., Gredler, H., and M. Chen, "Label Switched Path (LSP) S., Gredler, H., and M. Chen, "Label Switched Path (LSP)
Ping/Trace for Segment Routing Networks Using MPLS Ping/Trace for Segment Routing Networks Using MPLS
Dataplane", draft-kumarkini-mpls-spring-lsp-ping-02 (work Dataplane", draft-kumarkini-mpls-spring-lsp-ping-03 (work
in progress), October 2014. in progress), April 2015.
[I-D.previdi-6man-segment-routing-header] [I-D.previdi-6man-segment-routing-header]
Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 Previdi, S., Filsfils, C., Field, B., Leung, I., Aries,
Segment Routing Header (SRH)", draft-previdi-6man-segment- E., Vyncke, E., and D. Lebrun, "IPv6 Segment Routing
routing-header-05 (work in progress), January 2015. Header (SRH)", draft-previdi-6man-segment-routing-
header-07 (work in progress), July 2015.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[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>.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic [RFC5586] Bocci, M., Ed., Vigoureux, M., Ed., and S. Bryant, Ed.,
Associated Channel", RFC 5586, June 2009. "MPLS Generic Associated Channel", RFC 5586,
DOI 10.17487/RFC5586, June 2009,
<http://www.rfc-editor.org/info/rfc5586>.
[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>.
[RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord,
"Return Path Specified Label Switched Path (LSP) Ping", "Return Path Specified Label Switched Path (LSP) Ping",
RFC 7110, January 2014. RFC 7110, DOI 10.17487/RFC7110, January 2014,
<http://www.rfc-editor.org/info/rfc7110>.
Authors' Addresses Authors' Addresses
Greg Mirsky Greg Mirsky
Ericsson Ericsson
Email: gregory.mirsky@ericsson.com Email: gregory.mirsky@ericsson.com
Jeff Tantsura Jeff Tantsura
Ericsson Ericsson
 End of changes. 24 change blocks. 
49 lines changed or deleted 68 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/