< draft-wang-bess-sbfd-discriminator-01.txt   draft-wang-bess-sbfd-discriminator-02.txt >
Network Working Group H. Wang Network Working Group H. Wang
Internet-Draft Y. Huang Internet-Draft J. Dong
Intended status: Standards Track J. Dong Intended status: Standards Track Huawei
Expires: 7 July 2022 Huawei Expires: 18 October 2022 G. Mirsky
3 January 2022 Ericsson
Y. Huang
Huawei
16 April 2022
Advertising S-BFD Discriminators in BGP Advertising S-BFD Discriminators in BGP
draft-wang-bess-sbfd-discriminator-01 draft-wang-bess-sbfd-discriminator-02
Abstract Abstract
This document defines the method of transmitting S-BFD discriminators Seamless Bidirectional Forwarding Detection (S-BFD) is a simplified
through BGP attributes. This method makes it easier for operators to BFD mechanism. It eliminates most negotiation aspects and provides
create S-BFD for services. advantages such as fast configuration injection. S-BFD is especially
useful in multi-homing PE scenarios and reduces resource overheads on
the dual-homing PEs. Although S-BFD is simpler than BFD, a large
number of manual configurations are required when there are a large
number of PEs.
This document provides the mechanism of distributing S-BFD
discriminators with VPN service routes, which simplifies S-BFD
deployment for VPN services.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
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 38 skipping to change at page 2, line 4
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 18 October 2022.
This Internet-Draft will expire on 7 July 2022.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. EVPN Layer 3 Service Over SRv6 BE Use Case . . . . . . . 3 3.1. EVPN Layer 3 Service Over SRv6 BE Use Case . . . . . . . 4
3.2. EVPN Layer 3 Service Over SPv6 Policy Use Case . . . . . 5 3.2. EVPN Layer 3 Service Over SPv6 Policy Use Case . . . . . 5
4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . 6 4.1. BGP Encoding . . . . . . . . . . . . . . . . . . . . . . 6
4.2. ProceduerProceduer . . . . . . . . . . . . . . . . . . . 8 4.2. Router Procedure . . . . . . . . . . . . . . . . . . . . 8
4.2.1. Egress Node Process . . . . . . . . . . . . . . . . . 8 4.2.1. Egress Node Process . . . . . . . . . . . . . . . . . 8
4.2.2. Transit Node Process . . . . . . . . . . . . . . . . 8 4.2.2. Transit Node Process . . . . . . . . . . . . . . . . 9
4.2.3. Ingress Node Process . . . . . . . . . . . . . . . . 8 4.2.3. Ingress Node Process . . . . . . . . . . . . . . . . 9
5. Error handling . . . . . . . . . . . . . . . . . . . . . . . 8 5. Error handling . . . . . . . . . . . . . . . . . . . . . . . 9
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. References . . . . . . . . . . . . . . . . . . . . . . . 10 9.2. References . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
[RFC7880] defines the Seamless Bidirectional Forwarding Detection [RFC7880] defines the Seamless Bidirectional Forwarding Detection
(S-BFD) mechanism. S-BFD is a simplified mechanism for using BFD (S-BFD) mechanism. S-BFD is a simplified mechanism for using BFD
with a large proportion of negotiation aspects eliminated, thus with a large proportion of negotiation aspects eliminated, thus
providing benefits such as quick provisioning, as well as improved providing benefits such as quick provisioning, as well as improved
control and flexibility for network nodes initiating path monitoring. control and flexibility for network nodes initiating path monitoring.
Currently, S-BFD can be used to simplify the service deployment. Currently, S-BFD can be used to simplify the service deployment.
2. Motivations During network construction, carriers usually deploy active and
standby nodes to improve network reliability. In this way, when a
An important usage for S-BFD is to check the reachability of targets, single node is faulty, a protection switchover can be performed
so that service interruption can be swiftly detected when there is a quickly. To accelerate fault detection, BFD is generally used. BFD
failure on the service path and services can be switched to a backup sessions must be deployed on both ends of the BFD session, which
path quickly. occupies resources on both ends of the PE.
[RFC7880] specifies the Seamless Bidirectional Forwarding Detection
(S-BFD) mechanism. Generally, the operators need to manually deploy
S-BFD discriminators on the device to generate S-BFD sessions.
For the deployment of S-BFD in IPv4 network, the reflector can use [RFC7880] defines Seamless Bidirectional Forwarding Detection
the LSR-ID address as the discriminator. This reduces the number of (S-BFD), a simplified mechanism for using BFD with a large proportion
discriminators deployed on the transmit end. This mode cannot be of negotiation aspects eliminated, thus providing benefits such as
used for IPv6 because the discriminator has only four bytes. quick provisioning, as well as improved control and flexibility for
network nodes initiating path monitoring. This mechanism is useful
for asymmetric scenarios, such as 3PE scenarios. In dual-homing
scenarios, BFD does not need to be deployed to detect single-homing
nodes. In this scenario, S-BFD greatly saves resources on the dual-
homing side.
[RFC7883] [RFC7884] defines IS-IS and OSPF to flood BFD To deploy S-BFD, the initiator needs to know the reflector's endpoint
discriminators. However, this mode is based on nodes and cannot and identifier. When a large number of PEs need to be deployed, the
traverse an IGP area. In addition, without the knowledge of services deployment is complicated. [RFC7883] and [RFC7884] introduced an
to be detected, a large number of redundant S-BFD sessions may be IGP-based S-BFD discriminator advertisement mechanism to simplify
generated. S-BFD deployment. VPN service may be deployed across inter-area or
inter-AS. In this case, the IGP flooding mechanism does not work.
It is recommended to use BGP to distribute BFD discriminator It is recommended to use BGP to distribute BFD discriminator
information. BGP can transmit routes across domains, and service information. BGP can transmit routes across domains, and service
routes can drive to generate the end-to-end S-BFD sessions on demand. routes can drive to generate the end-to-end S-BFD sessions on demand.
2. Terminology
BFD : Bidirectional Forwarding Detection
S-BFD : Seamless Bidirectional Forwarding Detection
APE : Access PE, used to access users
SPE: Service PE, used to support service for users
UCE: User CE
SCE: Service CE
3. Scenarios 3. Scenarios
When the services are across multiple areas or multiple ASes, the BFD In some EVPN deployments, for example, when it spans over multiple
discriminator of the remote PE node cannot be obtained through the domains, only one of a pair of interconnected PEs benefits from
IGP based S-BFD extensions, thus a BGP based mechanism is required. monitoring the status of the connection. In such a case, using S-BFD
[RFC7880] is advantageous as it reduces the load on one of the PEs
while providing the benefit of faster convergence. The following
sections provide examples of EVPNs that would benefit from using
S-BFD.
For SRv6 services, there are two different service types. One is For SRv6 services, there are two different service types. One is
service over SRv6 BE, the other is service over SRv6 Policy. For the service over SRv6 BE, the other is service over SRv6 Policy. For the
service over SRv6 BE, it will use the VPNSID to resolve the service over SRv6 BE, it will use the VPNSID to resolve the
forwarding information. Thus we must generate an S-BFD session to forwarding information. Thus we must generate an S-BFD session to
detect the VPNSID's reachablity. This is an IP-routed S-BFD. We may detect the VPNSID's reachability. This is an IP-routed S-BFD. We
use the remote VPNSID's locator as the destination of the S-BFD may use the remote VPNSID's locator as the destination of the S-BFD
session. For the service over SRv6 Polcy, it will use <nexthop, session. For the service over SRv6 Policy, it will use <nexthop,
color> of the service route to resolve an SRv6 Policy. Then we must color> of the service route to resolve an SRv6 Policy. Then we must
generate an S-BFD session to detect the reachablity of the SR Policy. generate an S-BFD session to detect the reachability of the SR
Policy.
3.1. EVPN Layer 3 Service Over SRv6 BE Use Case 3.1. EVPN Layer 3 Service Over SRv6 BE Use Case
+-----------------------+ +-------------------+
| | | | /---------------------\ /--------------------\
| +-----+ +-----+ | | +-----+ | | | | |
| , PE1 |------|ASBR1|------|ASBR3\ | +----+ | +----+ +-----+ | |+-----+ +----+ |
|/+-----+ +-----+ | | +-----+\ | |UCE1|---|-|APE1|------|ASBR1|-|--||ASBR3|------|SPE1| |
/ | | \ | +----+ | +----+ \ ,-----+ | |+-----+\ /+----+ |
/| | | \ | | \ / | | \ / `|
+-----/ | | | '-----+ | +-----+ | .... \/ | | \/ |', +----+
| CE1 | | | | | PE3 |---| CE2 | | /\ | | /\ | .|SCE1|
+------ | | | /-----+ | +-----+ | / \ | | / \ |-` +----+
`, | | / | +----+ | +----+ / '-----+ | |+-----+- '+-----`|
|.+-----+ +-----+ | | +-----+ / | |UCEn|---|-|APEn|------|ASBR2|-|--||ASBR4|------|SPE2| |
| ' PE2 |------|ASBR2|------|ASBR4|- | +----+ | +----+ +-----+ | |+-----+ +----+ |
| +-----+ +-----+ | | +-----+ | | | | |
| | | | | AS65001 | | AS65002 |
| AS65001 | | AS65002 | \---------------------/ \--------------------/
+-----------------------+ +-------------------+
Figure 1: EVPN Layer 3 Service Over SRv6 BE Figure 1: EVPN Layer 3 Service Over SRv6 BE
Figure 1 shows a SRv6 BE based seamless scenario. CE1 is dual-homed Figure 1 shows a SRv6 BE based seamless scenario. UCE is single-
to PE1 and PE2, and CE2 is accecssed to PE3. PE1, PE2, and PE3 are homed to APE, and SCE is dual-homed to SPE1 and SPE2. The service is
cross BGP ASes. across multiple ASes.
CE1 accesses PE1 and PE2 through Layer 3 and advertises its private SCE1 accesses SPE1 and SE2 through Layer 3 and advertises its private
network routes to PE1. PE1 encapsulates the routes into Type 5 network routes to them. SPE1 and SPE2 encapsulate the routes into
routes in the EVPN format and sends them to PE3. After receiving Type 5 routes in the EVPN format and sends them to APE1. After
Type 5 routes advertised by PE1 and PE2, PE3 generates primary and receiving Type 5 routes advertised by SPE1 and SPE2, APE1 generates
backup entries for the routes to speed up service switchover. In primary and backup entries for the routes to speed up service
this scenario, the SRv6 BE service mode is used. PE3 will resolve switchover. In this scenario, the SRv6 BE service mode is used.
PE1's VPN routes reachbility through the VPNSID. To ensure that PE3 APE1 will resolve SPE1's VPN routes reachability through the VPNSID.
can properly route to PE1, PE1 needs to advertise its own locator To ensure that APE1 can properly route to PE1, PE1 needs to advertise
route. The advertisement of the locator route is not in the scope of its own locator route. The advertisement of the locator route is not
this document. in the scope of this document.
To speed up fault detection, we may configure an S-BFD session on PE3 To speed up fault detection, we may configure an S-BFD session on
to detect PE1 or PE2's reachbility. In traditional mode, a APE1 to detect SPE1 or SPE2's reachability. In traditional mode, a
discriminator needs to be assigned by PE1 and PE2, and two S-BFD discriminator needs to be assigned by SPE1 and SPE2, and two S-BFD
sessions need to be configured on PE3 to detect the VPN SID's sessions need to be configured on APE1 to detect the VPN SID's
reachability of PE1 and PE2. It needs to generate an S-BFD session reachability of SPE1 and SPE2. It needs to generate an S-BFD session
with the destination set to the VPN SID. To reduce the number of with the destination set to the VPN SID. To reduce the number of
S-BFD sessions, these sessions can be merged into an S-BFD session S-BFD sessions, locator-based S-BFD sessions can be used instead of
which target is remote PE's locator route. S-BFD sessions for VPNSIDs.
There are a large number of such PEs that exist on the network. Each There are a large number of such APEs that exist on the network.
PE is configured with several S-BFD sessions to detect PE1 and PE2, Each APE is configured with several S-BFD sessions to detect PE1 and
which increases the deployment complexity. PE2, which increases the deployment complexity.
3.2. EVPN Layer 3 Service Over SPv6 Policy Use Case 3.2. EVPN Layer 3 Service Over SPv6 Policy Use Case
+-----------------------+ +-------------------+ /---------------------\ /--------------------\
| | | | | | | |
| +-----+ +-----+ | | +-----+ | +----+ | +----+ +-----+ | |+-----+ +----+ |
| , PE1 |------|ASBR1|------|ASBR3\ | |UCE1|---|-|APE1|------|ASBR1|-|--||ASBR3|------|SPE1| |
|/+-----+ +-----+ | | +-----+\ | +----+ | +----+ \ ,-----+ | |+-----+\ /+----+ |
/ | | \ | | \ / | | \ / `|
/| | | \ | | .... \/ | | \/ |', +----+
+-----/ | | | '-----+ | +-----+ | /\ | | /\ | .|SCE1|
| CE1 | | | | | PE3 |---| CE2 | | / \ | | / \ |-` +----+
+------ | | | /-----+ | +-----+ +----+ | +----+ / '-----+ | |+-----+- '+-----`|
`, | | / | |UCEn|---|-|APEn|------|ASBR2|-|--||ASBR4|------|SPE2| |
|.+-----+ +-----+ | | +-----+ / | +----+ | +----+ +-----+ | |+-----+ +----+ |
| ' PE2 |------|ASBR2|------|ASBR4|- | | | | |
| +-----+ +-----+ | | +-----+ | | AS65001 | | AS65002 |
| | | | \---------------------/ \--------------------/
| AS65001 | | AS65002 |
+-----------------------+ +-------------------+
Figure 2: EVPN Layer 3 Service Over SRv6 Policy Figure 2: EVPN Layer 3 Service Over SRv6 Policy
Figure 2 shows a SRv6 Policy scenario. CE1 is dual-homed to PE1 and Figure 2 shows a SRv6 Policy scenario. SCE1 is dual-homed to SPE1
PE2, and CE2 is accessed to PE3. PE1, PE2, and PE3 are cross BGP and SPE2, and UCE1 is accessed to APE1. SPE1, SPE2, and APE1 are
ASes. cross BGP ASes.
CE1 accesses PE1 and PE2 through Layer 3 and advertises its private SCE1 accesses SPE1 and SPE2 through Layer 3 and advertises its
network routes to PE1. PE1 encapsulates the routes into Type 5 private network routes to APE1. SPE1 and SPE2 encapsulate the routes
routes in the EVPN format and sends them to PE3. into Type 5 routes in the EVPN format and sends them to APE1.
After receiving Type 5 routes advertised by PE1 and PE2, PE3 After receiving Type 5 routes advertised by SPE1 and SPE2, APE1
generates primary and backup entries for the routes, speeding up generates primary and backup entries for the routes, speeding up
service switchover. PE3 parses the tunnel based on the <nexthop, service switchover. APE1 parses the tunnel based on the <nexthop,
color> of the service routes advertised by PE1 and PE2, and matches color> of the service routes advertised by SPE1 and SPE2, and matches
an SRv6 Policy. After receiving the traffic from CE2 to CE1, PE3 an SRv6 Policy. After receiving the traffic from UCE1 to SCE1, APE1
encapsulates and forwards the traffic based on the SRv6 Policy. encapsulates and forwards the traffic based on the SRv6 Policy.
An S-BFD session needs to be established for these SRv6 Policy-based An S-BFD session needs to be established for these SRv6 Policy-based
forwarding paths to swiftly detect the availability of the paths. forwarding paths to swiftly detect the availability of the paths.
When detecting a fault on the SRv6 Policy path of the primary service When detecting a fault on the SRv6 Policy path of the primary service
route, services can be swiftly switched to the backup path, providing route, services can be swiftly switched to the backup path, providing
more reliable protection for services. more reliable protection for services.
There are a large number of such PEs that exist on the network. Each There are a large number of such PEs that exist on the network. Each
PE is configured with several S-BFD sessions to detect PE1 and PE2, PE is configured with several S-BFD sessions to detect PE1 and PE2,
skipping to change at page 6, line 40 skipping to change at page 7, line 19
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BFD Discriminator | | BFD Discriminator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Optional TLVs ~ ~ Optional TLVs ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of the BFD Discriminator Attribute Figure 3: Format of the BFD Discriminator Attribute
o BFD Mode: o BFD Mode:
The BFD Mode field is 1 octet. [RFC9026] defines only the P2MP BFD The BFD Mode field is 1 octet. [RFC9026] defines only the P2MP BFD
session for MVPN. This document defines two new types of SBFD session for MVPN. This document defines two new types of S-BFD
session types based on the preceding scenarios. session types based on the preceding scenarios.
As described in the preceding scenario. There are two types of S-BFD As described in the preceding scenario. There are two types of S-BFD
sessions for SRv6 services. For service over SRv6 BE, an IP-routed sessions for SRv6 services. For service over SRv6 BE, an IP-routed
S-BFD session needs to be created to detect the locator route. For S-BFD session needs to be created to detect the locator route. For
service over SRv6 Policy, an S-BFD session for SRv6 Policy path needs service over SRv6 Policy, an S-BFD session for SRv6 Policy path needs
to be created to detect the SRv6 Policy path. So two new BFD modes to be created to detect the SRv6 Policy path. So two new BFD modes
should be introduced here. should be introduced here.
SBFD for SRv6 Locator Session Mode, which is dedicated to detecting S-BFD for SRv6 Locator Session Mode, which is dedicated to detecting
the locator. The temporary type is 176, and is to be allocated by the locator. The temporary type is 176, and is to be allocated by
IANA. IANA.
SBFD for Common Session Mode, which is for general SBFD session. The S-BFD for Common Session Mode, which is for general S-BFD session.
temporary type is 177, and is to be allocated by IANA. This mode is The temporary type is 177, and is to be allocated by IANA. This mode
not only for SRv6, but also can be used for other scenarios. is not only for SRv6, but also can be used for other scenarios.
o BFD Discriminators: o BFD Discriminators:
The field length is 4 octets. Used to specify the discriminator for The field length is 4 octets. Used to specify the discriminator for
S-BFD session. S-BFD session.
o Optional TLVs: o Optional TLVs:
Variable-length fields are optional. Indicates the additional Variable-length fields are optional. Indicates the additional
information required for creating a S-BFD session. The format is as information required for creating a S-BFD session. The format is as
skipping to change at page 7, line 45 skipping to change at page 8, line 26
Discriminator attribute in the learned route and continues to Discriminator attribute in the learned route and continues to
advertise the route to the remote PE, the receiver may use incorrect advertise the route to the remote PE, the receiver may use incorrect
information when creating an S-BFD session. Therefore, the information when creating an S-BFD session. Therefore, the
advertised S-BFD Discriminator attribute needs to carry the IP advertised S-BFD Discriminator attribute needs to carry the IP
address for receiver verification. address for receiver verification.
In this document, S-BFD for SRv6 Locator Session and S-BFD for Common In this document, S-BFD for SRv6 Locator Session and S-BFD for Common
Session must carry IP addresses except discriminators, which reuse Session must carry IP addresses except discriminators, which reuse
the Source IP Address TLV defined in [RFC9026]. the Source IP Address TLV defined in [RFC9026].
If the mode is set to SBFD for SRv6 Locator Session, the SRv6 Locator If the mode is set to S-BFD for SRv6 Locator Session, the SRv6
address used for the service is carried. Locator address used for the service is carried.
If the mode is set to SBFD for Common Session, the next-hop address If the mode is set to S-BFD for Common Session, the next-hop address
used for the service is carried. used for the service is carried.
For details about the error handling, see section "Error Handling". For details about the error handling, see section "Error Handling".
4.2. ProceduerProceduer 4.2. Router Procedure
In BGP address families, such as L3VPN or EVPN, routes can carry the In BGP address families, such as L3VPN or EVPN, routes can carry the
S-BFD Discriminator attribute as required so that S-BFD sessions can S-BFD Discriminator attribute as required so that S-BFD sessions can
be established based on the attribute. The following uses S-BFD for be established based on the attribute. The following uses S-BFD for
SRv6 Locator as an example. If mode is set to SBFD for Common SRv6 Locator as an example. If mode is set to S-BFD for Common
Session, the processing method is similar. Session, the processing method is similar.
4.2.1. Egress Node Process 4.2.1. Egress Node Process
As shown in figure 1, the S-BFD discriminator is configured on PE1. As shown in figure 1, the S-BFD discriminator is configured on PE1.
After obtaining the information, BGP encapsulates the attribute into After obtaining the information, BGP encapsulates the attribute into
the EVPN route and sets the BFD Mode to SBFD for Locator Session, the EVPN route and sets the BFD Mode to S-BFD for Locator Session,
when advertising the EVPN route. The Discriminator value is local when advertising the EVPN route. The Discriminator value is local
discriminator value. The optional TLV carries the local PE's locator discriminator value. The optional TLV carries the local PE's locator
address used by the VPN. address used by the VPN.
4.2.2. Transit Node Process 4.2.2. Transit Node Process
Here is the end-to-end SRv6 BE scenario. The ASBR does not re- Here is the end-to-end SRv6 BE scenario. The ASBR does not re-
allocate the VPN SID. Thus, the ASBR does not require to modify the allocate the VPN SID. Thus, the ASBR does not require to modify the
VPN SID, and not to alter the BFD discriminator attribute. VPN SID, and not to alter the BFD discriminator attribute.
skipping to change at page 8, line 51 skipping to change at page 9, line 34
attribute. In this case, the SID and locator carried in the route attribute. In this case, the SID and locator carried in the route
received by PE3 do not match the Source IP carried in the Optional received by PE3 do not match the Source IP carried in the Optional
TLV in the BFD attribute. Therefore, PE3 does not need to establish TLV in the BFD attribute. Therefore, PE3 does not need to establish
an S-BFD session to remote PE, which can avoid resource waste. an S-BFD session to remote PE, which can avoid resource waste.
5. Error handling 5. Error handling
Error handling complies with [RFC7606]. In this document, the BFD Error handling complies with [RFC7606]. In this document, the BFD
discriminator information is used only to establish an S-BFD session. discriminator information is used only to establish an S-BFD session.
Therefore, if the BFD discriminator information is invalid, the BFD Therefore, if the BFD discriminator information is invalid, the BFD
attirbute will be discard and not transmit to other devices. attribute will be discard and not transmit to other devices.
For BFD discriminator attribute, the following case will be For BFD discriminator attribute, the following case will be
processed: processed:
o The BFD Discriminator value in receiving BFD Discriminator o The BFD Discriminator value in receiving BFD Discriminator
attribute is 0, the attribute is invalid. attribute is 0, the attribute is invalid.
For BFD mode type is S-BFD for SRv6 Locator Session, the following For BFD mode type is S-BFD for SRv6 Locator Session, the following
case will be processed: case will be processed:
skipping to change at page 11, line 22 skipping to change at page 12, line 4
Forwarding Detection (S-BFD) Target Discriminators", Forwarding Detection (S-BFD) Target Discriminators",
RFC 7884, DOI 10.17487/RFC7884, July 2016, RFC 7884, DOI 10.17487/RFC7884, July 2016,
<https://www.rfc-editor.org/info/rfc7884>. <https://www.rfc-editor.org/info/rfc7884>.
[RFC9026] Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed., [RFC9026] Morin, T., Ed., Kebler, R., Ed., and G. Mirsky, Ed.,
"Multicast VPN Fast Upstream Failover", RFC 9026, "Multicast VPN Fast Upstream Failover", RFC 9026,
DOI 10.17487/RFC9026, April 2021, DOI 10.17487/RFC9026, April 2021,
<https://www.rfc-editor.org/info/rfc9026>. <https://www.rfc-editor.org/info/rfc9026>.
Authors' Addresses Authors' Addresses
Haibo Wang Haibo Wang
Huawei Huawei
No. 156 Beiqing Road No. 156 Beiqing Road
Beijing Beijing
100095 100095
P.R. China P.R. China
Email: rainsword.wang@huawei.com Email: rainsword.wang@huawei.com
Yang Huang Jie Dong
Huawei Huawei
No. 156 Beiqing Road No. 156 Beiqing Road
Beijing Beijing
100095 100095
P.R. China P.R. China
Email: jie.dong@huawei.com
Email: yang.huang@huawei.com Greg Mirsky
Ericsson
Email: gregimirsky@gmail.com
Jie Dong Yang Huang
Huawei Huawei
No. 156 Beiqing Road No. 156 Beiqing Road
Beijing Beijing
100095 100095
P.R. China P.R. China
Email: yang.huang@huawei.com
Email: jie.dong@huawei.com
 End of changes. 42 change blocks. 
131 lines changed or deleted 160 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/