| Internet-Draft | SR Ingress Protection | April 2022 |
| Chen, et al. | Expires 20 October 2022 | [Page] |
This document describes extensions to Border Gateway Protocol (BGP) for protecting the ingress node of a Segment Routing (SR) tunnel or path.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 20 October 2022.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The fast protection of a transit node of a Segment Routing (SR) path or tunnel is described in [I-D.bashandy-rtgwg-segment-routing-ti-lfa] and [I-D.hu-spring-segment-routing-proxy-forwarding]. [RFC8424] presents extensions to RSVP-TE for the fast protection of the ingress node of a traffic engineering (TE) Label Switching Path (LSP). However, these documents do not discuss any protocol extensions for the fast protection of the ingress node of an SR path or tunnel.¶
This document fills that void and specifies protocol extensions to Border Gateway Protocol (BGP) for the fast protection of the ingress node of an SR path or tunnel. Ingress node and ingress, fast protection and protection as well as SR path and SR tunnel will be used exchangeably in the following sections.¶
The following terminologies are used in this document.¶
To protect against the failure of the (primary) ingress node of a (primary) SR path, a backup ingress node is configured or selected and is different from the (primary) ingress node. A backup SR path from the backup ingress node is computed and installed. Primary ingress and ingress as well as primary SR path and SR path will be used exchangeably.¶
Figure 1 shows an example of protecting ingress PE1 of a SR path, which is from ingress PE1 to egress PE3.¶
******* *******
[PE1]-----[P1]-----[PE3] PE1 Ingress
/ | |& &&&&& | \ PEx Provider Edge
/ | |& | \ CEx Customer Edge
[CE1] | |& | [CE2] Px Non Provider Edge
\ | |& | / *** SR Path
\ | &&&&&& |& | / &&& Backup Path
[PE2]-----[P2]-----[PE4]
In normal operations, CE1 sends the traffic with destination PE3 to ingress PE1, which imports the traffic into the SR path.¶
When CE1 detects the failure of ingress PE1, it switches the traffic to backup ingress PE2, which imports the traffic from CE1 into a backup SR path. The backup path is from the backup ingress PE2 to the egress PE3. When the traffic is imported into the backup path, it is sent to the egress PE3 along the path.¶
After the failure of the ingress of an SR path happens, there are a couple of different ways to detect the failure. In each way, there may be some specific behavior for the traffic source (e.g., CE1) and the backup ingress (e.g., PE2).¶
In one way, the traffic source (e.g., CE1) is responsible for fast detecting the failure of the ingress (e.g., PE1) of an SR path. Fast detecting the failure means detecting the failure in a few or tens of milliseconds. The backup ingress (e.g., PE2) is ready to import the traffic from the traffic source into the backup SR path installed.¶
In normal operations, the source sends the traffic to the ingress of the SR path. When the source detects the failure of the ingress, it switches the traffic to the backup ingress, which delivers the traffic to the egress of the SR path via the backup SR path.¶
In another way, the backup ingress is responsible for fast detecting the failure of the ingress of an SR path.¶
In normal operations, the source (e.g., CE1) sends the traffic to the ingress (e.g., PE1) and may send the traffic to the backup ingress (e.g., PE2). It sends the traffic to the backup ingress (e.g., PE2) after the ingress fails.¶
The backup ingress does not import any traffic from the source into the backup SR path in normal operations. When it detects the failure of the ingress, it imports the traffic from the source into the backup SR path.¶
For a SR path from a primary ingress node to an egress node, a backup ingress node is selected to protect the failure of the primary ingress node of the SR path. This section describes the extensions to BGP for representing the information for protecting the primary ingress node in a BGP UPDATE message and distributing the information to the backup ingress node. The information includes a SR backup path.¶
[I-D.ietf-idr-segment-routing-te-policy] specifies a way of representing a SR path in a BGP UPDATE message and distributing the SR path to the ingress node of the SR path.¶
This is extended to represent the information for protecting the primary ingress by defining a few of new Sub-TLVs.¶
A new Sub-TLV, called SR Path Ingress Protection Sub-TLV, is defined. When a UPDATE message is sent to the backup ingress node for protecting the primary ingress node of a SR path, the message contains this Sub-TLV. Its format is illustrated below.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD1) | Length (variable) | Flags |A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ~ ~ Sub-TLVs (optional) ~ ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1 octet. One flag is defined.¶
1 bit. It is set to¶
A few optional Sub-TLVs are defined, which are Primary Ingress Sub-TLV, Service Sub-TLV and Traffic Description Sub-TLV.¶
A Primary Ingress Sub-TLV indicates the IP address of the primary ingress node of a primary SR path. It has two formats: one for primary ingress node IPv4 address and the other for primary ingress node IPv6 address, which are illustrated below.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (1) | Length (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primary Ingress IPv4 Address (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (2) | Length (16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Primary Ingress IPv6 Address (16 octets) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Service Sub-TLV contains a service ID or label to be added into a packet to be carried by a SR path. It has three formats: the first one for the service identified by a label, the second one for the service identified by a service identifier (ID) of 32 bits, and the third one for the service identified by a service identifier (ID) of 128 bits. Their formats are illustrated below.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (3) | Length (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | zero | Service Label (20 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (4) | Length (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service ID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (5) | Length (16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service ID (16 octets) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A Traffic Description Sub-TLV describes the traffic to be imported into a backup SR path. Five Traffic Description Sub-TLVs are defined. Two of them are FEC Sub-TLVs and the others are interface Sub-TLVs.¶
Two FEC Sub-TLVs are IPv4 and IPv6 FEC Sub-TLVs. Their formats are illustrated below.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (6) |Length(variable| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |IPv4 Prefix Len| IPv4 Prefix ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ (Optional) Virtual Network ID (2 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (7) |Length(variable| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |IPv6 Prefix Len| IPv6 Prefix ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Optional Virtual Network ID (2 octets) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An Interface sub-TLV indicates the interface from which the traffic is received and imported into the backup SR path/tunnel. It has three formats: one for interface index, the other two for IPv4 and IPv6 address, which are illustrated below.¶
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (8) | Length (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface Index (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (9) | Length (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface IPv4 Address (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (10) | Length (16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Interface IPv6 Address (16 octets) | ~ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When a backup ingress node receives a UPDATE message containing the information for protecting the primary ingress node of a SR path, it installs a forwarding entry in its FIB based on the information. The information is encoded in a SR policy of the following structure:¶
SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
Attributes:
Tunnel Encaps Attribute (23)
Tunnel Type (15): SR Policy
SR Path Ingress Protection Sub-TLV
Primary Ingress Sub-TLV
Service Sub-TLV
Traffic Description Sub-TLV
Preference Sub-TLV
Binding SID Sub-TLV
Explicit NULL Label Policy (ENLP) Sub-TLV
Priority Sub-TLV
Policy Name Sub-TLV
Segment List Sub-TLV
Weight Sub-TLV
Segment Sub-TLV
Segment Sub-TLV
...
...
¶
Where:¶
After receiving a SR policy with a SR Path Ingress Protection Sub-TLV, the backup ingress node will install one or more candidate paths into its "BGP table". Another module such as SRPM will choose one or more paths and install the forwarding entries for them in the data plane.¶
The forwarding entries for the paths installed in the data plane will be set to be inactive if the flag A in the SR Path Ingress Protection Sub-TLV is zero. When the primary ingress node fails, these forwarding entries are set to be active. The failure of the primary ingress may be detected by the backup ingress node through using a mechanism such as BFD. The IP address of the primary ingress in the Primary Ingress Sub-TLV may be used for detecting the failure of the primary ingress node.¶
If the flag A in the SR Path Ingress Protection Sub-TLV is one, then the forwarding entries for the paths installed in the data plane will be set to be active.¶
When there is a Service Sub-TLV in the SR Path Ingress Protection Sub-TLV, the ID or Label in the Service Sub-TLV will be included in the forwarding entries. When a packet is imported into a backup SR path using the forwarding entries, the service ID or Label is pushed first and then the sequence of segments represented in the Segment List Sub-TLV.¶
Protocol extensions defined in this document do not affect the BGP security other than those as discussed in the Security Considerations section of [RFC5575].¶
The authors of this document would like to thank Dhruv Dhody for the comments.¶
Under Existing Registry Name: "BGP Tunnel Encapsulation Attribute Sub-TLVs", IANA is requested to assign a new Sub-TLV value for SR Path Ingress Protection as follows:¶
Value sub-TLV Name Reference ----- ------------------------------------ -------------- TBD1 SR Path Ingress Protection Sub-TLV This Document¶
A new registry called "Ingress Protection Information Sub-TLVs" is defined in this document. IANA is requested to create and maintain new registry:¶
Initial values for the registry are given below. The future assignments are to be made through IETF Review [RFC5226].¶
Value sub-TLV Name Reference ----- ------------------------------------- -------------- 0 Reserved 1 Primary Ingress IPv4 Address Sub-TLV This Document 2 Primary Ingress IPv6 Address Sub-TLV This Document 3 Service Label Sub-TLV This Document 4 32 Bits Service ID Sub-TLV This Document 5 128 Bits Service ID Sub-TLV This Document 6 IPv4 FEC Sub-TLV This Document 7 IPv6 FEC Sub-TLV This Document 8 Interface Index Sub-TLV This Document 9 Interface IPv4 Address Sub-TLV This Document 10 Interface IPv6 Address Sub-TLV This Document 11-255 Unassigned¶