idnits 2.17.1 draft-ietf-idr-bgp-ls-segment-routing-ext-18.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 15, 2021) is 1104 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-lsr-ospf-prefix-originator-07 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-21) exists of draft-ietf-isis-sr-yang-09 == Outdated reference: A later version (-30) exists of draft-ietf-ospf-sr-yang-13 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing S. Previdi 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track K. Talaulikar, Ed. 5 Expires: October 17, 2021 C. Filsfils 6 Cisco Systems, Inc. 7 H. Gredler 8 RtBrick Inc. 9 M. Chen 10 Huawei Technologies 11 April 15, 2021 13 BGP Link-State extensions for Segment Routing 14 draft-ietf-idr-bgp-ls-segment-routing-ext-18 16 Abstract 18 Segment Routing (SR) allows for a flexible definition of end-to-end 19 paths by encoding paths as sequences of topological sub-paths, called 20 "segments". These segments are advertised by routing protocols e.g. 21 by the link state routing protocols (IS-IS, OSPFv2 and OSPFv3) within 22 IGP topologies. 24 This document defines extensions to the BGP Link-state address-family 25 in order to carry segment routing information via BGP. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 31 "OPTIONAL" in this document are to be interpreted as described in BCP 32 14 [RFC2119] [RFC8174] when, and only when, they appear in all 33 capitals, as shown here. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on October 17, 2021. 51 Copyright Notice 53 Copyright (c) 2021 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. BGP-LS Extensions for Segment Routing . . . . . . . . . . . . 5 70 2.1. Node Attributes TLVs . . . . . . . . . . . . . . . . . . 5 71 2.1.1. SID/Label TLV . . . . . . . . . . . . . . . . . . . . 5 72 2.1.2. SR Capabilities TLV . . . . . . . . . . . . . . . . . 6 73 2.1.3. SR Algorithm TLV . . . . . . . . . . . . . . . . . . 8 74 2.1.4. SR Local Block TLV . . . . . . . . . . . . . . . . . 8 75 2.1.5. SRMS Preference TLV . . . . . . . . . . . . . . . . . 10 76 2.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . . . 11 77 2.2.1. Adjacency SID TLV . . . . . . . . . . . . . . . . . . 11 78 2.2.2. LAN Adjacency SID TLV . . . . . . . . . . . . . . . . 12 79 2.2.3. L2 Bundle Member Attribute TLV . . . . . . . . . . . 14 80 2.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . . . 15 81 2.3.1. Prefix SID TLV . . . . . . . . . . . . . . . . . . . 16 82 2.3.2. Prefix Attribute Flags TLV . . . . . . . . . . . . . 17 83 2.3.3. Source Router Identifier TLV . . . . . . . . . . . . 18 84 2.3.4. Source OSPF Router-ID TLV . . . . . . . . . . . . . . 19 85 2.3.5. Range TLV . . . . . . . . . . . . . . . . . . . . . . 20 86 2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs . . . . . 21 87 2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs . 22 88 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 89 3.1. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . 25 90 4. Manageability Considerations . . . . . . . . . . . . . . . . 25 91 5. Security Considerations . . . . . . . . . . . . . . . . . . . 26 92 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 95 8.1. Normative References . . . . . . . . . . . . . . . . . . 28 96 8.2. Informative References . . . . . . . . . . . . . . . . . 30 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 100 1. Introduction 102 Segment Routing (SR) allows for a flexible definition of end-to-end 103 paths by combining sub-paths called "segments". A segment can 104 represent any instruction: topological or service-based. A segment 105 can have a local semantic to an SR node or global semantic within a 106 domain. Within IGP topologies, an SR path is encoded as a sequence 107 of topological sub-paths, called "IGP segments". These segments are 108 advertised by the link-state routing protocols (IS-IS, OSPFv2 and 109 OSPFv3). 111 [RFC8402] defines the Link-State IGP segments - Prefix, Node, Anycast 112 and Adjacency segments. Prefix segments, by default, represent an 113 ECMP-aware shortest-path to a prefix, as per the state of the IGP 114 topology. Adjacency segments represent a hop over a specific 115 adjacency between two nodes in the IGP. A prefix segment is 116 typically a multi-hop path while an adjacency segment, in most of the 117 cases, is a one-hop path. Node and anycast segments are variations 118 of the prefix segment with their specific characteristics. 120 When Segment Routing is enabled in an IGP domain, segments are 121 advertised in the form of Segment Identifiers (SIDs). The IGP link- 122 state routing protocols have been extended to advertise SIDs and 123 other SR-related information. IGP extensions are described for: IS- 124 IS [RFC8667], OSPFv2 [RFC8665] and OSPFv3 [RFC8666]. Using these 125 extensions, Segment Routing can be enabled within an IGP domain. 127 Segment Routing (SR) allows advertisement of single or multi-hop 128 paths. The flooding scope for the IGP extensions for Segment routing 129 is IGP area-wide. Consequently, the contents of a Link State 130 Database (LSDB) or a Traffic Engineering Database (TED) has the scope 131 of an IGP area and therefore, by using the IGP alone it is not enough 132 to construct segments across multiple IGP Area or AS boundaries. 134 In order to address the need for applications that require 135 topological visibility across IGP areas, or even across Autonomous 136 Systems (AS), the BGP-LS address-family/sub-address-family have been 137 defined to allow BGP to carry Link-State information. The BGP 138 Network Layer Reachability Information (NLRI) encoding format for 139 BGP-LS and a new BGP Path Attribute called the BGP-LS attribute are 140 defined in [RFC7752]. The identifying key of each Link-State object, 141 namely a node, link, or prefix, is encoded in the NLRI and the 142 properties of the object are encoded in the BGP-LS attribute. 144 +------------+ 145 | Consumer | 146 +------------+ 147 ^ 148 | 149 v 150 +-------------------+ 151 | BGP Speaker | +-----------+ 152 | (Route-Reflector) | | Consumer | 153 +-------------------+ +-----------+ 154 ^ ^ ^ ^ 155 | | | | 156 +---------------+ | +-------------------+ | 157 | | | | 158 v v v v 159 +-----------+ +-----------+ +-----------+ 160 | BGP | | BGP | | BGP | 161 | Speaker | | Speaker | . . . | Speaker | 162 +-----------+ +-----------+ +-----------+ 163 ^ ^ ^ 164 | | | 165 IGP IGP IGP 167 Figure 1: Link State info collection 169 Figure 1 denotes a typical deployment scenario. In each IGP area, 170 one or more nodes are configured with BGP-LS. These BGP speakers 171 form an IBGP mesh by connecting to one or more route-reflectors. 172 This way, all BGP speakers (specifically the route-reflectors) obtain 173 Link-State information from all IGP areas (and from other ASes from 174 EBGP peers). An external component connects to the route-reflector 175 to obtain this information (perhaps moderated by a policy regarding 176 what information is or isn't advertised to the external component) as 177 described in [RFC7752]. 179 This document describes extensions to BGP-LS to advertise the SR 180 information. An external component (e.g., a controller) can collect 181 SR information from across an SR domain (as described in [RFC8402]) 182 and construct the end-to-end path (with its associated SIDs) that 183 need to be applied to an incoming packet to achieve the desired end- 184 to-end forwarding. SR operates within a trusted domain consisting of 185 a single or multiple ASes managed by the same administrative entity 186 e.g. within a single provider network. 188 2. BGP-LS Extensions for Segment Routing 190 This document defines SR extensions to BGP-LS and specifies the TLVs 191 and sub-TLVs for advertising SR information within the BGP-LS 192 Attribute. Section 2.4 and Section 2.5 lists the equivalent TLVs and 193 sub-TLVs in IS-IS, OSPFv2 and OSPFv3 protocols. 195 BGP-LS [RFC7752] defines the BGP-LS NLRI that can be a Node NLRI, a 196 Link NLRI or a Prefix NLRI. BGP-LS [RFC7752] defines the TLVs that 197 map link-state information to BGP-LS NLRI within the BGP-LS 198 Attribute. This document adds additional BGP-LS Attribute TLVs in 199 order to encode SR information. It does not introduce any changes to 200 the encoding of the BGP-LS NLRIs. 202 2.1. Node Attributes TLVs 204 The following Node Attribute TLVs are defined: 206 +------+-----------------+---------------+ 207 | Type | Description | Section | 208 +------+-----------------+---------------+ 209 | 1161 | SID/Label | Section 2.1.1 | 210 | 1034 | SR Capabilities | Section 2.1.2 | 211 | 1035 | SR Algorithm | Section 2.1.3 | 212 | 1036 | SR Local Block | Section 2.1.4 | 213 | 1037 | SRMS Preference | Section 2.1.5 | 214 +------+-----------------+---------------+ 216 Table 1: Node Attribute TLVs 218 These TLVs should only be added to the BGP-LS Attribute associated 219 with the Node NLRI describing the IGP node that is originating the 220 corresponding IGP TLV/sub-TLV described below. 222 2.1.1. SID/Label TLV 224 The SID/Label TLV is used as a sub-TLV by the SR Capabilities 225 (Section 2.1.2) and Segment Routing Local Block (SRLB) 226 (Section 2.1.4) TLVs. This information is derived from the protocol 227 specific advertisements. 229 o IS-IS, as defined by the SID/Label sub-TLV in section 2.3 of 230 [RFC8667]. 232 o OSPFv2/OSPFv3, as defined by the SID/Label sub-TLV in section 2.1 233 of [RFC8665] and section 3.1 of [RFC8666]. 235 The TLV has the following format: 237 0 1 2 3 238 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 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Type | Length | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | SID/Label (variable) // 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Figure 2: SID/Label TLV Format 247 Where: 249 Type: 1161 251 Length: Variable. Either 3 or 4 depending whether the value is 252 encoded as a label or as an index/SID. 254 SID/Label: If length is set to 3, then the 20 rightmost bits 255 represent a label (the total TLV size is 7) and the 4 leftmost 256 bits are set to 0. If length is set to 4, then the value 257 represents a 32 bit SID (the total TLV size is 8). 259 2.1.2. SR Capabilities TLV 261 The SR Capabilities TLV is used in order to advertise the node's SR 262 Capabilities including its Segment Routing Global Base (SRGB) 263 range(s). In the case of IS-IS, the capabilities also include the 264 IPv4 and IPv6 support for the SR-MPLS forwarding plane. This 265 information is derived from the protocol specific advertisements. 267 o IS-IS, as defined by the SR Capabilities sub-TLV in section 3.1 of 268 [RFC8667]. 270 o OSPFv2/OSPFv3, as defined by the SID/Label Range TLV in section 271 3.2 of [RFC8665]. OSPFv3 leverages the same TLV as defined for 272 OSPFv2. 274 The SR Capabilities TLV has the following format: 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Type | Length | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Flags | Reserved | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Range Size 1 | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | SID/Label sub-TLV 1 // 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 ... 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Range Size N | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | SID/Label sub-TLV N // 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Figure 3: SR Capabilities TLV Format 300 Where: 302 Type: 1034 304 Length: Variable. Minimum length is 12. 306 Flags: 1 octet of flags as defined in section 3.1 of [RFC8667] for 307 IS-IS. The flags are not currently defined for OSPFv2 and OSPFv3 308 and MUST be set to 0 and ignored on receipt. 310 Reserved: 1 octet that MUST be set to 0 and ignored on receipt. 312 One or more entries, each of which have the following format: 314 Range Size: 3 octet with a non-zero value indicating the number 315 of labels in the range. 317 SID/Label TLV (as defined in Section 2.1.1) used as sub-TLV 318 which encodes the first label in the range. Since the SID/ 319 Label TLV is used to indicate the first label of the SRGB 320 range, only label encoding is valid under the SR Capabilities 321 TLV. 323 2.1.3. SR Algorithm TLV 325 The SR Algorithm TLV is used in order to advertise the SR Algorithms 326 supported by the node. This information is derived from the protocol 327 specific advertisements. 329 o IS-IS, as defined by the SR-Algorithm sub-TLV in section 3.2 of 330 [RFC8667]. 332 o OSPFv2/OSPFv3, as defined by the SR-Algorithm TLV in section 3.1 333 of [RFC8665]. OSPFv3 leverages the same TLV as defined for 334 OSPFv2. 336 The SR Algorithm TLV has the following format: 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Type | Length | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Algorithm 1 | Algorithm... | Algorithm N | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Figure 4: SR Algorithm TLV Format 348 Where: 350 Type: 1035 352 Length: Variable. Minimum length is 1 and maximum can be 256. 354 Algorithm: One or more fields of 1 octet each identifying the 355 algorithm. 357 2.1.4. SR Local Block TLV 359 The SR Local Block (SRLB) TLV contains the range(s) of labels the 360 node has reserved for local SIDs. Local SIDs are used, e.g., in IGP 361 (IS-IS, OSPF) for Adjacency-SIDs, and may also be allocated by 362 components other than IGP protocols. As an example, an application 363 or a controller may instruct a node to allocate a specific local SID. 364 Therefore, in order for such applications or controllers to know the 365 range of local SIDs available, it is required that the node 366 advertises its SRLB. 368 This information is derived from the protocol specific 369 advertisements. 371 o IS-IS, as defined by the SR Local Block sub-TLV in section 3.3 of 372 [RFC8667]. 374 o OSPFv2/OSPFv3, as defined by the SR Local Block TLV in section 375 3.3. of [RFC8665]. OSPFv3 leverages the same TLV as defined for 376 OSPFv2. 378 The SRLB TLV has the following format: 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Type | Length | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Flags | Reserved | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Sub-Range Size 1 | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | SID/Label sub-TLV 1 // 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 ... 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Sub-Range Size N | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | SID/Label sub-TLV N // 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 Figure 5: SRLB TLV Format 404 Where: 406 Type: 1036 408 Length: Variable. Minimum length is 12. 410 Flags: 1 octet of flags. The flags are as defined in section 3.3 411 of [RFC8667] for IS-IS. The flags are not currently defined for 412 OSPFv2 and OSPFv3 and MUST be set to 0 and ignored on receipt. 414 Reserved: 1 octet that MUST be set to 0 and ignored on receipt. 416 One or more entries corresponding to sub-range(s), each of which 417 have the following format: 419 Range Size: 3 octet value indicating the number of labels in 420 the range. 422 SID/Label TLV (as defined in Section 2.1.1) used as sub-TLV 423 which encodes the first label in the sub-range. Since the SID/ 424 Label TLV is used to indicate the first label of the SRLB sub- 425 range, only label encoding is valid under the SR Local Block 426 TLV. 428 2.1.5. SRMS Preference TLV 430 The Segment Routing Mapping Server (SRMS) Preference TLV is used in 431 order to associate a preference with SRMS advertisements from a 432 particular source. [RFC8661] specifies the SRMS functionality along 433 with SRMS preference of the node advertising the SRMS Prefix-to-SID 434 Mapping ranges. 436 This information is derived from the protocol specific 437 advertisements. 439 o IS-IS, as defined by the SRMS Preference sub-TLV in section 3.4 of 440 [RFC8667]. 442 o OSPFv2/OSPFv3, as defined by the SRMS Preference TLV in section 443 3.4 of [RFC8665]. OSPFv3 leverages the same TLV as defined for 444 OSPFv2. 446 The SRMS Preference TLV has the following format: 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Type | Length | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Preference | 454 +-+-+-+-+-+-+-+-+ 456 Figure 6: SRMS Preference TLV Format 458 Where: 460 Type: 1037 462 Length: 1. 464 Preference: 1 octet carrying an unsigned 8 bit SRMS preference. 466 2.2. Link Attribute TLVs 468 The following Link Attribute TLVs are are defined: 470 +------+-----------------------+---------------+ 471 | Type | Description | Section | 472 +------+-----------------------+---------------+ 473 | 1099 | Adjacency SID TLV | Section 2.2.1 | 474 | 1100 | LAN Adjacency SID TLV | Section 2.2.2 | 475 | 1172 | L2 Bundle Member TLV | Section 2.2.3 | 476 +------+-----------------------+---------------+ 478 Table 2: Link Attribute TLVs 480 These TLVs should only be added to the BGP-LS Attribute associated 481 with the Link NLRI describing the link of the IGP node that is 482 originating the corresponding IGP TLV/sub-TLV described below. 484 2.2.1. Adjacency SID TLV 486 The Adjacency SID TLV is used in order to advertise information 487 related to an Adjacency SID. This information is derived from Adj- 488 SID sub-TLV of IS-IS (section 2.2.1 of [RFC8667]), OSPFv2 (section 489 6.1 of [RFC8665]) and OSPFv3 (section 7.1 of [RFC8666]). 491 The Adjacency SID TLV has the following format: 493 0 1 2 3 494 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 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Type | Length | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Flags | Weight | Reserved | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | SID/Label/Index (variable) // 501 +---------------------------------------------------------------+ 503 Figure 7: Adjacency SID TLV Format 505 Where: 507 Type: 1099 509 Length: Variable. Either 7 or 8 depending on Label or Index 510 encoding of the SID 512 Flags. 1 octet value which should be set as: 514 * IS-IS Adj-SID flags are defined in section 2.2.1 of [RFC8667]. 516 * OSPFv2 Adj-SID flags are defined in section 6.1 of [RFC8665]. 518 * OSPFv3 Adj-SID flags are defined in section 7.1 of [RFC8666]. 520 Weight: 1 octet carrying the weight used for load-balancing 521 purposes. The use of weight is described in section 3.4 of 522 [RFC8402]. 524 Reserved: 2 octets that MUST be set to 0 and ignored on receipt. 526 SID/Index/Label: 528 * IS-IS: Label or index value as defined in section 2.2.1 of 529 [RFC8667]. 531 * OSPFv2: Label or index value as defined in section 6.1 of 532 [RFC8665]. 534 * OSPFv3: Label or index value as defined in section 7.1 of 535 [RFC8666]. 537 The Flags and, as an extension, the SID/Index/Label fields of this 538 TLV are interpreted according to the respective underlying IS-IS, 539 OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Link NLRI 540 is used to determine the underlying protocol specification for 541 parsing these fields. 543 2.2.2. LAN Adjacency SID TLV 545 For a LAN, normally a node only announces its adjacency to the IS-IS 546 pseudo-node (or the equivalent OSPF Designated and Backup Designated 547 Routers). The LAN Adjacency Segment TLV allows a node to announce 548 adjacencies to all other nodes attached to the LAN in a single 549 instance of the BGP-LS Link NLRI. Without this TLV, the 550 corresponding BGP-LS link NLRI would need to be originated for each 551 additional adjacency in order to advertise the SR TLVs for these 552 neighbor adjacencies. 554 This information is derived from LAN-Adj-SID sub-TLV of IS-IS 555 (section 2.2.2 of [RFC8667]) and LAN Adj-SID sub-TLV of OSPFv2 556 (section 6.2 of [RFC8665]) and OSPFv3 (section 7.2 of [RFC8666]). 558 The LAN Adjacency SID TLV has the following format: 560 0 1 2 3 561 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 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Type | Length | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Flags | Weight | Reserved | 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | OSPF Neighbor ID / IS-IS System-ID | 570 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | SID/Label/Index (variable) // 576 +---------------------------------------------------------------+ 578 Figure 8: LAN Adjacency SID TLV Format 580 Where: 582 Type: 1100 584 Length: Variable. For IS-IS it would be 13 or 14 depending on 585 Label or Index encoding of the SID. For OSPF it would be 11 or 12 586 depending on Label or Index encoding of the SID. 588 Flags. 1 octet value which should be set as: 590 * IS-IS LAN Adj-SID flags are defined in section 2.2.2 of 591 [RFC8667]. 593 * OSPFv2 LAN Adj-SID flags are defined in section 6.2 of 594 [RFC8665]. 596 * OSPFv3 LAN Adj-SID flags are defined in section 7.2 of 597 [RFC8666]. 599 Weight: 1 octet carrying the weight used for load-balancing 600 purposes. The use of weight is described in section 3.4 of 601 [RFC8402]. 603 Reserved: 2 octets that MUST be set to 0 and ignored on receipt. 605 Neighbor ID: 6 octets for IS-IS for the System-ID and 4 octets for 606 OSPF for the OSPF Router-ID of the neighbor. 608 SID/Index/Label: 610 * IS-IS: Label or index value as defined in section 2.2.2 of 611 [RFC8667]. 613 * OSPFv2: Label or index value as defined in section 6.2 of 614 [RFC8665]. 616 * OSPFv3: Label or index value as defined in section 7.2 of 617 [RFC8666]. 619 The Neighbor ID, Flags and, as an extension, the SID/Index/Label 620 fields of this TLV are interpreted according to the respective 621 underlying IS-IS, OSPFv2 or OSPFv3 protocol. The Protocol-ID of the 622 BGP-LS Link NLRI is used to determine the underlying protocol 623 specification for parsing these fields. 625 2.2.3. L2 Bundle Member Attribute TLV 627 The L2 Bundle Member Attribute TLV identifies an L2 Bundle Member 628 link which in turn is associated with a parent L3 link. The L3 link 629 is described by the Link NLRI defined in [RFC7752] and the L2 Bundle 630 Member Attribute TLV is associated with the Link NLRI. The TLV MAY 631 include sub-TLVs which describe attributes associated with the bundle 632 member. The identified bundle member represents a unidirectional 633 path from the originating router to the neighbor specified in the 634 parent L3 Link. Multiple L2 Bundle Member Attribute TLVs MAY be 635 associated with a Link NLRI. 637 This information is derived from L2 Bundle Member Attributes TLV of 638 IS-IS (section 2 of [RFC8668]). The equivalent functionality has not 639 been specified as yet for OSPF. 641 The L2 Bundle Member Attribute TLV has the following format: 643 0 1 2 3 644 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 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 | Type | Length | 647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 | L2 Bundle Member Descriptor | 649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 | Link attribute sub-TLVs(variable) // 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 Figure 9: L2 Bundle Member Attributes TLV Format 655 Where: 657 Type: 1172 659 Length: Variable. 661 L2 Bundle Member Descriptor: 4 octets field that carries a Link 662 Local Identifier as defined in [RFC4202]. 664 Link attributes for L2 Bundle Member Links are advertised as sub-TLVs 665 of the L2 Bundle Member Attribute TLV. The sub-TLVs are identical to 666 existing BGP-LS TLVs as identified in the table below. 668 +-------------+------------------------------------+----------------+ 669 | TLV Code | Description | Reference | 670 | Point | | Document | 671 +-------------+------------------------------------+----------------+ 672 | 1088 | Administrative group (color) | [RFC7752] | 673 | 1089 | Maximum link bandwidth | [RFC7752] | 674 | 1090 | Max. reservable link bandwidth | [RFC7752] | 675 | 1091 | Unreserved bandwidth | [RFC7752] | 676 | 1092 | TE default metric | [RFC7752] | 677 | 1093 | Link protection type | [RFC7752] | 678 | 1099 | Adjacency Segment Identifier (Adj- | Section 2.2.1 | 679 | | SID) TLV | | 680 | 1100 | LAN Adjacency Segment Identifier | Section 2.2.2 | 681 | | (Adj-SID) TLV | | 682 | 1114 | Unidirectional link delay | [RFC8571] | 683 | 1115 | Min/Max Unidirectional link delay | [RFC8571] | 684 | 1116 | Unidirectional Delay Variation | [RFC8571] | 685 | 1117 | Unidirectional packet loss | [RFC8571] | 686 | 1118 | Unidirectional residual bandwidth | [RFC8571] | 687 | 1119 | Unidirectional available bandwidth | [RFC8571] | 688 | 1120 | Unidirectional bandwidth | [RFC8571] | 689 | | utilization | | 690 +-------------+------------------------------------+----------------+ 692 Table 3: BGP-LS Attribute TLVs also used as sub-TLVs of L2 Bundle 693 Member Attribute TLV 695 2.3. Prefix Attribute TLVs 697 The following Prefix Attribute TLVs are defined: 699 +------------------+--------------------------+---------------+ 700 | Type | Description | Section | 701 +------------------+--------------------------+---------------+ 702 | 1158 | Prefix SID | Section 2.3.1 | 703 | 1159 | Range | Section 2.3.5 | 704 | 1170 | Prefix Attribute Flags | Section 2.3.2 | 705 | 1171 | Source Router Identifier | Section 2.3.3 | 706 | 1174 (suggested) | Source OSPF Router-ID | Section 2.3.4 | 707 +------------------+--------------------------+---------------+ 709 Table 4: Prefix Attribute TLVs 711 These TLVs should only be added to the BGP-LS Attribute associated 712 with the Prefix NLRI describing the prefix of the IGP node that is 713 originating the corresponding IGP TLV/sub-TLV described below. 715 2.3.1. Prefix SID TLV 717 The Prefix SID TLV is used in order to advertise information related 718 to a Prefix SID. This information is derived from Prefix-SID sub-TLV 719 of IS-IS (section 2.1 of [RFC8667]) and the Prefix SID sub-TLV of 720 OSPFv2 (section 5 of [RFC8665]) and OSPFv3 (section 6 of [RFC8666]). 722 The Prefix SID TLV has the following format: 724 0 1 2 3 725 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 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Type | Length | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Flags | Algorithm | Reserved | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | SID/Index/Label (variable) // 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 734 Figure 10: Prefix SID TLV Format 736 Where: 738 Type: 1158 740 Length: Variable. 7 or 8 depending on Label or Index encoding of 741 the SID 743 Flags: 1 octet value which should be set as: 745 * IS-IS Prefix SID flags are defined in section 2.1.1 of 746 [RFC8667]. 748 * OSPFv2 Prefix SID flags are defined in section 5 of [RFC8665]. 750 * OSPFv3 Prefix SID flags are defined in section 6 of [RFC8666]. 752 Algorithm: 1 octet value identify the algorithm. The semantics of 753 algorithm are described in section 3.1.1 of [RFC8402]. 755 Reserved: 2 octets that MUST be set to 0 and ignored on receipt. 757 SID/Index/Label: 759 * IS-IS: Label or index value as defined in section 2.1 of 760 [RFC8667]. 762 * OSPFv2: Label or index value as defined in section 5 of 763 [RFC8665]. 765 * OSPFv3: Label or index value as defined in section 6 of 766 [RFC8666]. 768 The Flags and, as an extension, the SID/Index/Label fields of this 769 TLV are interpreted according to the respective underlying IS-IS, 770 OSPFv2 or OSPFv3 protocol. The Protocol-ID of the BGP-LS Prefix NLRI 771 is used to determine the underlying protocol specification for 772 parsing these fields. 774 2.3.2. Prefix Attribute Flags TLV 776 The Prefix Attribute Flags TLV carries IPv4/IPv6 prefix attribute 777 flags information. These flags are defined for OSPFv2 in section 2.1 778 of [RFC7684], for OSPFv3 in section A.4.1.1 of [RFC5340] and for IS- 779 IS in section 2.1 of [RFC7794]. 781 The Prefix Attribute Flags TLV has the following format: 783 0 1 2 3 784 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 785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 | Type | Length | 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Flags (variable) // 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 Figure 11: Prefix Attribute Flags TLV Format 793 Where: 795 Type: 1170 797 Length: Variable. 799 Flags: a variable length flag field (according to the length 800 field). Flags are routing protocol specific and are to be set as 801 below: 803 * IS-IS flags correspond to the IPv4/IPv6 Extended Reachability 804 Attribute Flags defined in section 2.1 of [RFC7794]. In the 805 case of the X-flag when associated with IPv6 prefix 806 reachability, the setting corresponds to the setting of the 807 X-flag in the fixed format of IS-IS TLVs 236 [RFC5308] and 237 808 [RFC5120]. 810 * OSPFv2 flags correspond to the Flags field of the OSPFv2 811 Extended Prefix TLV defined in section 2.1 of [RFC7684] 813 * OSPFv3 flags map to the Prefix Options field defined in section 814 A.4.1.1 of [RFC5340] and extended in section 3.1 of [RFC8362] 816 The Flags field of this TLV is interpreted according to the 817 respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The 818 Protocol-ID of the BGP-LS Prefix NLRI is used to determine the 819 underlying protocol specification for parsing this field. 821 2.3.3. Source Router Identifier TLV 823 The Source Router Identifier TLV contains the IPv4 or IPv6 Router 824 Identifier of the originator of the Prefix. For the IS-IS protocol 825 this is derived from the IPv4/IPv6 Source Router ID sub-TLV as 826 defined in section 2.2 of [RFC7794]. For the OSPF protocol, this is 827 derived from the Prefix Source Router Address sub-TLV as defined in 828 section 2.2 of [I-D.ietf-lsr-ospf-prefix-originator]. 830 The Source Router Identifier TLV has the following format: 832 0 1 2 3 833 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 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Type | Length | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 | 4 or 16 octet Router Identifier // 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 Figure 12: Source Router Identifier TLV Format 842 Where: 844 Type: 1171 846 Length: Variable. 4 or 16 for IPv4 and IPv6 prefix respectively. 848 Router-ID: the IPv4 or IPv6 Router-ID in case of IS-IS and the 849 IPv4 or IPv6 Router Address in the case of OSPF. 851 2.3.4. Source OSPF Router-ID TLV 853 The Source OSPF Router-ID TLV is applicable only for the OSPF 854 protocol and contains OSPF Router-ID of the originator of the Prefix. 855 It is derived from the Prefix Source OSPF Router-ID sub-TLV as 856 defined in section 2.1 of [I-D.ietf-lsr-ospf-prefix-originator]. 858 The Source OSPF Router-ID TLV has the following format: 860 0 1 2 3 861 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 862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 | Type | Length | 864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 | 4 octet OSPF Router-ID // 866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 Figure 13: Source OSPF Router-ID TLV Format 870 Where: 872 Type: 1174 (suggested) 874 Length: 4 876 OSPF Router-ID: the OSPF Router-ID of the node originating the 877 prefix. 879 2.3.5. Range TLV 881 The Range TLV is used in order to advertise a range of prefix-to-SID 882 mappings as part of the Segment Routing Mapping Server (SRMS) 883 functionality [RFC8661], as defined in the respective underlying IGP 884 SR extensions [RFC8665] (section 4), [RFC8666] (section 5) and 885 [RFC8667] (section 2.4). The information advertised in the Range TLV 886 is derived from the SID/Label Binding TLV in the case of IS-IS and 887 the OSPFv2/OSPFv3 Extended Prefix Range TLV in the case of OSPFv2/ 888 OSPFv3. 890 A Prefix NLRI, that been advertised with a Range TLV, is considered a 891 normal routing prefix (i.e. prefix reachability) only when there is 892 also an IGP metric TLV (TLV 1095) associated it. Otherwise, it is 893 considered only as the first prefix in the range for prefix-to-SID 894 mapping advertisement. 896 The format of the Range TLV is as follows: 898 0 1 2 3 899 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 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Type | Length | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Flags | Reserved | Range Size | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | sub-TLVs // 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 Figure 14: Range TLV Format 910 Where: 912 Type: 1159 914 Length: Variable. 11 or 12 depending on Label or Index encoding of 915 the SID 917 Flags: 1 octet value which should be set as: 919 * IS-IS SID/Label Binding TLV flags are defined in section 2.4.1 920 of [RFC8667]. 922 * OSPFv2 OSPF Extended Prefix Range TLV flags are defined in 923 section 4 of [RFC8665]. 925 * OSPFv3 Extended Prefix Range TLV flags are defined in section 5 926 of [RFC8666]. 928 Reserved: 1 octet that MUST be set to 0 and ignored on receipt. 930 Range Size: 2 octets that carry the number of prefixes that are 931 covered by the advertisement.. 933 The Flags field of this TLV is interpreted according to the 934 respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The 935 Protocol-ID of the BGP-LS Prefix NLRI is used to determine the 936 underlying protocol specification for parsing this field. 938 The prefix-to-SID mappings are advertised using sub-TLVs as below: 940 IS-IS: 941 SID/Label Range TLV 942 Prefix-SID sub-TLV 944 OSPFv2/OSPFv3: 945 OSPFv2/OSPFv3 Extended Prefix Range TLV 946 Prefix SID sub-TLV 948 BGP-LS: 949 Range TLV 950 Prefix-SID TLV (used as a sub-TLV in this context) 952 The prefix-to-SID mapping information for the BGP-LS Prefix-SID TLV 953 (used as sub-TLV in this context) is encoded as described in 954 Section 2.3.1. 956 2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs 958 This section illustrate the IS-IS Segment Routing Extensions TLVs and 959 sub-TLVs mapped to the ones defined in this document. 961 The following table, illustrates for each BGP-LS TLV, its equivalence 962 in IS-IS. 964 +----------------------+--------------------------------+-----------+ 965 | Description | IS-IS TLV/sub-TLV | Reference | 966 +----------------------+--------------------------------+-----------+ 967 | SR Capabilities | SR-Capabilities sub-TLV (2) | [RFC8667] | 968 | SR Algorithm | SR-Algorithm sub-TLV (19) | [RFC8667] | 969 | SR Local Block | SR Local Block sub-TLV (22) | [RFC8667] | 970 | SRMS Preference | SRMS Preference sub-TLV (19) | [RFC8667] | 971 | Adjacency SID | Adj-SID sub-TLV (31) | [RFC8667] | 972 | LAN Adjacency SID | LAN-Adj-SID sub-TLV (32) | [RFC8667] | 973 | Prefix SID | Prefix-SID sub-TLV (3) | [RFC8667] | 974 | Range | SID/Label Binding TLV (149) | [RFC8667] | 975 | SID/Label | SID/Label sub-TLV (1) | [RFC8667] | 976 | Prefix Attribute | Prefix Attributes Flags sub- | [RFC7794] | 977 | Flags | TLV (4) | | 978 | Source Router | IPv4/IPv6 Source Router ID | [RFC7794] | 979 | Identifier | sub-TLV (11/12) | | 980 | L2 Bundle Member | L2 Bundle Member Attributes | [RFC8668] | 981 | Attributes | TLV (25) | | 982 +----------------------+--------------------------------+-----------+ 984 Table 5: IS-IS Segment Routing Extensions TLVs/Sub-TLVs 986 2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs 988 This section illustrate the OSPFv2 and OSPFv3 Segment Routing 989 Extensions TLVs and sub-TLVs mapped to the ones defined in this 990 document. 992 The following table, illustrates for each BGP-LS TLV, its equivalence 993 in OSPFv2 and OSPFv3. 995 +-------------+--------------+--------------------------------------+ 996 | Description | OSPFv2 | Reference | 997 | | TLV/sub-TLV | | 998 +-------------+--------------+--------------------------------------+ 999 | SR Capabili | SID/Label | [RFC8665] | 1000 | ties | Range TLV | | 1001 | | (9) | | 1002 | SR | SR-Algorithm | [RFC8665] | 1003 | Algorithm | TLV (8) | | 1004 | SR Local | SR Local | [RFC8665] | 1005 | Block | Block TLV | | 1006 | | (14) | | 1007 | SRMS | SRMS | [RFC8665] | 1008 | Preference | Preference | | 1009 | | TLV (15) | | 1010 | Adjacency | Adj-SID sub- | [RFC8665] | 1011 | SID | TLV (2) | | 1012 | LAN | LAN Adj-SID | [RFC8665] | 1013 | Adjacency | sub-TLV (3) | | 1014 | SID | | | 1015 | Prefix SID | Prefix SID | [RFC8665] | 1016 | | sub-TLV (2) | | 1017 | Range | OSPF | [RFC8665] | 1018 | | Extended | | 1019 | | Prefix Range | | 1020 | | TLV (2) | | 1021 | SID/Label | SID/Label | [RFC8665] | 1022 | | sub-TLV (1) | | 1023 | Prefix | Flags of | [RFC7684] | 1024 | Attribute | OSPFv2 | | 1025 | Flags | Extended | | 1026 | | Prefix TLV | | 1027 | | (1) | | 1028 | Source | Prefix | [I-D.ietf-lsr-ospf-prefix-originator | 1029 | Router | Source | ] | 1030 | Identifier | Router-ID | | 1031 | | sub-TLV (4) | | 1032 | Source OSPF | Prefix | [I-D.ietf-lsr-ospf-prefix-originator | 1033 | Router-ID | Source OSPF | ] | 1034 | | Router-ID | | 1035 | | sub-TLV (5) | | 1036 +-------------+--------------+--------------------------------------+ 1038 Table 6: OSPFv2 Segment Routing Extensions TLVs/Sub-TLVs 1040 +-------------+--------------+--------------------------------------+ 1041 | Description | OSPFv3 | Reference | 1042 | | TLV/sub-TLV | | 1043 +-------------+--------------+--------------------------------------+ 1044 | SR Capabili | SID/Label | [RFC8665] | 1045 | ties | Range TLV | | 1046 | | (9) | | 1047 | SR | SR-Algorithm | [RFC8665] | 1048 | Algorithm | TLV (8) | | 1049 | SR Local | SR Local | [RFC8665] | 1050 | Block | Block TLV | | 1051 | | (14) | | 1052 | SRMS | SRMS | [RFC8665] | 1053 | Preference | Preference | | 1054 | | TLV (15) | | 1055 | Adjacency | Adj-SID sub- | [RFC8666] | 1056 | SID | TLV (5) | | 1057 | LAN | LAN Adj-SID | [RFC8666] | 1058 | Adjacency | sub-TLV (6) | | 1059 | SID | | | 1060 | Prefix SID | Prefix SID | [RFC8666] | 1061 | | sub-TLV (4) | | 1062 | Range | OSPFv3 | [RFC8666] | 1063 | | Extended | | 1064 | | Prefix Range | | 1065 | | TLV (9) | | 1066 | SID/Label | SID/Label | [RFC8666] | 1067 | | sub-TLV (7) | | 1068 | Prefix | Prefix | [RFC8362] | 1069 | Attribute | Option | | 1070 | Flags | Fields of | | 1071 | | Prefix TLV | | 1072 | | types 3,5,6 | | 1073 | Source OSPF | Prefix | [I-D.ietf-lsr-ospf-prefix-originator | 1074 | Router | Source | ] | 1075 | Identifier | Router-ID | | 1076 | | sub-TLV (27) | | 1077 | Source OSPF | Prefix | [I-D.ietf-lsr-ospf-prefix-originator | 1078 | Router-ID | Source OSPF | ] | 1079 | | Router-ID | | 1080 | | sub-TLV (28) | | 1081 +-------------+--------------+--------------------------------------+ 1083 Table 7: OSPFv3 Segment Routing Extensions TLVs/Sub-TLVs 1085 3. IANA Considerations 1087 Early allocation of codepoints has been done by IANA for this 1088 document from the registry "BGP-LS Node Descriptor, Link Descriptor, 1089 Prefix Descriptor, and Attribute TLVs" under the "BGP-LS Parameters" 1090 registry based on Table 8. The column "IS-IS TLV/Sub-TLV" defined in 1091 the registry does not require any value and should be left empty. 1093 3.1. TLV/Sub-TLV Code Points Summary 1095 This section contains the global table of all TLVs/sub-TLVs defined 1096 in this document. 1098 +------------------+-----------------------------+---------------+ 1099 | TLV Code Point | Description | Reference | 1100 +------------------+-----------------------------+---------------+ 1101 | 1034 | SR Capabilities | Section 2.1.2 | 1102 | 1035 | SR Algorithm | Section 2.1.3 | 1103 | 1036 | SR Local Block | Section 2.1.4 | 1104 | 1037 | SRMS Preference | Section 2.1.5 | 1105 | 1099 | Adjacency SID | Section 2.2.1 | 1106 | 1100 | LAN Adjacency SID | Section 2.2.2 | 1107 | 1158 | Prefix SID | Section 2.3.1 | 1108 | 1159 | Range | Section 2.3.5 | 1109 | 1161 | SID/Label | Section 2.1.1 | 1110 | 1170 | Prefix Attribute Flags | Section 2.3.2 | 1111 | 1171 | Source Router Identifier | Section 2.3.3 | 1112 | 1172 | L2 Bundle Member Attributes | Section 2.2.3 | 1113 | 1174 (suggested) | Source OSPF Router-ID | Section 2.3.4 | 1114 +------------------+-----------------------------+---------------+ 1116 Table 8: Summary Table of TLV/Sub-TLV Codepoints 1118 4. Manageability Considerations 1120 This section is structured as recommended in [RFC5706]. 1122 The new protocol extensions introduced in this document augment the 1123 existing IGP topology information that is distributed via [RFC7752]. 1124 Procedures and protocol extensions defined in this document do not 1125 affect the BGP protocol operations and management other than as 1126 discussed in the Manageability Considerations section of [RFC7752]. 1127 Specifically, the malformed attribute tests for syntactic checks in 1128 the Fault Management section of [RFC7752] now encompass the new BGP- 1129 LS Attribute TLVs defined in this document. The semantic or content 1130 checking for the TLVs specified in this document and their 1131 association with the BGP-LS NLRI types or their BGP-LS Attribute is 1132 left to the consumer of the BGP-LS information (e.g. an application 1133 or a controller) and not the BGP protocol. 1135 A consumer of the BGP-LS information retrieves this information over 1136 a BGP-LS session (refer Section 1 and 2 of [RFC7752]). The handling 1137 of semantic or content errors by the consumer would be dictated by 1138 the nature of its application usage and hence is beyond the scope of 1139 this document. 1141 This document only introduces new Attribute TLVs and any syntactic 1142 error in them would result in the BGP-LS Attribute being discarded 1143 with an error log. The SR information introduced in BGP-LS by this 1144 specification, may be used by BGP-LS consumer applications like a SR 1145 path computation engine (PCE) to learn the SR capabilities of the 1146 nodes in the topology and the mapping of SR segments to those nodes. 1147 This can enable the SR PCE to perform path computations based on SR 1148 for traffic engineering use-cases and to steer traffic on paths 1149 different from the underlying IGP based distributed best path 1150 computation. Errors in the encoding or decoding of the SR 1151 information may result in the unavailability of such information to 1152 the SR PCE or incorrect information being made available to it. This 1153 may result in the SR PCE not being able to perform the desired SR 1154 based optimization functionality or to perform it in an unexpected or 1155 inconsistent manner. The handling of such errors by applications 1156 like SR PCE may be implementation specific and out of scope of this 1157 document. 1159 The extensions, specified in this document, do not introduce any new 1160 configuration or monitoring aspects in BGP or BGP-LS other than as 1161 discussed in [RFC7752]. The manageability aspects of the underlying 1162 SR features are covered by [I-D.ietf-spring-sr-yang], 1163 [I-D.ietf-isis-sr-yang] and [I-D.ietf-ospf-sr-yang]. 1165 5. Security Considerations 1167 The new protocol extensions introduced in this document augment the 1168 existing IGP topology information that is distributed via [RFC7752]. 1169 The advertisement of the SR link attribute information defined in 1170 this document presents similar risk as associated with the existing 1171 set of link attribute information as described in [RFC7752]. The 1172 Security Considerations section of [RFC7752] also applies to these 1173 extensions. The procedures and new TLVs defined in this document, by 1174 themselves, do not affect the BGP-LS security model discussed in 1175 [RFC7752]. 1177 The TLVs introduced in this document are used to propagate IGP 1178 defined information ([RFC8667], [RFC8665] and [RFC8666]). These TLVs 1179 represent the SR information associated with the IGP node, link and 1180 prefix. The IGP instances originating these TLVs are assumed to 1181 support all the required security and authentication mechanisms (as 1182 described in [RFC8667], [RFC8665] and [RFC8666]) in order to prevent 1183 any security issue when propagating the TLVs into BGP-LS. 1185 BGP-LS SR extensions enable traffic engineering use-cases within the 1186 Segment Routing domain. SR operates within a trusted domain 1187 [RFC8402] and its security considerations also apply to BGP-LS 1188 sessions when carrying SR information. The SR traffic engineering 1189 policies using the SIDs advertised via BGP-LS are expected to be used 1190 entirely within this trusted SR domain (e.g. between multiple AS/ 1191 domains within a single provider network). Therefore, precaution is 1192 necessary to ensure that the link-state information (including SR 1193 information) advertised via BGP-LS sessions is limited to consumers 1194 in a secure manner within this trusted SR domain. BGP peering 1195 sessions for address-families other than Link-State may be setup to 1196 routers outside the SR domain. The isolation of BGP-LS peering 1197 sessions is recommended to ensure that BGP-LS topology information 1198 (including the newly added SR information) is not advertised to an 1199 external BGP peering session outside the SR domain. 1201 6. Contributors 1203 The following people have substantially contributed to the editing of 1204 this document: 1206 Peter Psenak 1207 Cisco Systems 1208 Email: ppsenak@cisco.com 1210 Les Ginsberg 1211 Cisco Systems 1212 Email: ginsberg@cisco.com 1214 Acee Lindem 1215 Cisco Systems 1216 Email: acee@cisco.com 1218 Saikat Ray 1219 Individual 1220 Email: raysaikat@gmail.com 1222 Jeff Tantsura 1223 Apstra Inc. 1224 Email: jefftant.ietf@gmail.com 1226 7. Acknowledgements 1228 The authors would like to thank Jeffrey Haas, Aijun Wang, Robert 1229 Raszuk and Susan Hares for their review of this document and their 1230 comments. The authors would also like to thank Alvaro Retana for his 1231 extensive review and comments which helped correct issues and improve 1232 the document. 1234 8. References 1236 8.1. Normative References 1238 [I-D.ietf-lsr-ospf-prefix-originator] 1239 Wang, A., Lindem, A., Dong, J., Psenak, P., and K. 1240 Talaulikar, "OSPF Prefix Originator Extensions", draft- 1241 ietf-lsr-ospf-prefix-originator-07 (work in progress), 1242 October 2020. 1244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1245 Requirement Levels", BCP 14, RFC 2119, 1246 DOI 10.17487/RFC2119, March 1997, 1247 . 1249 [RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions 1250 in Support of Generalized Multi-Protocol Label Switching 1251 (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, 1252 . 1254 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1255 Topology (MT) Routing in Intermediate System to 1256 Intermediate Systems (IS-ISs)", RFC 5120, 1257 DOI 10.17487/RFC5120, February 2008, 1258 . 1260 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1261 DOI 10.17487/RFC5308, October 2008, 1262 . 1264 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 1265 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 1266 . 1268 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1269 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1270 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1271 2015, . 1273 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 1274 S. Ray, "North-Bound Distribution of Link-State and 1275 Traffic Engineering (TE) Information Using BGP", RFC 7752, 1276 DOI 10.17487/RFC7752, March 2016, 1277 . 1279 [RFC7794] Ginsberg, L., Ed., Decraene, B., Previdi, S., Xu, X., and 1280 U. Chunduri, "IS-IS Prefix Attributes for Extended IPv4 1281 and IPv6 Reachability", RFC 7794, DOI 10.17487/RFC7794, 1282 March 2016, . 1284 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1285 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1286 May 2017, . 1288 [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and 1289 F. Baker, "OSPFv3 Link State Advertisement (LSA) 1290 Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 1291 2018, . 1293 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1294 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1295 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1296 July 2018, . 1298 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 1299 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 1300 IGP Traffic Engineering Performance Metric Extensions", 1301 RFC 8571, DOI 10.17487/RFC8571, March 2019, 1302 . 1304 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 1305 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 1306 Extensions for Segment Routing", RFC 8665, 1307 DOI 10.17487/RFC8665, December 2019, 1308 . 1310 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 1311 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 1312 December 2019, . 1314 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 1315 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 1316 Extensions for Segment Routing", RFC 8667, 1317 DOI 10.17487/RFC8667, December 2019, 1318 . 1320 [RFC8668] Ginsberg, L., Ed., Bashandy, A., Filsfils, C., Nanduri, 1321 M., and E. Aries, "Advertising Layer 2 Bundle Member Link 1322 Attributes in IS-IS", RFC 8668, DOI 10.17487/RFC8668, 1323 December 2019, . 1325 8.2. Informative References 1327 [I-D.ietf-isis-sr-yang] 1328 Litkowski, S., Qu, Y., Sarkar, P., Chen, I., and J. 1329 Tantsura, "YANG Data Model for IS-IS Segment Routing", 1330 draft-ietf-isis-sr-yang-09 (work in progress), January 1331 2021. 1333 [I-D.ietf-ospf-sr-yang] 1334 Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, 1335 "YANG Data Model for OSPF SR (Segment Routing) Protocol", 1336 draft-ietf-ospf-sr-yang-13 (work in progress), January 1337 2021. 1339 [I-D.ietf-spring-sr-yang] 1340 Litkowski, S., Qu, Y., Lindem, A., Sarkar, P., and J. 1341 Tantsura, "YANG Data Model for Segment Routing", draft- 1342 ietf-spring-sr-yang-30 (work in progress), January 2021. 1344 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 1345 Management of New Protocols and Protocol Extensions", 1346 RFC 5706, DOI 10.17487/RFC5706, November 2009, 1347 . 1349 [RFC8661] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 1350 Decraene, B., and S. Litkowski, "Segment Routing MPLS 1351 Interworking with LDP", RFC 8661, DOI 10.17487/RFC8661, 1352 December 2019, . 1354 Authors' Addresses 1356 Stefano Previdi 1357 Huawei Technologies 1358 Rome 1359 Italy 1361 Email: stefano@previdi.net 1362 Ketan Talaulikar (editor) 1363 Cisco Systems, Inc. 1364 India 1366 Email: ketant@cisco.com 1368 Clarence Filsfils 1369 Cisco Systems, Inc. 1370 Brussels 1371 Belgium 1373 Email: cfilsfil@cisco.com 1375 Hannes Gredler 1376 RtBrick Inc. 1378 Email: hannes@rtbrick.com 1380 Mach(Guoyi) Chen 1381 Huawei Technologies 1382 Huawei Building, No. 156 Beiqing Rd. 1383 Beijing 100095 1384 China 1386 Email: mach.chen@huawei.com