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