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