idnits 2.17.1 draft-ietf-ospf-segment-routing-extensions-11.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 non-RFC2606-compliant FQDNs in the document. == 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 (February 28, 2017) is 2613 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 313 -- Looks like a reference, but probably isn't: '199' on line 313 -- Looks like a reference, but probably isn't: '1000' on line 314 -- Looks like a reference, but probably isn't: '1099' on line 314 -- Looks like a reference, but probably isn't: '500' on line 315 -- Looks like a reference, but probably isn't: '599' on line 315 == Unused Reference: 'RFC2328' is defined on line 1489, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 1503, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-filsfils-spring-segment-routing-ldp-interop-02 == Outdated reference: A later version (-05) exists of draft-ietf-spring-conflict-resolution-01 == Outdated reference: A later version (-15) exists of draft-ietf-spring-segment-routing-00 Summary: 0 errors (**), 0 flaws (~~), 8 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: September 1, 2017 Cisco Systems, Inc. 6 H. Gredler 7 RtBrick Inc. 8 R. Shakir 9 Google, Inc. 10 W. Henderickx 11 Nokia 12 J. Tantsura 13 Individual 14 February 28, 2017 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-11 19 Abstract 21 Segment Routing (SR) allows a flexible definition of end-to-end paths 22 within IGP topologies by encoding paths as sequences of topological 23 sub-paths, called "segments". These segments are advertised by the 24 link-state routing protocols (IS-IS and OSPF). 26 This draft describes the OSPF extensions required for Segment 27 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 September 1, 2017. 51 Copyright Notice 53 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . 6 74 3.3. SR Local Block Sub-TLV . . . . . . . . . . . . . . . . . 8 75 3.4. SRMS Preference Sub-TLV . . . . . . . . . . . . . . . . . 9 76 4. OSPF Extended Prefix Range TLV . . . . . . . . . . . . . . . 10 77 5. Prefix SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 12 78 6. SID/Label Binding Sub-TLV . . . . . . . . . . . . . . . . . . 16 79 6.1. ERO Metric Sub-TLV . . . . . . . . . . . . . . . . . . . 18 80 6.2. ERO Sub-TLVs . . . . . . . . . . . . . . . . . . . . . . 18 81 6.2.1. IPv4 ERO Sub-TLV . . . . . . . . . . . . . . . . . . 19 82 6.2.2. Unnumbered Interface ID ERO Sub-TLV . . . . . . . . . 19 83 6.2.3. IPv4 Backup ERO Sub-TLV . . . . . . . . . . . . . . . 21 84 6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV . . . . . 21 85 7. Adjacency Segment Identifier (Adj-SID) . . . . . . . . . . . 23 86 7.1. Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . . . 23 87 7.2. LAN Adj-SID Sub-TLV . . . . . . . . . . . . . . . . . . . 25 88 8. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 26 89 8.1. Intra-area Segment routing in OSPFv2 . . . . . . . . . . 26 90 8.2. Inter-area Segment routing in OSPFv2 . . . . . . . . . . 27 91 8.3. SID for External Prefixes . . . . . . . . . . . . . . . . 28 92 8.4. Advertisement of Adj-SID . . . . . . . . . . . . . . . . 29 93 8.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 29 94 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 29 95 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 96 9.1. OSPF OSPF Router Information (RI) TLVs Registry . . . . . 29 97 9.2. OSPF Extended Prefix LSA TLV Registry . . . . . . . . . . 30 98 9.3. OSPF Extended Prefix LSA Sub-TLV Registry . . . . . . . . 30 99 9.4. OSPF Extended Link LSA Sub-TLV Registry . . . . . . . . . 30 100 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 30 101 11. Security Considerations . . . . . . . . . . . . . . . . . . . 32 102 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32 103 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 104 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 105 14.1. Normative References . . . . . . . . . . . . . . . . . . 32 106 14.2. Informative References . . . . . . . . . . . . . . . . . 33 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 109 1. Introduction 111 Segment Routing (SR) allows a flexible definition of end-to-end paths 112 within IGP topologies by encoding paths as sequences of topological 113 sub-paths, called "segments". These segments are advertised by the 114 link-state routing protocols (IS-IS and OSPF). Prefix segments 115 represent an ECMP-aware shortest-path to a prefix (or a node), as per 116 the state of the IGP topology. Adjacency segments represent a hop 117 over a specific adjacency between two nodes in the IGP. A prefix 118 segment is typically a multi-hop path while an adjacency segment, in 119 most cases, is a one-hop path. SR's control-plane can be applied to 120 both IPv6 and MPLS data-planes, and does not require any additional 121 signalling (other than IGP extensions). The IPv6 data plane is out 122 of the scope of this specification - it is not applicable to OSPFv2 123 which only supports the IPv4 address-family. For example, when used 124 in MPLS networks, SR paths do not require any LDP or RSVP-TE 125 signalling. However, SR can interoperate in the presence of LSPs 126 established with RSVP or LDP. 128 This draft describes the OSPF extensions required for Segment 129 Routing. 131 Segment Routing architecture is described in 132 [I-D.ietf-spring-segment-routing]. 134 Segment Routing use cases are described in 135 [I-D.filsfils-spring-segment-routing-use-cases]. 137 2. Segment Routing Identifiers 139 Segment Routing defines various types of Segment Identifiers (SIDs): 140 Prefix-SID, Adjacency-SID, LAN Adjacency SID and Binding SID. 142 For the purpose of the advertisements of various SID values, new 143 Opaque LSAs [RFC5250] are defined in [RFC7684]. These LSAs are 144 generic containers that can be used to advertise any additional 145 attributes associated with a prefix or link. These Opaque LSAs are 146 complementary to the existing LSAs and are not aimed to replace any 147 of the existing LSAs. 149 2.1. SID/Label Sub-TLV 151 The SID/Label Sub-TLV appears in multiple TLVs or Sub-TLVs defined 152 later in this document. It is used to advertise the SID or label 153 associated with a prefix or adjacency. The SID/Label TLV has 154 following format: 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Type | Length | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | SID/Label (variable) | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 where: 166 Type: TBD, suggested value 1 168 Length: variable, 3 or 4 octet 170 SID/Label: If length is set to 3, then the 20 rightmost bits 171 represent a label. If length is set to 4, then the value 172 represents a 32-bit SID. 174 The receiving router MUST ignore SID/Label Sub-TLV if the length 175 is other then 3 or 4. 177 3. Segment Routing Capabilities 179 Segment Routing requires some additional router capabilities to be 180 advertised to other routers in the area. 182 These SR capabilities are advertised in the Router Information Opaque 183 LSA (defined in [RFC7770]). 185 3.1. SR-Algorithm TLV 187 The SR-Algorithm TLV is a top-level TLV of the Router Information 188 Opaque LSA (defined in [RFC7770]). 190 The SR-Algorithm Sub-TLV is optional. It MAY only be advertised once 191 in the Router Information Opaque LSA. If the SID/Label Range TLV, as 192 defined in Section 3.2, is advertised, then the SR-Algorithm TLV MUST 193 also be advertised. If the SR-Algorithm TLV is not advertised by the 194 node, such node is considered as not being segment routing capable. 196 An SR Router may use various algorithms when calculating reachability 197 to OSPF routers or prefixes in an OSPF area. Examples of these 198 algorithms are metric based Shortest Path First (SPF), various 199 flavors of Constrained SPF, etc. The SR-Algorithm TLV allows a 200 router to advertise the algorithms currently used by the router to 201 other routers in an OSPF area. The SR-Algorithm TLV has following 202 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 | Algorithm 1 | Algorithm... | Algorithm n | | 210 +- -+ 211 | | 212 + + 214 where: 216 Type: TBD, suggested value 8 218 Length: variable 220 Algorithm: Single octet identifying the algorithm. The following 221 values are defined by this document: 223 0: Shortest Path First (SPF) algorithm based on link metric. 224 This is the standard shortest path algorithm as computed by the 225 OSPF protocol. Consistent with the deployed practice for link- 226 state protocols, Algorithm 0 permits any node to overwrite the 227 SPF path with a different path based on its local policy. If 228 the SR-Algorithm Sub-TLV is advertised, Algorithm 0 MUST be 229 included. 231 1: Strict Shortest Path First (SPF) algorithm based on link 232 metric. The algorithm is identical to Algorithm 0 but 233 Algorithm 1 requires that all nodes along the path will honor 234 the SPF routing decision. Local policy at the node claiming 235 support for Algorithm 1 MUST NOT alter the SPF paths computed 236 by Algorithm 1. 238 When multiple SR-Algorithm sub-TLVs are received from a given router 239 the receiver SHOULD use the first occurrence of the sub-TLV in the 240 Router Information LSA. If the SR-Algorithm sub-TLV appears in 241 multiple Router Information LSAs that have different flooding scopes, 242 the SR-Algorithm sub-TLV in the Router Information LSA with the 243 lowest flooding scope SHOULD be used. If the SR-Algorithm sub-TLV 244 appears in multiple Router Information LSAs that have the same 245 flooding scope, the SR-Algorithm sub-TLV in the Router Information 246 LSA with the numerically smallest Instance ID SHOULD be used and 247 subsequent instances of the SR-Algorithm sub-TLV SHOULD be ignored. 249 The RI LSA can be advertised at any of the defined opaque flooding 250 scopes (link, area, or Autonomous System (AS)). For the purpose of 251 SR-Algorithm TLV advertisement, area scope flooding is required. 253 3.2. SID/Label Range TLV 255 The SID/Label Range TLV is a top-level TLV of the Router Information 256 Opaque LSA (defined in [RFC7770]). 258 The SID/Label Range TLV MAY appear multiple times and has the 259 following format: 261 0 1 2 3 262 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 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Type | Length | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Range Size | Reserved | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Sub-TLVs (variable) | 269 +- -+ 270 | | 271 + + 273 where: 275 Type: TBD, suggested value 9 277 Length: variable 279 Range Size: 3 octets of the SID/label range 281 Initially, the only supported Sub-TLV is the SID/Label TLV as defined 282 in Section 2.1. The SID/Label advertised in the SID/Label TLV 283 represents the first SID/Label in the advertised range. 285 Multiple occurrences of the SID/Label Range TLV MAY be advertised, in 286 order to advertise multiple ranges. In such case: 288 o The originating router MUST encode each range into a different 289 SID/Label Range TLV. 291 o The originating router decides the order in which the set of SID/ 292 Label Range TLVs are advertised inside the Router Information 293 Opaque LSA. The originating router MUST ensure the order is the 294 same after a graceful restart (using checkpointing, non-volatile 295 storage or any other mechanism) in order to assure the SID/label 296 range and SID index correspondence is preserved across graceful 297 restarts. 299 o The receiving router must adhere to the order in which the ranges 300 are advertised when calculating a SID/label from a SID index. 302 The following example illustrates the advertisement of multiple 303 ranges: 305 The originating router advertises following ranges: 306 Range 1: [100, 199] 307 Range 2: [1000, 1099] 308 Range 3: [500, 599] 310 The receiving routers concatenate the ranges and build the Segment 311 Routing Global Block (SRGB) as follows: 313 SRGB = [100, 199] 314 [1000, 1099] 315 [500, 599] 317 The indexes span multiple ranges: 319 index=0 means label 100 320 ... 321 index 99 means label 199 322 index 100 means label 1000 323 index 199 means label 1099 324 ... 325 index 200 means label 500 326 ... 328 The RI LSA can be advertised at any of the defined flooding scopes 329 (link, area, or autonomous system (AS)). For the purpose of SID/ 330 Label Range TLV advertisement, area scope flooding is required. 332 3.3. SR Local Block Sub-TLV 334 The SR Local Block (SRLB) Sub-TLV contains the range of labels the 335 node has reserved for local SIDs. Local SIDs are used, e.g., for 336 Adjacency-SIDs, and may also be allocated by other components than 337 OSPF protocol. As an example, an application or a controller may 338 instruct the router to allocate a specific local SID. Therefore, in 339 order for such applications or controllers to know what are the local 340 SIDs available in the router, it is required that the router 341 advertises its SRLB. The SRLB Sub-TLV is used for that purpose. 343 The SR Local Block (SRLB) Sub-TLV is a top-level TLV of the Router 344 Information Opaque LSA (defined in [RFC7770]). 346 The SR Local Block Sub-TLV MAY only be advertised once in the Router 347 Information Opaque LSA and has the following format: 349 0 1 2 3 350 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 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Type | Length | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Range Size | Reserved | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Sub-TLVs (variable) | 357 +- -+ 358 | | 359 + + 361 where: 363 Type: TBD, suggested value 12 365 Length: variable 367 Range Size: 3 octets of the SID/label range. MUST be higher then 368 0. 370 Initially, the only supported Sub-TLV is the SID/Label TLV as defined 371 in Section 2.1. The SID/Label advertised in the SID/Label TLV 372 represents the first SID/Label in the advertised range. 374 When multiple SRLB sub-TLVs are received from a given router the 375 receiver SHOULD use the first occurrence of the sub-TLV in the Router 376 Information LSA. If the SRLB sub-TLV appears in multiple Router 377 Information LSAs that have different flooding scopes, the SRLB sub- 378 TLV in the Router Information LSA with the lowest flooding scope 379 SHOULD be used. If the SRLB sub-TLV appears in multiple Router 380 Information LSAs that have the same flooding scope, the SRLB sub-TLV 381 in the Router Information LSA with the numerically smallest Instance 382 ID SHOULD be used and subsequent instances of the SRLB sub-TLV SHOULD 383 be ignored. 385 Each time a SID from the SRLB is allocated, it SHOULD also be 386 reported to all components (e.g.: controller or applications) in 387 order for these components to have an up-to-date view of the current 388 SRLB allocation. This is required to avoid collision between 389 allocation instructions. 391 Within the context of OSPF, the reporting of local SIDs is done 392 through OSPF Sub-TLVs such as the Adjacency-SID (Section 7). 393 However, the reporting of allocated local SIDs may also be done 394 through other means and protocols which mechanisms are outside the 395 scope of this document. 397 A router advertising the SRLB TLV may also have other label ranges, 398 outside of the SRLB, used for its local allocation purposes which are 399 NOT advertised in the SRLB. For example, it is possible that an 400 Adjacency-SID is allocated using a local label that is not part of 401 the SRLB. 403 The RI LSA can be advertised at any of the defined flooding scopes 404 (link, area, or autonomous system (AS)). For the purpose of SR Local 405 Block Sub-TLV TLV advertisement, area scope flooding is required. 407 3.4. SRMS Preference Sub-TLV 409 The Segment Routing Mapping Server (SRMS) Preference sub-TLV is used 410 to advertise a preference associated with the node that acts as a SR 411 Mapping Server. SRMS preference is defined in 412 [I-D.ietf-spring-conflict-resolution]. 414 The SRMS Preference Sub-TLV is a top-level TLV of the Router 415 Information Opaque LSA (defined in [RFC7770]). 417 The SRMS Preference Sub-TLV MAY only be advertised once in the Router 418 Information Opaque LSA and has the following format: 420 0 1 2 3 421 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 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Type | Length | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Preference | Reserved | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 where: 430 Type: TBD, suggested value 13 432 Length: 4 octets 434 Preference: 1 octet. SRMS preference value from 0 to 255. 436 When multiple SRMS Preference sub-TLVs are received from a given 437 router the receiver SHOULD use the first occurrence of the sub-TLV in 438 the Router Information LSA. If the SRMS Preference sub-TLV appears 439 in multiple Router Information LSAs that have different flooding 440 scopes, the SRLB sub-TLV in the Router Information LSA with the 441 lowest flooding scope SHOULD be used. If the SRMS Preference sub-TLV 442 appears in multiple Router Information LSAs that have the same 443 flooding scope, the SRMS Preference sub-TLV in the Router Information 444 LSA with the numerically smallest Instance ID SHOULD be used and 445 subsequent instances of the SRMS Preference sub-TLV SHOULD be 446 ignored. 448 The RI LSA can be advertised at any of the defined flooding scopes 449 (link, area, or autonomous system (AS)). For the purpose of the SRMS 450 Preference Sub-TLV advertisement, AS scope flooding is required. If 451 the SRMS advertisements from the SRMS server are only used inside the 452 area to which the SRMS server is attached, area scope flooding may be 453 used. 455 4. OSPF Extended Prefix Range TLV 457 In some cases it is useful to advertise attributes for a range of 458 prefixes. The Segment Routing Mapping Server, which is described in 459 [I-D.filsfils-spring-segment-routing-ldp-interop], is an example 460 where we need a single advertisement to advertise SIDs for multiple 461 prefixes from a contiguous address range. 463 The OSPF Extended Prefix Range TLV, which is a new top level TLV of 464 the Extended Prefix LSA described in [RFC7684] is defined for this 465 purpose. 467 Multiple OSPF Extended Prefix Range TLVs MAY be advertised in each 468 OSPF Extended Prefix Opaque LSA, but all prefix ranges included in a 469 single OSPF Extended Prefix Opaque LSA MUST have the same flooding 470 scope. The OSPF Extended Prefix Range TLV has the following format: 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Type | Length | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Prefix Length | AF | Range Size | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 | Flags | Reserved | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | Address Prefix (variable) | 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Sub-TLVs (variable) | 484 +- -+ 485 | | 487 where: 489 Type: TBD, suggested value 2. 491 Length: Variable 493 Prefix length: Length of the prefix 495 AF: 0 - IPv4 unicast 497 Range size: Represents the number of prefixes that are covered by 498 the advertisement. The Range Size MUST NOT exceed the number of 499 prefixes that could be satisfied by the prefix length without 500 including the IPv4 multicast address range (224.0.0.0/3). 502 Flags: Single octet field. The following flags are defined: 504 0 1 2 3 4 5 6 7 505 +--+--+--+--+--+--+--+--+ 506 |IA| | | | | | | | 507 +--+--+--+--+--+--+--+--+ 509 where: 511 IA-Flag: Inter-Area flag. If set, advertisement is of inter- 512 area type. The ABR that is advertising the OSPF Extended 513 Prefix Range TLV between areas MUST set this bit. 515 This bit is used to prevent redundant flooding of Prefix Range 516 TLVs between areas as follows: 518 An ABR always prefers intra-area Prefix Range advertisements 519 over inter-area advertisements. 521 An ABR does not consider inter-area Prefix Range 522 advertisements coming from non-backbone areas. 524 An ABR only propagates an inter-area Prefix Range 525 advertisement from the backbone area to connected non- 526 backbone areas if the advertisement is considered to be the 527 best one. 529 Address Prefix: The prefix, encoded as an even multiple of 32-bit 530 words, padded with zero bits as necessary. This encoding consumes 531 ((PrefixLength + 31) / 32) 32-bit words. The Address Prefix 532 represents the first prefix in the prefix range. 534 5. Prefix SID Sub-TLV 536 The Prefix SID Sub-TLV is a Sub-TLV of the OSPF Extended Prefix TLV 537 described in [RFC7684] and the OSPF Extended Prefix Range TLV 538 described in Section 4. It MAY appear more than once in the parent 539 TLV and has the following format: 541 0 1 2 3 542 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 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Type | Length | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 546 | Flags | Reserved | MT-ID | Algorithm | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | SID/Index/Label (variable) | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 where: 553 Type: TBD, suggested value 2. 555 Length: Variable 557 Flags: Single octet field. The following flags are defined: 559 0 1 2 3 4 5 6 7 560 +--+--+--+--+--+--+--+--+ 561 | |NP|M |E |V |L | | | 562 +--+--+--+--+--+--+--+--+ 564 where: 566 NP-Flag: No-PHP flag. If set, then the penultimate hop MUST 567 NOT pop the Prefix-SID before delivering packets to the node 568 that advertised the Prefix-SID. 570 M-Flag: Mapping Server Flag. If set, the SID was advertised by 571 a Segment Routing Mapping Server as described in 572 [I-D.filsfils-spring-segment-routing-ldp-interop]. 574 E-Flag: Explicit-Null Flag. If set, any upstream neighbor of 575 the Prefix-SID originator MUST replace the Prefix-SID with the 576 Explicit-NULL label (0 for IPv4) before forwarding the packet. 578 V-Flag: Value/Index Flag. If set, then the Prefix-SID carries 579 an absolute value. If not set, then the Prefix-SID carries an 580 index. 582 L-Flag: Local/Global Flag. If set, then the value/index 583 carried by the Prefix-SID has local significance. If not set, 584 then the value/index carried by this Sub-TLV has global 585 significance. 587 Other bits: Reserved. These MUST be zero when sent and are 588 ignored when received. 590 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 592 Algorithm: Single octet identifying the algorithm the Prefix-SID 593 is associated with as defined in Section 3.1. 595 A router receiving a Prefix-SID from a remote node and with an 596 algorithm value that such remote node has not advertised in the 597 SR-Algorithm sub-TLV (Section 3.1) MUST ignore the Prefix-SID sub- 598 TLV. 600 SID/Index/Label: According to the V and L flags, it contains 601 either: 603 A 32-bit index defining the offset in the SID/Label space 604 advertised by this router. 606 A 24-bit label where the 20 rightmost bits are used for 607 encoding the label value. 609 If multiple Prefix-SIDs are advertised for the same prefix, the 610 receiving router MUST use the first encoded SID and MAY use the 611 subsequent SIDs. 613 When propagating Prefix-SIDs between areas, if multiple prefix-SIDs 614 are advertised for a prefix, an implementation SHOULD preserve the 615 original order when advertising prefix-SIDs to other areas. This 616 allows implementations that only support a single Prefix-SID to have 617 a consistent view across areas. 619 When calculating the outgoing label for the prefix, the router MUST 620 take into account the E and P flags advertised by the next-hop router 621 if that router advertised the SID for the prefix. This MUST be done 622 regardless of whether the next-hop router contributes to the best 623 path to the prefix. 625 The NP-Flag (No-PHP) MUST be set for Prefix-SIDs allocated to inter- 626 area prefixes that are originated by the ABR based on intra-area or 627 inter-area reachability between areas. When the inter-area prefix is 628 generated based on a prefix which is directly attached to the ABR, 629 the NP-Flag SHOULD NOT be set. 631 The NP-Flag (No-PHP) MUST be be set for the Prefix-SIDs allocated to 632 redistributed prefixes, unless the redistributed prefix is directly 633 attached to the ASBR, in which case the NP-flag SHOULD NOT be set. 635 If the NP-Flag is not set, then any upstream neighbor of the Prefix- 636 SID originator MUST pop the Prefix-SID. This is equivalent to the 637 penultimate hop popping mechanism used in the MPLS dataplane. In 638 such case, MPLS EXP bits of the Prefix-SID are not preserved for the 639 final destination (the Prefix-SID being removed). If the NP-flag is 640 not set then the received E-flag is ignored. 642 If the NP-flag is set then: 644 If the E-flag is not set, then any upstream neighbor of the 645 Prefix-SID originator MUST keep the Prefix-SID on top of the 646 stack. This is useful when the originator of the Prefix-SID must 647 stitch the incoming packet into a continuing MPLS LSP to the final 648 destination. This could occur at an Area Border Router (prefix 649 propagation from one area to another) or at an AS Boundary Router 650 (prefix propagation from one domain to another). 652 If the E-flag is set, then any upstream neighbor of the Prefix-SID 653 originator MUST replace the Prefix-SID with an Explicit-NULL 654 label. This is useful, e.g., when the originator of the Prefix- 655 SID is the final destination for the related prefix and the 656 originator wishes to receive the packet with the original EXP 657 bits. 659 When the M-Flag is set, the NP-flag and the E-flag MUST be ignored at 660 reception. 662 As the Mapping Server does not specify the originator of a prefix 663 advertisement, it is not possible to determine PHP behavior solely 664 based on the Mapping Server advertisement. However, PHP behavior may 665 safely be done in following cases: 667 The Prefix is intra-area type and the downstream neighbor is the 668 originator of the prefix. 670 The Prefix is inter-area type and downstream neighbor is an ABR, 671 which is advertising the prefix reachability and is also 672 generating the Extended Prefix TLV with the A-flag set for this 673 prefix as described in section 2.1 of [RFC7684]. 675 The Prefix is external type and downstream neighbor is an ASBR, 676 which is advertising the prefix reachability and is also 677 generating the Extended Prefix TLV with the A-flag set for this 678 prefix as described in section 2.1 of [RFC7684]. 680 When a Prefix-SID is advertised in an Extended Prefix Range TLV, then 681 the value advertised in Prefix SID Sub-TLV is interpreted as a 682 starting SID value. 684 Example 1: If the following router addresses (loopback addresses) 685 need to be mapped into the corresponding Prefix SID indexes: 687 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 688 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 689 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 690 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 692 then the Prefix field in the Extended Prefix Range TLV would be set 693 to 192.0.2.1, Prefix Length would be set to 32, Range Size would be 694 set to 4, and the Index value in the Prefix-SID Sub-TLV would be set 695 to 1. 697 Example 2: If the following prefixes need to be mapped into the 698 corresponding Prefix-SID indexes: 700 10.1.1/24, Prefix-SID: Index 51 701 10.1.2/24, Prefix-SID: Index 52 702 10.1.3/24, Prefix-SID: Index 53 703 10.1.4/24, Prefix-SID: Index 54 704 10.1.5/24, Prefix-SID: Index 55 705 10.1.6/24, Prefix-SID: Index 56 706 10.1.7/24, Prefix-SID: Index 57 708 then the Prefix field in the Extended Prefix Range TLV would be set 709 to 10.1.1.0, Prefix Length would be set to 24, Range Size would be 7, 710 and the Index value in the Prefix-SID Sub-TLV would be set to 51. 712 6. SID/Label Binding Sub-TLV 714 The SID/Label Binding Sub-TLV is used to advertise a SID/Label 715 mapping for a path to the prefix. 717 The SID/Label Binding Sub-TLV MAY be originated by any router in an 718 OSPF domain. The router may advertise a SID/Label binding to a FEC 719 along with at least a single 'nexthop style' anchor. The protocol 720 supports more than one 'nexthop style' anchor to be attached to a 721 SID/Label binding, which results in a simple path description 722 language. In analogy to RSVP, the terminology for this is called an 723 'Explicit Route Object' (ERO). Since ERO style path notation allows 724 anchoring SID/label bindings to both link and node IP addresses, any 725 Label Switched Path (LSP) can be described. Additionally, SID/Label 726 Bindings from external protocols can be easily re-advertised. 728 The SID/Label Binding Sub-TLV may be used for advertising SID/Label 729 Bindings and their associated Primary and Backup paths. In a single 730 TLV, a primary ERO Path, backup ERO Path, or both can be advertised. 731 If a router wants to advertise multiple parallel paths, then it can 732 generate several TLVs for the same Prefix/FEC. Each occurrence of a 733 Binding TLV for a given FEC Prefix will add a new path. 735 The SID/Label Binding Sub-TLV is a Sub-TLV of the OSPF Extended 736 Prefix TLV described in [RFC7684] and the OSPF Extended Prefix Range 737 TLV described in Section 4. Multiple SID/Label Binding TLVs can be 738 present in their parent TLV. The SID/Label Binding Sub-TLV has 739 following format: 741 0 1 2 3 742 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 743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 | Type | Length | 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Flags | Reserved | MT-ID | Weight | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Sub-TLVs (variable) | 749 +- -+ 750 | | 752 where: 754 Type: TBD, suggested value 3 756 Length: Variable 758 Flags: Single octet field containing the following flags: 760 0 1 2 3 4 5 6 7 761 +-+-+-+-+-+-+-+-+ 762 |M| | 763 +-+-+-+-+-+-+-+-+ 765 where: 767 M-bit - When the bit is set, the binding represents a mirroring 768 context as defined in 769 [I-D.minto-rsvp-lsp-egress-fast-protection]. 771 MT-ID: Multi-Topology ID (as defined in [RFC4915]). 773 Weight: Weight used for load-balancing purposes. The use of the 774 weight is defined in [I-D.ietf-spring-segment-routing]. 776 The SID/Label Binding Sub-TLV supports the following Sub-TLVs: 778 SID/Label Sub-TLV as described in Section 2.1. This Sub-TLV MUST 779 appear in the SID/Label Binding Sub-TLV and it SHOULD only appear 780 once. If the SID/Label Sub-TLV is not included in the SID/Label 781 Binding Sub-TLV, the SID/Label Binding Sub-TLV MUST be ignored. 782 If the SID/Label Sub-TLV appears in the SID/Label Binding Sub-TLV 783 more than once, instances other than the first will be ignored and 784 the condition SHOULD be logged for possible action by the network 785 operator. 787 ERO Metric Sub-TLV as defined in Section 6.1. 789 ERO Sub-TLVs as defined in Section 6.2. 791 6.1. ERO Metric Sub-TLV 793 The ERO Metric Sub-TLV is a Sub-TLV of the SID/Label Binding TLV. 795 The ERO Metric Sub-TLV advertises the cost of an ERO path. It is 796 used to compare the cost of a given source/destination path. A 797 router SHOULD advertise the ERO Metric Sub-TLV in an advertised ERO 798 TLV. The cost of the ERO Metric Sub-TLV SHOULD be set to the 799 cumulative IGP or TE path cost of the advertised ERO. Since 800 manipulation of the Metric field may attract or repel traffic to and 801 from the advertised segment, it MAY be manually overridden. 803 0 1 2 3 804 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 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 | Type | Length | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 808 | Metric (4 octets) | 809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 811 ERO Metric Sub-TLV format 813 where: 815 Type: TBD, suggested value 8 817 Length: Always 4 819 Metric: A 4-octet metric representing the aggregate IGP or TE path 820 cost. 822 6.2. ERO Sub-TLVs 824 All ERO information represents an ordered set which describes the 825 segments of a path. The first ERO Sub-TLV describes the first 826 segment of a path. Similiarly, the last ERO Sub-TLV describes the 827 segment closest to the egress point. If a router extends or stitches 828 a path, it MUST prepend the new segment's path information to the ERO 829 list. This applies equally to advertised backup EROs. 831 All ERO Sub-TLVs must immediately follow the SID/Label Sub-TLV. 833 All Backup ERO Sub-TLVs must immediately follow the last ERO Sub-TLV. 835 6.2.1. IPv4 ERO Sub-TLV 837 The IPv4 ERO Sub-TLV is a Sub-TLV of the SID/Label Binding Sub-TLV. 839 The IPv4 ERO Sub-TLV describes a path segment using IPv4 Address 840 style encoding. Its semantics have been borrowed from [RFC3209]. 842 0 1 2 3 843 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 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | Type | Length | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Flags | Reserved | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | IPv4 Address (4 octets) | 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 IPv4 ERO Sub-TLV format 854 where: 856 Type: TBD, suggested value 4 858 Length: 8 octets 860 Flags: Single octet field containing the following flags: 862 0 1 2 3 4 5 6 7 863 +-+-+-+-+-+-+-+-+ 864 |L| | 865 +-+-+-+-+-+-+-+-+ 867 where: 869 L-bit - If the L-bit is set, then the segment path is 870 designated as 'loose'. Otherwise, the segment path is 871 designated as 'strict'. The terms 'loose' and 'strict' are 872 defined for RSVP subobjects in [RFC3209]. 874 IPv4 Address - The address of the explicit route hop. 876 6.2.2. Unnumbered Interface ID ERO Sub-TLV 878 The Unnumbered Interface ID ERO Sub-TLV is a Sub-TLV of the SID/Label 879 Binding Sub-TLV. 881 The appearance and semantics of the 'Unnumbered Interface ID' have 882 been borrowed from [RFC3477]. 884 The Unnumbered Interface-ID ERO Sub-TLV describes a path segment that 885 includes an unnumbered interface. Unnumbered interfaces are 886 referenced using the interface index. Interface indices are assigned 887 local to the router and therefore are not unique within a domain. 888 All elements in an ERO path need to be unique within a domain and 889 hence need to be disambiguated using a domain unique Router-ID. 891 0 1 2 3 892 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 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | Type | Length | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | Flags | Reserved | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Router ID | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 900 | Interface ID | 901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 where: 905 Unnumbered Interface ID ERO Sub-TLV format 907 Type: TBD, suggested value 5 909 Length: 12 octets 911 Flags: Single octet field containing the following flags: 913 0 1 2 3 4 5 6 7 914 +-+-+-+-+-+-+-+-+ 915 |L| | 916 +-+-+-+-+-+-+-+-+ 918 where: 920 L-bit - If the L-bit is set, then the segment path is 921 designated as 'loose'. Otherwise, the segment path is 922 designated as 'strict'. The terms 'loose' and 'strict' are 923 defined for RSVP subobjects in [RFC3209] 925 Router-ID: Router-ID of the next-hop. 927 Interface ID: The identifier assigned to the link by the router 928 specified by the Router-ID. 930 6.2.3. IPv4 Backup ERO Sub-TLV 932 IPv4 Prefix Backup ERO Sub-TLV is a Sub-TLV of the SID/Label Binding 933 Sub-TLV. 935 The IPv4 Backup ERO Sub-TLV describes a path segment using IPv4 936 Address style of encoding. Its semantics have been borrowed from 937 [RFC3209]. 939 0 1 2 3 940 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 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 942 | Type | Length | 943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 944 | Flags | Reserved | 945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 946 | IPv4 Address (4 octets) | 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 IPv4 Backup ERO Sub-TLV format 951 where: 953 Type: TBD, suggested value 6 955 Length: 8 octets 957 Flags: Single octet field containing the following flags: 959 0 1 2 3 4 5 6 7 960 +-+-+-+-+-+-+-+-+ 961 |L| | 962 +-+-+-+-+-+-+-+-+ 964 where: 966 L-bit - If the L-bit is set, then the segment path is 967 designated as 'loose'. Otherwise, the segment path is 968 designated as 'strict'. The terms 'loose' and 'strict' are 969 defined for RSVP subobjects in [RFC3209] 971 IPv4 Address - The address of the explicit route hop. 973 6.2.4. Unnumbered Interface ID Backup ERO Sub-TLV 975 The Unnumbered Interface ID Backup ERO Sub-TLV is a Sub-TLV of the 976 SID/Label Binding Sub-TLV. 978 The appearance and semantics of the 'Unnumbered Interface ID' have 979 been borrowed from [RFC3477]. 981 The Unnumbered Interface-ID Backup ERO Sub-TLV describes a path 982 segment that includes an unnumbered interface. Unnumbered interfaces 983 are referenced using the interface index. Interface indices are 984 assigned local to the router and are therefore not unique within a 985 domain. All elements in an ERO path need to be unique within a 986 domain and hence need to be disambiguated with specification of the 987 domain unique Router-ID. 989 0 1 2 3 990 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 991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 992 | Type | Length | 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Flags | Reserved | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Router ID | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | Interface ID | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1001 Unnumbered Interface ID Backup ERO Sub-TLV format 1003 where: 1005 Type: TBD, suggested value 7 1007 Length: 12 octets 1009 Flags: Single octet field containing the following flags: 1011 0 1 2 3 4 5 6 7 1012 +-+-+-+-+-+-+-+-+ 1013 |L| | 1014 +-+-+-+-+-+-+-+-+ 1016 where: 1018 L-bit - If the L-bit is set, then the segment path is 1019 designated as 'loose'. Otherwise, the segment path is 1020 designated as 'strict'. 1022 Router-ID: Router-ID of the next-hop. 1024 Interface ID: The identifier assigned to the link by the router 1025 specified by the Router-ID. 1027 7. Adjacency Segment Identifier (Adj-SID) 1029 An Adjacency Segment Identifier (Adj-SID) represents a router 1030 adjacency in Segment Routing. 1032 7.1. Adj-SID Sub-TLV 1034 Adj-SID is an optional Sub-TLV of the Extended Link TLV defined in 1035 [RFC7684]. It MAY appear multiple times in the Extended Link TLV. 1036 Examples where more than one Adj-SID may be used per neighbor are 1037 described in section 4 of 1038 [I-D.filsfils-spring-segment-routing-use-cases]. The Adj-SID Sub-TLV 1039 has the following format: 1041 0 1 2 3 1042 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 1043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1044 | Type | Length | 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | Flags | Reserved | MT-ID | Weight | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 | SID/Label/Index (variable) | 1049 +---------------------------------------------------------------+ 1051 where: 1053 Type: TBD, suggested value 2. 1055 Length: Variable. 1057 Flags: Single octet field containing the following flags: 1059 0 1 2 3 4 5 6 7 1060 +-+-+-+-+-+-+-+-+ 1061 |B|V|L|G|P| | 1062 +-+-+-+-+-+-+-+-+ 1064 where: 1066 B-Flag: Backup Flag. If set, the Adj-SID refers to an 1067 adjacency that is eligible for protection (e.g.: using IPFRR or 1068 MPLS-FRR) as described in section 3.5 of 1069 [I-D.ietf-spring-segment-routing]. 1071 The V-Flag: Value/Index Flag. If set, then the Adj-SID carries 1072 an absolute value. If not set, then the Adj-SID carries an 1073 index. 1075 The L-Flag: Local/Global Flag. If set, then the value/index 1076 carried by the Adj-SID has local significance. If not set, 1077 then the value/index carried by this Sub-TLV has global 1078 significance. 1080 The G-Flag: Group Flag. When set, the G-Flag indicates that 1081 the Adj-SID refers to a group of adjacencies (and therefore MAY 1082 be assigned to other adjacencies as well). 1084 P-Flag. Persistent flag. When set, the P-Flag indicates that 1085 the Adj-SID is persistently allocated, i.e., the Adj-SID value 1086 remains consistent across router restart and/or interface flap. 1088 Other bits: Reserved. These MUST be zero when sent and are 1089 ignored when received. 1091 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 1093 Weight: Weight used for load-balancing purposes. The use of the 1094 weight is defined in [I-D.ietf-spring-segment-routing]. 1096 SID/Index/Label: According to the V and L flags, it contains 1097 either: 1099 A 32-bit index defining the offset in the SID/Label space 1100 advertised by this router. 1102 A 24-bit label where the 20 rightmost bits are used for 1103 encoding the label value. 1105 An SR capable router MAY allocate an Adj-SID for each of its 1106 adjacencies and set the B-Flag when the adjacency is eligible for 1107 protection by an FRR mechanism (IP or MPLS) as described in section 1108 3.5 of [I-D.ietf-spring-segment-routing]. 1110 An SR capable router MAY allocate more than one Adj-SID to an 1111 adjacency 1113 An SR capable router MAY allocate the same Adj-SID to different 1114 adjacencies 1116 When the P-flag is not set, the Adj-SID MAY be persistent. When the 1117 P-flag is set, the Adj-SID MUST be persistent. 1119 7.2. LAN Adj-SID Sub-TLV 1121 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined 1122 in [RFC7684]. It MAY appear multiple times in the Extended-Link TLV. 1123 It is used to advertise a SID/Label for an adjacency to a non-DR 1124 router on a broadcast, NBMA, or hybrid [RFC6845] network. 1126 0 1 2 3 1127 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 1128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 | Type | Length | 1130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1131 | Flags | Reserved | MT-ID | Weight | 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | Neighbor ID | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | SID/Label/Index (variable) | 1136 +---------------------------------------------------------------+ 1138 where: 1140 Type: TBD, suggested value 3. 1142 Length: Variable. 1144 Flags: Single octet field containing the following flags: 1146 0 1 2 3 4 5 6 7 1147 +-+-+-+-+-+-+-+-+ 1148 |B|V|L|G|P| | 1149 +-+-+-+-+-+-+-+-+ 1151 where: 1153 B-Flag: Backup-flag. If set, the LAN-Adj-SID refers to an 1154 adjacency that is eligible for protection (e.g.: using IPFRR or 1155 MPLS-FRR) as described in section 3.5 of 1156 [I-D.ietf-spring-segment-routing]. 1158 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 1159 carries an absolute value. If not set, then the Prefix-SID 1160 carries an index. 1162 The L-Flag: Local/Global Flag. If set, then the value/index 1163 carried by the Prefix-SID has local significance. If not set, 1164 then the value/index carried by this Sub-TLV has global 1165 significance. 1167 The G-Flag: Group Flag. When set, the G-Flag indicates that 1168 the LAN-Adj-SID refers to a group of adjacencies (and therefore 1169 MAY be assigned to other adjacencies as well). 1171 P-Flag. Persistent flag. When set, the P-Flag indicates that 1172 the Adj-SID is persistently allocated, i.e., the Adj-SID value 1173 remains consistent across router restart and/or interface flap. 1175 Other bits: Reserved. These MUST be zero when sent and are 1176 ignored when received. 1178 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 1180 Weight: Weight used for load-balancing purposes. The use of the 1181 weight is defined in [I-D.ietf-spring-segment-routing]. 1183 Neighbor ID: The Router ID of the neighbor for which the LAN-Adj- 1184 SID is advertised. 1186 SID/Index/Label: According to the V and L flags, it contains 1187 either: 1189 A 32-bit index defining the offset in the SID/Label space 1190 advertised by this router. 1192 A 24-bit label where the 20 rightmost bits are used for 1193 encoding the label value. 1195 When the P-flag is not set, the Adj-SID MAY be persistent. When 1196 the P-flag is set, the Adj-SID MUST be persistent. 1198 8. Elements of Procedure 1200 8.1. Intra-area Segment routing in OSPFv2 1202 An OSPFv2 router that supports segment routing MAY advertise Prefix- 1203 SIDs for any prefix to which it is advertising reachability (e.g., a 1204 loopback IP address as described in Section 5). 1206 If multiple routers advertise a Prefix-SID for the same prefix, then 1207 the Prefix-SID MUST be the same. This is required in order to allow 1208 traffic load-balancing when multiple equal cost paths to the 1209 destination exist in the OSPFv2 routing domain. 1211 Prefix-SID can also be advertised by the SR Mapping Servers (as 1212 described in [I-D.filsfils-spring-segment-routing-ldp-interop]). The 1213 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 1214 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 1215 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 1216 MUST be advertised by all of them. The flooding scope of the OSPF 1217 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 1218 could be either area scoped or AS scoped and is determined based on 1219 the configuration of the SR Mapping Server. 1221 The SR Mapping Server MUST use OSPF Extended Prefix Range TLV when 1222 advertising SIDs for prefixes. Prefixes of different route-types can 1223 be combined in a single OSPF Extended Prefix Range TLV advertised by 1224 the SR Mapping Server. 1226 Area-scoped OSPF Extended Prefix Range TLV are propagated between 1227 areas. Similar to propagation of prefixes between areas, an ABR only 1228 propagates the OSPF Extended Prefix Range TLV that it considers to be 1229 the best from the set it received. The rules used to pick the best 1230 OSPF Extended Prefix Range TLV are described in Section 4. 1232 When propagating an OSPF Extended Prefix Range TLV between areas, 1233 ABRs MUST set the IA-Flag, that is used to prevent redundant flooding 1234 of the OSPF Extended Prefix Range TLV between areas as described in 1235 Section 4. 1237 8.2. Inter-area Segment routing in OSPFv2 1239 In order to support SR in a multi-area environment, OSPFv2 must 1240 propagate Prefix-SID information between areas. The following 1241 procedure is used to propagate Prefix SIDs between areas. 1243 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 1244 prefix to all its connected areas, it will also originate an Extended 1245 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 1246 the Extended Prefix Opaque LSA type will be set to area-scope. The 1247 route-type in the OSPF Extended Prefix TLV is set to inter-area. The 1248 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 1249 value will be set as follows: 1251 The ABR will look at its best path to the prefix in the source 1252 area and find the advertising router associated with the best path 1253 to that prefix. 1255 The ABR will then determine if such router advertised a Prefix-SID 1256 for the prefix and use it when advertising the Prefix-SID to other 1257 connected areas. 1259 If no Prefix-SID was advertised for the prefix in the source area 1260 by the router that contributes to the best path to the prefix, the 1261 originating ABR will use the Prefix-SID advertised by any other 1262 router when propagating the Prefix-SID for the prefix to other 1263 areas. 1265 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 1266 route to all its connected areas, it will also originate an Extended 1267 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 1268 the Extended Prefix Opaque LSA type will be set to area-scope. The 1269 route-type in OSPF Extended Prefix TLV is set to inter-area. The 1270 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 1271 will be set as follows: 1273 The ABR will look at its best path to the prefix in the backbone 1274 area and find the advertising router associated with the best path 1275 to that prefix. 1277 The ABR will then determine if such router advertised a Prefix-SID 1278 for the prefix and use it when advertising the Prefix-SID to other 1279 connected areas. 1281 If no Prefix-SID was advertised for the prefix in the backbone 1282 area by the ABR that contributes to the best path to the prefix, 1283 the originating ABR will use the Prefix-SID advertised by any 1284 other router when propagating the Prefix-SID for the prefix to 1285 other areas. 1287 8.3. SID for External Prefixes 1289 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 1290 SR, generates Type-5 LSAs, it should also originate Extended Prefix 1291 Opaque LSAs, as described in [RFC7684]. The flooding scope of the 1292 Extended Prefix Opaque LSA type is set to AS-scope. The route-type 1293 in the OSPF Extended Prefix TLV is set to external. The Prefix-SID 1294 Sub-TLV is included in this LSA and the Prefix-SID value will be set 1295 to the SID that has been reserved for that prefix. 1297 When an NSSA ABR translates Type-7 LSAs into Type-5 LSAs, it should 1298 also advertise the Prefix-SID for the prefix. The NSSA ABR 1299 determines its best path to the prefix advertised in the translated 1300 Type-7 LSA and finds the advertising router associated with that 1301 path. If the advertising router has advertised a Prefix-SID for the 1302 prefix, then the NSSA ABR uses it when advertising the Prefix-SID for 1303 the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other 1304 router will be used. 1306 8.4. Advertisement of Adj-SID 1308 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 1309 using the Adj-SID Sub-TLV as described in Section 7. 1311 8.4.1. Advertisement of Adj-SID on Point-to-Point Links 1313 An Adj-SID MAY be advertised for any adjacency on a P2P link that is 1314 in neighbor state 2-Way or higher. If the adjacency on a P2P link 1315 transitions from the FULL state, then the Adj-SID for that adjacency 1316 MAY be removed from the area. If the adjacency transitions to a 1317 state lower then 2-Way, then the Adj-SID advertisement MUST be 1318 removed from the area. 1320 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces 1322 Broadcast, NBMA or or hybrid [RFC6845] networks in OSPF are 1323 represented by a star topology where the Designated Router (DR) is 1324 the central point to which all other routers on the broadcast, NBMA, 1325 or hybrid network connect. As a result, routers on the broadcast, 1326 NBMA, or hybrid network advertise only their adjacency to the DR. 1327 Routers that do not act as DR do not form or advertise adjacencies 1328 with each other. They do, however, maintain 2-Way adjacency state 1329 with each other and are directly reachable. 1331 When Segment Routing is used, each router on the broadcast or NBMA 1332 network MAY advertise the Adj-SID for its adjacency to the DR using 1333 the Adj-SID Sub-TLV as described in Section 7.1. 1335 SR capable routers MAY also advertise an LAN-Adj-SID for other 1336 neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA or hybrid 1337 network using the LAN-ADJ-SID Sub-TLV as described in Section 7.2. 1339 9. IANA Considerations 1341 This specification updates several existing OSPF registries. 1343 9.1. OSPF OSPF Router Information (RI) TLVs Registry 1345 o 8 (IANA Preallocated) - SR-Algorithm TLV 1347 o 9 (IANA Preallocated) - SID/Label Range TLV 1349 o 12 - SR Local Block Sub-TLV 1351 o 13 - SRMS Preference Sub-TLV 1353 9.2. OSPF Extended Prefix LSA TLV Registry 1355 Following values are allocated: 1357 o 2 - OSPF Extended Prefix Range TLV 1359 9.3. OSPF Extended Prefix LSA Sub-TLV Registry 1361 Following values are allocated: 1363 o 1 - SID/Label Sub-TLV 1365 o 2 - Prefix SID Sub-TLV 1367 o 3 - SID/Label Binding Sub-TLV 1369 o 4 - IPv4 ERO Sub-TLV 1371 o 5 - Unnumbered Interface ID ERO Sub-TLV 1373 o 6 - IPv4 Backup ERO Sub-TLV 1375 o 7 - Unnumbered Interface ID Backup ERO Sub-TLV 1377 o 8 - ERO Metric Sub-TLV 1379 9.4. OSPF Extended Link LSA Sub-TLV Registry 1381 Following initial values are allocated: 1383 o 1 - SID/Label Sub-TLV 1385 o 2 - Adj-SID Sub-TLV 1387 o 3 - LAN Adj-SID/Label Sub-TLV 1389 10. Implementation Status 1391 An implementation survey with seven questions related to the 1392 implementer's support of OSPFv2 Segment Routing was sent to the OSPF 1393 WG list and several known implementers. This section contains 1394 responses from two implementers who completed the survey. No 1395 external means were used to verify the accuracy of the information 1396 submitted by the respondents. The respondents are considered experts 1397 on the products they reported on. Additionally, responses were 1398 omitted from implementers who indicated that they have not 1399 implemented the function yet. 1401 Responses from Nokia (former Alcatel-Lucent): 1403 Link to a web page describing the implementation: 1404 https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename.cgi/ 1405 3HE10799AAAATQZZA01_V1_7450%20ESS%207750%20SR%20and%207950%20XRS%20Un 1406 icast%20Routing%20Protocols%20Guide%20R14.0.R1.pdf 1408 The implementation's level of maturity: Production. 1410 Coverage: We have implemented all sections and have support for the 1411 latest draft. 1413 Licensing: Part of the software package that needs to be purchased. 1415 Implementation experience: Great spec. We also performed inter- 1416 operability testing with Cisco's OSPF Segment Routing implementation. 1418 Contact information: wim.henderickx@nokia.com 1420 Responses from Cisco Systems: 1422 Link to a web page describing the implementation: 1424 www.segment-routing.net/home/tutorial 1426 The implementation's level of maturity: Production. 1428 Coverage: All sections, except the section 6 (SID/Label Binding Sub- 1429 TLV) have been implemented according to the latest draft. 1431 Licensing: Part of a commercial software package. 1433 Implementation experience: Many aspects of the draft are result of 1434 the actual implementation experience, as the draft evolved from its 1435 initial version to the current one. Interoperability testing with 1436 Alcatel-Lucent was performed, which confirmed the draft's ability to 1437 serve as a reference for the implementors. 1439 Contact information: ppsenak@cisco.com 1441 Responses from Juniper: 1443 The implementation's name and/or a link to a web page describing the 1444 implementation: 1446 Feature name is OSPF SPRING 1447 The implementation's level of maturity: To be released in 16.2 1448 (second half of 2016) 1450 Coverage: All sections implemented except Sections 4, and 6. 1452 Licensing: JUNOS Licensing needed. 1454 Implementation experience: NA 1456 Contact information: shraddha@juniper.net 1458 11. Security Considerations 1460 Implementations must assure that malformed TLV and Sub-TLV 1461 permutations do not result in errors which cause hard OSPF failures. 1463 12. Contributors 1465 The following people gave a substantial contribution to the content 1466 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1467 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1468 Saku Ytti. 1470 13. Acknowledgements 1472 We would like to thank Anton Smirnov for his contribution. 1474 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1475 contribution on earlier definition of the "Binding / MPLS Label TLV". 1477 Thanks to Acee Lindem for the detail review of the draft, 1478 corrections, as well as discussion about details of the encoding. 1480 14. References 1482 14.1. Normative References 1484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1485 Requirement Levels", BCP 14, RFC 2119, 1486 DOI 10.17487/RFC2119, March 1997, 1487 . 1489 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1490 DOI 10.17487/RFC2328, April 1998, 1491 . 1493 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1494 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1495 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1496 . 1498 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1499 in Resource ReSerVation Protocol - Traffic Engineering 1500 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1501 . 1503 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1504 (TE) Extensions to OSPF Version 2", RFC 3630, 1505 DOI 10.17487/RFC3630, September 2003, 1506 . 1508 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1509 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1510 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1511 . 1513 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1514 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 1515 July 2008, . 1517 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 1518 and Point-to-Multipoint Interface Type", RFC 6845, 1519 DOI 10.17487/RFC6845, January 2013, 1520 . 1522 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1523 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1524 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1525 2015, . 1527 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1528 S. Shaffer, "Extensions to OSPF for Advertising Optional 1529 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 1530 February 2016, . 1532 14.2. Informative References 1534 [I-D.filsfils-spring-segment-routing-ldp-interop] 1535 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1536 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1537 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1538 "Segment Routing interoperability with LDP", draft- 1539 filsfils-spring-segment-routing-ldp-interop-02 (work in 1540 progress), September 2014. 1542 [I-D.filsfils-spring-segment-routing-use-cases] 1543 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1544 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1545 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1546 Crabbe, "Segment Routing Use Cases", draft-filsfils- 1547 spring-segment-routing-use-cases-01 (work in progress), 1548 October 2014. 1550 [I-D.ietf-spring-conflict-resolution] 1551 Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, 1552 "Segment Routing Conflict Resolution", draft-ietf-spring- 1553 conflict-resolution-01 (work in progress), June 2016. 1555 [I-D.ietf-spring-segment-routing] 1556 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1557 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 1558 and E. Crabbe, "Segment Routing Architecture", draft-ietf- 1559 spring-segment-routing-00 (work in progress), December 1560 2014. 1562 [I-D.minto-rsvp-lsp-egress-fast-protection] 1563 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1564 egress fast-protection", draft-minto-rsvp-lsp-egress-fast- 1565 protection-03 (work in progress), November 2013. 1567 Authors' Addresses 1569 Peter Psenak (editor) 1570 Cisco Systems, Inc. 1571 Apollo Business Center 1572 Mlynske nivy 43 1573 Bratislava 821 09 1574 Slovakia 1576 Email: ppsenak@cisco.com 1578 Stefano Previdi (editor) 1579 Cisco Systems, Inc. 1580 Via Del Serafico, 200 1581 Rome 00142 1582 Italy 1584 Email: sprevidi@cisco.com 1585 Clarence Filsfils 1586 Cisco Systems, Inc. 1587 Brussels 1588 Belgium 1590 Email: cfilsfil@cisco.com 1592 Hannes Gredler 1593 RtBrick Inc. 1595 Email: hannes@rtbrick.com 1597 Rob Shakir 1598 Google, Inc. 1599 1600 Amphitheatre Parkway 1600 Mountain View, CA 94043 1601 US 1603 Email: robjs@google.com 1605 Wim Henderickx 1606 Nokia 1607 Copernicuslaan 50 1608 Antwerp 2018 1609 BE 1611 Email: wim.henderickx@nokia.com 1613 Jeff Tantsura 1614 Individual 1615 US 1617 Email: jefftant.ietf@gmail.com