idnits 2.17.1 draft-psenak-ospf-segment-routing-ospfv3-extension-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 2 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2013) is 3815 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-01 == Outdated reference: A later version (-03) exists of draft-minto-rsvp-lsp-egress-fast-protection-02 Summary: 1 error (**), 0 flaws (~~), 5 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: April 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 October 18, 2013 14 OSPFv3 Extensions for Segment Routing 15 draft-psenak-ospf-segment-routing-ospfv3-extension-00 17 Abstract 19 Segment Routing (SR) allows for a flexible definition of end-to-end 20 paths within IGP topologies by encoding paths as sequences of 21 topological sub-paths, called "segments". These segments are 22 advertised by the link-state routing protocols (IS-IS and OSPF). 24 This draft describes the necessary OSPFv3 extensions that need to be 25 introduced for Segment Routing. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 21, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Segment Routing Identifiers . . . . . . . . . . . . . . . . . 3 69 2.1. SID/Label sub-TLV . . . . . . . . . . . . . . . . . . . . 3 70 3. Segment Routing Capabilities . . . . . . . . . . . . . . . . . 4 71 3.1. SR-Algorithm TLV . . . . . . . . . . . . . . . . . . . . . 4 72 3.2. SID/Label Range TLV . . . . . . . . . . . . . . . . . . . 5 73 4. Prefix SID Identifier . . . . . . . . . . . . . . . . . . . . 6 74 4.1. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . 6 75 4.2. SID/Label Binding sub-TLV . . . . . . . . . . . . . . . . 8 76 4.2.1. ERO Metric sub-TLV . . . . . . . . . . . . . . . . . . 10 77 4.2.2. ERO sub-TLVs . . . . . . . . . . . . . . . . . . . . . 10 78 5. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . . 16 79 5.1. Adj-SID sub-TLV . . . . . . . . . . . . . . . . . . . . . 17 80 5.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 18 81 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19 82 6.1. Intra-area Segment routing in OSPFv3 . . . . . . . . . . . 19 83 6.2. Inter-area Segment routing in OSPFv3 . . . . . . . . . . . 20 84 6.3. SID for External Prefixes . . . . . . . . . . . . . . . . 21 85 6.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . . 21 86 6.4.1. Advertisement of Adj-SID on Point-to-Point Links . . . 21 87 6.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 21 88 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 90 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 94 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 97 1. Introduction 99 Segment Routing (SR) allows for a flexible definition of end-to-end 100 paths within IGP topologies by encoding paths as sequences of 101 topological sub-paths, called "segments". These segments are 102 advertised by the link-state routing protocols (IS-IS and OSPF). 103 Prefix segments represent an ecmp-aware shortest-path to a prefix (or 104 a node), as per the state of the IGP topology. Adjacency segments 105 represent a hop over a specific adjacency between two nodes in the 106 IGP. A prefix segment is typically a multi-hop path while an 107 adjacency segment, in most of the cases, is a one-hop path. SR's 108 control-plane can be applied to both IPv6 and MPLS data-planes, and 109 do not require any additional signaling (other than the regular IGP). 110 For example, when used in MPLS networks, SR paths do not require any 111 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 112 of LSPs established with RSVP or LDP . 114 This draft describes the necessary OSPFv3 extensions that need to be 115 introduced for Segment Routing. 117 Segment Routing architecture is described in 118 [I-D.filsfils-rtgwg-segment-routing]. 120 Segment Routing use cases are described in 121 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 123 2. Segment Routing Identifiers 125 Segment Routing defines various types of Segment Identifiers (SIDs): 126 Prefix-SID, Adjacency-SID, LAN Adjacency SID and Binding SID. 128 2.1. SID/Label sub-TLV 130 SID/Label sub-TLV appears in multiple TLVs or Sub-TLVs defined later 131 in this document. It is used to advertise SID or label associated 132 with the prefix or adjacency. SID/Label TLV has following format: 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Type | Length | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | SID/Label (variable) | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 where: 144 Type: 1 146 Length: variable, 3 or 4 bytes 148 SID/Label: if length is set to 3, then the 20 rightmost bits 149 represent a label. If length is set to 4 then the value 150 represents a 32 bit SID. 152 3. Segment Routing Capabilities 154 Segment Routing requires some additional capabilities of the router 155 to be advertised to other routers in the area. 157 These SR capabilities are advertised in OSPFv3 Router Information 158 Opaque LSA (defined in [RFC4970]). 160 3.1. SR-Algorithm TLV 162 SR-Algorithm TLV is a TLV of Router Information Opaque LSA (defined 163 in [RFC4970]). 165 Router may use various algorithms when calculating reachability to 166 other nodes in area or to prefixes attached to these nodes. Examples 167 of these algorithms are metric based Shortest Path First (SPF), 168 various sorts of Constrained SPF, etc. SR-Algorithm TLV allows a 169 router to advertise algorithms that router is currently using to 170 other routers in an area. SR-Algorithm TLV has following structure: 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Type | Length | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Algorithm 1 | Algorithm... | Algorithm n | | 178 +- -+ 179 | | 180 + + 182 where: 184 Type: 8 186 Length: variable 188 Algorithm: one octet identifying the algorithm. The following 189 value has been defined: 191 0: IGP metric based SPT. 193 RI LSA can be advertised at any of the defined flooding scopes (link, 194 area, or autonomous system (AS)). For the purpose of the SR- 195 Algorithm TLV propagation area scope flooding is required. 197 3.2. SID/Label Range TLV 199 The SID/Label Range TLV is a TLV of Router Information Opaque LSA 200 (defined in [RFC4970]). 202 SID/Label Sub-TLV MAY appear multiple times and has following format: 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Type | Length | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Range Size | Reserved | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Sub-TLVs (variable) | 212 +- -+ 213 | | 214 + + 216 where: 218 Type: 9 220 Length: variable 222 Range Size: size of the SID/label range 224 Currently the only supported Sub-TLV is the SID/Label TLV as defined 225 in Section 2.1. SID/Label advertised in SID/Label TLV represents the 226 first SID/Label from the advertised range. 228 RI LSA can be advertised at any of the defined flooding scopes (link, 229 area, or autonomous system (AS)). For the purpose of the SR- 230 Capability TLV propagation area scope flooding is required. 232 4. Prefix SID Identifier 234 A new extended OSPFv3 LSAs as defined in [I-D.acee-ospfv3-lsa-extend] 235 are used to advertise prefix SID in OSPFv3. 237 4.1. Prefix SID Sub-TLV 239 The Prefix SID Sub-TLV is a Sub-TLV of the following OSPFv3 TLVs as 240 defined in [I-D.acee-ospfv3-lsa-extend]: 242 Inter-Area Prefix TLV 244 External Prefix TLV 246 Intra-Area-Prefix TLV 248 It MAY appear more than once and has following format: 250 0 1 2 3 251 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 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Type | Length | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Flags | Algorithm | Range Size | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Index | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 where: 262 Type: 2. 264 Length: A 16-bit field that indicates the length of the value 265 portion in octets. Set to 8. 267 Flags: 1 octet field. The following flags are defined: 269 0 270 0 1 2 3 4 5 6 7 271 +-+-+-+-+-+-+-+-+ 272 |N|P|M| | 273 +-+-+-+-+-+-+-+-+ 275 where: 277 N-Flag: Node-SID flag. If set, then the Prefix-SID refers to 278 the router identified by the prefix. Typically, the N-Flag is 279 set on Prefix-SIDs attached to a router loopback address. The 280 N-Flag is set when the Prefix-SID is a Node- SID as described 281 in [I-D.filsfils-rtgwg-segment-routing]. 283 P-Flag: no-PHP flag. If set, then the penultimate hop MUST NOT 284 pop the Prefix-SID before delivering the packet to the node 285 that advertised the Prefix-SID. 287 M-Flag: Mapping Server Flag. If set, the SID is advertised 288 from the Segment Routing Mapping Server functionality as 289 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 291 Other bits: MUST be zero when sent and ignored when received. 293 Algorithm: one octet identifying the algorithm the Prefix-SID is 294 associated with as defined in Section 3.1. 296 Range Size: this field provides the ability to specify a range of 297 addresses and their associated Prefix SIDs. It represents a 298 compression scheme to distribute a continuous Prefix and their 299 continuous, corresponding SID/Label Block. If a single SID is 300 advertised then the Range Size field MUST be set to 1. For range 301 advertisements > 1, Range Size represents the the number of 302 addresses that need to be mapped into a Prefix-SID. 304 Index: 32 bits representing the offset to the advertised SID/Label 305 range. 307 If multiple Prefix-SIDs are advertised for the same prefix, the 308 receiving router MUST use the first encoded SID and MAY use the 309 subsequent ones. 311 P-Flag (no-PHP) MUST be set on the Prefix-SIDs allocated to inter- 312 area prefixes that are originated by the ABR based on intra-area or 313 inter-area reachability between areas. In case the inter-area prefix 314 is generated based on the prefix which is directly attached to the 315 ABR, P-Flag SHOULD NOT be set 317 P-Flag (no-PHP) MUST NOT be set on the Prefix-SIDs allocated to 318 redistributed prefixes, unless the redistributed prefix is directly 319 attached to ASBR, in which case the P-Flag SHOULD NOT be set. 321 When M-Flag is set, PHP MUST NOT be done. 323 Example 1: if the following router addresses (loopback addresses) 324 need to be mapped into the corresponding Prefix SID indexes: 326 Router-A: 192::1/128, Prefix-SID: Index 1 327 Router-B: 192::2/128, Prefix-SID: Index 2 328 Router-C: 192::3/128, Prefix-SID: Index 3 329 Router-D: 192::4/128, Prefix-SID: Index 4 331 then the Address Prefix field in Intra-Area Prefix TLV, Inter-Area 332 Prefix TLV or External Prefix TLV is set to 192::1, Prefix Length in 333 these TLVs would be set to 128, Range Size in Prefix SID sub-TLV 334 would be set to 4 and Index value would be set to 1. 336 Example 2: If the following prefixes need to be mapped into the 337 corresponding Prefix-SID indexes: 339 10:1:1::0/120, Prefix-SID: Index 51 340 10:1:1::100/120, Prefix-SID: Index 52 341 10:1:1::200/120, Prefix-SID: Index 53 342 10:1:1::300/120, Prefix-SID: Index 54 343 10:1:1::400/120, Prefix-SID: Index 55 344 10:1:1::500/120, Prefix-SID: Index 56 345 10:1:1::600/120, Prefix-SID: Index 57 347 then the Address Prefix field in Intra-Area Prefix TLV, Inter-Area 348 Prefix TLV or External Prefix TLV is set to 10:1:1::0, Prefix Length 349 in these TLVs would be set to 120, Range Size in Prefix SID sub-TLV 350 would be set to 7 and Index value would be set to 51. 352 4.2. SID/Label Binding sub-TLV 354 SID/Label Binding sub-TLV is used to advertise SID/Label mapping for 355 a prefix or a path to the prefix. SID/Label value advertised in this 356 sub-TLV has local significance (to the router). 358 SID/Label Binding sub-TLV is a sub-TLV of the following OSPFv3 TLVs, 359 as defined in [I-D.acee-ospfv3-lsa-extend]: 361 Inter-Area Prefix TLV 363 External Prefix TLV 365 Intra-Area-Prefix TLV 367 Multiple SID/Label Binding sub-TLVs can be present in above mentioned 368 TLVs. SID/Label Binding sub-TLV has following format: 370 0 1 2 3 371 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 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Type | Length | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Flags | Weight | Range Size | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Sub-TLVs (variable) | 378 +- -+ 379 | | 381 where: 383 Type: 3 385 Length: variable 387 Flags: 1 octet field of following flags: 389 0 1 2 3 4 5 6 7 390 +-+-+-+-+-+-+-+-+ 391 |M| | 392 +-+-+-+-+-+-+-+-+ 394 where: 396 M-bit - When the bit is set the binding represents the 397 mirroring context as defined in 398 [I-D.minto-rsvp-lsp-egress-fast-protection]. 400 Weight: weight used for load-balancing purposes. The use of the 401 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 403 Range Size: usage is the same as described in Section 4.1 405 SID/Label Binding sub-TLV currently supports following Sub-TLVs: 407 SID/Label sub-TLV as described in Section 2.1. This sub-TLV MUST 408 appear in the SID/Label Binding Sub-TLV and it MUST only appear 409 once. 411 ERO Metric sub-TLV as defined in Section 4.2.1. 413 ERO sub-TLVs as defined in Section 4.2.2. 415 4.2.1. ERO Metric sub-TLV 417 ERO Metric sub-TLV is a Sub-TLV of the SID/Label Binding TLV. 419 The ERO Metric sub-TLV carries the cost of an ERO path. It is used 420 to compare the cost of a given source/destination path. A router 421 SHOULD advertise the ERO Metric sub-TLV. The cost of the ERO Metric 422 sub-TLV SHOULD be set to the cumulative IGP or TE path cost of the 423 advertised ERO. Since manipulation of the Metric field may attract 424 or distract traffic from and to the advertised segment it MAY be 425 manually overridden. 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Type | Length | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Metric (4 octets) | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 ERO Metric sub-TLV format 437 where: 439 Type: 12 441 Length: 4 bytes 443 Metric: 4 bytes 445 4.2.2. ERO sub-TLVs 447 All 'ERO' information represents an ordered set which describes the 448 segments of a path. The last ERO sub-TLV describes the segment 449 closest to the egress point, contrary the first ERO sub-TLV describes 450 the first segment of a path. If a router extends or stitches a path 451 it MUST prepend the new segments path information to the ERO list. 453 The above similarly applies to backup EROs. 455 All ERO Sub-TLVs must immediately follow the (SID)/Label Sub-TLV. 457 All Backup ERO sub-TLVs must immediately follow last ERO Sub-TLV. 459 4.2.2.1. IPv4 ERO sub-TLV 461 IPv4 ERO sub-TLV is a sub-TLV of the SID/Label Binding sub-TLV. 463 The IPv4 ERO sub-TLV describes a path segment using IPv4 Address 464 style of encoding. Its semantics have been borrowed from [RFC3209]. 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Type | Length | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Flags | Reserved | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | IPv4 Address (4 octets) | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 IPv4 ERO sub-TLV format 478 where: 480 Type: 4 482 Length: 8 bytes 484 Flags: 1 octet field of following flags: 486 0 1 2 3 4 5 6 7 487 +-+-+-+-+-+-+-+-+ 488 |L| | 489 +-+-+-+-+-+-+-+-+ 491 where: 493 L-bit - If the L bit is set, then the value of the attribute is 494 'loose.' Otherwise, the value of the attribute is 'strict.' 496 IPv4 Address - the address of the explicit route hop. 498 4.2.2.2. IPv6 ERO sub-TLV 500 IPv6 ERO sub-TLV is a sub-TLV of the SID/Label Binding sub-TLV. 502 The IPv6 ERO sub-TLV (Type TBA) describes a path segment using IPv6 503 Address style of encoding. Its semantics have been borrowed from 504 [RFC3209]. 506 0 1 2 3 507 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 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | Type | Length | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Flags | Reserved | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | | 514 +- -+ 515 | | 516 +- IPv6 Address -+ 517 | | 518 +- -+ 519 | | 520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 IPv6 ERO sub-TLV format 524 where: 526 Type: 5 528 Length: 8 bytes 530 Flags: 1 octet field of following flags: 532 0 1 2 3 4 5 6 7 533 +-+-+-+-+-+-+-+-+ 534 |L| | 535 +-+-+-+-+-+-+-+-+ 537 where: 539 L-bit - If the L bit is set, then the value of the attribute is 540 'loose.' Otherwise, the value of the attribute is 'strict.' 542 IPv6 Address - the address of the explicit route hop. 544 4.2.2.3. Unnumbered Interface ID ERO sub-TLV 546 Unnumbered Interface ID ERO sub-TLV is a sub-TLV of the SID/Label 547 Binding sub-TLV. 549 The appearance and semantics of the 'Unnumbered Interface ID' have 550 been borrowed from [RFC3477]. 552 The Unnumbered Interface-ID ERO sub-TLV describes a path segment that 553 spans over an unnumbered interface. Unnumbered interfaces are 554 referenced using the interface index. Interface indices are assigned 555 local to the router and therefore not unique within a domain. All 556 elements in an ERO path need to be unique within a domain and hence 557 need to be disambiguated using a domain unique Router-ID. 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Type | Length | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Flags | Reserved | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Router ID | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Interface ID | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 where: 573 Unnumbered Interface ID ERO sub-TLV format 575 Type: 6 577 Length: 12 bytes 579 Flags: 1 octet field of following flags: 581 0 1 2 3 4 5 6 7 582 +-+-+-+-+-+-+-+-+ 583 |L| | 584 +-+-+-+-+-+-+-+-+ 586 where: 588 L-bit - If the L bit is set, then the value of the attribute is 589 'loose.' Otherwise, the value of the attribute is 'strict.' 591 Router-ID: Router-ID of the next-hop. 593 Interface ID: is the identifier assigned to the link by the router 594 specified by the Router-ID. 596 4.2.2.4. IPv4 Backup ERO sub-TLV 598 IPv4 Prefix Backup ERO sub-TLV is a sub-TLV of the SID/Label Binding 599 sub-TLV. 601 The IPv4 Backup ERO sub-TLV describes a path segment using IPv4 602 Address style of encoding. Its semantics have been borrowed from 603 [RFC3209]. 605 0 1 2 3 606 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 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 | Type | Length | 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | Flags | Reserved | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | IPv4 Address (4 octets) | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 IPv4 Backup ERO sub-TLV format 617 where: 619 Type: 7 621 Length: 8 bytes 623 Flags: 1 octet field of following flags: 625 0 1 2 3 4 5 6 7 626 +-+-+-+-+-+-+-+-+ 627 |L| | 628 +-+-+-+-+-+-+-+-+ 630 where: 632 L-bit - If the L bit is set, then the value of the attribute is 633 'loose.' Otherwise, the value of the attribute is 'strict.' 635 IPv4 Address - the address of the explicit route hop. 637 4.2.2.5. IPv6 Backup ERO sub-TLV 639 IPv6 ERO sub-TLV is a sub-TLV of the SID/Label Binding sub-TLV. 641 The IPv6 Backup ERO sub-TLV describes a Backup path segment using 642 IPv6 Address style of encoding. Its appearance and semantics have 643 been borrowed from [RFC3209]. 645 The 'L' bit in the Flags is a one-bit attribute. If the L bit is 646 set, then the value of the attribute is 'loose.' Otherwise, the 647 value of the attribute is 'strict.' 648 0 1 2 3 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Type | Length | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Flags | Reserved | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | | 656 +- -+ 657 | | 658 +- IPv6 Address -+ 659 | | 660 +- -+ 661 | | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 IPv6 Backup ERO sub-TLV format 666 where: 668 Type: 8 670 Length: 8 bytes 672 Flags: 1 octet field of following flags: 674 0 1 2 3 4 5 6 7 675 +-+-+-+-+-+-+-+-+ 676 |L| | 677 +-+-+-+-+-+-+-+-+ 679 where: 681 L-bit - If the L bit is set, then the value of the attribute is 682 'loose.' Otherwise, the value of the attribute is 'strict.' 684 IPv6 Address - the address of the explicit route hop. 686 4.2.2.6. Unnumbered Interface ID Backup ERO sub-TLV 688 Unnumbered Interface ID Backup sub-TLV is a sub-TLV of the SID/Label 689 Binding sub-TLV. 691 The appearance and semantics of the 'Unnumbered Interface ID' have 692 been borrowed from [RFC3477]. 694 The Unnumbered Interface-ID ERO sub-TLV describes a path segment that 695 spans over an unnumbered interface. Unnumbered interfaces are 696 referenced using the interface index. Interface indices are assigned 697 local to the router and therefore not unique within a domain. All 698 elements in an ERO path need to be unique within a domain and hence 699 need to be disambiguated using a domain unique Router-ID. 701 0 1 2 3 702 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 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 | Type | Length | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | Flags | Reserved | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 | Router ID | 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Interface ID | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 Unnumbered Interface ID Backup ERO sub-TLV format 715 where: 717 Type: 9 719 Length: 12 bytes 721 Flags: 1 octet field of following flags: 723 0 1 2 3 4 5 6 7 724 +-+-+-+-+-+-+-+-+ 725 |L| | 726 +-+-+-+-+-+-+-+-+ 728 where: 730 L-bit - If the L bit is set, then the value of the attribute is 731 'loose.' Otherwise, the value of the attribute is 'strict.' 733 Router-ID: Router-ID of the next-hop. 735 Interface ID: is the identifier assigned to the link by the router 736 specified by the Router-ID. 738 5. Adjacency Segment Identifier (Adj-SID) 740 An Adjacency Segment Identifier (Adj-SID) represents a router 741 adjacency in Segment Routing. At the current stage of Segment 742 Routing architecture it is assumed that the Adj-SID value has local 743 significance (to the router). 745 5.1. Adj-SID sub-TLV 747 A new extended OSPFv3 LSAs, as defined in 748 [I-D.acee-ospfv3-lsa-extend], are used to advertise prefix SID in 749 OSPFv3 751 Adj-SID sub-TLV is an optional sub-TLV of the Router-Link TLV as 752 defined in [I-D.acee-ospfv3-lsa-extend]. It MAY appear multiple 753 times in Router-Link TLV. Examples where more than one Adj-SID may 754 be used per neighbor are described in 755 [I-D.filsfils-rtgwg-segment-routing-use-cases]. The structure of the 756 Adj-SID Sub-TLV is as follows: 758 0 1 2 3 759 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 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Type | Length | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Flags | Weight | Reserved | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Sub-TLVs (variable) | 766 +- -+ 767 | | 769 where: 771 Type: 10. 773 Length: variable. 775 Flags. 1 octet field of following flags: 777 0 1 2 3 4 5 6 7 778 +-+-+-+-+-+-+-+-+ 779 |B| | 780 +-+-+-+-+-+-+-+-+ 782 where: 784 B-Flag: Backup-flag: set if the Adj-SID refer to an adjacency 785 being protected (e.g.: using IPFRR or MPLS-FRR) as described in 786 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 788 Other bits: MUST be zero when originated and ignored when 789 received. 791 Weight: weight used for load-balancing purposes. The use of the 792 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 794 Adj-SID Sub-TLV supports following Sub-TLVs: 796 SID/Label sub-TLV as described in Section 2.1. This TLV MUST 797 appear in the Adj-SID sub-TLV and it MUST only appear once. 799 A SR capable router MAY allocate an Adj-SID for each of its 800 adjacencies and set the B-Flag when the adjacency is protected by a 801 FRR mechanism (IP or MPLS) as described in 802 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 804 5.2. LAN Adj-SID Sub-TLV 806 LAN Adj-SID is an optional sub-TLV of the Router-Link TLV. It MAY 807 appear multiple times in Router-Link TLV. It is used to advertise 808 SID/Label for adjacency to non-DR node on broadcast or NBMA network. 810 0 1 2 3 811 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 812 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 813 | Type | Length | 814 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 815 | Flags | Weight | Reserved | 816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 817 | Neighbor ID | 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | Sub-TLVs (variable) | 820 +- -+ 821 | | 823 where: 825 Type: 11. 827 Length: variable. 829 Flags. 1 octet field of following flags: 831 0 1 2 3 4 5 6 7 832 +-+-+-+-+-+-+-+-+ 833 |B| | 834 +-+-+-+-+-+-+-+-+ 835 where: 837 B-Flag: Backup-flag: set if the LAN-Adj-SID refer to an 838 adjacency being protected (e.g.: using IPFRR or MPLS-FRR) as 839 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]. 841 Other bits: MUST be zero when originated and ignored when 842 received. 844 Weight: weight used for load-balancing purposes. The use of the 845 weight is defined in [I-D.filsfils-rtgwg-segment-routing]. 847 LAN Adj-SID Sub-TLV supports following Sub-TLVs: 849 SID/Label sub-TLV as described in Section 2.1. This TLV MUST 850 appear in the Adj-SID sub-TLV and it MUST only appear once. 852 6. Elements of Procedure 854 6.1. Intra-area Segment routing in OSPFv3 856 The OSPFv3 node that supports segment routing MAY advertise Prefix- 857 SIDs for any prefix that it is advertising reachability for (e.g. 858 loopback IP address) as described in Section 4.1. 860 If multiple routers advertise Prefix-SID for the same prefix, then 861 the Prefix-SID MUST be the same. This is required in order to allow 862 traffic load-balancing if multiple equal cost paths to the 863 destination exist in the network. 865 Prefix-SID can also be advertised by the SR Mapping Servers (as 866 described in [I-D.filsfils-rtgwg-segment-routing-use-cases]). The 867 Mapping Server advertises Prefix-SID for remote prefixes that exist 868 in the network. Multiple Mapping Servers can advertise Prefix-SID 869 for the same prefix, in which case the same Prefix-SID MUST be 870 advertised by all of them. SR Mapping Server could use either area 871 scope or autonomous system flooding scope when advertising Prefix SID 872 for prefixes, based on the configuration of the SR Mapping Server. 873 Depending on the flooding scope used, SR Mapping Server chooses the 874 LSA that will be used. If the area flooding scope is needed, 875 E-Intra-Area-Prefix-LSA ([I-D.acee-ospfv3-lsa-extend]) is used. If 876 autonomous system flooding scope is needed, E-AS-External-LSA 877 ([I-D.acee-ospfv3-lsa-extend]) is used. 879 When Prefix-SID is advertised by the Mapping Server, which is 880 indicated by the M-flag in the Prefix-SID sub-TLV (Section 4.1), 881 route-type as indicated by the LSA type which is being used for 882 flooding is ignored. Prefix SID is bound to a prefix, in which case 883 route-type becomes unimportant. 885 Advertisement of the Prefix-SID by the Mapping Server using Inter- 886 Area Prefix TLV, External Prefix TLV or Intra-Area-Prefix TLV 887 ([I-D.acee-ospfv3-lsa-extend]) does not itself contribute to the 888 prefix reachability. NU-bit MUST be set in the PrefixOptions field 889 of the LSA which is used by the Mapping Server to advertise SID or 890 SID range, which prevents such advertisement to contribute to the 891 prefix reachability. 893 6.2. Inter-area Segment routing in OSPFv3 895 In order to support SR in a multi-area environment, OSPFv3 must 896 propagate Prefix-SID information between areas. The following 897 procedure is used in order to propagate Prefix SIDs between areas. 899 When an OSPFv3 ABR advertises a Inter-Area-Prefix-LSA from an intra- 900 area prefix to all its connected areas, it will also include Prefix- 901 SID sub-TLV, as described in Section 4.1. The Prefix-SID value will 902 be set as follows: 904 The ABR will look at its best path to the prefix in the source 905 area and find out the advertising router associated with its best 906 path to that prefix. 908 If no Prefix-SID was advertised for the prefix in the source area 909 by the router that contributes to the best path to the prefix, 910 then the ABR will use the Prefix-SID advertised by any other 911 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 912 defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when 913 propagating Prefix-SID for the prefix to other areas. 915 When an OSPFv3 ABR advertises Inter-Area-Prefix-LSA LSAs from an 916 inter-area route to all its connected areas it will also include 917 Prefix-SID sub-TLV, as described in Section 4.1. The Prefix-SID 918 value will be set as follows: 920 The ABR will look at its best path to the prefix in the source 921 area and find out the advertising router associated with its best 922 path to that prefix. 924 The ABR will then look if such router advertised a Prefix-SID for 925 the prefix and use it when advertising the Prefix-SID to other 926 connected areas. 928 If no Prefix-SID was advertised for the prefix in the source area 929 by the ABR that contributes to the best path to the prefix, the 930 originating ABR will use the Prefix-SID advertised by any other 931 router (e.g.: a Prefix-SID coming from an SR Mapping Server as 932 defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]) when 933 propagating Prefix-SID for the prefix to other areas. 935 6.3. SID for External Prefixes 937 AS-External-LSAs are flooded domain wide. When an ASBR, which 938 supports SR, generates AS-External-LSA, it should also include 939 Prefix-SID sub-TLV, as described in Section 4.1 Prefix-SID value will 940 be set to the SID that has been reserved for that prefix. 942 When a NSSA ASBR translates NSSA-LSA into AS-External-LSA, it should 943 also advertise the Prefix-SID for the prefix. The NSSA ABR 944 determines its best path to the prefix advertised in the translated 945 NSSA-LSA and finds the advertising router associated with such path. 946 If such advertising router has advertised a Prefix-SID for the 947 prefix, then the NSSA ASBR uses it when advertising the Prefix-SID in 948 AS-External-LSA. Otherwise the Prefix-SID advertised by any other 949 router will be used (e.g.: a Prefix-SID coming from an SR Mapping 950 Server as defined in [I-D.filsfils-rtgwg-segment-routing-use-cases]). 952 6.4. Advertisement of Adj-SID 954 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 955 using the Adj-SID Sub-TLV as described in Section 5. 957 6.4.1. Advertisement of Adj-SID on Point-to-Point Links 959 Adj-SID MAY be advertised for any adjacency on p2p link that is in a 960 state 2-Way or higher. If the adjacency on a p2p link transitions 961 from the FULL state, then the Adj-SID for that adjacency MAY be 962 removed from the area. If the adjacency transitions to a state lower 963 then 2-Way, then the Adj-SID MUST be removed from the area. 965 6.4.2. Adjacency SID on Broadcast or NBMA Interfaces 967 Broadcast or NBMA networks in OSPFv3 are represented by a star 968 topology where the Designated Router (DR) is the central point all 969 other routers on the broadcast or NBMA network connect to. As a 970 result, routers on the broadcast or NBMA network advertise only their 971 adjacency to DR and BDR. Routers that are neither DR nor BDR do not 972 form and do not advertise adjacencies between them. They, however, 973 maintain a 2-Way adjacency state between them. 975 When Segment Routing is used, each router on the broadcast or NBMA 976 network MAY advertise the Adj-SID for its adjacency to DR using Adj- 977 SID Sub-TLV as described in Section 5.1. 979 SR capable router MAY also advertise Adj-SID for other neighbors 980 (e.g. BDR, DR-OTHER) on broadcast or NBMA network using the LAN ADJ- 981 SID Sub-TLV as described in section 5.1.1.2. Section 5.2. 983 7. IANA Considerations 985 This specification updates OSPFv3 Extend-LSA sub-TLV registry and 986 allocates following sub-TLVs: 988 o 1 - SID/Label sub-TLV 990 o 2 - Prefix SID sub-TLV 992 o 3 - SID/Label Binding sub-TLV 994 o 4 - IPv4 ERO sub-TLV 996 o 5 - IPv6 ERO sub-TLV 998 o 6 - Unnumbered Interface ID ERO sub-TLV 1000 o 7 - IPv4 Backup ERO sub-TLV 1002 o 8 - IPv6 Backup ERO sub-TLV 1004 o 9 - Unnumbered Interface ID Backup ERO sub-TLV 1006 o 10 - Adj-SID sub-TLV 1008 o 11 - LAN Adj-SID sub-TLV 1010 o 12 - ERO Metric sub-TLV 1012 8. Security Considerations 1014 Implementations must assure that malformed permutations of the newly 1015 defined sub-TLvs do not result in errors which cause hard OSPFv3 1016 failures. 1018 9. Contributors 1020 The following people gave a substantial contribution to the content 1021 of this document: Ahmed Bashandy, Martin Horneffer, Bruno Decraene, 1022 Stephane Litkowski, Igor Milojevic, Rob Shakir and Saku Ytti. 1024 10. Acknowledgements 1026 We would like to thank Anton Smirnov for his contribution. 1028 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1029 contribution on earlier incarnations of the "Binding / MPLS Label 1030 TLV" in [I-D.gredler-ospf-label-advertisement]. 1032 11. References 1034 11.1. Normative References 1036 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1037 Requirement Levels", BCP 14, RFC 2119, March 1997. 1039 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1040 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1041 Tunnels", RFC 3209, December 2001. 1043 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1044 in Resource ReSerVation Protocol - Traffic Engineering 1045 (RSVP-TE)", RFC 3477, January 2003. 1047 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 1048 Shaffer, "Extensions to OSPF for Advertising Optional 1049 Router Capabilities", RFC 4970, July 2007. 1051 11.2. Informative References 1053 [I-D.acee-ospfv3-lsa-extend] 1054 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 1055 LSA Extendibility", draft-acee-ospfv3-lsa-extend-02 (work 1056 in progress), September 2013. 1058 [I-D.filsfils-rtgwg-segment-routing] 1059 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1060 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1061 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1062 "Segment Routing Architecture", 1063 draft-filsfils-rtgwg-segment-routing-00 (work in 1064 progress), June 2013. 1066 [I-D.filsfils-rtgwg-segment-routing-use-cases] 1067 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1068 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1069 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1070 "Segment Routing Use Cases", 1071 draft-filsfils-rtgwg-segment-routing-use-cases-01 (work in 1072 progress), July 2013. 1074 [I-D.gredler-ospf-label-advertisement] 1075 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1076 "Advertising MPLS labels in OSPF", 1077 draft-gredler-ospf-label-advertisement-03 (work in 1078 progress), May 2013. 1080 [I-D.minto-rsvp-lsp-egress-fast-protection] 1081 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1082 egress fast-protection", 1083 draft-minto-rsvp-lsp-egress-fast-protection-02 (work in 1084 progress), April 2013. 1086 Authors' Addresses 1088 Peter Psenak (editor) 1089 Cisco Systems, Inc. 1090 Apollo Business Center 1091 Mlynske nivy 43 1092 Bratislava 821 09 1093 Slovakia 1095 Email: ppsenak@cisco.com 1097 Stefano Previdi (editor) 1098 Cisco Systems, Inc. 1099 Via Del Serafico, 200 1100 Rome 00142 1101 Italy 1103 Email: sprevidi@cisco.com 1105 Clarence Filsfils 1106 Cisco Systems, Inc. 1107 Brussels, 1108 Belgium 1110 Email: cfilsfil@cisco.com 1111 Hannes Gredler 1112 Juniper Networks, Inc. 1113 1194 N. Mathilda Ave. 1114 Sunnyvale, CA 94089 1115 US 1117 Email: hannes@juniper.net 1119 Rob Shakir 1120 British Telecom 1121 London 1122 UK 1124 Email: rob.shakir@bt.com 1126 Wim Henderickx 1127 Alcatel-Lucent 1128 Copernicuslaan 50 1129 Antwerp 2018 1130 BE 1132 Email: wim.henderickx@alcatel-lucent.com