]> China Unicom

No.9 South Shouti Road Beijing 100048 China het21@chinaunicom.cn

China Unicom

No.9 South Shouti Road Beijing 100048 China liuy619@chinaunicom.cn

Huawei

Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China huzhibo@huawei.com

This document specifies the IGP protocol extensions required to support SRv6 path egress protection using the Mirror SID (End.M) mechanism. It defines new sub-TLVs within IS-IS and OSPFv3 for advertising the Mirror SID and the set of protected locators, enabling a backup egress node (protector) to signal its capability to protect a primary egress node within a single link-state IGP area. This document is a companion to , which specifies the overall SRv6 path egress protection mechanism and the End.M behavior. The IGP encoding defined herein provides the signaling substrate for that mechanism. Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Introduction specifies a mechanism for fast protecting the egress node and link of a Segment Routing for IPv6 (SRv6) path. The mechanism introduces a Mirror SID (End.M) behavior and requires the backup egress node (protector) to advertise the tuple <PEB, PEA, Mirror SID> together with the protected locators through the IGP. This enables the Point of Local Repair (PLR) to pre-compute backup paths toward the protector for use upon failure of the primary egress. This document provides the IGP protocol encoding for that mechanism. It defines the IS-IS and OSPFv3 sub-TLVs needed to carry the Mirror SID and protected locator information within link-state advertisements. The overall egress protection mechanism, including the End.M behavior definition, protection procedures, and operational guidelines, is described in . The IGP extensions defined in this document operate within a single link-state IGP area/level. They carry locator-level protection information only; no per-service (e.g., per-VPN or per-Service SID) signaling is introduced in the IGP. The encoding is designed to minimize IGP flooding overhead while enabling the PLR to compute Loop-Free Alternates (LFAs) for egress protection. Note: The applicability and scaling considerations for the overall mechanism are discussed in . This document focuses solely on the encoding of the IGP extensions.

Terminology The following terminologies are used in this document.

End.M:

Mirror SID endpoint behavior (value 74)

IGP:

Interior Gateway Protocol

IS-IS:

Intermediate System to Intermediate System

LFA:

Loop-Free Alternate

Locator:

An IPv6 prefix advertised by an SRv6-capable node

LS:

Link State, which is LSA in OSPFv3 or LSP in IS-IS

LSA:

Link State Advertisement in OSPFv3

LSP:

Link State Protocol Data Unit in IS-IS

Mirror SID:

An SRv6 SID with the End.M behavior, used to redirect traffic to a backup egress node

OSPFv3:

Open Shortest Path First version 3

PE:

Provider Edge

PEA:

Primary Egress node to be protected

PEB:

Backup Egress node (protector)

PLR:

Point of Local Repair

SID:

Segment Identifier

SR:

Segment Routing

SRv6:

Segment Routing for IPv6

sub-TLV:

A TLV nested within another TLV

sub-sub-TLV:

A TLV nested within a sub-TLV

TI-LFA:

Topology Independent LFA

SRv6 Mirror SID Overview This section provides a brief overview of the SRv6 Mirror SID (End.M) mechanism. For a complete description, including the protection procedures, packet walks, and operational guidelines, refer to . In SRv6 path egress protection, a backup egress node PEB is provisioned to protect a primary egress node PEA. A Mirror SID (End.M, SRv6 Endpoint Behavior value 74) is configured on PEB. The Mirror SID is associated with an IPv6 FIB table that contains the forwarding entries for the services anchored on PEA. When PEA fails, the PLR (typically the upstream neighbor of PEA) re-routes the traffic to PEB by encapsulating the packet with the Mirror SID as the destination. PEB decapsulates the packet and forwards the inner packet using the FIB table identified by the Mirror SID, thus reproducing the egress behavior of the failed PEA. To enable this protection, PEB must advertise through the IGP the information <PEB, PEA, Mirror SID>, together with the locators of PEA that are protected. This advertisement allows the PLR to learn that PEB protects PEA and to compute a backup path toward PEB. The following sections define the IS-IS and OSPFv3 sub-TLVs for carrying this information.

IS-IS Extensions for Mirror SID This section defines the IS-IS extensions for advertising the Mirror SID and associated protected locators.

IS-IS SRv6 Mirror SID sub-TLV A new sub-TLV, called the IS-IS SRv6 Mirror SID sub-TLV, is defined. It is carried within the SRv6 Locator TLV defined in to advertise the SRv6 Mirror SID and the locators of the nodes to be protected. The SRv6 Mirror SID inherits the topology and algorithm from the parent locator TLV. The format of the sub-TLV is illustrated below.

IS-IS SRv6 Mirror SID sub-TLV

Type:

TBD1 (suggested value 8) is to be assigned by IANA.

Length:

1 octet. Its value MUST NOT be less than 23. 23 is 19 (i.e., the size of Reserved, SRv6 Endpoint Function and SID) plus 4 (i.e., the minimum size of an IS-IS Protected Locators sub-sub-TLV). The entire IS-IS SRv6 Mirror SID sub-TLV MUST be ignored if the length is less than 23.

Reserved:

1 octet. This octet MUST be set to zero on transmit, and ignored on receipt.

SRv6 Endpoint Function:

2 octets. It MUST contain the endpoint function 74 for Mirror SID (End.M). The entire IS-IS SRv6 Mirror SID sub-TLV MUST be ignored if it does not contain the endpoint function 74.

SID:

16 octets. This field contains the SRv6 Mirror SID to be advertised. It MUST NOT be zero (0). The entire IS-IS SRv6 Mirror SID sub-TLV MUST be ignored if it contains zero (0).

IS-IS Protected Locators sub-sub-TLV A Protected Locators sub-sub-TLV is defined and used to carry the locators of the egress node to be protected by the SRv6 Mirror SID. The IS-IS SRv6 Mirror SID sub-TLV MUST include exactly one IS-IS Protected Locators sub-sub-TLV. It has the following format.

IS-IS Protected Locators sub-sub-TLV

Type:

TBD2 (suggested value 1) is to be assigned by IANA.

Length:

1 octet. Its value MUST NOT be less than 2. The entire IS-IS SRv6 Mirror SID sub-TLV MUST be ignored if the length is less than 2.

Locator-Size:

1 octet. Number of bits in the Locator field, which MUST be from the range (1-128). The entire IS-IS SRv6 Mirror SID sub-TLV MUST be ignored if the Locator-Size is outside this range.

Locator:

1-16 octets. This field encodes an SRv6 Locator of an egress node to be protected by the SRv6 Mirror SID. The Locator is encoded in the minimal number of octets for the given number of bits. Trailing bits MUST be set to zero and ignored when received.

IS-IS Advertisement Procedures When a backup egress node PEB advertises that it protects a primary egress node PEA with a Mirror SID through an LSP, the LSP MUST contain an SRv6 Locator TLV carrying an IS-IS SRv6 Mirror SID sub-TLV. This sub-TLV includes the Mirror SID in the SID field and PEA's locators in the IS-IS Protected Locators sub-sub-TLV. The IS-IS SRv6 Mirror SID sub-TLV MUST include exactly one Protected Locators sub-sub-TLV and MUST NOT carry per-service (e.g., VPN or Service-SID) enumerations. Attempting to list individual services at large scale is not suitable due to IGP flooding and convergence considerations, as discussed in .

OSPFv3 Extensions for Mirror SID This section defines the OSPFv3 extensions for advertising the Mirror SID and associated protected locators.

OSPFv3 SRv6 Mirror SID sub-TLV A new sub-TLV, called the OSPFv3 SRv6 Mirror SID sub-TLV, is defined. It is carried within the SRv6 Locator TLV defined in to advertise the SRv6 Mirror SID and the locators of the nodes to be protected. Its format is illustrated below. Note that OSPFv3 sub-TLVs use 2-octet Type and Length fields, unlike IS-IS which uses 1-octet fields.

OSPFv3 SRv6 Mirror SID sub-TLV

Type:

TBD3 (suggested value 8) is to be assigned by IANA.

Length:

2 octets. Its value MUST NOT be less than 26. 26 is 20 (i.e., the size of Reserved, SRv6 Endpoint Function and SID) plus 6 (i.e., the minimum size of an OSPFv3 Protected Locators sub-TLV). The entire OSPFv3 SRv6 Mirror SID sub-TLV MUST be ignored if the length is less than 26.

Reserved:

2 octets. It MUST be set to zero for transmission and ignored on reception.

SRv6 Endpoint Function:

2 octets. It MUST contain the endpoint function 74 for End.M SID. The entire OSPFv3 SRv6 Mirror SID sub-TLV MUST be ignored if it does not contain the endpoint function 74.

SID:

16 octets. This field contains the SRv6 Mirror SID to be advertised. It MUST NOT be zero (0). The entire OSPFv3 SRv6 Mirror SID sub-TLV MUST be ignored if it contains zero (0).

OSPFv3 Protected Locators sub-TLV A Protected Locators sub-TLV is defined and used to carry the locators of the node to be protected by the SRv6 Mirror SID. The OSPFv3 SRv6 Mirror SID sub-TLV MUST include exactly one OSPFv3 Protected Locators sub-TLV. It has the following format.

OSPFv3 Protected Locators sub-TLV

Type:

TBD4 (suggested value 1) is to be assigned by IANA.

Length:

2 octets. Its value MUST NOT be less than 2. The entire OSPFv3 SRv6 Mirror SID sub-TLV MUST be ignored if the Length is less than 2.

Locator-Size:

1 octet. Number of bits in the Locator field, which MUST be from the range (1-128). The entire OSPFv3 SRv6 Mirror SID sub-TLV MUST be ignored if the Locator-Size is outside this range.

Locator:

1-16 octets. This field encodes an SRv6 Locator of an egress node to be protected by the SRv6 Mirror SID. The Locator is encoded in the minimal number of octets for the given number of bits. Trailing bits MUST be set to zero and ignored when received.

OSPFv3 Advertisement Procedures When a backup egress node PEB advertises that it protects a primary egress node PEA with a Mirror SID through an LSA, the LSA MUST contain an SRv6 Locator TLV carrying an OSPFv3 SRv6 Mirror SID sub-TLV. This sub-TLV includes the Mirror SID in the SID field and PEA's locators in the OSPFv3 Protected Locators sub-TLV. The OSPFv3 SRv6 Mirror SID sub-TLV MUST include exactly one Protected Locators sub-TLV and MUST NOT carry per-service (e.g., VPN or Service-SID) enumerations, for the same scaling reasons discussed in .

Comparison of IS-IS and OSPFv3 Encodings The IS-IS and OSPFv3 encodings for the Mirror SID and Protected Locators are semantically equivalent but differ in the following structural aspects:

o

Type field: 1 octet in IS-IS sub-TLVs vs. 2 octets in OSPFv3 sub-TLVs.

o

Length field: 1 octet in IS-IS sub-TLVs vs. 2 octets in OSPFv3 sub-TLVs.

o

Reserved field: 1 octet in the IS-IS SRv6 Mirror SID sub-TLV vs. 2 octets in the OSPFv3 equivalent.

o

Minimum Length: 23 for the IS-IS SRv6 Mirror SID sub-TLV vs. 26 for the OSPFv3 equivalent.

o

Nested TLV naming: sub-sub-TLVs in IS-IS vs. sub-TLVs in OSPFv3, reflecting the terminology conventions of each protocol.

IANA Considerations This document requests IANA to make the following assignments in the specified registries.

IS-IS Sub-TLV Registrations Under registry "IS-IS Sub-TLVs for TLVs Advertising Prefix Reachability", IANA is requested to assign the following new sub-TLV:

IS-IS Sub-Sub-TLV Registry IANA is requested to create and maintain a new registry for sub-sub-TLVs of the SRv6 Mirror SID sub-TLV. The suggested registry name is:

o

Sub-Sub-TLVs for SRv6 Mirror SID Sub-TLV

Initial values for the registry are given below. Future assignments are to be made through IETF Review .

OSPFv3 Sub-TLV Registrations Under registry "OSPFv3 SRv6 Locator LSA Sub-TLVs" , IANA is requested to assign the following new sub-TLVs:

Security Considerations The IGP extensions defined in this document are used within a single link-state IGP area/level under a single administrative domain. They introduce new sub-TLVs to IS-IS and OSPFv3 for advertising Mirror SID and protected locator information. Security concerns for IS-IS are addressed in , , and . While IS-IS is deployed under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the IS-IS routing domain. In these deployments, the stronger authentication mechanisms defined in the aforementioned documents SHOULD be used. Security concerns for OSPFv3 are described in and . While OSPFv3 is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPFv3 routing domain. In these deployments, stronger authentication mechanisms such as those specified in and SHOULD be used. The following additional security considerations apply specifically to the Mirror SID IGP extensions: Mirror SID Authentication: Since the Mirror SID is advertised through IGP, it is essential that IGP advertisements are authenticated to prevent malicious nodes from advertising counterfeit Mirror SIDs. Implementations SHOULD support the cryptographic authentication mechanisms specified in for IS-IS and for OSPFv3. Unauthorized Rerouting: An attacker could attempt to trigger unnecessary rerouting by advertising false protection relationships. This is mitigated by authenticating IGP advertisements and limiting protector selection to trusted nodes within the same administrative domain. Traffic Interception: An attacker could attempt to become a protector to intercept traffic destined to a primary egress node. This is mitigated by authenticating IGP advertisements of Mirror SIDs and monitoring for unexpected protector advertisements. Control Plane Overload: An attacker could attempt to flood the IGP with excessive protection advertisements, causing control plane overload and convergence issues. This is mitigated by:

o

Limiting the number of protection relationships per node.

o

Implementing IGP flooding rate limiting.

o

Following the operational guidelines in to limit the scale of deployments.

o

Monitoring IGP database size and convergence times.

References Normative References International Organization for Standardization In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the authentication of Intermediate System to Intermediate System (IS-IS) Protocol Data Units (PDUs) using the Hashed Message Authentication Codes - Message Digest 5 (HMAC-MD5) algorithm as found in RFC 2104. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. The base specification includes an authentication mechanism that allows for multiple authentication algorithms. The base specification only specifies the algorithm for cleartext passwords. This document replaces RFC 3567. This document proposes an extension to that specification that allows the use of the HMAC-MD5 authentication algorithm to be used in conjunction with the existing authentication mechanisms. [STANDARDS-TRACK] This document proposes an extension to Intermediate System to Intermediate System (IS-IS) to allow the use of any cryptographic authentication algorithm in addition to the already-documented authentication schemes, described in the base specification and RFC 5304. IS-IS is specified in International Standards Organization (ISO) 10589, with extensions to support Internet Protocol version 4 (IPv4) described in RFC 1195. Although this document has been written specifically for using the Hashed Message Authentication Code (HMAC) construct along with the Secure Hash Algorithm (SHA) family of cryptographic hash functions, the method described in this document is generic and can be used to extend IS-IS to support any cryptographic hash function in the future. [STANDARDS-TRACK] This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3). Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP). Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet- size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible. All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6. [STANDARDS-TRACK] OSPFv3 requires functional extension beyond what can readily be done with the fixed-format Link State Advertisement (LSA) as described in RFC 5340. Without LSA extension, attributes associated with OSPFv3 links and advertised IPv6 prefixes must be advertised in separate LSAs and correlated to the fixed-format LSAs. This document extends the LSA format by encoding the existing OSPFv3 LSA information in Type-Length-Value (TLV) tuples and allowing advertisement of additional information with additional TLVs. Backward-compatibility mechanisms are also described. This document updates RFC 5340, "OSPF for IPv6", and RFC 5838, "Support of Address Families in OSPFv3", by providing TLV-based encodings for the base OSPFv3 unicast support and OSPFv3 address family support. This document describes means and mechanisms to provide authentication/confidentiality to OSPFv3 using an IPv6 Authentication Header/Encapsulating Security Payload (AH/ESP) extension header. [STANDARDS-TRACK] Currently, OSPF for IPv6 (OSPFv3) uses IPsec as the only mechanism for authenticating protocol packets. This behavior is different from authentication mechanisms present in other routing protocols (OSPFv2, Intermediate System to Intermediate System (IS-IS), RIP, and Routing Information Protocol Next Generation (RIPng)). In some environments, it has been found that IPsec is difficult to configure and maintain and thus cannot be used. This document defines an alternative mechanism to authenticate OSPFv3 protocol packets so that OSPFv3 does not depend only upon IPsec for authentication. The OSPFv3 Authentication Trailer was originally defined in RFC 6506. This document obsoletes RFC 6506 by providing a revised definition, including clarifications and refinements of the procedures. The Segment Routing over IPv6 (SRv6) Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. Each instruction is implemented on one or several nodes in the network and identified by an SRv6 Segment Identifier in the packet. This document defines the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors that enables the creation of interoperable overlays with underlay optimization. The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called "segments". It can be implemented over the MPLS or the IPv6 data plane. This document describes the IS-IS extensions required to support SR over the IPv6 data plane. This document updates RFC 7370 by modifying an existing registry. The Segment Routing (SR) architecture allows a flexible definition of the end-to-end path by encoding it as a sequence of topological elements called segments. It can be implemented over an MPLS or IPv6 data plane. This document describes the OSPFv3 extensions required to support SR over the IPv6 data plane. China Unicom Huawei Futurewei Verizon China Unicom Informative References Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. This document specifies a fast reroute framework for protecting IP/MPLS services and MPLS transport tunnels against egress node and egress link failures. For each type of egress failure, it defines the roles of Point of Local Repair (PLR), protector, and backup egress router and the procedures of establishing a bypass tunnel from a PLR to a protector. It describes the behaviors of these routers in handling an egress failure, including local repair on the PLR and context-based forwarding on the protector. The framework can be used to develop egress protection mechanisms to reduce traffic loss before global repair reacts to an egress failure and control-plane protocols converge on the topology changes due to the egress failure. Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy. This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy. This document defines procedures and messages for SRv6-based BGP services, including Layer 3 Virtual Private Network (L3VPN), Ethernet VPN (EVPN), and Internet services. It builds on "BGP/MPLS IP Virtual Private Networks (VPNs)" (RFC 4364) and "BGP MPLS-Based Ethernet VPN" (RFC 7432). Individual Cisco Systems Cisco Systems INSA Lyon Orange Bell Canada This document presents Topology Independent Loop-free Alternate Fast Reroute (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Reroute (FRR) behavior builds on proven IP Fast Reroute concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any two-connected networks using a link-state IGP. An important aspect of TI-LFA is the FRR path selection approach establishing protection over the expected post-convergence paths from the point of local repair, reducing the operational need to control the tie-breaks among various FRR options. This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407; it also updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained YANG modules.

Acknowledgments The authors would like to thank Acee Lindem, Peter Psenak, Huaimo Chen, Mehmet Toy and all scontributors to for their work on the overall egress protection mechanism that this document builds upon.