idnits 2.17.1 draft-ietf-ospf-segment-routing-extensions-00.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 19, 2014) is 3598 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) -- Looks like a reference, but probably isn't: '100' on line 278 -- Looks like a reference, but probably isn't: '199' on line 278 -- Looks like a reference, but probably isn't: '1000' on line 279 -- Looks like a reference, but probably isn't: '1099' on line 279 -- Looks like a reference, but probably isn't: '500' on line 280 -- Looks like a reference, but probably isn't: '599' on line 280 ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Shortest Path First IGP P. Psenak, Ed. 3 Internet-Draft S. Previdi, Ed. 4 Intended status: Standards Track C. Filsfils 5 Expires: December 21, 2014 Cisco Systems, Inc. 6 H. Gredler 7 Juniper Networks, Inc. 8 R. Shakir 9 British Telecom 10 W. Henderickx 11 Alcatel-Lucent 12 J. Tantsura 13 Ericsson 14 June 19, 2014 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-00 19 Abstract 21 Segment Routing (SR) allows for a flexible definition of end-to-end 22 paths within IGP topologies by encoding paths as sequences of 23 topological sub-paths, called "segments". These segments are 24 advertised by the link-state routing protocols (IS-IS and OSPF). 26 This draft describes the necessary OSPF extensions that need to be 27 introduced for Segment Routing. 29 Requirements Language 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 33 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 http://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 December 21, 2014. 51 Copyright Notice 53 Copyright (c) 2014 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 (http://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. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 70 2.1. SID/Label sub-TLV . . . . . . . . . . . . . . . . . . . . 4 71 3. Segment Routing Capabilities . . . . . . . . . . . . . . . . 4 72 3.1. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . . . 4 73 3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 5 74 4. OSPFv2 Extended Prefix Opaque LSA type . . . . . . . . . . . 7 75 4.1. OSPF Extended Prefix TLV . . . . . . . . . . . . . . . . 8 76 4.2. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . 9 77 4.3. SID/Label Binding sub-TLV . . . . . . . . . . . . . . . . 13 78 4.3.1. ERO Metric sub-TLV . . . . . . . . . . . . . . . . . 15 79 4.3.2. ERO sub-TLVs . . . . . . . . . . . . . . . . . . . . 15 80 5. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 20 81 5.1. OSPFv2 Extended Link Opaque LSA . . . . . . . . . . . . . 20 82 5.2. OSPFv2 Extended Link TLV . . . . . . . . . . . . . . . . 21 83 5.3. Adj-SID sub-TLV . . . . . . . . . . . . . . . . . . . . . 22 84 5.4. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 23 85 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 25 86 6.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 25 87 6.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . 25 88 6.3. SID for External Prefixes . . . . . . . . . . . . . . . . 26 89 6.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 27 90 6.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 27 91 6.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 27 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 93 7.1. OSPF Extend Prefix LSA TLV Registry . . . . . . . . . . . 28 94 7.2. OSPF Extend Prefix LSA sub-TLV Registry . . . . . . . . . 28 95 7.3. OSPF Extend Link LSA TLV Registry . . . . . . . . . . . . 29 96 7.4. OSPF Extend Link LSA sub-TLV Registry . . . . . . . . . . 29 98 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 99 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 100 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30 101 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 102 11.1. Normative References . . . . . . . . . . . . . . . . . . 30 103 11.2. Informative References . . . . . . . . . . . . . . . . . 31 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 106 1. Introduction 108 Segment Routing (SR) allows for a flexible definition of end-to-end 109 paths within IGP topologies by encoding paths as sequences of 110 topological sub-paths, called "segments". These segments are 111 advertised by the link-state routing protocols (IS-IS and OSPF). 112 Prefix segments represent an ecmp-aware shortest-path to a prefix (or 113 a node), as per the state of the IGP topology. Adjacency segments 114 represent a hop over a specific adjacency between two nodes in the 115 IGP. A prefix segment is typically a multi-hop path while an 116 adjacency segment, in most of the cases, is a one-hop path. SR's 117 control-plane can be applied to both IPv6 and MPLS data-planes, and 118 do not require any additional signaling (other than the regular IGP). 119 For example, when used in MPLS networks, SR paths do not require any 120 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 121 of LSPs established with RSVP or LDP . 123 This draft describes the necessary OSPF extensions that need to be 124 introduced for Segment Routing. 126 Segment Routing architecture is described in 127 [I-D.filsfils-rtgwg-segment-routing]. 129 Segment Routing use cases are described in 130 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 132 2. Segment Routing Identifiers 134 Segment Routing defines various types of Segment Identifiers (SIDs): 135 Prefix-SID, Adjacency-SID, LAN Adjacency SID and Binding SID. 137 For the purpose of the advertisements of various SID values new 138 Opaque LSAs (defined in [RFC5250]) are defined. These new LSAs are 139 defined as generic containers that can be used in order to advertise 140 any additional attributes associated with the prefix or link. These 141 new Opaque LSAs are complementary to the existing LSAs and are not 142 aimed to replace any of the existing LSAs. 144 2.1. SID/Label sub-TLV 146 SID/Label sub-TLV appears in multiple TLVs or sub-TLVs defined later 147 in this document. It is used to advertise SID or label associated 148 with the prefix or adjacency. SID/Label TLV has following format: 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | Type | Length | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | SID/Label (variable) | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 where: 160 Type: TBD, suggested value 1 162 Length: variable, 3 or 4 bytes 164 SID/Label: if length is set to 3, then the 20 rightmost bits 165 represent a label. If length is set to 4 then the value 166 represents a 32 bit SID. 168 The receiving router MUST ignore SID/Label sub-TLV if the length 169 is other then 3 or 4. 171 3. Segment Routing Capabilities 173 Segment Routing requires some additional capabilities of the router 174 to be advertised to other routers in the area. 176 These SR capabilities are advertised in Router Information Opaque LSA 177 (defined in [RFC4970]). 179 3.1. SR-Algorithm TLV 181 SR-Algorithm TLV is a TLV of Router Information Opaque LSA (defined 182 in [RFC4970]). 184 The SR-Algorithm Sub-TLV is optional, it MAY only appear once inside 185 the Router Informational Opaque LSA. If the SID/Label Range TLV, as 186 defined in Section 3.2, is advertised, then SR-Algorithm TLV MUST 187 also be advertised. 189 Router may use various algorithms when calculating reachability to 190 other nodes in area or to prefixes attached to these nodes. Examples 191 of these algorithms are metric based Shortest Path First (SPF), 192 various sorts of Constrained SPF, etc. SR-Algorithm TLV allows a 193 router to advertise algorithms that router is currently using to 194 other routers in an area. SR-Algorithm TLV has following structure: 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Type | Length | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Algorithm 1 | Algorithm... | Algorithm n | | 202 +- -+ 203 | | 204 + + 206 where: 208 Type: TBD, suggested value 8 210 Length: variable 212 Algorithm: one octet identifying the algorithm. The following 213 value has been defined: 215 0: IGP metric based SPT. 217 RI LSA can be advertised at any of the defined flooding scopes (link, 218 area, or autonomous system (AS)). For the purpose of the SR- 219 Algorithm TLV propagation area scope flooding is required. 221 3.2. SID/Label Range TLV 223 The SID/Label Range TLV is a TLV of Router Information Opaque LSA 224 (defined in [RFC4970]). 226 SID/Label Sub-TLV MAY appear multiple times and has following format: 228 0 1 2 3 229 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 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Type | Length | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Range Size | Reserved | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Sub-TLVs (variable) | 236 +- -+ 237 | | 238 + + 240 where: 242 Type: TBD, suggested value 9 244 Length: variable 246 Range Size: 3 octet of the SID/label range 248 Currently the only supported Sub-TLV is the SID/Label TLV as defined 249 in Section 2.1. SID/Label advertised in SID/Label TLV represents the 250 first SID/Label from the advertised range. 252 Multiple occurrence of the SID/Label Range TLV MAY be advertised, in 253 order to advertise multiple ranges. In such case: 255 o The originating router MUST encode each range into a different 256 SID/Label Range TLV. 258 o The originating router decides in which order the set of SID/Label 259 Range TLVs are advertised inside Router Information Opaque LSA. 260 The originating router MUST ensure the order is same after a 261 graceful restart (using checkpointing, non-volatile storage or any 262 other mechanism) in order to guarantee the same order before and 263 after graceful restart. 265 o Receiving router must adhere to the order in which the ranges are 266 advertised when calculating a SID/label from the SID index. 268 Here follows an example of advertisement of multiple ranges: 270 The originating router advertises following ranges: 271 Range 1: [100, 199] 272 Range 2: [1000, 1099] 273 Range 3: [500, 599] 275 The receiving routers concatenate the ranges and build the SRGB 276 is as follows: 278 SRGB = [100, 199] 279 [1000, 1099] 280 [500, 599] 282 The indexes span multiple ranges: 284 index=0 means label 100 285 ... 286 index 99 means label 199 287 index 100 means label 1000 288 index 199 means label 1099 289 ... 290 index 200 means label 500 291 ... 293 RI LSA can be advertised at any of the defined flooding scopes (link, 294 area, or autonomous system (AS)). For the purpose of the SR- 295 Capability TLV propagation area scope flooding is required. 297 4. OSPFv2 Extended Prefix Opaque LSA type 299 A new Opaque LSA (defined in [RFC5250]) is defined in OSPFv2 in order 300 to advertise additional prefix attributes: OSPFv2 Extended Prefix 301 Opaque LSA. 303 Multiple OSPFv2 Extended Prefix Opaque LSAs can be advertised by a 304 single router. Flooding scope of the OSPFv2 Extended Prefix Opaque 305 LSA depends on the content inside the LSA and is in control of the 306 originating router. 308 The format of the OSPFv2 Extended Prefix Opaque LSA is as follows: 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | LS age | Options | 9, 10, or 11 | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Opaque type | Instance | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Advertising Router | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | LS sequence number | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | LS checksum | length | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | | 324 +- TLVs -+ 325 | ... | 327 Opaque type used by OSPFv2 Extended Prefix Opaque LSA is 7. 329 The format of the TLVs within the body of the LSA is the same as the 330 format used by the Traffic Engineering Extensions to OSPF defined in 331 [RFC3630]. The LSA payload consists of one or more nested 332 Type/Length/Value (TLV) triplets. The format of each TLV is: 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Type | Length | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Value... | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 The Length field defines the length of the value portion in octets. 343 The TLV is padded to 4-octet alignment; padding is not included in 344 the length field. Nested TLVs are also 32-bit aligned. Unrecognized 345 types are ignored. 347 4.1. OSPF Extended Prefix TLV 349 The OSPF Extended Prefix TLV is used in order to advertise additional 350 attributes associated with the prefix. Multiple OSPF Extended Prefix 351 TLVs MAY be carried in each OSPFv2 Extended Prefix Opaque LSA, 352 however all prefixes included in the single OSPFv2 Extended Prefix 353 Opaque LSA MUST have the same flooding scope. The structure of the 354 OSPF Extended Prefix TLV is as follows: 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Type | Length | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Route Type | Prefix Length | AF | Reserved | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Address Prefix (variable) | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Sub-TLVs (variable) | 366 +- -+ 367 | | 369 where: 371 Type: TBD, suggested value 1. 373 Length: variable 375 Route type: type of the OSPF route. Supported types are: 377 0 - unspecified 378 1 - intra-area 379 3 - inter-area 380 5 - external 381 7 - NSSA external 383 If the route type is 0 (unspecified) the information inside the 384 OSPF External Prefix TLV applies to the prefix regardless of what 385 route-type it is. This is useful when some prefix specific 386 attributes are advertised by some external entity, which is not 387 aware of the route-type associated with the prefix. 389 Prefix length: length of the prefix 391 AF: 0 - IPv4 unicast 393 Address Prefix: the prefix itself encoded as an even multiple of 394 32-bit words, padded with zeroed bits as necessary. This encoding 395 consumes ((PrefixLength + 31) / 32) 32-bit words. The default 396 route is represented by a prefix of length 0. 398 4.2. Prefix SID Sub-TLV 400 The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV. 401 It MAY appear more than once and has following format: 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Type | Length | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Flags | Reserved | MT-ID | Algorithm | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Range Size | Reserved + 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | SID/Index/Label (variable) | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 where: 417 Type: TBD, suggested value 2. 419 Length: variable 421 Flags: 1 octet field. The following flags are defined: 423 0 424 0 1 2 3 4 5 6 7 425 +-+-+-+-+-+-+-+-+ 426 |N|P|M|E|V|L| | 427 +-+-+-+-+-+-+-+-+ 429 where: 431 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 432 the router identified by the prefix. Typically, the N-Flag is 433 set on Prefix-SIDs attached to a router loopback address. The 434 N-Flag is set when the Prefix-SID is a Node- SID as described 435 in [I-D.filsfils-rtgwg-segment-routing]. 437 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 438 pop the Prefix-SID before delivering the packet to the node 439 that advertised the Prefix-SID. 441 M-Flag: Mapping Server Flag. If set, the SID is advertised 442 from the Segment Routing Mapping Server functionality as 443 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 445 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 446 the Prefix-SID originator MUST replace the Prefix-SID with a 447 Prefix-SID having an Explicit-NULL value (0 for IPv4) before 448 forwarding the packet. 450 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 451 carries an absolute value. If not set, then the Prefix-SID 452 carries an index. 454 The L-Flag: Local/Global Flag. If set, then the value/index 455 carried by the PrefixSID has local significance. If not set, 456 then the value/index carried by this subTLV has global 457 significance. 459 Other bits: MUST be zero when sent and ignored when received. 461 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 463 Algorithm: one octet identifying the algorithm the Prefix-SID is 464 associated with as defined in Section 3.1. 466 Range size: this field provides the ability to specify a range of 467 addresses and their associated Prefix SIDs. It represents a 468 compression scheme to distribute a continuous Prefix and their 469 continuous, corresponding SID/Label Block. If a single SID is 470 advertised then the Range Size field MUST be set to one. For 471 range advertisements > 1, Range Size represents the number of 472 addresses that need to be mapped into a Prefix-SID. 474 SID/Index/Label: according to the V and L flags, it contains 475 either: 477 A 32 bit index defining the offset in the SID/Label space 478 advertised by this router. 480 A 24 bit label where the 20 rightmost bits are used for 481 encoding the label value. 483 If multiple Prefix-SIDs are advertised for the same prefix, the 484 receiving router MUST use the first encoded SID and MAY use the 485 subsequent ones. 487 When propagating Prefix-SIDs between areas, if multiple prefix-SIDs 488 are advertised for a prefix, an implementation SHOULD preserve the 489 original ordering, when advertising prefix-SIDs to other areas. This 490 allows implementations that only use single Prefix-SID to have a 491 consistent view across areas. 493 When calculating the outgoing label for the prefix, the router MUST 494 take into account E and P flags advertised by the next-hop router, if 495 next-hop router advertised the SID for the prefix. This MUST be done 496 regardless of next-hop router contributing to the best path to the 497 prefix or not. 499 P-Flag (no-PHP) MUST be set on the Prefix-SIDs allocated to inter- 500 area prefixes that are originated by the ABR based on intra-area or 501 inter-area reachability between areas. In case the inter-area prefix 502 is generated based on the prefix which is directly attached to the 503 ABR, P-Flag SHOULD NOT be set 505 P-Flag (no-PHP) MUST NOT be set on the Prefix-SIDs allocated to 506 redistributed prefixes, unless the redistributed prefix is directly 507 attached to ASBR, in which case the P-Flag SHOULD NOT be set. 509 If the P-flag is not set then any upstream neighbor of the Prefix-SID 510 originator MUST pop the Prefix-SID. This is equivalent to the 511 penultimate hop popping mechanism used in the MPLS dataplane. In 512 such case MPLS EXP bits of the Prefix-SID are not preserved to the 513 ultimate hop (the Prefix-SID being removed). If the P-flag is unset 514 the received E-flag is ignored. 516 If the P-flag is set then: 518 If the E-flag is not set then any upstream neighbor of the Prefix- 519 SID originator MUST keep the Prefix-SID on top of the stack. This 520 is useful when the originator of the Prefix-SID must stitch the 521 incoming packet into a continuing MPLS LSP to the final 522 destination. This could occur at an inter-area border router 523 (prefix propagation from one area to another) or at an inter- 524 domain border router (prefix propagation from one domain to 525 another). 527 If the E-flag is set then any upstream neighbor of the Prefix-SID 528 originator MUST replace the PrefixSID with a Prefix-SID having an 529 Explicit-NULL value. This is useful, e.g., when the originator of 530 the Prefix-SID is the final destination for the related prefix and 531 the originator wishes to receive the packet with the original EXP 532 bits. 534 When M-Flag is set, P-flag MUST be set and E-bit MUST NOT be set. 536 Example 1: if the following router addresses (loopback addresses) 537 need to be mapped into the corresponding Prefix SID indexes: 539 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 540 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 541 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 542 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 544 then the Prefix field in Extended Prefix TLV would be set to 545 192.0.2.1, Prefix Length would be set to 32, Range Size in Prefix SID 546 sub-TLV would be 4 and Index value would be set to 1. 548 Example 2: If the following prefixes need to be mapped into the 549 corresponding Prefix-SID indexes: 551 10.1.1/24, Prefix-SID: Index 51 552 10.1.2/24, Prefix-SID: Index 52 553 10.1.3/24, Prefix-SID: Index 53 554 10.1.4/24, Prefix-SID: Index 54 555 10.1.5/24, Prefix-SID: Index 55 556 10.1.6/24, Prefix-SID: Index 56 557 10.1.7/24, Prefix-SID: Index 57 559 then the Prefix field in Extended Prefix TLV would be set to 560 10.1.1.0, Prefix Length would be set to 24, Range Size in Prefix SID 561 sub-TLV would be 7 and Index value would be set to 51. 563 4.3. SID/Label Binding sub-TLV 565 SID/Label Binding sub-TLV is used to advertise SID/Label mapping for 566 a path to the prefix. 568 The SID/Label Binding TLV MAY be originated by any router in an OSPF 569 domain. The router may advertise a SID/Label binding to a FEC along 570 with at least a single 'nexthop style' anchor. The protocol supports 571 more than one 'nexthop style' anchor to be attached to a SID/Label 572 binding, which results into a simple path description language. In 573 analogy to RSVP the terminology for this is called an 'Explicit Route 574 Object' (ERO). Since ERO style path notation allows to anchor SID/ 575 label bindings to both link and node IP addresses any label switched 576 path, can be described. Furthermore also SID/Label Bindings from 577 external protocols can get easily re-advertised. 579 The SID/Label Binding TLV may be used for advertising SID/Label 580 Bindings and their associated Primary and Backup paths. In one 581 single TLV either a primary ERO Path, a backup ERO Path or both are 582 advertised. If a router wants to advertise multiple parallel paths 583 then it can generate several TLVs for the same Prefix/FEC. Each 584 occurrence of a Binding TLV with respect with a given FEC Prefix has 585 accumulating and not canceling semantics. 587 SID/Label Binding sub-TLV is as sub-TLV of the OSPF Extended Prefix 588 TLV. Multiple SID/Label Binding TLVs can be present in OSPF Extended 589 Prefix TLV. SID/Label Binding sub-TLV has following format: 591 0 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Type | Length | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Flags | Reserved | MT-ID | Weight | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Range Size | Reserved + 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | Sub-TLVs (variable) | 601 +- -+ 602 | | 604 where: 606 Type: TBD, suggested value 3 608 Length: variable 610 Flags: 1 octet field of following flags: 612 0 1 2 3 4 5 6 7 613 +-+-+-+-+-+-+-+-+ 614 |M| | 615 +-+-+-+-+-+-+-+-+ 617 where: 619 M-bit - When the bit is set the binding represents the 620 mirroring context as defined in 621 [I-D.minto-rsvp-lsp-egress-fast-protection]. 623 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 625 Weight: weight used for load-balancing purposes. The use of the 626 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 628 Range Size: usage is the same as described in Section 4.2. 630 SID/Label Binding TLV currently supports following Sub-TLVs: 632 SID/Label sub-TLV as described in Section 2.1. This sub-TLV MUST 633 appear in the SID/Label Binding Sub-TLV and it MUST only appear 634 once. 636 ERO Metric sub-TLV as defined in Section 4.3.1. 638 ERO sub-TLVs as defined in Section 4.3.2. 640 4.3.1. ERO Metric sub-TLV 642 ERO Metric sub-TLV is a Sub-TLV of the SID/Label Binding TLV. 644 The ERO Metric sub-TLV carries the cost of an ERO path. It is used 645 to compare the cost of a given source/destination path. A router 646 SHOULD advertise the ERO Metric sub-TLV. The cost of the ERO Metric 647 sub-TLV SHOULD be set to the cumulative IGP or TE path cost of the 648 advertised ERO. Since manipulation of the Metric field may attract 649 or distract traffic from and to the advertised segment it MAY be 650 manually overridden. 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Type | Length | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Metric (4 octets) | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 ERO Metric sub-TLV format 662 where: 664 Type: TBD, suggested value 8 666 Length: 4 bytes 668 Metric: 4 bytes 670 4.3.2. ERO sub-TLVs 672 All 'ERO' information represents an ordered set which describes the 673 segments of a path. The last ERO sub-TLV describes the segment 674 closest to the egress point, contrary the first ERO sub-TLV describes 675 the first segment of a path. If a router extends or stitches a path 676 it MUST prepend the new segments path information to the ERO list. 678 The above similarly applies to backup EROs. 680 All ERO Sub-TLVs must immediately follow the (SID)/Label Sub-TLV. 682 All Backup sub-ERO TLVs must immediately follow last ERO Sub-TLV. 684 4.3.2.1. IPv4 ERO subTLV 686 IPv4 ERO sub-TLV is a Sub-TLV of the SID/Label Binding sub-TLV. 688 The IPv4 ERO sub-TLV describes a path segment using IPv4 Address 689 style of encoding. Its semantics have been borrowed from [RFC3209]. 691 0 1 2 3 692 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 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Type | Length | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Flags | Reserved | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | IPv4 Address (4 octets) | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 IPv4 ERO sub-TLV format 703 where: 705 Type: TBD, suggested value 4 707 Length: 8 bytes 709 Flags: 1 octet field of following flags: 711 0 1 2 3 4 5 6 7 712 +-+-+-+-+-+-+-+-+ 713 |L| | 714 +-+-+-+-+-+-+-+-+ 716 where: 718 L-bit - If the L bit is set, then the value of the attribute is 719 'loose.' Otherwise, the value of the attribute is 'strict.' 721 IPv4 Address - the address of the explicit route hop. 723 4.3.2.2. Unnumbered Interface ID ERO sub-TLV 725 Unnumbered Interface ID ERO sub-TLV is a Sub-TLV of the SID/Label 726 Binding sub-TLV. 728 The appearance and semantics of the 'Unnumbered Interface ID' have 729 been borrowed from [RFC3477]. 731 The Unnumbered Interface-ID ERO sub-TLV describes a path segment that 732 spans over an unnumbered interface. Unnumbered interfaces are 733 referenced using the interface index. Interface indices are assigned 734 local to the router and therefore not unique within a domain. All 735 elements in an ERO path need to be unique within a domain and hence 736 need to be disambiguated using a domain unique Router-ID. 738 0 1 2 3 739 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 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Type | Length | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Flags | Reserved | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Router ID | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Interface ID | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 where: 752 Unnumbered Interface ID ERO sub-TLV format 754 Type: TBD, suggested value 5 756 Length: 12 bytes 758 Flags: 1 octet field of following flags: 760 0 1 2 3 4 5 6 7 761 +-+-+-+-+-+-+-+-+ 762 |L| | 763 +-+-+-+-+-+-+-+-+ 765 where: 767 L-bit - If the L bit is set, then the value of the attribute is 768 'loose.' Otherwise, the value of the attribute is 'strict.' 770 Router-ID: Router-ID of the next-hop. 772 Interface ID: is the identifier assigned to the link by the router 773 specified by the Router-ID. 775 4.3.2.3. IPv4 Backup ERO sub-TLV 777 IPv4 Prefix Backup ERO sub-TLV is a Sub-TLV of the SID/Label Binding 778 sub-TLV. 780 The IPv4 Backup ERO sub-TLV describes a path segment using IPv4 781 Address style of encoding. Its semantics have been borrowed from 782 [RFC3209]. 784 0 1 2 3 785 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 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Type | Length | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Flags | Reserved | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | IPv4 Address (4 octets) | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 IPv4 Backup ERO sub-TLV format 796 where: 798 Type: TBD, suggested value 6 800 Length: 8 bytes 802 Flags: 1 octet field of following flags: 804 0 1 2 3 4 5 6 7 805 +-+-+-+-+-+-+-+-+ 806 |L| | 807 +-+-+-+-+-+-+-+-+ 809 where: 811 L-bit - If the L bit is set, then the value of the attribute is 812 'loose.' Otherwise, the value of the attribute is 'strict.' 814 IPv4 Address - the address of the explicit route hop. 816 4.3.2.4. Unnumbered Interface ID Backup ERO sub-TLV 818 Unnumbered Interface ID Backup -sub-TLV is a sub-TLV of the SID/Label 819 Binding sub-TLV. 821 The appearance and semantics of the 'Unnumbered Interface ID' have 822 been borrowed from [RFC3477]. 824 The Unnumbered Interface-ID ERO sub-TLV describes a path segment that 825 spans over an unnumbered interface. Unnumbered interfaces are 826 referenced using the interface index. Interface indices are assigned 827 local to the router and therefore not unique within a domain. All 828 elements in an ERO path need to be unique within a domain and hence 829 need to be disambiguated using a domain unique Router-ID. 831 0 1 2 3 832 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 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | Type | Length | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | Flags | Reserved | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | Router ID | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 840 | Interface ID | 841 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 Unnumbered Interface ID Backup ERO sub-TLV format 845 where: 847 Type: TBD, suggested value 7 849 Length: 12 bytes 851 Flags: 1 octet field of following flags: 853 0 1 2 3 4 5 6 7 854 +-+-+-+-+-+-+-+-+ 855 |L| | 856 +-+-+-+-+-+-+-+-+ 858 where: 860 L-bit - If the L bit is set, then the value of the attribute is 861 'loose.' Otherwise, the value of the attribute is 'strict.' 863 Router-ID: Router-ID of the next-hop. 865 Interface ID: is the identifier assigned to the link by the router 866 specified by the Router-ID. 868 5. Adjacency Segment Identifier (Adj-SID) 870 An Adjacency Segment Identifier (Adj-SID) represents a router 871 adjacency in Segment Routing. At the current stage of Segment 872 Routing architecture it is assumed that the Adj-SID value has local 873 significance (to the router). 875 5.1. OSPFv2 Extended Link Opaque LSA 877 A new Opaque LSA (defined in [RFC5250] is defined in OSPFv2 in order 878 to advertise additional link attributes: the OSPFv2 Extended Link 879 Opaque LSA. 881 The OSPFv2 Extended Link Opaque LSA has an area flooding scope. 882 Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a 883 single router in an area. 885 The format of the OSPFv2 Extended Link Opaque LSA is as follows: 887 0 1 2 3 888 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 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | LS age | Options | 10 | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | Opaque type | Instance | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Advertising Router | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | LS sequence number | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | LS checksum | length | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | | 901 +- TLVs -+ 902 | ... | 904 Opaque type used by OSPFv2 Extended Link Opaque LSA is 8. 906 The format of the TLVs within the body of LSA is the same as the 907 format used by the Traffic Engineering Extensions to OSPF defined in 908 [RFC3630]. The LSA payload consists of one or more nested 909 Type/Length/Value (TLV) triplets. The format of each TLV is: 911 0 1 2 3 912 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 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 | Type | Length | 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 | Value... | 917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 The Length field defines the length of the value portion in octets. 920 The TLV is padded to 4-octet alignment; padding is not included in 921 the length field. Nested TLVs are also 32-bit aligned. Unrecognized 922 types are ignored. 924 5.2. OSPFv2 Extended Link TLV 926 OSPFv2 Extended Link TLV is used in order to advertise various 927 attributes of the link. It describes a single link and is 928 constructed of a set of Sub-TLVs. There are no ordering requirements 929 for the Sub-TLVs. Only one Extended Link TLV SHALL be carried in 930 each Extended Link Opaque LSA, allowing for fine granularity changes 931 in the topology. 933 The Extended Link TLV has following format: 935 0 1 2 3 936 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 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Type | Length | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | Link-Type | Reserved | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Link ID | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Link Data | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | Sub-TLVs (variable) | 947 +- -+ 948 | | 950 where: 952 Type is 1. 954 Length is variable. 956 Link-Type: as defined in section A.4.2 of [RFC2328]. 958 Link-ID: as defined in section A.4.2 of [RFC2328]. 960 Link Data: as defined in section A.4.2 of [RFC2328]. 962 5.3. Adj-SID sub-TLV 964 Adj-SID is an optional Sub-TLV of the Extended Link TLV. It MAY 965 appear multiple times in Extended Link TLV. Examples where more than 966 one Adj-SID may be used per neighbor are described in 967 [I-D.filsfils-rtgwg-segment-routing-use-cases]. The structure of the 968 Adj-SID Sub-TLV is as follows: 970 0 1 2 3 971 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 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 | Type | Length | 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Flags | Reserved | MT-ID | Weight | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | SID/Label/Index (variable) | 978 +---------------------------------------------------------------+ 980 where: 982 Type: TBD, suggested value 2. 984 Length: variable. 986 Flags. 1 octet field of following flags: 988 0 1 2 3 4 5 6 7 989 +-+-+-+-+-+-+-+-+ 990 |B|V|L|S| | 991 +-+-+-+-+-+-+-+-+ 993 where: 995 B-Flag: Backup-flag: set if the Adj-SID refer to an adjacency 996 being protected (e.g.: using IPFRR or MPLS-FRR) as described in 997 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 999 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 1000 carries an absolute value. If not set, then the Prefix-SID 1001 carries an index. 1003 The L-Flag: Local/Global Flag. If set, then the value/index 1004 carried by the PrefixSID has local significance. If not set, 1005 then the value/index carried by this subTLV has global 1006 significance. 1008 The S-Flag. Set Flag. When set, the S-Flag indicates that the 1009 Adj-SID refers to a set of adjacencies (and therefore MAY be 1010 assigned to other adjacencies as well). 1012 Other bits: MUST be zero when originated and ignored when 1013 received. 1015 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 1017 Weight: weight used for load-balancing purposes. The use of the 1018 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 1020 SID/Index/Label: according to the V and L flags, it contains 1021 either: 1023 A 32 bit index defining the offset in the SID/Label space 1024 advertised by this router. 1026 A 24 bit label where the 20 rightmost bits are used for 1027 encoding the label value. 1029 A SR capable router MAY allocate an Adj-SID for each of its 1030 adjacencies and set the B-Flag when the adjacency is protected by a 1031 FRR mechanism (IP or MPLS) as described in 1032 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 1034 5.4. LAN Adj-SID Sub-TLV 1036 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV. It MAY 1037 appear multiple times in Extended Link TLV. It is used to advertise 1038 SID/Label for adjacency to non-DR node on broadcast or NBMA network. 1040 0 1 2 3 1041 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 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | Type | Length | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 | Flags | Reserved | MT-ID | Weight | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | Neighbor ID | 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | SID/Label/Index (variable) | 1050 +---------------------------------------------------------------+ 1052 where: 1054 Type: TBD, suggested value 3. 1056 Length: variable. 1058 Flags. 1 octet field of following flags: 1060 0 1 2 3 4 5 6 7 1061 +-+-+-+-+-+-+-+-+ 1062 |B|V|L|S| | 1063 +-+-+-+-+-+-+-+-+ 1065 where: 1067 B-Flag: Backup-flag: set if the LAN-Adj-SID refer to an 1068 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 1069 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 1071 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 1072 carries an absolute value. If not set, then the Prefix-SID 1073 carries an index. 1075 The L-Flag: Local/Global Flag. If set, then the value/index 1076 carried by the PrefixSID has local significance. If not set, 1077 then the value/index carried by this subTLV has global 1078 significance. 1080 The S-Flag. Set Flag. When set, the S-Flag indicates that the 1081 Adj-SID refers to a set of adjacencies (and therefore MAY be 1082 assigned to other adjacencies as well). 1084 Other bits: MUST be zero when originated and ignored when 1085 received. 1087 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 1089 Weight: weight used for load-balancing purposes. The use of the 1090 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 1092 SID/Index/Label: according to the V and L flags, it contains 1093 either: 1095 A 32 bit index defining the offset in the SID/Label space 1096 advertised by this router. 1098 A 24 bit label where the 20 rightmost bits are used for 1099 encoding the label value. 1101 6. Elements of Procedure 1103 6.1. Intra-area Segment routing in OSPFv2 1105 The OSPFv2 node that supports segment routing MAY advertise Prefix- 1106 SIDs for any prefix that it is advertising reachability for (e.g. 1107 loopback IP address) as described in Section 4.2. 1109 If multiple routers advertise Prefix-SID for the same prefix, then 1110 the Prefix-SID MUST be the same. This is required in order to allow 1111 traffic load-balancing if multiple equal cost paths to the 1112 destination exist in the network. 1114 Prefix-SID can also be advertised by the SR Mapping Servers (as 1115 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]). The 1116 Mapping Server advertise Prefix-SID for remote prefixes that exist in 1117 the network. Multiple Mapping Servers can advertise Prefix-SID for 1118 the same prefix, in which case the same Prefix-SID MUST be advertised 1119 by all of them. Flooding scope of the OSPF Extended Prefix Opaque 1120 LSA that is generated by the SR Mapping Server could be either area 1121 scope or autonomous system scope and is decided based on the 1122 configuration of the SR Mapping Server. 1124 6.2. Inter-area Segment routing in OSPFv2 1126 In order to support SR in a multi-area environment, OSPFv2 must 1127 propagate Prefix-SID information between areas. The following 1128 procedure is used in order to propagate Prefix SIDs between areas. 1130 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 1131 prefix to all its connected areas, it will also originate an Extended 1132 Prefix Opaque LSA, as described in Section 4. The flooding scope of 1133 the Extended Prefix Opaque LSA type will be set to area-scope. The 1134 route-type in OSPF Extended Prefix TLV is set to inter-area. The 1135 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 1136 value will be set as follows: 1138 The ABR will look at its best path to the prefix in the source 1139 area and find out the advertising router associated with its best 1140 path to that prefix. 1142 If no Prefix-SID was advertised for the prefix in the source area 1143 by the router that contributes to the best path to the prefix, 1144 then the ABR will use the Prefix-SID advertised by any other 1145 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 1146 defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when 1147 propagating Prefix-SID for the prefix to other areas. 1149 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 1150 route to all its connected areas it will also originate an Extended 1151 Prefix Opaque LSA, as described in Section 4. The flooding scope of 1152 the Extended Prefix Opaque LSA type will be set to area-scope. The 1153 route-type in OSPF Extended Prefix TLV is set to inter-area. The 1154 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 1155 will be set as follows: 1157 The ABR will look at its best path to the prefix in the source 1158 area and find out the advertising router associated with its best 1159 path to that prefix. 1161 The ABR will then look if such router advertised a Prefix-SID for 1162 the prefix and use it when advertising the Prefix-SID to other 1163 connected areas. 1165 If no Prefix-SID was advertised for the prefix in the source area 1166 by the ABR that contributes to the best path to the prefix, the 1167 originating ABR will use the Prefix-SID advertised by any other 1168 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 1169 defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when 1170 propagating Prefix-SID for the prefix to other areas. 1172 6.3. SID for External Prefixes 1174 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 1175 SR, generates Type-5 LSAs, it should also originate Extended Prefix 1176 Opaque LSAs, as described in Section 4. The flooding scope of the 1177 Extended Prefix Opaque LSA type is set to AS-scope. The route-type 1178 in OSPF Extended Prefix TLV is set to external. Prefix-SID Sub-TLV 1179 is included in this LSA and the Prefix-SID value will be set to the 1180 SID that has been reserved for that prefix. 1182 When a NSSA ASBR translates Type-7 LSAs into Type-5 LSAs, it should 1183 also advertise the Prefix-SID for the prefix. The NSSA ABR 1184 determines its best path to the prefix advertised in the translated 1185 Type-7 LSA and finds the advertising router associated with such 1186 path. If such advertising router has advertised a Prefix-SID for the 1187 prefix, then the NSSA ASBR uses it when advertising the Prefix-SID 1188 for the Type-5 prefix. Otherwise the Prefix-SID advertised by any 1189 other router will be used (e.g.: a Prefix-SID coming from an SR 1190 Mapping Server as defined in 1191 [I-D.filsfils-rtgwg-segment-routing-use-cases]). 1193 6.4. Advertisement of Adj-SID 1195 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 1196 using the Adj-SID Sub-TLV as described in Section 5. 1198 6.4.1. Advertisement of Adj-SID on Point-to-Point Links 1200 Adj-SID MAY be advertised for any adjacency on p2p link that is in a 1201 state 2-Way or higher. If the adjacency on a p2p link transitions 1202 from the FULL state, then the Adj-SID for that adjacency MAY be 1203 removed from the area. If the adjacency transitions to a state lower 1204 then 2-Way, then the Adj-SID MUST be removed from the area. 1206 6.4.2. Adjacency SID on Broadcast or NBMA Interfaces 1208 Broadcast or NBMA networks in OSPF are represented by a star topology 1209 where the Designated Router (DR) is the central point all other 1210 routers on the broadcast or NBMA network connect to. As a result, 1211 routers on the broadcast or NBMA network advertise only their 1212 adjacency to DR and BDR. Routers that are neither DR nor BDR do not 1213 form and do not advertise adjacencies between them. They, however, 1214 maintain a 2-Way adjacency state between them. 1216 When Segment Routing is used, each router on the broadcast or NBMA 1217 network MAY advertise the Adj-SID for its adjacency to DR using Adj- 1218 SID Sub-TLV as described in Section 5.3. 1220 SR capable router MAY also advertise Adj-SID for other neighbors 1221 (e.g. BDR, DR-OTHER) on broadcast or NBMA network using the LAN ADJ- 1222 SID Sub-TLV as described in section 5.1.1.2. Section 5.4. 1224 7. IANA Considerations 1226 This specification updates two existing OSPF registries. 1228 Opaque Link-State Advertisements (LSA) Option Types: 1230 o suggested value 7 - OSPFv2 Extended Prefix Opaque LSA 1232 o suggested value 8 - OSPFv2 Extended Link Opaque LSA 1234 OSPF Router Information (RI) TLVs: 1236 o suggested value 8 - SR-Algorithm TLV 1238 o suggested value 9 - SID/Label Range TLV 1240 This specification also creates four new registries: 1242 - OSPF Extended Prefix LSA TLVs and sub-TLVs 1244 - OSPF Extended Link LSA TLVs and sub-TLVs 1246 7.1. OSPF Extend Prefix LSA TLV Registry 1248 The OSPF Extend Prefix LSA TLV registry will define top-level TLVs 1249 for Extended Prefix LSAs and should be placed in the existing OSPF 1250 IANA registry. New values can be allocated via IETF Consensus or 1251 IESG Approval. 1253 Following initial values are allocated: 1255 o 0 - Reserved 1257 o 1 - OSPF Extended Prefix TLV 1259 Types in the range 32768-32023 are for experimental use; these will 1260 not be registered with IANA, and MUST NOT be mentioned by RFCs. 1262 Types in the range 32023-65535 are not to be assigned at this time. 1263 Before any assignments can be made in this range, there MUST be a 1264 Standards Track RFC that specifies IANA Considerations that covers 1265 the range being assigned. 1267 7.2. OSPF Extend Prefix LSA sub-TLV Registry 1269 The OSPF Extended Prefix sub-TLV registry will define will define 1270 sub-TLVs at any level of nesting for Extended Prefix LSAs and should 1271 be placed in the existing OSPF IANA registry. New values can be 1272 allocated via IETF Consensus or IESG Approval. 1274 Following initial values are allocated: 1276 o 0 - Reserved 1278 o 1 - SID/Label sub-TLV 1280 o 2 - Prefix SID sub-TLV 1282 o 3 - SID/Label Binding sub-TLV 1284 o 4 - IPv4 ERO sub-TLV 1286 o 5 - Unnumbered Interface ID ERO sub-TLV 1288 o 6 - IPv4 Backup ERO sub-TLV 1289 o 7 - Unnumbered Interface ID Backup ERO sub-TLV 1291 o 8 - ERO Metric sub-TLV 1293 Types in the range 32768-32023 are for experimental use; these will 1294 not be registered with IANA, and MUST NOT be mentioned by RFCs. 1296 Types in the range 32023-65535 are not to be assigned at this time. 1297 Before any assignments can be made in this range, there MUST be a 1298 Standards Track RFC that specifies IANA Considerations that covers 1299 the range being assigned. 1301 7.3. OSPF Extend Link LSA TLV Registry 1303 The OSPF Extend Link LSA TLV registry will define top-level TLVs for 1304 Extended Link LSAs and should be placed in the existing OSPF IANA 1305 registry. New values can be allocated via IETF Consensus or IESG 1306 Approval. 1308 Following initial values are allocated: 1310 o 0 - Reserved 1312 o 1 - OSPFv2 Extended Link TLV 1314 Types in the range 32768-32023 are for experimental use; these will 1315 not be registered with IANA, and MUST NOT be mentioned by RFCs. 1317 Types in the range 32023-65535 are not to be assigned at this time. 1318 Before any assignments can be made in this range, there MUST be a 1319 Standards Track RFC that specifies IANA Considerations that covers 1320 the range being assigned. 1322 7.4. OSPF Extend Link LSA sub-TLV Registry 1324 The OSPF Extended Link LSA sub-TLV registry will define will define 1325 sub-TLVs at any level of nesting for Extended Link LSAs and should be 1326 placed in the existing OSPF IANA registry. New values can be 1327 allocated via IETF Consensus or IESG Approval. 1329 Following initial values are allocated: 1331 o 1 - SID/Label sub-TLV 1333 o 2 - Adj-SID sub-TLV 1335 o 3 - LAN Adj-SID/Label Sub-TLV 1336 Types in the range 32768-32023 are for experimental use; these will 1337 not be registered with IANA, and MUST NOT be mentioned by RFCs. 1339 Types in the range 32023-65535 are not to be assigned at this time. 1340 Before any assignments can be made in this range, there MUST be a 1341 Standards Track RFC that specifies IANA Considerations that covers 1342 the range being assigned. 1344 8. Security Considerations 1346 In general, new LSAs defined in this document are subject to the same 1347 security concerns as those described in [RFC2328]. Additionally, 1348 implementations must assure that malformed TLV and Sub-TLV 1349 permutations do not result in errors which cause hard OSPF failures. 1351 9. Contributors 1353 The following people gave a substantial contribution to the content 1354 of this document: Ahmed Bashandy, Martin Horneffer, Bruno Decraene, 1355 Stephane Litkowski, Igor Milojevic, Rob Shakir and Saku Ytti. 1357 10. Acknowledgements 1359 We would like to thank Anton Smirnov for his contribution. 1361 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1362 contribution on earlier incarnations of the "Binding / MPLS Label 1363 TLV" in [I-D.gredler-ospf-label-advertisement]. 1365 11. References 1367 11.1. Normative References 1369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1370 Requirement Levels", BCP 14, RFC 2119, March 1997. 1372 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1374 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1375 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1376 Tunnels", RFC 3209, December 2001. 1378 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1379 in Resource ReSerVation Protocol - Traffic Engineering 1380 (RSVP-TE)", RFC 3477, January 2003. 1382 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1383 (TE) Extensions to OSPF Version 2", RFC 3630, September 1384 2003. 1386 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1387 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 1388 4915, June 2007. 1390 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 1391 Shaffer, "Extensions to OSPF for Advertising Optional 1392 Router Capabilities", RFC 4970, July 2007. 1394 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1395 OSPF Opaque LSA Option", RFC 5250, July 2008. 1397 11.2. Informative References 1399 [I-D.filsfils-rtgwg-segment-routing] 1400 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1401 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1402 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1403 "Segment Routing Architecture", draft-filsfils-rtgwg- 1404 segment-routing-01 (work in progress), October 2013. 1406 [I-D.filsfils-rtgwg-segment-routing-use-cases] 1407 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1408 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1409 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1410 Crabbe, "Segment Routing Use Cases", draft-filsfils-rtgwg- 1411 segment-routing-use-cases-02 (work in progress), October 1412 2013. 1414 [I-D.gredler-ospf-label-advertisement] 1415 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1416 "Advertising MPLS labels in OSPF", draft-gredler-ospf- 1417 label-advertisement-03 (work in progress), May 2013. 1419 [I-D.minto-rsvp-lsp-egress-fast-protection] 1420 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1421 egress fast-protection", draft-minto-rsvp-lsp-egress-fast- 1422 protection-03 (work in progress), November 2013. 1424 Authors' Addresses 1425 Peter Psenak (editor) 1426 Cisco Systems, Inc. 1427 Apollo Business Center 1428 Mlynske nivy 43 1429 Bratislava 821 09 1430 Slovakia 1432 Email: ppsenak@cisco.com 1434 Stefano Previdi (editor) 1435 Cisco Systems, Inc. 1436 Via Del Serafico, 200 1437 Rome 00142 1438 Italy 1440 Email: sprevidi@cisco.com 1442 Clarence Filsfils 1443 Cisco Systems, Inc. 1444 Brussels 1445 Belgium 1447 Email: cfilsfil@cisco.com 1449 Hannes Gredler 1450 Juniper Networks, Inc. 1451 1194 N. Mathilda Ave. 1452 Sunnyvale, CA 94089 1453 US 1455 Email: hannes@juniper.net 1457 Rob Shakir 1458 British Telecom 1459 London 1460 UK 1462 Email: rob.shakir@bt.com 1463 Wim Henderickx 1464 Alcatel-Lucent 1465 Copernicuslaan 50 1466 Antwerp 2018 1467 BE 1469 Email: wim.henderickx@alcatel-lucent.com 1471 Jeff Tantsura 1472 Ericsson 1473 300 Holger Way 1474 San Jose, CA 95134 1475 US 1477 Email: Jeff.Tantsura@ericsson.com