From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc9085.txt | 1441 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 1441 insertions(+) create mode 100644 doc/rfc/rfc9085.txt (limited to 'doc/rfc/rfc9085.txt') diff --git a/doc/rfc/rfc9085.txt b/doc/rfc/rfc9085.txt new file mode 100644 index 0000000..681938e --- /dev/null +++ b/doc/rfc/rfc9085.txt @@ -0,0 +1,1441 @@ + + + + +Internet Engineering Task Force (IETF) S. Previdi +Request for Comments: 9085 Huawei Technologies +Category: Standards Track K. Talaulikar, Ed. +ISSN: 2070-1721 C. Filsfils + Cisco Systems, Inc. + H. Gredler + RtBrick Inc. + M. Chen + Huawei Technologies + August 2021 + + + Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment + Routing + +Abstract + + Segment Routing (SR) allows for a flexible definition of end-to-end + paths by encoding paths as sequences of topological subpaths, called + "segments". These segments are advertised by routing protocols, + e.g., by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) + within IGP topologies. + + This document defines extensions to the Border Gateway Protocol - + Link State (BGP-LS) address family in order to carry SR information + via BGP. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc9085. + +Copyright Notice + + Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction + 1.1. Requirements Language + 2. BGP-LS Extensions for Segment Routing + 2.1. Node Attribute TLVs + 2.1.1. SID/Label TLV + 2.1.2. SR Capabilities TLV + 2.1.3. SR-Algorithm TLV + 2.1.4. SR Local Block TLV + 2.1.5. SRMS Preference TLV + 2.2. Link Attribute TLVs + 2.2.1. Adjacency SID TLV + 2.2.2. LAN Adjacency SID TLV + 2.2.3. L2 Bundle Member Attributes TLV + 2.3. Prefix Attribute TLVs + 2.3.1. Prefix-SID TLV + 2.3.2. Prefix Attribute Flags TLV + 2.3.3. Source Router Identifier TLV + 2.3.4. Source OSPF Router-ID TLV + 2.3.5. Range TLV + 2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs + 2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs + 3. IANA Considerations + 3.1. TLV/Sub-TLV Code Points Summary + 4. Manageability Considerations + 5. Security Considerations + 6. References + 6.1. Normative References + 6.2. Informative References + Acknowledgements + Contributors + Authors' Addresses + +1. Introduction + + Segment Routing (SR) allows for a flexible definition of end-to-end + paths by combining subpaths called "segments". A segment can + represent any instruction: topological or service based. A segment + can have a local semantic to an SR node or global semantic within a + domain. Within IGP topologies, an SR path is encoded as a sequence + of topological subpaths, called "IGP segments". These segments are + advertised by the link-state routing protocols (IS-IS, OSPFv2, and + OSPFv3). + + [RFC8402] defines the link-state IGP segments -- prefix, node, + anycast, and adjacency segments. Prefix segments, by default, + represent an ECMP-aware shortest-path to a prefix, as per the state + of the IGP topology. Adjacency segments represent a hop over a + specific adjacency between two nodes in the IGP. A prefix segment is + typically a multi-hop path while an adjacency segment, in most of the + cases, is a one-hop path. Node and anycast segments are variations + of the prefix segment with their specific characteristics. + + When SR is enabled in an IGP domain, segments are advertised in the + form of Segment Identifiers (SIDs). The IGP link-state routing + protocols have been extended to advertise SIDs and other SR-related + information. IGP extensions are described for: IS-IS [RFC8667], + OSPFv2 [RFC8665], and OSPFv3 [RFC8666]. Using these extensions, SR + can be enabled within an IGP domain. + + SR allows advertisement of single or multi-hop paths. The flooding + scope for the IGP extensions for SR is IGP area-wide. Consequently, + the contents of a Link-State Database (LSDB) or a Traffic Engineering + Database (TED) has the scope of an IGP area; therefore, by using the + IGP alone, it is not enough to construct segments across multiple IGP + area or Autonomous System (AS) boundaries. + + In order to address the need for applications that require + topological visibility across IGP areas, or even across ASes, the + BGP-LS address family / subaddress family have been defined to allow + BGP to carry link-state information. The BGP Network Layer + Reachability Information (NLRI) encoding format for BGP-LS and a new + BGP Path Attribute called the "BGP-LS Attribute" are defined in + [RFC7752]. The identifying key of each link-state object, namely a + node, link, or prefix, is encoded in the NLRI, and the properties of + the object are encoded in the BGP-LS Attribute. + + +------------+ + | Consumer | + +------------+ + ^ + | + v + +-------------------+ + | BGP Speaker | +-----------+ + | (Route Reflector) | | Consumer | + +-------------------+ +-----------+ + ^ ^ ^ ^ + | | | | + +---------------+ | +-------------------+ | + | | | | + v v v v + +-----------+ +-----------+ +-----------+ + | BGP | | BGP | | BGP | + | Speaker | | Speaker | . . . | Speaker | + +-----------+ +-----------+ +-----------+ + ^ ^ ^ + | | | + IGP IGP IGP + + Figure 1: Link-State Information Collection + + Figure 1 denotes a typical deployment scenario. In each IGP area, + one or more nodes are configured with BGP-LS. These BGP speakers + form an Internal BGP (IBGP) mesh by connecting to one or more route + reflectors. This way, all BGP speakers (specifically the route + reflectors) obtain link-state information from all IGP areas (and + from other ASes from External BGP (EBGP) peers). An external + component connects to the route reflector to obtain this information + (perhaps moderated by a policy regarding what information is or isn't + advertised to the external component) as described in [RFC7752]. + + This document describes extensions to BGP-LS to advertise the SR + information. An external component (e.g., a controller) can collect + SR information from across an SR domain (as described in [RFC8402]) + and construct the end-to-end path (with its associated SIDs) that + needs to be applied to an incoming packet to achieve the desired end- + to-end forwarding. SR operates within a trusted domain consisting of + a single AS or multiple ASes managed by the same administrative + entity, e.g., within a single provider network. + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and + "OPTIONAL" in this document are to be interpreted as described in BCP + 14 [RFC2119] [RFC8174] when, and only when, they appear in all + capitals, as shown here. + +2. BGP-LS Extensions for Segment Routing + + This document defines SR extensions to BGP-LS and specifies the TLVs + and sub-TLVs for advertising SR information within the BGP-LS + Attribute. Sections 2.4 and 2.5 list the equivalent TLVs and sub- + TLVs in the IS-IS, OSPFv2, and OSPFv3 protocols. + + BGP-LS [RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a + Link NLRI, or a Prefix NLRI, and it defines the TLVs that map link- + state information to BGP-LS NLRI within the BGP-LS Attribute. This + document adds additional BGP-LS Attribute TLVs in order to encode SR + information. It does not introduce any changes to the encoding of + the BGP-LS NLRIs. + +2.1. Node Attribute TLVs + + The following Node Attribute TLVs are defined: + + +======+=================+===============+ + | Type | Description | Section | + +======+=================+===============+ + | 1161 | SID/Label | Section 2.1.1 | + +------+-----------------+---------------+ + | 1034 | SR Capabilities | Section 2.1.2 | + +------+-----------------+---------------+ + | 1035 | SR Algorithm | Section 2.1.3 | + +------+-----------------+---------------+ + | 1036 | SR Local Block | Section 2.1.4 | + +------+-----------------+---------------+ + | 1037 | SRMS Preference | Section 2.1.5 | + +------+-----------------+---------------+ + + Table 1: Node Attribute TLVs + + These TLVs should only be added to the BGP-LS Attribute associated + with the Node NLRI that describes the IGP node that is originating + the corresponding IGP TLV/sub-TLV described below. + +2.1.1. SID/Label TLV + + The SID/Label TLV is used as a sub-TLV by the SR Capabilities + (Section 2.1.2) and Segment Routing Local Block (SRLB) + (Section 2.1.4) TLVs. This information is derived from the protocol- + specific advertisements. + + * IS-IS, as defined by the SID/Label Sub-TLV in Section 2.3 of + [RFC8667]. + + * OSPFv2/OSPFv3, as defined by the SID/Label Sub-TLV in Section 2.1 + of [RFC8665] and Section 3.1 of [RFC8666]. + + The TLV has the following format: + + 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 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SID/Label (variable) // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: SID/Label TLV Format + + Where: + + Type: 1161 + + Length: Variable. Either 3 or 4 octets depending on whether the + value is encoded as a label or as an index/SID. + + SID/Label: If the length is set to 3, then the 20 rightmost bits + represent a label (the total TLV size is 7), and the 4 leftmost + bits are set to 0. If the length is set to 4, then the value + represents a 32-bit SID (the total TLV size is 8). + +2.1.2. SR Capabilities TLV + + The SR Capabilities TLV is used in order to advertise the node's SR + capabilities including its Segment Routing Global Base (SRGB) + range(s). In the case of IS-IS, the capabilities also include the + IPv4 and IPv6 support for the SR-MPLS forwarding plane. This + information is derived from the protocol-specific advertisements. + + * IS-IS, as defined by the SR-Capabilities Sub-TLV in Section 3.1 of + [RFC8667]. + + * OSPFv2/OSPFv3, as defined by the SID/Label Range TLV in + Section 3.2 of [RFC8665]. OSPFv3 leverages the same TLV as + defined for OSPFv2. + + The SR Capabilities TLV has the following format: + + 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 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Range Size 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SID/Label Sub-TLV 1 // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + ... + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Range Size N | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SID/Label Sub-TLV N // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: SR Capabilities TLV Format + + Where: + + Type: 1034 + + Length: Variable. The minimum length is 12 octets. + + Flags: 1 octet of flags as defined in Section 3.1 of [RFC8667] for + IS-IS. The flags are not currently defined for OSPFv2 and OSPFv3 + and MUST be set to 0 and ignored on receipt. + + Reserved: 1 octet that MUST be set to 0 and ignored on receipt. + + One or more entries, each of which have the following format: + + Range Size: 3 octets with a non-zero value indicating the number + of labels in the range. + + SID/Label TLV: (as defined in Section 2.1.1) used as a sub-TLV, + which encodes the first label in the range. Since the SID/ + Label TLV is used to indicate the first label of the SRGB + range, only label encoding is valid under the SR Capabilities + TLV. + +2.1.3. SR-Algorithm TLV + + The SR-Algorithm TLV is used in order to advertise the SR algorithms + supported by the node. This information is derived from the + protocol-specific advertisements. + + * IS-IS, as defined by the SR-Algorithm Sub-TLV in Section 3.2 of + [RFC8667]. + + * OSPFv2/OSPFv3, as defined by the SR-Algorithm TLV in Section 3.1 + of [RFC8665]. OSPFv3 leverages the same TLV as defined for + OSPFv2. + + The SR-Algorithm TLV has the following format: + + 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 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Algorithm 1 | Algorithm... | Algorithm N | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: SR-Algorithm TLV Format + + Where: + + Type: 1035 + + Length: Variable. The minimum length is 1 octet and the maximum can + be 256. + + Algorithm: One or more fields of 1 octet each that identifies the + algorithm. + +2.1.4. SR Local Block TLV + + The SRLB TLV contains the range(s) of labels the node has reserved + for local SIDs. Local SIDs are used, e.g., in IGP (IS-IS, OSPF) for + Adjacency SIDs and may also be allocated by components other than IGP + protocols. As an example, an application or a controller may + instruct a node to allocate a specific local SID. Therefore, in + order for such applications or controllers to know the range of local + SIDs available, the node is required to advertise its SRLB. + + This information is derived from the protocol-specific + advertisements. + + * IS-IS, as defined by the SRLB Sub-TLV in Section 3.3 of [RFC8667]. + + * OSPFv2/OSPFv3, as defined by the SR Local Block TLV in Section 3.3 + of [RFC8665]. OSPFv3 leverages the same TLV as defined for + OSPFv2. + + The SRLB TLV has the following format: + + 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 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sub-Range Size 1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SID/Label Sub-TLV 1 // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + ... + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Sub-Range Size N | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SID/Label Sub-TLV N // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: SRLB TLV Format + + Where: + + Type: 1036 + + Length: Variable. The minimum length is 12 octets. + + Flags: 1 octet of flags. The flags are as defined in Section 3.3 of + [RFC8667] for IS-IS. The flags are not currently defined for + OSPFv2 and OSPFv3 and MUST be set to 0 and ignored on receipt. + + Reserved: 1 octet that MUST be set to 0 and ignored on receipt. + + One or more entries corresponding to a sub-range(s), each of which + have the following format: + + Range Size: 3-octet value indicating the number of labels in the + range. + + SID/Label TLV: (as defined in Section 2.1.1) used as a sub-TLV, + which encodes the first label in the sub-range. Since the SID/ + Label TLV is used to indicate the first label of the SRLB sub- + range, only label encoding is valid under the SR Local Block + TLV. + +2.1.5. SRMS Preference TLV + + The Segment Routing Mapping Server (SRMS) Preference TLV is used in + order to associate a preference with SRMS advertisements from a + particular source. [RFC8661] specifies the SRMS functionality along + with the SRMS preference of the node advertising the SRMS Prefix-to- + SID mapping ranges. + + This information is derived from the protocol-specific + advertisements. + + * IS-IS, as defined by the SRMS Preference Sub-TLV in Section 3.4 of + [RFC8667]. + + * OSPFv2/OSPFv3, as defined by the SRMS Preference TLV in + Section 3.4 of [RFC8665]. OSPFv3 leverages the same TLV as + defined for OSPFv2. + + The SRMS Preference TLV has the following format: + + 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 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Preference | + +-+-+-+-+-+-+-+-+ + + Figure 6: SRMS Preference TLV Format + + Where: + + Type: 1037 + + Length: 1 octet + + Preference: 1 octet carrying an unsigned 8-bit SRMS preference. + +2.2. Link Attribute TLVs + + The following Link Attribute TLVs are defined: + + +======+=================================+===============+ + | Type | Description | Section | + +======+=================================+===============+ + | 1099 | Adjacency SID TLV | Section 2.2.1 | + +------+---------------------------------+---------------+ + | 1100 | LAN Adjacency SID TLV | Section 2.2.2 | + +------+---------------------------------+---------------+ + | 1172 | L2 Bundle Member Attributes TLV | Section 2.2.3 | + +------+---------------------------------+---------------+ + + Table 2: Link Attribute TLVs + + These TLVs should only be added to the BGP-LS Attribute associated + with the Link NLRI that describes the link of the IGP node that is + originating the corresponding IGP TLV/sub-TLV described below. + +2.2.1. Adjacency SID TLV + + The Adjacency SID TLV is used in order to advertise information + related to an Adjacency SID. This information is derived from the + Adj-SID Sub-TLV of IS-IS (Section 2.2.1 of [RFC8667]), OSPFv2 + (Section 6.1 of [RFC8665]), and OSPFv3 (Section 7.1 of [RFC8666]). + + The Adjacency SID TLV has the following format: + + 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 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Weight | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SID/Label/Index (variable) // + +---------------------------------------------------------------+ + + Figure 7: Adjacency SID TLV Format + + Where: + + Type: 1099 + + Length: Variable. Either 7 or 8 octets depending on the label or + index encoding of the SID. + + Flags: 1-octet value that should be set as: + + * IS-IS Adj-SID flags as defined in Section 2.2.1 of [RFC8667]. + + * OSPFv2 Adj-SID flags as defined in Section 6.1 of [RFC8665]. + + * OSPFv3 Adj-SID flags as defined in Section 7.1 of [RFC8666]. + + Weight: 1 octet carrying the weight used for load-balancing + purposes. The use of weight is described in Section 3.4 of + [RFC8402]. + + Reserved: 2 octets that MUST be set to 0 and ignored on receipt. + + SID/Index/Label: + + IS-IS: Label or index value as defined in Section 2.2.1 of + [RFC8667]. + + OSPFv2: Label or index value as defined in Section 6.1 of + [RFC8665]. + + OSPFv3: Label or index value as defined in Section 7.1 of + [RFC8666]. + + The Flags and, as an extension, the SID/Index/Label fields of this + TLV are interpreted according to the respective underlying IS-IS, + OSPFv2, or OSPFv3 protocol. The Protocol-ID of the BGP-LS Link NLRI + is used to determine the underlying protocol specification for + parsing these fields. + +2.2.2. LAN Adjacency SID TLV + + For a LAN, normally a node only announces its adjacency to the IS-IS + pseudonode (or the equivalent OSPF Designated and Backup Designated + Routers). The LAN Adjacency SID TLV allows a node to announce + adjacencies to all other nodes attached to the LAN in a single + instance of the BGP-LS Link NLRI. Without this TLV, the + corresponding BGP-LS Link NLRI would need to be originated for each + additional adjacency in order to advertise the SR TLVs for these + neighbor adjacencies. + + This information is derived from the LAN-Adj-SID Sub-TLV of IS-IS + (Section 2.2.2 of [RFC8667]), the LAN Adj-SID Sub-TLV of OSPFv2 + (Section 6.2 of [RFC8665]), and the LAN Adj-SID Sub-TLV of OSPFv3 + (Section 7.2 of [RFC8666]). + + The LAN Adjacency SID TLV has the following format: + + 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 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Weight | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | OSPF Neighbor ID / IS-IS System ID | + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SID/Label/Index (variable) // + +---------------------------------------------------------------+ + + Figure 8: LAN Adjacency SID TLV Format + + Where: + + Type: 1100 + + Length: Variable. For IS-IS, it would be 13 or 14 octets depending + on the label or index encoding of the SID. For OSPF, it would be + 11 or 12 octets depending on the label or index encoding of the + SID. + + Flags: 1-octet value that should be set as: + + * IS-IS LAN Adj-SID flags as defined in Section 2.2.2 of + [RFC8667]. + + * OSPFv2 LAN Adj-SID flags as defined in Section 6.2 of + [RFC8665]. + + * OSPFv3 LAN Adj-SID flags as defined in Section 7.2 of + [RFC8666]. + + Weight: 1 octet carrying the weight used for load-balancing + purposes. The use of weight is described in Section 3.4 of + [RFC8402]. + + Reserved: 2 octets that MUST be set to 0 and ignored on receipt. + + Neighbor ID: 6 octets for IS-IS for the System ID, and 4 octets for + OSPF for the OSPF Router-ID of the neighbor. + + SID/Index/Label: + + IS-IS: Label or index value as defined in Section 2.2.2 of + [RFC8667]. + + OSPFv2: Label or index value as defined in Section 6.2 of + [RFC8665]. + + OSPFv3: Label or index value as defined in Section 7.2 of + [RFC8666]. + + The Neighbor ID, Flags, and, as an extension, the SID/Index/Label + fields of this TLV are interpreted according to the respective + underlying IS-IS, OSPFv2, or OSPFv3 protocol. The Protocol-ID of the + BGP-LS Link NLRI is used to determine the underlying protocol + specification for parsing these fields. + +2.2.3. L2 Bundle Member Attributes TLV + + The L2 Bundle Member Attributes TLV identifies an L2 Bundle Member + link, which in turn is associated with a parent L3 link. The L3 link + is described by the Link NLRI defined in [RFC7752], and the L2 Bundle + Member Attributes TLV is associated with the Link NLRI. The TLV MAY + include sub-TLVs that describe attributes associated with the bundle + member. The identified bundle member represents a unidirectional + path from the originating router to the neighbor specified in the + parent L3 link. Multiple L2 Bundle Member Attributes TLVs MAY be + associated with a Link NLRI. + + This information is derived from L2 Bundle Member Attributes TLV of + IS-IS (Section 2 of [RFC8668]). The equivalent functionality has not + been specified as yet for OSPF. + + The L2 Bundle Member Attributes TLV has the following format: + + 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 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | L2 Bundle Member Descriptor | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link Attribute Sub-TLVs(variable) // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 9: L2 Bundle Member Attributes TLV Format + + Where: + + Type: 1172 + + Length: Variable. + + L2 Bundle Member Descriptor: 4-octet field that carries a link-local + identifier as defined in [RFC4202]. + + Link attributes for L2 Bundle Member links are advertised as sub-TLVs + of the L2 Bundle Member Attributes TLV. The sub-TLVs are identical + to existing BGP-LS TLVs as identified in the table below. + + +================+==========================+====================+ + | TLV Code Point | Description | Reference Document | + +================+==========================+====================+ + | 1088 | Administrative group | [RFC7752] | + | | (color) | | + +----------------+--------------------------+--------------------+ + | 1089 | Maximum link bandwidth | [RFC7752] | + +----------------+--------------------------+--------------------+ + | 1090 | Max. reservable link | [RFC7752] | + | | bandwidth | | + +----------------+--------------------------+--------------------+ + | 1091 | Unreserved bandwidth | [RFC7752] | + +----------------+--------------------------+--------------------+ + | 1092 | TE default metric | [RFC7752] | + +----------------+--------------------------+--------------------+ + | 1093 | Link protection type | [RFC7752] | + +----------------+--------------------------+--------------------+ + | 1099 | Adjacency Segment | Section 2.2.1 | + | | Identifier (Adj-SID) TLV | | + +----------------+--------------------------+--------------------+ + | 1100 | LAN Adjacency Segment | Section 2.2.2 | + | | Identifier (Adj-SID) TLV | | + +----------------+--------------------------+--------------------+ + | 1114 | Unidirectional link | [RFC8571] | + | | delay | | + +----------------+--------------------------+--------------------+ + | 1115 | Min/Max Unidirectional | [RFC8571] | + | | link delay | | + +----------------+--------------------------+--------------------+ + | 1116 | Unidirectional Delay | [RFC8571] | + | | Variation | | + +----------------+--------------------------+--------------------+ + | 1117 | Unidirectional Link Loss | [RFC8571] | + +----------------+--------------------------+--------------------+ + | 1118 | Unidirectional residual | [RFC8571] | + | | bandwidth | | + +----------------+--------------------------+--------------------+ + | 1119 | Unidirectional available | [RFC8571] | + | | bandwidth | | + +----------------+--------------------------+--------------------+ + | 1120 | Unidirectional Utilized | [RFC8571] | + | | Bandwidth | | + +----------------+--------------------------+--------------------+ + + Table 3: BGP-LS Attribute TLVs are also used as sub-TLVs of + the L2 Bundle Member Attributes TLV + +2.3. Prefix Attribute TLVs + + The following Prefix Attribute TLVs are defined: + + +======+==========================+===============+ + | Type | Description | Section | + +======+==========================+===============+ + | 1158 | Prefix-SID | Section 2.3.1 | + +------+--------------------------+---------------+ + | 1159 | Range | Section 2.3.5 | + +------+--------------------------+---------------+ + | 1170 | Prefix Attribute Flags | Section 2.3.2 | + +------+--------------------------+---------------+ + | 1171 | Source Router Identifier | Section 2.3.3 | + +------+--------------------------+---------------+ + | 1174 | Source OSPF Router-ID | Section 2.3.4 | + +------+--------------------------+---------------+ + + Table 4: Prefix Attribute TLVs + + These TLVs should only be added to the BGP-LS Attribute associated + with the Prefix NLRI that describes the prefix of the IGP node that + is originating the corresponding IGP TLV/sub-TLV described below. + +2.3.1. Prefix-SID TLV + + The Prefix-SID TLV is used in order to advertise information related + to a Prefix-SID. This information is derived from the Prefix-SID + Sub-TLV of IS-IS (Section 2.1 of [RFC8667]), the Prefix-SID Sub-TLV + of OSPFv2 (Section 5 of [RFC8665]), and the Prefix-SID Sub-TLV of + OSPFv3 (Section 6 of [RFC8666]). + + The Prefix-SID TLV has the following format: + + 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 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Algorithm | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | SID/Index/Label (variable) // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 10: Prefix-SID TLV Format + + Where: + + Type: 1158 + + Length: Variable. 7 or 8 octets depending on the label or index + encoding of the SID. + + Flags: 1-octet value that should be set as: + + * IS-IS Prefix-SID flags as defined in Section 2.1.1 of + [RFC8667]. + + * OSPFv2 Prefix-SID flags as defined in Section 5 of [RFC8665]. + + * OSPFv3 Prefix-SID flags as defined in Section 6 of [RFC8665]. + + Algorithm: 1-octet value identifies the algorithm. The semantics of + the algorithm are described in Section 3.1.1 of [RFC8402]. + + Reserved: 2 octets that MUST be set to 0 and ignored on receipt. + + SID/Index/Label: + + IS-IS: Label or index value as defined in Section 2.1 of + [RFC8667]. + + OSPFv2: Label or index value as defined in Section 5 of + [RFC8665]. + + OSPFv3: Label or index value as defined in Section 6 of + [RFC8666]. + + The Flags and, as an extension, the SID/Index/Label fields of this + TLV are interpreted according to the respective underlying IS-IS, + OSPFv2, or OSPFv3 protocol. The Protocol-ID of the BGP-LS Prefix + NLRI is used to determine the underlying protocol specification for + parsing these fields. + +2.3.2. Prefix Attribute Flags TLV + + The Prefix Attribute Flags TLV carries IPv4/IPv6 prefix attribute + flags information. These flags are defined for OSPFv2 in Section 2.1 + of [RFC7684], OSPFv3 in Appendix A.4.1.1 of [RFC5340], and IS-IS in + Section 2.1 of [RFC7794]. + + The Prefix Attribute Flags TLV has the following format: + + 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 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags (variable) // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 11: Prefix Attribute Flags TLV Format + + Where: + + Type: 1170 + + Length: Variable. + + Flags: a variable-length Flag field (according to the Length field). + Flags are routing protocol specific and are to be set as below: + + * IS-IS flags correspond to the IPv4/IPv6 Extended Reachability + Attribute Flags defined in Section 2.1 of [RFC7794]. In the + case of the X-flag when associated with IPv6 prefix + reachability, the setting corresponds to the setting of the + X-flag in the fixed format of IS-IS TLVs 236 [RFC5308] and 237 + [RFC5120]. + + * OSPFv2 flags correspond to the Flags field of the OSPFv2 + Extended Prefix TLV defined in Section 2.1 of [RFC7684]. + + * OSPFv3 flags map to the Prefix Options field defined in + Appendix A.4.1.1 of [RFC5340] and extended in Section 3.1 of + [RFC8362]. + + The Flags field of this TLV is interpreted according to the + respective underlying IS-IS, OSPFv2, or OSPFv3 protocol. The + Protocol-ID of the BGP-LS Prefix NLRI is used to determine the + underlying protocol specification for parsing this field. + +2.3.3. Source Router Identifier TLV + + The Source Router Identifier TLV contains the IPv4 or IPv6 Router + Identifier of the originator of the prefix. For the IS-IS protocol, + this is derived from the IPv4/IPv6 Source Router ID Sub-TLV as + defined in Section 2.2 of [RFC7794]. For the OSPF protocol, this is + derived from the Prefix Source Router Address Sub-TLV as defined in + Section 2.2 of [RFC9084]. + + The Source Router Identifier TLV has the following format: + + 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 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 4- or 16-octet Router Identifier // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 12: Source Router Identifier TLV Format + + Where: + + Type: 1171 + + Length: Variable. 4 or 16 octets for the IPv4 or IPv6 prefix, + respectively. + + Router-ID: the IPv4 or IPv6 Router-ID in the case of IS-IS, and the + IPv4 or IPv6 Router Address in the case of OSPF. + +2.3.4. Source OSPF Router-ID TLV + + The Source OSPF Router-ID TLV is applicable only for the OSPF + protocol and contains the OSPF Router-ID of the originator of the + prefix. It is derived from the Prefix Source OSPF Router-ID Sub-TLV + as defined in Section 2.1 of [RFC9084]. + + The Source OSPF Router-ID TLV has the following format: + + 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 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 4-octet OSPF Router-ID // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 13: Source OSPF Router-ID TLV Format + + Where: + + Type: 1174 + + Length: 4 octets + + OSPF Router-ID: the OSPF Router-ID of the node originating the + prefix. + +2.3.5. Range TLV + + The Range TLV is used in order to advertise a range of prefix-to-SID + mappings as part of the SRMS functionality [RFC8661], as defined in + the respective underlying IGP SR extensions: Section 4 of [RFC8665], + Section 5 of [RFC8666], and Section 2.4 of [RFC8667]. The + information advertised in the Range TLV is derived from the SID/Label + Binding TLV in the case of IS-IS and the OSPFv2/OSPFv3 Extended + Prefix Range TLV in the case of OSPFv2/OSPFv3. + + A Prefix NLRI, that has been advertised with a Range TLV, is + considered a normal routing prefix (i.e., prefix reachability) only + when there is also an IGP metric TLV (TLV 1095) associated it. + Otherwise, it is considered only as the first prefix in the range for + prefix-to-SID mapping advertisement. + + The format of the Range TLV is as follows: + + 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 | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Flags | Reserved | Range Size | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | sub-TLVs // + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 14: Range TLV Format + + Where: + + Type: 1159 + + Length: Variable. 11 or 12 octets depending on the label or index + encoding of the SID. + + Flags: 1-octet value that should be set as: + + * IS-IS SID/Label Binding TLV flags as defined in Section 2.4.1 + of [RFC8667]. + + * OSPFv2 OSPF Extended Prefix Range TLV flags as defined in + Section 4 of [RFC8665]. + + * OSPFv3 Extended Prefix Range TLV flags as defined in Section 5 + of [RFC8666]. + + Reserved: 1 octet that MUST be set to 0 and ignored on receipt. + + Range Size: 2 octets that carry the number of prefixes that are + covered by the advertisement. + + The Flags field of this TLV is interpreted according to the + respective underlying IS-IS, OSPFv2, or OSPFv3 protocol. The + Protocol-ID of the BGP-LS Prefix NLRI is used to determine the + underlying protocol specification for parsing this field. + + The prefix-to-SID mappings are advertised using sub-TLVs as below: + + IS-IS: + SID/Label Range TLV + Prefix-SID Sub-TLV + + OSPFv2/OSPFv3: + OSPFv2/OSPFv3 Extended Prefix Range TLV + Prefix-SID Sub-TLV + + BGP-LS: + Range TLV + Prefix-SID TLV (used as a sub-TLV in this context) + + The prefix-to-SID mapping information for the BGP-LS Prefix-SID TLV + (used as a sub-TLV in this context) is encoded as described in + Section 2.3.1. + +2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs + + This section illustrates the IS-IS Segment Routing Extensions TLVs + and sub-TLVs mapped to the ones defined in this document. + + For each BGP-LS TLV, the following table illustrates its equivalence + in IS-IS. + + +========================+==============================+===========+ + | Description | IS-IS TLV/sub-TLV | Reference | + +========================+==============================+===========+ + | SR Capabilities | SR-Capabilities Sub-TLV (2) | [RFC8667] | + +------------------------+------------------------------+-----------+ + | SR Algorithm | SR-Algorithm Sub-TLV (19) | [RFC8667] | + +------------------------+------------------------------+-----------+ + | SR Local Block | SR Local Block Sub-TLV (22) | [RFC8667] | + +------------------------+------------------------------+-----------+ + | SRMS Preference | SRMS Preference Sub-TLV (19) | [RFC8667] | + +------------------------+------------------------------+-----------+ + | Adjacency SID | Adj-SID Sub-TLV (31) | [RFC8667] | + +------------------------+------------------------------+-----------+ + | LAN Adjacency SID | LAN-Adj-SID Sub-TLV (32) | [RFC8667] | + +------------------------+------------------------------+-----------+ + | Prefix-SID | Prefix-SID Sub-TLV (3) | [RFC8667] | + +------------------------+------------------------------+-----------+ + | Range | SID/Label Binding TLV (149) | [RFC8667] | + +------------------------+------------------------------+-----------+ + | SID/Label | SID/Label Sub-TLV (1) | [RFC8667] | + +------------------------+------------------------------+-----------+ + | Prefix Attribute | Prefix Attribute Flags Sub- | [RFC7794] | + | Flags | TLV (4) | | + +------------------------+------------------------------+-----------+ + | Source Router | IPv4/IPv6 Source Router ID | [RFC7794] | + | Identifier | Sub-TLV (11/12) | | + +------------------------+------------------------------+-----------+ + | L2 Bundle Member | L2 Bundle Member Attributes | [RFC8668] | + | Attributes | TLV (25) | | + +------------------------+------------------------------+-----------+ + + Table 5: IS-IS Segment Routing Extensions TLVs/Sub-TLVs + +2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs + + This section illustrates the OSPFv2 and OSPFv3 Segment Routing + Extensions TLVs and sub-TLVs mapped to the ones defined in this + document. + + For each BGP-LS TLV, the following tables illustrate its equivalence + in OSPFv2 and OSPFv3. + + +===================+==========================+===========+ + | Description | OSPFv2 TLV/sub-TLV | Reference | + +===================+==========================+===========+ + | SR Capabilities | SID/Label Range TLV (9) | [RFC8665] | + +-------------------+--------------------------+-----------+ + | SR Algorithm | SR-Algorithm TLV (8) | [RFC8665] | + +-------------------+--------------------------+-----------+ + | SR Local Block | SR Local Block TLV (14) | [RFC8665] | + +-------------------+--------------------------+-----------+ + | SRMS Preference | SRMS Preference TLV (15) | [RFC8665] | + +-------------------+--------------------------+-----------+ + | Adjacency SID | Adj-SID Sub-TLV (2) | [RFC8665] | + +-------------------+--------------------------+-----------+ + | LAN Adjacency SID | LAN Adj-SID Sub-TLV (3) | [RFC8665] | + +-------------------+--------------------------+-----------+ + | Prefix-SID | Prefix-SID Sub-TLV (2) | [RFC8665] | + +-------------------+--------------------------+-----------+ + | Range | OSPF Extended Prefix | [RFC8665] | + | | Range TLV (2) | | + +-------------------+--------------------------+-----------+ + | SID/Label | SID/Label Sub-TLV (1) | [RFC8665] | + +-------------------+--------------------------+-----------+ + | Prefix Attribute | Flags of OSPFv2 Extended | [RFC7684] | + | Flags | Prefix TLV (1) | | + +-------------------+--------------------------+-----------+ + | Source Router | Prefix Source Router | [RFC9084] | + | Identifier | Address Sub-TLV (5) | | + +-------------------+--------------------------+-----------+ + | Source OSPF | Prefix Source OSPF | [RFC9084] | + | Router-ID | Router-ID Sub-TLV (4) | | + +-------------------+--------------------------+-----------+ + + Table 6: OSPFv2 Segment Routing Extensions TLVs/Sub-TLVs + + +===================+==========================+===========+ + | Description | OSPFv3 TLV/sub-TLV | Reference | + +===================+==========================+===========+ + | SR Capabilities | SID/Label Range TLV (9) | [RFC8665] | + +-------------------+--------------------------+-----------+ + | SR Algorithm | SR-Algorithm TLV (8) | [RFC8665] | + +-------------------+--------------------------+-----------+ + | SR Local Block | SR Local Block TLV (14) | [RFC8665] | + +-------------------+--------------------------+-----------+ + | SRMS Preference | SRMS Preference TLV (15) | [RFC8665] | + +-------------------+--------------------------+-----------+ + | Adjacency SID | Adj-SID Sub-TLV (5) | [RFC8666] | + +-------------------+--------------------------+-----------+ + | LAN Adjacency SID | LAN Adj-SID Sub-TLV (6) | [RFC8666] | + +-------------------+--------------------------+-----------+ + | Prefix-SID | Prefix-SID Sub-TLV (4) | [RFC8666] | + +-------------------+--------------------------+-----------+ + | Range | OSPFv3 Extended Prefix | [RFC8666] | + | | Range TLV (9) | | + +-------------------+--------------------------+-----------+ + | SID/Label | SID/Label Sub-TLV (7) | [RFC8666] | + +-------------------+--------------------------+-----------+ + | Prefix Attribute | Prefix Option Fields of | [RFC8362] | + | Flags | Prefix TLV types 3,5,6 | | + +-------------------+--------------------------+-----------+ + | Source OSPF | Prefix Source Router | [RFC9084] | + | Router Identifier | Address Sub-TLV (28) | | + +-------------------+--------------------------+-----------+ + | Source OSPF | Prefix Source OSPF | [RFC9084] | + | Router-ID | Router-ID Sub-TLV (27) | | + +-------------------+--------------------------+-----------+ + + Table 7: OSPFv3 Segment Routing Extensions TLVs/Sub-TLVs + +3. IANA Considerations + + IANA has registered the following code points in the "BGP-LS Node + Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" + registry under the "Border Gateway Protocol - Link State (BGP-LS) + Parameter" registry based on Table 8. The column "IS-IS TLV/Sub-TLV" + defined in the registry does not require any value and should be left + empty. + +3.1. TLV/Sub-TLV Code Points Summary + + This section contains the global table of all TLVs/sub-TLVs defined + in this document. + + +================+=============================+===============+ + | TLV Code Point | Description | Reference | + +================+=============================+===============+ + | 1034 | SR Capabilities | Section 2.1.2 | + +----------------+-----------------------------+---------------+ + | 1035 | SR Algorithm | Section 2.1.3 | + +----------------+-----------------------------+---------------+ + | 1036 | SR Local Block | Section 2.1.4 | + +----------------+-----------------------------+---------------+ + | 1037 | SRMS Preference | Section 2.1.5 | + +----------------+-----------------------------+---------------+ + | 1099 | Adjacency SID | Section 2.2.1 | + +----------------+-----------------------------+---------------+ + | 1100 | LAN Adjacency SID | Section 2.2.2 | + +----------------+-----------------------------+---------------+ + | 1158 | Prefix-SID | Section 2.3.1 | + +----------------+-----------------------------+---------------+ + | 1159 | Range | Section 2.3.5 | + +----------------+-----------------------------+---------------+ + | 1161 | SID/Label | Section 2.1.1 | + +----------------+-----------------------------+---------------+ + | 1170 | Prefix Attribute Flags | Section 2.3.2 | + +----------------+-----------------------------+---------------+ + | 1171 | Source Router Identifier | Section 2.3.3 | + +----------------+-----------------------------+---------------+ + | 1172 | L2 Bundle Member Attributes | Section 2.2.3 | + +----------------+-----------------------------+---------------+ + | 1174 | Source OSPF Router-ID | Section 2.3.4 | + +----------------+-----------------------------+---------------+ + + Table 8: Summary of TLV/Sub-TLV Code Points + +4. Manageability Considerations + + This section is structured as recommended in [RFC5706]. + + The new protocol extensions introduced in this document augment the + existing IGP topology information that is distributed via [RFC7752]. + Procedures and protocol extensions defined in this document do not + affect the BGP protocol operations and management other than as + discussed in the Manageability Considerations section of [RFC7752]. + Specifically, the malformed attribute tests for syntactic checks in + the Fault Management section of [RFC7752] now encompass the new BGP- + LS Attribute TLVs defined in this document. The semantic or content + checking for the TLVs specified in this document and their + association with the BGP-LS NLRI types or their BGP-LS Attribute is + left to the consumer of the BGP-LS information (e.g., an application + or a controller) and not the BGP protocol. + + A consumer of the BGP-LS information retrieves this information over + a BGP-LS session (refer to Sections 1 and 2 of [RFC7752]). The + handling of semantic or content errors by the consumer would be + dictated by the nature of its application usage and hence is beyond + the scope of this document. + + This document only introduces new Attribute TLVs, and any syntactic + error in them would result in the BGP-LS Attribute being discarded + with an error log. The SR information introduced in BGP-LS by this + specification may be used by BGP-LS consumer applications like an SR + Path Computation Engine (PCE) to learn the SR capabilities of the + nodes in the topology and the mapping of SR segments to those nodes. + This can enable the SR PCE to perform path computations based on SR + for traffic engineering use cases and to steer traffic on paths + different from the underlying IGP-based distributed best-path + computation. Errors in the encoding or decoding of the SR + information may result in the unavailability of such information to + the SR PCE or incorrect information being made available to it. This + may result in the SR PCE not being able to perform the desired SR- + based optimization functionality or to perform it in an unexpected or + inconsistent manner. The handling of such errors by applications + like SR PCE may be implementation specific and out of scope of this + document. + + The extensions, specified in this document, do not introduce any new + configuration or monitoring aspects in BGP or BGP-LS other than as + discussed in [RFC7752]. The manageability aspects of the underlying + SR features are covered by [RFC9020], [ISIS-SR-YANG], and + [OSPF-SR-YANG]. + +5. Security Considerations + + The new protocol extensions introduced in this document augment the + existing IGP topology information that is distributed via [RFC7752]. + The advertisement of the SR link attribute information defined in + this document presents similar risk as associated with the existing + set of link attribute information as described in [RFC7752]. The + Security Considerations section of [RFC7752] also applies to these + extensions. The procedures and new TLVs defined in this document, by + themselves, do not affect the BGP-LS security model discussed in + [RFC7752]. + + The TLVs introduced in this document are used to propagate IGP- + defined information (see [RFC8665], [RFC8666], and [RFC8667]). These + TLVs represent the SR information associated with the IGP node, link, + and prefix. The IGP instances originating these TLVs are assumed to + support all the required security and authentication mechanisms (as + described in [RFC8665], [RFC8666], and [RFC8667]) in order to prevent + any security issue when propagating the TLVs into BGP-LS. + + BGP-LS SR extensions enable traffic engineering use cases within the + SR domain. SR operates within a trusted domain [RFC8402], and its + security considerations also apply to BGP-LS sessions when carrying + SR information. The SR traffic engineering policies using the SIDs + advertised via BGP-LS are expected to be used entirely within this + trusted SR domain (e.g., between multiple ASes/domains within a + single provider network). Therefore, precaution is necessary to + ensure that the link-state information (including SR information) + advertised via BGP-LS sessions is limited to consumers in a secure + manner within this trusted SR domain. BGP peering sessions for + address families other than link state may be set up to routers + outside the SR domain. The isolation of BGP-LS peering sessions is + recommended to ensure that BGP-LS topology information (including the + newly added SR information) is not advertised to an external BGP + peering session outside the SR domain. + +6. References + +6.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions + in Support of Generalized Multi-Protocol Label Switching + (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, + . + + [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi + Topology (MT) Routing in Intermediate System to + Intermediate Systems (IS-ISs)", RFC 5120, + DOI 10.17487/RFC5120, February 2008, + . + + [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, + DOI 10.17487/RFC5308, October 2008, + . + + [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF + for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, + . + + [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., + Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute + Advertisement", RFC 7684, DOI 10.17487/RFC7684, November + 2015, . + + [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and + S. Ray, "North-Bound Distribution of Link-State and + Traffic Engineering (TE) Information Using BGP", RFC 7752, + DOI 10.17487/RFC7752, March 2016, + . + + [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and + U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 + and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, + March 2016, . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and + F. Baker, "OSPFv3 Link State Advertisement (LSA) + Extensibility", RFC 8362, DOI 10.17487/RFC8362, April + 2018, . + + [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., + Decraene, B., Litkowski, S., and R. Shakir, "Segment + Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, + July 2018, . + + [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and + C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of + IGP Traffic Engineering Performance Metric Extensions", + RFC 8571, DOI 10.17487/RFC8571, March 2019, + . + + [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, + H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF + Extensions for Segment Routing", RFC 8665, + DOI 10.17487/RFC8665, December 2019, + . + + [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions + for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, + December 2019, . + + [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., + Bashandy, A., Gredler, H., and B. Decraene, "IS-IS + Extensions for Segment Routing", RFC 8667, + DOI 10.17487/RFC8667, December 2019, + . + + [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, + M., and E. Aries, "Advertising Layer 2 Bundle Member Link + Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, + December 2019, . + + [RFC9084] Wang, A., Lindem, A., Dong, J., Psenak, P., and K. + Talaulikar, Ed., "OSPF Prefix Originator Extensions", + RFC 9084, DOI 10.17487/RFC9084, August 2021, + . + +6.2. Informative References + + [ISIS-SR-YANG] + Litkowski, S., Qu, Y., Sarkar, P., Chen, I., and J. + Tantsura, "YANG Data Model for IS-IS Segment Routing", + Work in Progress, Internet-Draft, draft-ietf-isis-sr-yang- + 10, 21 February 2021, + . + + [OSPF-SR-YANG] + Yeung, D., Qu, Y., Zhang, J., Chen, I., and A. Lindem, + "YANG Data Model for OSPF SR (Segment Routing) Protocol", + Work in Progress, Internet-Draft, draft-ietf-ospf-sr-yang- + 15, 2 July 2021, . + + [RFC5706] Harrington, D., "Guidelines for Considering Operations and + Management of New Protocols and Protocol Extensions", + RFC 5706, DOI 10.17487/RFC5706, November 2009, + . + + [RFC8661] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., + Decraene, B., and S. Litkowski, "Segment Routing MPLS + Interworking with LDP", RFC 8661, DOI 10.17487/RFC8661, + December 2019, . + + [RFC9020] Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. + Tantsura, "YANG Data Model for Segment Routing", RFC 9020, + DOI 10.17487/RFC9020, May 2021, + . + +Acknowledgements + + The authors would like to thank Jeffrey Haas, Aijun Wang, Robert + Raszuk, and Susan Hares for their review of this document and their + comments. The authors would also like to thank Alvaro Retana for his + extensive review and comments, which helped correct issues and + improve the document. + +Contributors + + The following people have substantially contributed to the editing of + this document: + + Peter Psenak + Cisco Systems + + Email: ppsenak@cisco.com + + + Les Ginsberg + Cisco Systems + + Email: ginsberg@cisco.com + + + Acee Lindem + Cisco Systems + + Email: acee@cisco.com + + + Saikat Ray + Individual + + Email: raysaikat@gmail.com + + + Jeff Tantsura + Apstra Inc. + + Email: jefftant.ietf@gmail.com + + +Authors' Addresses + + Stefano Previdi + Huawei Technologies + Rome + Italy + + Email: stefano@previdi.net + + + Ketan Talaulikar (editor) + Cisco Systems, Inc. + India + + Email: ketant@cisco.com + + + Clarence Filsfils + Cisco Systems, Inc. + Brussels + Belgium + + Email: cfilsfil@cisco.com + + + Hannes Gredler + RtBrick Inc. + + Email: hannes@rtbrick.com + + + Mach(Guoyi) Chen + Huawei Technologies + Huawei Building, No. 156 Beiqing Rd. + Beijing + 100095 + China + + Email: mach.chen@huawei.com -- cgit v1.2.3