idnits 2.17.1 draft-psenak-ospf-segment-routing-extensions-01.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 (July 1, 2013) is 3952 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) ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) == Outdated reference: A later version (-01) exists of draft-filsfils-rtgwg-segment-routing-00 == Outdated reference: A later version (-02) exists of draft-filsfils-rtgwg-segment-routing-use-cases-00 == Outdated reference: A later version (-03) exists of draft-minto-rsvp-lsp-egress-fast-protection-02 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: January 2, 2014 Cisco Systems, Inc. 6 H. Gredler 7 Juniper Networks, Inc. 8 R. Shakir 9 British Telecom 10 July 1, 2013 12 OSPF Extensions for Segment Routing 13 draft-psenak-ospf-segment-routing-extensions-01 15 Abstract 17 Segment Routing (SR) allows for a flexible definition of end-to-end 18 paths within IGP topologies by encoding paths as sequences of 19 topological sub-paths, called "segments". These segments are 20 advertised by the link-state routing protocols (IS-IS and OSPF). 22 This draft describes the necessary OSPF extensions that need to be 23 introduced for Segment Routing. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 2, 2014. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 66 2.1. SID/Label TLV . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Segment Routing Capabilities . . . . . . . . . . . . . . . . . 4 68 3.1. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . . . . 4 69 3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 5 70 4. OSPFv2 Extended Prefix Opaque LSA type . . . . . . . . . . . . 6 71 4.1. OSPF Extended Prefix TLV . . . . . . . . . . . . . . . . . 7 72 4.2. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . 8 73 4.3. SID/Label Binding TLV . . . . . . . . . . . . . . . . . . 9 74 4.3.1. ERO TLVs . . . . . . . . . . . . . . . . . . . . . . . 11 75 5. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . . 15 76 5.1. OSPFv2 Extended Link Opaque LSA . . . . . . . . . . . . . 15 77 5.2. OSPFv2 Extended Link TLV . . . . . . . . . . . . . . . . . 16 78 5.3. Adj-SID sub-TLV . . . . . . . . . . . . . . . . . . . . . 17 79 5.4. LAN Adj-SID/Label Sub-TLV . . . . . . . . . . . . . . . . 18 80 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19 81 6.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . . 19 82 6.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . . 20 83 6.3. SID for External Prefixes . . . . . . . . . . . . . . . . 21 84 6.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . . 21 85 6.4.1. Advertisement of Adj-SID on Point-to-Point Links . . . 21 86 6.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 21 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 88 8. Manageability Considerations . . . . . . . . . . . . . . . . . 22 89 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 90 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 91 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 92 11.1. Normative References . . . . . . . . . . . . . . . . . . . 22 93 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 96 1. Introduction 98 Segment Routing (SR) allows for a flexible definition of end-to-end 99 paths within IGP topologies by encoding paths as sequences of 100 topological sub-paths, called "segments". These segments are 101 advertised by the link-state routing protocols (IS-IS and OSPF). 102 Prefix segments represent an ecmp-aware shortest-path to a prefix (or 103 a node), as per the state of the IGP topology. Adjacency segments 104 represent a hop over a specific adjacency between two nodes in the 105 IGP. A prefix segment is typically a multi-hop path while an 106 adjacency segment, in most of the cases, is a one-hop path. SR's 107 control-plane can be applied to both IPv6 and MPLS data-planes, and 108 do not require any additional signaling (other than the regular IGP). 109 For example, when used in MPLS networks, SR paths do not require any 110 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 111 of LSPs established with RSVP or LDP . 113 This draft describes the necessary OSPF extensions that need to be 114 introduced for Segment Routing. 116 Segment Routing architecture is described in 117 [I-D.filsfils-rtgwg-segment-routing]. 119 Segment Routing use cases are described in 120 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 122 2. Segment Routing Identifiers 124 Segment Routing defines various types of Segment Identifiers (SIDs): 125 Prefix-SID, Adjacency-SID, LAN Adjacency SID and Binding SID. 127 For the purpose of the advertisements of various SID values new 128 Opaque LSAs (defined in [RFC5250]) are defined. These new LSAs are 129 defined as generic containers that can be used in order to advertise 130 any additional attributes associated with the prefix or link. These 131 new Opaque LSAs are complementary to the existing LSAs and are not 132 aimed to replace any of the existing LSAs. 134 2.1. SID/Label TLV 136 SID/Label TLV appears as Sub-TLV in multiple TLVs or Sub-TLVs defined 137 later in this document. It is used to advertise SID or label 138 associated with the prefix or adjacency. SID/Lable TLV has following 139 format: 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Type | Length | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | SID/Label (variable) | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 where: 151 Type: TBA 153 Length: variable, 3 or 4 bytes 155 SID/Label: if length is set to 3, then the 20 rightmost bits 156 represent a label. If length is set to 4 then the value 157 represents a 32 bit SID. 159 3. Segment Routing Capabilities 161 Segment Routing requires some additional capabilities of the router 162 to be advertised to other routers in the area. 164 These SR capabilities are advertised in Router Information Opaque LSA 165 (defined in [RFC4970]). 167 3.1. SR-Algorithm TLV 169 SR-Algorithm TLV is a TLV of Router Information Opaque LSA (defined 170 in [RFC4970]). 172 Router may use various algorithms when calculating reachability to 173 other nodes in area or to prefixes attached to these nodes. Examples 174 of these algorithms are metric based Shortest Path First (SPF), 175 various sorts of Constrained SPF, etc. SR-Algorithm TLV allows a 176 router to advertise algorithms that router is currently using to 177 other routers in an area. SR-Algorithm TLV has following structure: 179 0 1 2 3 180 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 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Type | Length | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Algorithm 1 | Algorithm... | Algorithm n | | 185 +- -+ 186 | | 187 + + 189 where: 191 Type: TBA 193 Length: variable 195 Algorithm: one octet identifying the algorithm. The following 196 value has been defined: 198 0: IGP metric based SPT. 200 RI LSA can be advertised at any of the defined flooding scopes (link, 201 area, or autonomous system (AS)). For the purpose of the SR- 202 Algorithm TLV propagation area scope flooding is required. 204 3.2. SID/Label Range TLV 206 The SID/Label Range TLV is a TLV of Router Information Opaque LSA 207 (defined in [RFC4970]). 209 SID/Label Sub-TLV MAY appear multiple times and has following format: 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Type | Length | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Range Size | Reserved | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Sub-TLVs (variable) | 219 +- -+ 220 | | 221 + + 223 where: 225 Type: TBA 227 Length: variable 229 Range Size: size of the SID/label range 231 Currently the only supported Sub-TLV is the SID/Label TLV as defined 232 in Section 2.1. SID/Label advertised in SID/Label TLV represents the 233 first SID/Label from the advertised range. 235 RI LSA can be advertised at any of the defined flooding scopes (link, 236 area, or autonomous system (AS)). For the purpose of the SR- 237 Capability TLV propagation area scope flooding is required. 239 4. OSPFv2 Extended Prefix Opaque LSA type 241 A new Opaque LSA (defined in [RFC5250]) is defined in OSPFv2 in order 242 to advertise additional prefix attributes: OSPFv2 Extended Prefix 243 Opaque LSA. 245 Multiple OSPFv2 Extended Prefix Opaque LSAs can be advertised by a 246 single router. Flooding scope of the OSPFv2 Extended Prefix Opaque 247 LSA depends on the content inside the LSA and is in control of the 248 originating router. 250 The format of the OSPFv2 Extended Prefix Opaque LSA is as follows: 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | LS age | Options | 9, 10, or 11 | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Opaque type | Instance | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Advertising Router | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | LS sequence number | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | LS checksum | length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | | 266 +- TLVs -+ 267 | ... | 269 Opaque type used by OSPFv2 Extended Prefix Opaque LSA is TBA. 271 The format of the TLVs within the body of the LSA is the same as the 272 format used by the Traffic Engineering Extensions to OSPF defined in 273 [RFC3630]. The LSA payload consists of one or more nested Type/ 274 Length/Value (TLV) triplets. The format of each TLV is: 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 | Value... | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 The Length field defines the length of the value portion in octets. 285 The TLV is padded to 4-octet alignment; padding is not included in 286 the length field. Nested TLVs are also 32-bit aligned. Unrecognized 287 types are ignored. 289 4.1. OSPF Extended Prefix TLV 291 The OSPF Extended Prefix TLV is used in order to advertise additional 292 attributes associated with the prefix. Multiple OSPF Extended Prefix 293 TLVs MAY be carried in each OSPFv2 Extended Prefix Opaque LSA, 294 however all prefixes included in the single OSPFv2 Extended Prefix 295 Opaque LSA MUST have the same flooding scope. The structure of the 296 OSPF Extended Prefix TLV is as follows: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Type | Length | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Route Type | Prefix Length | AF | Reserved | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Address Prefix (variable) | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Sub-TLVs (variable) | 308 +- -+ 309 | | 311 where: 313 Type is TBA. 315 Length is variable 316 Route type: type of the OSPF route. Supported types are: 318 0 - unspecified 319 1 - intra-area 320 3 - inter-area 321 5 - external 322 7 - NSSA external 323 If the route type is 0 (unspecified) the information inside the 324 OSPF External Prefix TLV applies to the prefix regardless of what 325 route-type it is. This is useful when some prefix specific 326 attributes are advertised by some external entity, which is not 327 aware of the route-type associated with the prefix. 329 Prefix length: length of the prefix 331 AF: 0 - IPv4 unicast 333 Address Prefix: the prefix itself encoded as an even multiple of 334 32-bit words, padded with zeroed bits as necessary. This encoding 335 consumes ((PrefixLength + 31) / 32) 32-bit words. The default 336 route is represented by a prefix of length 0. 338 4.2. Prefix SID Sub-TLV 340 The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV. 341 It MAY appear more than once and has following format: 343 0 1 2 3 344 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 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Type | Length | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Flags | MT-ID | Algorithm | Reserved | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Index | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 where: 355 Type: TBA. 357 Length: A 16-bit field that indicates the length of the value 358 portion in octets. Set to 8. 360 Flags: 1 octet field. The following flags are defined: 362 0 363 0 1 2 3 4 5 6 7 364 +-+-+-+-+-+-+-+-+ 365 |N|P|M| | 366 +-+-+-+-+-+-+-+-+ 368 where: 370 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 371 the router identified by the prefix. Typically, the N-Flag is 372 set on Prefix-SIDs attached to a router loopback address. The 373 N-Flag is set when the Prefix-SID is a Node- SID as described 374 in [I-D.filsfils-rtgwg-segment-routing]. 376 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 377 pop the Prefix-SID before delivering the packet to the node 378 that advertised the Prefix-SID. 380 M-Flag: Mapping Server Flag. If set, the SID is advertised 381 from the Segment Routing Mapping Server functionality as 382 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 384 Other bits: MUST be zero when sent and ignored when received. 386 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 388 Algorithm: one octet identifying the algorithm the Prefix-SID is 389 associated with as defined in Section 3.1. 391 Index: 32 bits representing the offset to the advertised SID/Label 392 range. 394 If multiple Prefix-SIDs are advertised for the same prefix, the 395 receiving router MUST use the first encoded SID and MAY use the 396 subsequent ones. 398 PHP flag MUST NOT be set on the Prefix-SIDs allocated to inter- area 399 prefixes that are originated by the router based on intra-area or 400 inter-area reachability between areas. 402 4.3. SID/Label Binding TLV 404 SID/Label Binding TLV is used to advertise SID/Label mapping for a 405 prefix or a path to the prefix. SID/Label value advertised in this 406 TLV has local significance (to the router). 408 SID/Label Binding TLV is a Sub-TLV of the OSPF Extended Prefix TLV. 409 Multiple SID/Label Binding TLVs can be present in OSPF Extended 410 Prefix TLV. SID/Label Binding TLV has following format: 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Type | Length | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Flags | MT-ID | Weight | Reserved | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Sub-TLVs (variable) | 420 +- -+ 421 | | 423 where: 425 Type: TBA 427 Length: variable 429 Flags: 1 octet field of following flags: 431 0 1 2 3 4 5 6 7 432 +-+-+-+-+-+-+-+-+ 433 |M| | 434 +-+-+-+-+-+-+-+-+ 436 where: 438 M-bit - When the bit is set the binding represents the 439 mirroring context as defined in 440 [I-D.minto-rsvp-lsp-egress-fast-protection]. 442 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 444 Weight: weight used for load-balancing purposes. The use of the 445 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 447 SID/Label Binding TLV currently supports following Sub-TLVs: 449 SID/Lable TLV as described in Section 2.1. This TLV MUST appear 450 in the SID/Label Binding Sub-TLV and it MUST only appear once. 452 ERO TLVs as defined in Section 4.3.1. 454 4.3.1. ERO TLVs 456 All 'ERO' information represents an ordered set which describes the 457 segments of a path. The last ERO TLV describes the segment closest 458 to the egress point, contrary the first ERO TLV describes the first 459 segment of a path. If a router extends or stitches a path it MUST 460 prepend the new segments path information to the ERO list. 462 The above similarly applies to backup EROs. 464 All ERO Sub-TLVs must immediately follow the (SID)/Label Sub-TLV. 466 All Backup ERO TLVs must immediately follow last ERO Sub-TLV. 468 4.3.1.1. IPv4 ERO TLV 470 IPv4 ERO TLV is a Sub-TLV of the SID/Lable Binding TLV. 472 The IPv4 ERO TLV describes a path segment using IPv4 Address style of 473 encoding. Its semantics have been borrowed from [RFC3209]. 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Type | Length | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Flags | Reserved | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | IPv4 Address (4 octets) | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 IPv4 ERO TLV format 487 where: 489 Type: TBA 491 Length: 8 bytes 493 Flags: 1 octet field of following flags: 495 0 1 2 3 4 5 6 7 496 +-+-+-+-+-+-+-+-+ 497 |L| | 498 +-+-+-+-+-+-+-+-+ 500 where: 502 L-bit - If the L bit is set, then the value of the attribute is 503 'loose.' Otherwise, the value of the attribute is 'strict.' 505 IPv4 Address - the address of the explicit route hop. 507 4.3.1.2. Unnumbered Interface ID ERO TLV 509 Unnumbered Interface ID ERO TLV is a Sub-TLV of the SID/Lable Binding 510 TLV. 512 The appearance and semantics of the 'Unnumbered Interface ID' have 513 been borrowed from [RFC3477]. 515 The Unnumbered Interface-ID ERO TLV describes a path segment that 516 spans over an unnumbered interface. Unnumbered interfaces are 517 referenced using the interface index. Interface indices are assigned 518 local to the router and therefore not unique within a domain. All 519 elements in an ERO path need to be unique within a domain and hence 520 need to be disambiguated using a domain unique Router-ID. 522 0 1 2 3 523 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 524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 | Type | Length | 526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 527 | Flags | Reserved | 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Router ID | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Interface ID | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 where: 536 Unnumbered Interface ID ERO TLV format 538 Type: TBA 540 Length: 12 bytes 542 Flags: 1 octet field of following flags: 544 0 1 2 3 4 5 6 7 545 +-+-+-+-+-+-+-+-+ 546 |L| | 547 +-+-+-+-+-+-+-+-+ 549 where: 551 L-bit - If the L bit is set, then the value of the attribute is 552 'loose.' Otherwise, the value of the attribute is 'strict.' 554 Router-ID: Router-ID of the next-hop. 556 Interface ID: is the identifier assigned to the link by the router 557 specified by the Router-ID. 559 4.3.1.3. IPv4 Backup ERO TLV 561 IPv4 Prefix Backup ERO TLV is a Sub-TLV of the SID/Lable Binding TLV. 563 The IPv4 Backup ERO TLV describes a path segment using IPv4 Address 564 style of encoding. Its semantics have been borrowed from [RFC3209]. 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Type | Length | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Flags | Reserved | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | IPv4 Address (4 octets) | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 IPv4 Backup ERO TLV format 578 where: 580 Type: TBA 582 Length: 8 bytes 584 Flags: 1 octet field of following flags: 586 0 1 2 3 4 5 6 7 587 +-+-+-+-+-+-+-+-+ 588 |L| | 589 +-+-+-+-+-+-+-+-+ 591 where: 593 L-bit - If the L bit is set, then the value of the attribute is 594 'loose.' Otherwise, the value of the attribute is 'strict.' 596 IPv4 Address - the address of the explicit route hop. 598 4.3.1.4. Unnumbered Interface ID Backup ERO TLV 600 Unnumbered Interface ID Backup TLV is a Sub-TLV of the SID/Lable 601 Binding TLV. 603 The appearance and semantics of the 'Unnumbered Interface ID' have 604 been borrowed from [RFC3477]. 606 The Unnumbered Interface-ID ERO TLV describes a path segment that 607 spans over an unnumbered interface. Unnumbered interfaces are 608 referenced using the interface index. Interface indices are assigned 609 local to the router and therefore not unique within a domain. All 610 elements in an ERO path need to be unique within a domain and hence 611 need to be disambiguated using a domain unique Router-ID. 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Type | Length | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Flags | Reserved | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Router ID | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Interface ID | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 Unnumbered Interface ID Backup ERO TLV format 627 where: 629 Type: TBA 631 Length: 12 bytes 633 Flags: 1 octet field of following flags: 635 0 1 2 3 4 5 6 7 636 +-+-+-+-+-+-+-+-+ 637 |L| | 638 +-+-+-+-+-+-+-+-+ 640 where: 642 L-bit - If the L bit is set, then the value of the attribute is 643 'loose.' Otherwise, the value of the attribute is 'strict.' 645 Router-ID: Router-ID of the next-hop. 647 Interface ID: is the identifier assigned to the link by the router 648 specified by the Router-ID. 650 5. Adjacency Segment Identifier (Adj-SID) 652 An Adjacency Segment Identifier (Adj-SID) represents a router 653 adjacency in Segment Routing. At the current stage of Segment 654 Routing architecture it is assumed that the Adj-SID value has local 655 significance (to the router). 657 5.1. OSPFv2 Extended Link Opaque LSA 659 A new Opaque LSA (defined in [RFC5250] is defined in OSPFv2 in order 660 to advertise additional link attributes: the OSPFv2 Extended Link 661 Opaque LSA. 663 The OSPFv2 Extended Link Opaque LSA has an area flooding scope. 664 Multiple OSPFv2 Extended Link Opaque LSAs can be advertised by a 665 single router in an area. 667 The format of the OSPFv2 Extended Link Opaque LSA is as follows: 669 0 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | LS age | Options | 10 | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Opaque type | Instance | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Advertising Router | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | LS sequence number | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | LS checksum | length | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | | 683 +- TLVs -+ 684 | ... | 686 Opaque type used by OSPFv2 Extended Link Opaque LSA is TBA 688 The format of the TLVs within the body of LSA is the same as the 689 format used by the Traffic Engineering Extensions to OSPF defined in 690 [RFC3630]. The LSA payload consists of one or more nested Type/ 691 Length/Value (TLV) triplets. The format of each TLV is: 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Type | Length | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Value... | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 The Length field defines the length of the value portion in octets. 702 The TLV is padded to 4-octet alignment; padding is not included in 703 the length field. Nested TLVs are also 32-bit aligned. Unrecognized 704 types are ignored. 706 5.2. OSPFv2 Extended Link TLV 708 OSPFv2 Extended Link TLV is used in order to advertise various 709 attributes of the link. It describes a single link and is 710 constructed of a set of Sub-TLVs. There are no ordering requirements 711 for the Sub-TLVs. Only one Extended Link TLV SHALL be carried in 712 each Extended Link Opaque LSA, allowing for fine granularity changes 713 in the topology. 715 The Extended Link TLV has following format: 717 0 1 2 3 718 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 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Type | Length | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Link-Type | Reserved | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Link ID | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | Link Data | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | Sub-TLVs (variable) | 729 +- -+ 730 | | 732 where: 734 Type is TBA. 736 Length is variable. 738 Link-Type: as defined in section A.4.2 of [RFC2328]. 740 Link-ID: as defined in section A.4.2 of [RFC2328]. 742 Link Data: as defined in section A.4.2 of [RFC2328]. 744 5.3. Adj-SID sub-TLV 746 Adj-SID is an optional Sub-TLV of the Extended Link TLV. It MAY 747 appear multiple times in Extended Link TLV. Examples where more than 748 one Adj-SID may be used per neighbor are described in 749 [I-D.filsfils-rtgwg-segment-routing-use-cases]. The structure of the 750 Adj-SID Sub-TLV is as follows: 752 0 1 2 3 753 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 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Type | Length | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Flags | MT-ID | Weight | Reserved | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Sub-TLVs (variable) | 760 +- -+ 761 | | 763 where: 765 Type: TBA. 767 Length: variable. 769 Flags. 1 octet field of following flags: 771 0 1 2 3 4 5 6 7 772 +-+-+-+-+-+-+-+-+ 773 |B| | 774 +-+-+-+-+-+-+-+-+ 776 where: 778 B-Flag: Backup-flag: set if the Adj-SID refer to an adjacency 779 being protected (e.g.: using IPFRR or MPLS-FRR) as described in 780 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 782 Other bits: MUST be zero when originated and ignored when 783 received. 785 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 787 Weight: weight used for load-balancing purposes. The use of the 788 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 790 Adj-SID Sub-TLV supports following Sub-TLVs: 792 SID/Label TLV as described in Section 2.1. This TLV MUST 793 appear in the Adj-SID Sub-TLV and it MUST only appear once. 795 A SR capable router MAY allocate an Adj-SID for each of its 796 adjacencies and set the B-Flag when the adjacency is protected by a 797 FRR mechanism (IP or MPLS) as described in 798 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 800 5.4. LAN Adj-SID/Label Sub-TLV 802 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV. It MAY 803 appear multiple times in Extended Link TLV. It is used to advertise 804 SID/Label for adjacency to non-DR node on broadcast or NBMA network. 806 0 1 2 3 807 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 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 | Type | Length | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 | Flags | MT-ID | Weight | Reserved | 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Neighbor ID | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Sub-TLVs (variable) | 816 +- -+ 817 | | 819 where: 821 Type: TBA. 823 Length: variable. 825 Flags. 1 octet field of following flags: 827 0 1 2 3 4 5 6 7 828 +-+-+-+-+-+-+-+-+ 829 |B| | 830 +-+-+-+-+-+-+-+-+ 832 where: 834 B-Flag: Backup-flag: set if the LAN-Adj-SID refer to an 835 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 836 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 838 Other bits: MUST be zero when originated and ignored when 839 received. 841 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 843 Weight: weight used for load-balancing purposes. The use of the 844 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 846 LAN Adj-SID Sub-TLV supports following Sub-TLVs: 848 SID/Label TLV as described in Section 2.1. This TLV MUST 849 appear in the Adj-SID Sub-TLV and it MUST only appear once. 851 6. Elements of Procedure 853 6.1. Intra-area Segment routing in OSPFv2 855 The OSPFv2 node that supports segment routing MAY advertise Prefix- 856 SIDs for any prefix that it is advertising reachability for (e.g. 857 loopback IP address) as described in Section 4.2. 859 If multiple routers advertise Prefix-SID for the same prefix, then 860 the Prefix-SID MUST be the same. This is required in order to allow 861 traffic load-balancing if multiple equal cost paths to the 862 destination exist in the network. 864 Prefix-SID can also be advertised by the SR Mapping Servers (as 865 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]). The 866 Mapping Server advertise Prefix-SID for remote prefixes that exist in 867 the network. Multiple Mapping Servers can advertise Prefix-SID for 868 the same prefix, in which case the same Prefix-SID MUST be advertised 869 by all of them. Flooding scope of the OSPF Extended Prefix Opaque 870 LSA that is generated by the SR Mapping Server could be either area 871 scope or autonomous system scope and is decided based on the 872 configuration of the SR Mapping Server. 874 6.2. Inter-area Segment routing in OSPFv2 876 In order to support SR in a multi-area environment, OSPFv2 must 877 propagate Prefix-SID information between areas. The following 878 procedure is used in order to propagate Prefix SIDs between areas. 880 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 881 prefix to all its connected areas, it will also originate an Extended 882 Prefix Opaque LSA, as described in Section 4. The flooding scope of 883 the Extended Prefix Opaque LSA type will be set to area-scope. The 884 route-type in OSPF Extended Prefix TLV is set to inter-area. The 885 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 886 value will be set as follows: 888 The ABR will look at its best path to the prefix in the source 889 area and find out the advertising router associated with its best 890 path to that prefix. 892 If no Prefix-SID was advertised for the prefix in the source area 893 by the router that contributes to the best path to the prefix, 894 then the ABR will use the Prefix-SID advertised by any other 895 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 896 defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when 897 propagating Prefix-SID for the prefix to other areas. 899 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 900 route to all its connected areas it will also originate an Extended 901 Prefix Opaque LSA, as described in Section 4. The flooding scope of 902 the Extended Prefix Opaque LSA type will be set to area-scope. The 903 route-type in OSPF Extended Prefix TLV is set to inter-area. The 904 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 905 will be set as follows: 907 The ABR will look at its best path to the prefix in the source 908 area and find out the advertising router associated with its best 909 path to that prefix. 911 The ABR will then look if such router advertised a Prefix-SID for 912 the prefix and use it when advertising the Prefix-SID to other 913 connected areas. 915 If no Prefix-SID was advertised for the prefix in the source area 916 by the ABR that contributes to the best path to the prefix, the 917 originating ABR will use the Prefix-SID advertised by any other 918 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 919 defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when 920 propagating Prefix-SID for the prefix to other areas. 922 6.3. SID for External Prefixes 924 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 925 SR, generates Type-5 LSAs, it should also originate Extended Prefix 926 Opaque LSAs, as described in Section 4. The flooding scope of the 927 Extended Prefix Opaque LSA type is set to AS-scope. The route-type 928 in OSPF Extended Prefix TLV is set to external. Prefix-SID Sub-TLV 929 is included in this LSA and the Prefix-SID value will be set to the 930 SID that has been reserved for that prefix. 932 When a NSSA ASBR translates Type-7 LSAs into Type-5 LSAs, it should 933 also advertise the Prefix-SID for the prefix. The NSSA ABR 934 determines its best path to the prefix advertised in the translated 935 Type-7 LSA and finds the advertising router associated with such 936 path. If such advertising router has advertised a Prefix-SID for the 937 prefix, then the NSSA ASBR uses it when advertising the Prefix-SID 938 for the Type-5 prefix. Otherwise the Prefix-SID advertised by any 939 other router will be used (e.g.: a Prefix-SID coming from an SR 940 Mapping Server as defined in 941 [I-D.filsfils-rtgwg-segment-routing-use-cases]). 943 6.4. Advertisement of Adj-SID 945 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 946 using the Adj-SID Sub-TLV as described in Section 5. 948 6.4.1. Advertisement of Adj-SID on Point-to-Point Links 950 Adj-SID MAY be advertised for any adjacency on p2p link that is in a 951 state 2-Way or higher. If the adjacency on a p2p link transitions 952 from the FULL state, then the Adj-SID for that adjacency MAY be 953 removed from the area. If the adjacency transitions to a state lower 954 then 2-Way, then the Adj-SID MUST be removed from the area. 956 6.4.2. Adjacency SID on Broadcast or NBMA Interfaces 958 Broadcast or NBMA networks in OSPF are represented by a star topology 959 where the Designated Router (DR) is the central point all other 960 routers on the broadcast or NBMA network connect to. As a result, 961 routers on the broadcast or NBMA network advertise only their 962 adjacency to DR and BDR. Routers that are neither DR nor BDR do not 963 form and do not advertise adjacencies between them. They, however, 964 maintain a 2-Way adjacency state between them. 966 When Segment Routing is used, each router on the broadcast or NBMA 967 network MAY advertise the Adj-SID for its adjacency to DR using Adj- 968 SID Sub-TLV as described in Section 5.3. 970 SR capable router MAY also advertise Adj-SID for other neighbors 971 (e.g. BDR, DR-OTHER) on broadcast or NBMA network using the LAN ADJ- 972 SID Sub-TLV as described in section 5.1.1.2. Section 5.4. 974 7. IANA Considerations 976 TBD 978 8. Manageability Considerations 980 TBD 982 9. Security Considerations 984 TBD 986 10. Acknowledgements 988 We would like to thank Anton Smirnov and Wim Hendricks. 990 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 991 contribution on earlier incarnations of the "Binding / MPLS Label 992 TLV" in [I-D.gredler-ospf-label-advertisement]. 994 11. References 996 11.1. Normative References 998 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 999 Requirement Levels", BCP 14, RFC 2119, March 1997. 1001 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 1003 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1004 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1005 Tunnels", RFC 3209, December 2001. 1007 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1008 in Resource ReSerVation Protocol - Traffic Engineering 1009 (RSVP-TE)", RFC 3477, January 2003. 1011 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1012 (TE) Extensions to OSPF Version 2", RFC 3630, 1013 September 2003. 1015 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1016 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1017 RFC 4915, June 2007. 1019 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 1020 Shaffer, "Extensions to OSPF for Advertising Optional 1021 Router Capabilities", RFC 4970, July 2007. 1023 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1024 OSPF Opaque LSA Option", RFC 5250, July 2008. 1026 11.2. Informative References 1028 [I-D.filsfils-rtgwg-segment-routing] 1029 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1030 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1031 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1032 "Segment Routing Architecture", 1033 draft-filsfils-rtgwg-segment-routing-00 (work in 1034 progress), June 2013. 1036 [I-D.filsfils-rtgwg-segment-routing-use-cases] 1037 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1038 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1039 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1040 "Segment Routing Use Cases", 1041 draft-filsfils-rtgwg-segment-routing-use-cases-00 (work in 1042 progress), June 2013. 1044 [I-D.gredler-ospf-label-advertisement] 1045 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1046 "Advertising MPLS labels in OSPF", 1047 draft-gredler-ospf-label-advertisement-03 (work in 1048 progress), May 2013. 1050 [I-D.minto-rsvp-lsp-egress-fast-protection] 1051 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1052 egress fast-protection", 1053 draft-minto-rsvp-lsp-egress-fast-protection-02 (work in 1054 progress), April 2013. 1056 Authors' Addresses 1058 Peter Psenak (editor) 1059 Cisco Systems, Inc. 1060 Apollo Business Center 1061 Mlynske nivy 43 1062 Bratislava 821 09 1063 Slovakia 1065 Email: ppsenak@cisco.com 1067 Stefano Previdi (editor) 1068 Cisco Systems, Inc. 1069 Via Del Serafico, 200 1070 Rome 00142 1071 Italy 1073 Email: sprevidi@cisco.com 1075 Clarence Filsfils 1076 Cisco Systems, Inc. 1077 Brussels, 1078 Belgium 1080 Email: cfilsfil@cisco.com 1082 Hannes Gredler 1083 Juniper Networks, Inc. 1084 1194 N. Mathilda Ave. 1085 Sunnyvale, CA 94089 1086 US 1088 Email: hannes@juniper.net 1090 Rob Shakir 1091 British Telecom 1092 London 1093 UK 1095 Email: rob.shakir@bt.com