draft-ietf-spring-bfd-00.txt   draft-ietf-spring-bfd-01.txt 
SPRING Working Group G. Mirsky SPRING Working Group G. Mirsky
Internet-Draft ZTE Corp. Internet-Draft ZTE Corp.
Intended status: Standards Track J. Tantsura Intended status: Standards Track J. Tantsura
Expires: March 26, 2021 Apstra, Inc. Expires: 23 September 2021 Juniper Networks
I. Varlashkin I. Varlashkin
Google Google
M. Chen M. Chen
Huawei Huawei
J. Wenying J. Wenying
CMCC CMCC
September 22, 2020 22 March 2021
Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Bidirectional Forwarding Detection (BFD) in Segment Routing Networks
Using MPLS Dataplane Using MPLS Dataplane
draft-ietf-spring-bfd-00 draft-ietf-spring-bfd-01
Abstract Abstract
Segment Routing (SR) architecture leverages the paradigm of source Segment Routing (SR) architecture leverages the paradigm of source
routing. It can be realized in the Multiprotocol Label Switching routing. It can be realized in the Multiprotocol Label Switching
(MPLS) network without any change to the data plane. A segment is (MPLS) network without any change to the data plane. A segment is
encoded as an MPLS label, and an ordered list of segments is encoded encoded as an MPLS label, and an ordered list of segments is encoded
as a stack of labels. Bidirectional Forwarding Detection (BFD) is as a stack of labels. Bidirectional Forwarding Detection (BFD) is
expected to monitor any existing path between systems. This document expected to monitor any existing path between systems. This document
defines how to use Label Switched Path Ping to bootstrap a BFD defines how to use Label Switched Path Ping to bootstrap a BFD
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 26, 2021. This Internet-Draft will expire on 23 September 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3
1.1.2. Requirements Language . . . . . . . . . . . . . . . . 3 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4
2. Bootstrapping BFD Session over Segment Routed Tunnel with 2. Bootstrapping BFD Session over Segment Routed Tunnel with MPLS
MPLS Data Plane . . . . . . . . . . . . . . . . . . . . . . . 4 Data Plane . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use BFD Reverse Path TLV over Segment Routed MPLS Tunnel . . 5 3. Use BFD Reverse Path TLV over Segment Routed MPLS Tunnel . . 5
4. Use Non-FEC Path TLV . . . . . . . . . . . . . . . . . . . . 5 4. Use Non-FEC Path TLV . . . . . . . . . . . . . . . . . . . . 5
5. BFD Reverse Path TLV over Segment Routed MPLS Tunnel with 5. BFD Reverse Path TLV over Segment Routed MPLS Tunnel with
Dynamic Control Plane . . . . . . . . . . . . . . . . . . . . 7 Dynamic Control Plane . . . . . . . . . . . . . . . . . . 7
6. Applicability of BFD Demand Mode in SR-MPLS Domain . . . . . 7 6. Applicability of BFD Demand Mode in SR-MPLS Domain . . . . . 7
7. Using BFD to Monitor Point-to-Multipoint SR Policy . . . . . 7 7. Using BFD to Monitor Point-to-Multipoint SR Policy . . . . . 8
8. Use of Echo BFD in SR-MPLS . . . . . . . . . . . . . . . . . 8 8. Use of Echo BFD in SR-MPLS . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9.1. Non-FEC Path TLV . . . . . . . . . . . . . . . . . . . . 8 9.1. Non-FEC Path TLV . . . . . . . . . . . . . . . . . . . . 9
9.2. Return Code . . . . . . . . . . . . . . . . . . . . . . . 9 9.2. Return Code . . . . . . . . . . . . . . . . . . . . . . . 10
10. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 10 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
14.1. Normative References . . . . . . . . . . . . . . . . . . 11 14.1. Normative References . . . . . . . . . . . . . . . . . . 12
14.2. Informative References . . . . . . . . . . . . . . . . . 13 14.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
[RFC5880], [RFC5881], and [RFC5883] defined the operation of [RFC5880], [RFC5881], and [RFC5883] defined the operation of
Bidirectional Forwarding Detection (BFD) protocol between the two Bidirectional Forwarding Detection (BFD) protocol between the two
systems over IP networks. [RFC5884] and [RFC7726] set rules for systems over IP networks. [RFC5884] and [RFC7726] set rules for
using BFD Asynchronous mode over point-to-point (p2p) Multiprotocol using BFD Asynchronous mode over point-to-point (p2p) Multiprotocol
Label Switching (MPLS) Label Switched Path (LSP). These latter Label Switching (MPLS) Label Switched Path (LSP). These latter
standards implicitly assume that the remote BFD system, which is at standards implicitly assume that the remote BFD system, which is at
the egress Label Edge Router (LER), will use the shortest path route the egress Label Edge Router (LER), will use the shortest path route
skipping to change at page 7, line 21 skipping to change at page 7, line 44
tunnel computation BFD Reverse Path TLV MAY use Target FEC sub-TLVs tunnel computation BFD Reverse Path TLV MAY use Target FEC sub-TLVs
defined in [RFC8287]. defined in [RFC8287].
6. Applicability of BFD Demand Mode in SR-MPLS Domain 6. Applicability of BFD Demand Mode in SR-MPLS Domain
[I-D.mirsky-bfd-mpls-demand] defines how Demand mode of BFD, [I-D.mirsky-bfd-mpls-demand] defines how Demand mode of BFD,
specified in sections 6.6 and 6.18.4 of [RFC5880], can be used to specified in sections 6.6 and 6.18.4 of [RFC5880], can be used to
monitor uni-directional MPLS LSP. Similar procedures can be monitor uni-directional MPLS LSP. Similar procedures can be
following in SR-MPLS to monitor uni-directional SR tunnels: following in SR-MPLS to monitor uni-directional SR tunnels:
o an ingress SR node bootstraps BFD session over SR-MPLS in Async * an ingress SR node bootstraps BFD session over SR-MPLS in Async
BFD mode; BFD mode;
o once BFD session is Up, the ingress SR node switches the egress * once BFD session is Up, the ingress SR node switches the egress
LER into the Demand mode by setting D field in BFD Control packet LER into the Demand mode by setting D field in BFD Control packet
it transmits; it transmits;
o if the egress LER detects the failure of the BFD session, it sends * if the egress LER detects the failure of the BFD session, it sends
its BFD Control packet to the ingress SR node over the IP network its BFD Control packet to the ingress SR node over the IP network
with a Poll sequence; with a Poll sequence;
o if the ingress SR node receives a BFD Control packet from the * if the ingress SR node receives a BFD Control packet from the
remote node in a Demand mode with Poll sequence and Diag field remote node in a Demand mode with Poll sequence and Diag field
indicating the failure, the ingress SR node transmits BFD Control indicating the failure, the ingress SR node transmits BFD Control
packet with Final over IP and switches the BFD over SR-MPLS back packet with Final over IP and switches the BFD over SR-MPLS back
into Async mode, sending BFD Control packets one per second. into Async mode, sending BFD Control packets one per second.
7. Using BFD to Monitor Point-to-Multipoint SR Policy 7. Using BFD to Monitor Point-to-Multipoint SR Policy
[I-D.voyer-spring-sr-p2mp-policy] defined variants of SR Policy to [I-D.voyer-spring-sr-p2mp-policy] defined variants of SR Policy to
deliver point-to-multipoint (p2mp) services. For the given P2MP deliver point-to-multipoint (p2mp) services. For the given P2MP
segment [RFC8562] can be used if, for example, leaves have an segment [RFC8562] can be used if, for example, leaves have an
skipping to change at page 8, line 44 skipping to change at page 9, line 19
9. IANA Considerations 9. IANA Considerations
9.1. Non-FEC Path TLV 9.1. Non-FEC Path TLV
IANA is requested to assign new TLV type from the from Standards IANA is requested to assign new TLV type from the from Standards
Action range of the registry "Multiprotocol Label Switching Action range of the registry "Multiprotocol Label Switching
Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters - Architecture (MPLS) Label Switched Paths (LSPs) Ping Parameters -
TLVs" as defined in Table 1. TLVs" as defined in Table 1.
+-------+------------------+---------------+ +=======+==================+===============+
| Value | TLV Name | Reference | | Value | TLV Name | Reference |
+-------+------------------+---------------+ +=======+==================+===============+
| TBD1 | Non-FEC Path TLV | This document | | TBD1 | Non-FEC Path TLV | This document |
+-------+------------------+---------------+ +-------+------------------+---------------+
Table 1: New Non-FEC Path TLV Table 1: New Non-FEC Path TLV
IANA is requested to create new Non-FEC Path sub-TLV registry for the IANA is requested to create new Non-FEC Path sub-TLV registry for the
Non-FEC Path TLV, as described in Table 2. Non-FEC Path TLV, as described in Table 2.
+-------------+---------------+-------------------------------------+ +=============+===============+=====================================+
| Range | Registration | Note | | Range | Registration | Note |
| | Procedures | | | | Procedures | |
+=============+===============+=====================================+
| 0-16383 | Standards | This range is for mandatory |
| | Action | TLVs or for optional TLVs |
| | | that require an error |
| | | message if not recognized. |
+-------------+---------------+-------------------------------------+ +-------------+---------------+-------------------------------------+
| 0-16383 | Standards | This range is for mandatory TLVs or |
| | Action | for optional TLVs that require an |
| | | error message if not recognized. |
| 16384-31743 | Specification | Experimental RFC needed | | 16384-31743 | Specification | Experimental RFC needed |
| | Required | | | | Required | |
| 32768-49161 | Standards | This range is for optional TLVs | +-------------+---------------+-------------------------------------+
| | Action | that can be silently dropped if not | | 32768-49161 | Standards | This range is for optional |
| | | recognized. | | | Action | TLVs that can be silently |
| | | dropped if not recognized. |
+-------------+---------------+-------------------------------------+
| 49162-64511 | Specification | Experimental RFC needed | | 49162-64511 | Specification | Experimental RFC needed |
| | Required | | | | Required | |
+-------------+---------------+-------------------------------------+
| 64512-65535 | Private Use | | | 64512-65535 | Private Use | |
+-------------+---------------+-------------------------------------+ +-------------+---------------+-------------------------------------+
Table 2: Non-FEC Path sub-TLV registry Table 2: Non-FEC Path sub-TLV registry
IANA is requested to allocate the following values from the Non-FEC IANA is requested to allocate the following values from the Non-FEC
Path sub-TLV registry as defined in Table 3. Path sub-TLV registry as defined in Table 3.
+-------+-------------------------------------+---------------+ +=======+=====================================+===============+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------------------------------+---------------+ +=======+=====================================+===============+
| 0 | Reserved | This document | | 0 | Reserved | This document |
| TBD2 | Segment Routing MPLS Tunnel sub-TLV | This document | +-------+-------------------------------------+---------------+
| TBD2 | Segment Routing MPLS Tunnel sub-TLV | This document |
+-------+-------------------------------------+---------------+
| 65535 | Reserved | This document | | 65535 | Reserved | This document |
+-------+-------------------------------------+---------------+ +-------+-------------------------------------+---------------+
Table 3: New Segment Routing Tunnel sub-TLV Table 3: New Segment Routing Tunnel sub-TLV
9.2. Return Code 9.2. Return Code
IANA is requested to create Non-FEC Path sub-TLV sub-registry for the IANA is requested to create Non-FEC Path sub-TLV sub-registry for the
new Non-FEC Path TLV and assign a new Return Code value from the new Non-FEC Path TLV and assign a new Return Code value from the
"Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs)
Ping Parameters" registry, "Return Codes" sub-registry, as follows Ping Parameters" registry, "Return Codes" sub-registry, as follows
using a Standards Action value. using a Standards Action value.
+--------+-------------------------+---------------+ +========+=========================+===============+
| Value | Description | Reference | | Value | Description | Reference |
+--------+-------------------------+---------------+ +========+=========================+===============+
| X TBD3 | Too Many TLVs Detected. | This document | | X TBD3 | Too Many TLVs Detected. | This document |
+--------+-------------------------+---------------+ +--------+-------------------------+---------------+
Table 4: New Return Code Table 4: New Return Code
10. Implementation Status 10. Implementation Status
- The organization responsible for the implementation: ZTE - The organization responsible for the implementation: ZTE
Corporation. Corporation.
skipping to change at page 11, line 23 skipping to change at page 12, line 20
Authors greatly appreciate the help of Qian Xin, who provided the Authors greatly appreciate the help of Qian Xin, who provided the
information about the implementation of this specification. information about the implementation of this specification.
14. References 14. References
14.1. Normative References 14.1. Normative References
[I-D.ietf-mpls-bfd-directed] [I-D.ietf-mpls-bfd-directed]
Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen, Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen,
"Bidirectional Forwarding Detection (BFD) Directed Return "Bidirectional Forwarding Detection (BFD) Directed Return
Path for MPLS Label Switched Paths (LSPs)", draft-ietf- Path for MPLS Label Switched Paths (LSPs)", Work in
mpls-bfd-directed-15 (work in progress), August 2020. Progress, Internet-Draft, draft-ietf-mpls-bfd-directed-17,
16 February 2021, <https://tools.ietf.org/html/draft-ietf-
mpls-bfd-directed-17>.
[I-D.mirsky-bfd-mpls-demand] [I-D.mirsky-bfd-mpls-demand]
Mirsky, G., "BFD in Demand Mode over Point-to-Point MPLS Mirsky, G., "BFD in Demand Mode over Point-to-Point MPLS
LSP", draft-mirsky-bfd-mpls-demand-08 (work in progress), LSP", Work in Progress, Internet-Draft, draft-mirsky-bfd-
September 2020. mpls-demand-08, 9 September 2020,
<https://tools.ietf.org/html/draft-mirsky-bfd-mpls-demand-
08>.
[I-D.voyer-spring-sr-p2mp-policy] [I-D.voyer-spring-sr-p2mp-policy]
daniel.voyer@bell.ca, d., Filsfils, C., Parekh, R., Voyer, D., Filsfils, C., Parekh, R., Bidgoli, H., and Z.
Bidgoli, H., and Z. Zhang, "SR Replication Policy for P2MP Zhang, "SR Replication Policy for P2MP Service Delivery",
Service Delivery", draft-voyer-spring-sr-p2mp-policy-03 Work in Progress, Internet-Draft, draft-voyer-spring-sr-
(work in progress), July 2019. p2mp-policy-03, 2 July 2019, <https://tools.ietf.org/html/
draft-voyer-spring-sr-p2mp-policy-03>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>. <https://www.rfc-editor.org/info/rfc5880>.
skipping to change at page 13, line 19 skipping to change at page 14, line 19
[RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing with the MPLS Data Plane", RFC 8660, Routing with the MPLS Data Plane", RFC 8660,
DOI 10.17487/RFC8660, December 2019, DOI 10.17487/RFC8660, December 2019,
<https://www.rfc-editor.org/info/rfc8660>. <https://www.rfc-editor.org/info/rfc8660>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-bess-mvpn-fast-failover] [I-D.ietf-bess-mvpn-fast-failover]
Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN fast Morin, T., Kebler, R., and G. Mirsky, "Multicast VPN Fast
upstream failover", draft-ietf-bess-mvpn-fast-failover-10 Upstream Failover", Work in Progress, Internet-Draft,
(work in progress), February 2020. draft-ietf-bess-mvpn-fast-failover-15, 21 January 2021,
<https://tools.ietf.org/html/draft-ietf-bess-mvpn-fast-
failover-15>.
[I-D.ietf-pim-bfd-p2mp-use-case] [I-D.ietf-pim-bfd-p2mp-use-case]
Mirsky, G. and J. Xiaoli, "Bidirectional Forwarding Mirsky, G. and J. Xiaoli, "Bidirectional Forwarding
Detection (BFD) for Multi-point Networks and Protocol Detection (BFD) for Multi-point Networks and Protocol
Independent Multicast - Sparse Mode (PIM-SM) Use Case", Independent Multicast - Sparse Mode (PIM-SM) Use Case",
draft-ietf-pim-bfd-p2mp-use-case-04 (work in progress), Work in Progress, Internet-Draft, draft-ietf-pim-bfd-p2mp-
July 2020. use-case-05, 30 November 2020,
<https://tools.ietf.org/html/draft-ietf-pim-bfd-p2mp-use-
case-05>.
[I-D.ietf-spring-mpls-anycast-segments] [I-D.ietf-spring-mpls-anycast-segments]
Sarkar, P., Gredler, H., Filsfils, C., Previdi, S., Sarkar, P., Gredler, H., Filsfils, C., Previdi, S.,
Decraene, B., and M. Horneffer, "Anycast Segments in MPLS Decraene, B., and M. Horneffer, "Anycast Segments in MPLS
based Segment Routing", draft-ietf-spring-mpls-anycast- based Segment Routing", Work in Progress, Internet-Draft,
segments-03 (work in progress), April 2020. draft-ietf-spring-mpls-anycast-segments-03, 27 April 2020,
<https://tools.ietf.org/html/draft-ietf-spring-mpls-
anycast-segments-03>.
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", L. Yong, "The Use of Entropy Labels in MPLS Forwarding",
RFC 6790, DOI 10.17487/RFC6790, November 2012, RFC 6790, DOI 10.17487/RFC6790, November 2012,
<https://www.rfc-editor.org/info/rfc6790>. <https://www.rfc-editor.org/info/rfc6790>.
Authors' Addresses Authors' Addresses
Greg Mirsky Greg Mirsky
ZTE Corp. ZTE Corp.
Email: gregimirsky@gmail.com Email: gregimirsky@gmail.com, gregory.mirsky@ztetx.com
Jeff Tantsura Jeff Tantsura
Apstra, Inc. Juniper Networks
Email: jefftant.ietf@gmail.com Email: jefftant.ietf@gmail.com
Ilya Varlashkin Ilya Varlashkin
Google Google
Email: Ilya@nobulus.com Email: Ilya@nobulus.com
Mach(Guoyi) Chen Mach(Guoyi) Chen
Huawei Huawei
Email: mach.chen@huawei.com Email: mach.chen@huawei.com
 End of changes. 39 change blocks. 
68 lines changed or deleted 85 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/