idnits 2.17.1 draft-ietf-ospf-segment-routing-extensions-10.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 (October 28, 2016) is 2737 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 1470, but no explicit reference was found in the text == Unused Reference: 'RFC3630' is defined on line 1484, 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: May 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 October 28, 2016 16 OSPF Extensions for Segment Routing 17 draft-ietf-ospf-segment-routing-extensions-10 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 May 1, 2017. 51 Copyright Notice 53 Copyright (c) 2016 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 . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . 28 93 8.4.1. Advertisement of Adj-SID on Point-to-Point Links . . 28 94 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces . . . . 28 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 . . . . . . . . . . 29 98 9.3. OSPF Extended Prefix LSA Sub-TLV Registry . . . . . . . . 29 99 9.4. OSPF Extended Link LSA Sub-TLV Registry . . . . . . . . . 30 100 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 30 101 11. Security Considerations . . . . . . . . . . . . . . . . . . . 31 102 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 31 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| | 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 Other bits: Reserved. These MUST be zero when sent and are 1085 ignored when received. 1087 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 1089 Weight: Weight used for load-balancing purposes. The use of the 1090 weight is defined in [I-D.ietf-spring-segment-routing]. 1092 SID/Index/Label: According to the V and L flags, it contains 1093 either: 1095 A 32-bit index defining the offset in the SID/Label space 1096 advertised by this router. 1098 A 24-bit label where the 20 rightmost bits are used for 1099 encoding the label value. 1101 An SR capable router MAY allocate an Adj-SID for each of its 1102 adjacencies and set the B-Flag when the adjacency is eligible for 1103 protection by an FRR mechanism (IP or MPLS) as described in section 1104 3.5 of [I-D.ietf-spring-segment-routing]. 1106 7.2. LAN Adj-SID Sub-TLV 1108 LAN Adj-SID is an optional Sub-TLV of the Extended Link TLV defined 1109 in [RFC7684]. It MAY appear multiple times in the Extended-Link TLV. 1110 It is used to advertise a SID/Label for an adjacency to a non-DR 1111 router on a broadcast, NBMA, or hybrid [RFC6845] network. 1113 0 1 2 3 1114 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 1115 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 | Type | Length | 1117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1118 | Flags | Reserved | MT-ID | Weight | 1119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 | Neighbor ID | 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | SID/Label/Index (variable) | 1123 +---------------------------------------------------------------+ 1125 where: 1127 Type: TBD, suggested value 3. 1129 Length: Variable. 1131 Flags: Single octet field containing the following flags: 1133 0 1 2 3 4 5 6 7 1134 +-+-+-+-+-+-+-+-+ 1135 |B|V|L|G| | 1136 +-+-+-+-+-+-+-+-+ 1138 where: 1140 B-Flag: Backup-flag. If set, the LAN-Adj-SID refers to an 1141 adjacency that is eligible for protection (e.g.: using IPFRR or 1142 MPLS-FRR) as described in section 3.5 of 1143 [I-D.ietf-spring-segment-routing]. 1145 The V-Flag: Value/Index Flag. If set, then the Prefix-SID 1146 carries an absolute value. If not set, then the Prefix-SID 1147 carries an index. 1149 The L-Flag: Local/Global Flag. If set, then the value/index 1150 carried by the Prefix-SID has local significance. If not set, 1151 then the value/index carried by this Sub-TLV has global 1152 significance. 1154 The G-Flag: Group Flag. When set, the G-Flag indicates that 1155 the LAN-Adj-SID refers to a group of adjacencies (and therefore 1156 MAY be assigned to other adjacencies as well). 1158 Other bits: Reserved. These MUST be zero when sent and are 1159 ignored when received. 1161 MT-ID: Multi-Topology ID (as defined in [RFC4915]. 1163 Weight: Weight used for load-balancing purposes. The use of the 1164 weight is defined in [I-D.ietf-spring-segment-routing]. 1166 Neighbor ID: The Router ID of the neighbor for which the LAN-Adj- 1167 SID is advertised. 1169 SID/Index/Label: According to the V and L flags, it contains 1170 either: 1172 A 32-bit index defining the offset in the SID/Label space 1173 advertised by this router. 1175 A 24-bit label where the 20 rightmost bits are used for 1176 encoding the label value. 1178 8. Elements of Procedure 1180 8.1. Intra-area Segment routing in OSPFv2 1182 An OSPFv2 router that supports segment routing MAY advertise Prefix- 1183 SIDs for any prefix to which it is advertising reachability (e.g., a 1184 loopback IP address as described in Section 5). 1186 If multiple routers advertise a Prefix-SID for the same prefix, then 1187 the Prefix-SID MUST be the same. This is required in order to allow 1188 traffic load-balancing when multiple equal cost paths to the 1189 destination exist in the OSPFv2 routing domain. 1191 Prefix-SID can also be advertised by the SR Mapping Servers (as 1192 described in [I-D.filsfils-spring-segment-routing-ldp-interop]). The 1193 Mapping Server advertises Prefix-SIDs for remote prefixes that exist 1194 in the OSPFv2 routing domain. Multiple Mapping Servers can advertise 1195 Prefix-SIDs for the same prefix, in which case the same Prefix-SID 1196 MUST be advertised by all of them. The flooding scope of the OSPF 1197 Extended Prefix Opaque LSA that is generated by the SR Mapping Server 1198 could be either area scoped or AS scoped and is determined based on 1199 the configuration of the SR Mapping Server. 1201 The SR Mapping Server MUST use OSPF Extended Prefix Range TLV when 1202 advertising SIDs for prefixes. Prefixes of different route-types can 1203 be combined in a single OSPF Extended Prefix Range TLV advertised by 1204 the SR Mapping Server. 1206 Area-scoped OSPF Extended Prefix Range TLV are propagated between 1207 areas. Similar to propagation of prefixes between areas, an ABR only 1208 propagates the OSPF Extended Prefix Range TLV that it considers to be 1209 the best from the set it received. The rules used to pick the best 1210 OSPF Extended Prefix Range TLV are described in Section 4. 1212 When propagating an OSPF Extended Prefix Range TLV between areas, 1213 ABRs MUST set the IA-Flag, that is used to prevent redundant flooding 1214 of the OSPF Extended Prefix Range TLV between areas as described in 1215 Section 4. 1217 8.2. Inter-area Segment routing in OSPFv2 1219 In order to support SR in a multi-area environment, OSPFv2 must 1220 propagate Prefix-SID information between areas. The following 1221 procedure is used to propagate Prefix SIDs between areas. 1223 When an OSPF ABR advertises a Type-3 Summary LSA from an intra-area 1224 prefix to all its connected areas, it will also originate an Extended 1225 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 1226 the Extended Prefix Opaque LSA type will be set to area-scope. The 1227 route-type in the OSPF Extended Prefix TLV is set to inter-area. The 1228 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 1229 value will be set as follows: 1231 The ABR will look at its best path to the prefix in the source 1232 area and find the advertising router associated with the best path 1233 to that prefix. 1235 The ABR will then determine if such router advertised a Prefix-SID 1236 for the prefix and use it when advertising the Prefix-SID to other 1237 connected areas. 1239 If no Prefix-SID was advertised for the prefix in the source area 1240 by the router that contributes to the best path to the prefix, the 1241 originating ABR will use the Prefix-SID advertised by any other 1242 router when propagating the Prefix-SID for the prefix to other 1243 areas. 1245 When an OSPF ABR advertises Type-3 Summary LSAs from an inter-area 1246 route to all its connected areas, it will also originate an Extended 1247 Prefix Opaque LSA, as described in [RFC7684]. The flooding scope of 1248 the Extended Prefix Opaque LSA type will be set to area-scope. The 1249 route-type in OSPF Extended Prefix TLV is set to inter-area. The 1250 Prefix-SID Sub-TLV will be included in this LSA and the Prefix-SID 1251 will be set as follows: 1253 The ABR will look at its best path to the prefix in the backbone 1254 area and find the advertising router associated with the best path 1255 to that prefix. 1257 The ABR will then determine if such router advertised a Prefix-SID 1258 for the prefix and use it when advertising the Prefix-SID to other 1259 connected areas. 1261 If no Prefix-SID was advertised for the prefix in the backbone 1262 area by the ABR that contributes to the best path to the prefix, 1263 the originating ABR will use the Prefix-SID advertised by any 1264 other router when propagating the Prefix-SID for the prefix to 1265 other areas. 1267 8.3. SID for External Prefixes 1269 Type-5 LSAs are flooded domain wide. When an ASBR, which supports 1270 SR, generates Type-5 LSAs, it should also originate Extended Prefix 1271 Opaque LSAs, as described in [RFC7684]. The flooding scope of the 1272 Extended Prefix Opaque LSA type is set to AS-scope. The route-type 1273 in the OSPF Extended Prefix TLV is set to external. The Prefix-SID 1274 Sub-TLV is included in this LSA and the Prefix-SID value will be set 1275 to the SID that has been reserved for that prefix. 1277 When an NSSA ABR translates Type-7 LSAs into Type-5 LSAs, it should 1278 also advertise the Prefix-SID for the prefix. The NSSA ABR 1279 determines its best path to the prefix advertised in the translated 1280 Type-7 LSA and finds the advertising router associated with that 1281 path. If the advertising router has advertised a Prefix-SID for the 1282 prefix, then the NSSA ABR uses it when advertising the Prefix-SID for 1283 the Type-5 prefix. Otherwise, the Prefix-SID advertised by any other 1284 router will be used. 1286 8.4. Advertisement of Adj-SID 1288 The Adjacency Segment Routing Identifier (Adj-SID) is advertised 1289 using the Adj-SID Sub-TLV as described in Section 7. 1291 8.4.1. Advertisement of Adj-SID on Point-to-Point Links 1293 An Adj-SID MAY be advertised for any adjacency on a P2P link that is 1294 in neighbor state 2-Way or higher. If the adjacency on a P2P link 1295 transitions from the FULL state, then the Adj-SID for that adjacency 1296 MAY be removed from the area. If the adjacency transitions to a 1297 state lower then 2-Way, then the Adj-SID advertisement MUST be 1298 removed from the area. 1300 8.4.2. Adjacency SID on Broadcast or NBMA Interfaces 1302 Broadcast, NBMA or or hybrid [RFC6845] networks in OSPF are 1303 represented by a star topology where the Designated Router (DR) is 1304 the central point to which all other routers on the broadcast, NBMA, 1305 or hybrid network connect. As a result, routers on the broadcast, 1306 NBMA, or hybrid network advertise only their adjacency to the DR. 1307 Routers that do not act as DR do not form or advertise adjacencies 1308 with each other. They do, however, maintain 2-Way adjacency state 1309 with each other and are directly reachable. 1311 When Segment Routing is used, each router on the broadcast or NBMA 1312 network MAY advertise the Adj-SID for its adjacency to the DR using 1313 the Adj-SID Sub-TLV as described in Section 7.1. 1315 SR capable routers MAY also advertise an LAN-Adj-SID for other 1316 neighbors (e.g., BDR, DR-OTHER) on the broadcast, NBMA or hybrid 1317 network using the LAN-ADJ-SID Sub-TLV as described in Section 7.2. 1319 9. IANA Considerations 1321 This specification updates several existing OSPF registries. 1323 9.1. OSPF OSPF Router Information (RI) TLVs Registry 1325 o 8 (IANA Preallocated) - SR-Algorithm TLV 1327 o 9 (IANA Preallocated) - SID/Label Range TLV 1329 o 12 - SR Local Block Sub-TLV 1331 o 13 - SRMS Preference Sub-TLV 1333 9.2. OSPF Extended Prefix LSA TLV Registry 1335 Following values are allocated: 1337 o 2 - OSPF Extended Prefix Range TLV 1339 9.3. OSPF Extended Prefix LSA Sub-TLV Registry 1341 Following values are allocated: 1343 o 1 - SID/Label Sub-TLV 1345 o 2 - Prefix SID Sub-TLV 1347 o 3 - SID/Label Binding Sub-TLV 1349 o 4 - IPv4 ERO Sub-TLV 1351 o 5 - Unnumbered Interface ID ERO Sub-TLV 1352 o 6 - IPv4 Backup ERO Sub-TLV 1354 o 7 - Unnumbered Interface ID Backup ERO Sub-TLV 1356 o 8 - ERO Metric Sub-TLV 1358 9.4. OSPF Extended Link LSA Sub-TLV Registry 1360 Following initial values are allocated: 1362 o 1 - SID/Label Sub-TLV 1364 o 2 - Adj-SID Sub-TLV 1366 o 3 - LAN Adj-SID/Label Sub-TLV 1368 10. Implementation Status 1370 An implementation survey with seven questions related to the 1371 implementer's support of OSPFv2 Segment Routing was sent to the OSPF 1372 WG list and several known implementers. This section contains 1373 responses from two implementers who completed the survey. No 1374 external means were used to verify the accuracy of the information 1375 submitted by the respondents. The respondents are considered experts 1376 on the products they reported on. Additionally, responses were 1377 omitted from implementers who indicated that they have not 1378 implemented the function yet. 1380 Responses from Nokia (former Alcatel-Lucent): 1382 Link to a web page describing the implementation: 1383 https://infoproducts.alcatel-lucent.com/cgi-bin/dbaccessfilename.cgi/ 1384 3HE10799AAAATQZZA01_V1_7450%20ESS%207750%20SR%20and%207950%20XRS%20Un 1385 icast%20Routing%20Protocols%20Guide%20R14.0.R1.pdf 1387 The implementation's level of maturity: Production. 1389 Coverage: We have implemented all sections and have support for the 1390 latest draft. 1392 Licensing: Part of the software package that needs to be purchased. 1394 Implementation experience: Great spec. We also performed inter- 1395 operability testing with Cisco's OSPF Segment Routing implementation. 1397 Contact information: wim.henderickx@nokia.com 1399 Responses from Cisco Systems: 1401 Link to a web page describing the implementation: 1403 www.segment-routing.net/home/tutorial 1405 The implementation's level of maturity: Production. 1407 Coverage: All sections, except the section 6 (SID/Label Binding Sub- 1408 TLV) have been implemented according to the latest draft. 1410 Licensing: Part of a commercial software package. 1412 Implementation experience: Many aspects of the draft are result of 1413 the actual implementation experience, as the draft evolved from its 1414 initial version to the current one. Interoperability testing with 1415 Alcatel-Lucent was performed, which confirmed the draft's ability to 1416 serve as a reference for the implementors. 1418 Contact information: ppsenak@cisco.com 1420 Responses from Juniper: 1422 The implementation's name and/or a link to a web page describing the 1423 implementation: 1425 Feature name is OSPF SPRING 1427 The implementation's level of maturity: To be released in 16.2 1428 (second half of 2016) 1430 Coverage: All sections implemented except Sections 4, and 6. 1432 Licensing: JUNOS Licensing needed. 1434 Implementation experience: NA 1436 Contact information: shraddha@juniper.net 1438 11. Security Considerations 1440 Implementations must assure that malformed TLV and Sub-TLV 1441 permutations do not result in errors which cause hard OSPF failures. 1443 12. Contributors 1445 The following people gave a substantial contribution to the content 1446 of this document: Acee Lindem, Ahmed Bashandy, Martin Horneffer, 1447 Bruno Decraene, Stephane Litkowski, Igor Milojevic, Rob Shakir and 1448 Saku Ytti. 1450 13. Acknowledgements 1452 We would like to thank Anton Smirnov for his contribution. 1454 Many thanks to Yakov Rekhter, John Drake and Shraddha Hedge for their 1455 contribution on earlier incarnations of the "Binding / MPLS Label 1456 TLV" in [I-D.gredler-ospf-label-advertisement]. 1458 Thanks to Acee Lindem for the detail review of the draft, 1459 corrections, as well as discussion about details of the encoding. 1461 14. References 1463 14.1. Normative References 1465 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1466 Requirement Levels", BCP 14, RFC 2119, 1467 DOI 10.17487/RFC2119, March 1997, 1468 . 1470 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 1471 DOI 10.17487/RFC2328, April 1998, 1472 . 1474 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1475 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1476 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 1477 . 1479 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1480 in Resource ReSerVation Protocol - Traffic Engineering 1481 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 1482 . 1484 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1485 (TE) Extensions to OSPF Version 2", RFC 3630, 1486 DOI 10.17487/RFC3630, September 2003, 1487 . 1489 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1490 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1491 RFC 4915, DOI 10.17487/RFC4915, June 2007, 1492 . 1494 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1495 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 1496 July 2008, . 1498 [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast 1499 and Point-to-Multipoint Interface Type", RFC 6845, 1500 DOI 10.17487/RFC6845, January 2013, 1501 . 1503 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 1504 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 1505 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 1506 2015, . 1508 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 1509 S. Shaffer, "Extensions to OSPF for Advertising Optional 1510 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 1511 February 2016, . 1513 14.2. Informative References 1515 [I-D.filsfils-spring-segment-routing-ldp-interop] 1516 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1517 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1518 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 1519 "Segment Routing interoperability with LDP", draft- 1520 filsfils-spring-segment-routing-ldp-interop-02 (work in 1521 progress), September 2014. 1523 [I-D.filsfils-spring-segment-routing-use-cases] 1524 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 1525 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 1526 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 1527 Crabbe, "Segment Routing Use Cases", draft-filsfils- 1528 spring-segment-routing-use-cases-01 (work in progress), 1529 October 2014. 1531 [I-D.gredler-ospf-label-advertisement] 1532 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1533 "Advertising MPLS labels in OSPF", draft-gredler-ospf- 1534 label-advertisement-03 (work in progress), May 2013. 1536 [I-D.ietf-spring-conflict-resolution] 1537 Ginsberg, L., Psenak, P., Previdi, S., and M. Pilka, 1538 "Segment Routing Conflict Resolution", draft-ietf-spring- 1539 conflict-resolution-01 (work in progress), June 2016. 1541 [I-D.ietf-spring-segment-routing] 1542 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 1543 Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., 1544 and E. Crabbe, "Segment Routing Architecture", draft-ietf- 1545 spring-segment-routing-00 (work in progress), December 1546 2014. 1548 [I-D.minto-rsvp-lsp-egress-fast-protection] 1549 Jeganathan, J., Gredler, H., and Y. Shen, "RSVP-TE LSP 1550 egress fast-protection", draft-minto-rsvp-lsp-egress-fast- 1551 protection-03 (work in progress), November 2013. 1553 Authors' Addresses 1555 Peter Psenak (editor) 1556 Cisco Systems, Inc. 1557 Apollo Business Center 1558 Mlynske nivy 43 1559 Bratislava 821 09 1560 Slovakia 1562 Email: ppsenak@cisco.com 1564 Stefano Previdi (editor) 1565 Cisco Systems, Inc. 1566 Via Del Serafico, 200 1567 Rome 00142 1568 Italy 1570 Email: sprevidi@cisco.com 1572 Clarence Filsfils 1573 Cisco Systems, Inc. 1574 Brussels 1575 Belgium 1577 Email: cfilsfil@cisco.com 1579 Hannes Gredler 1580 RtBrick Inc. 1582 Email: hannes@rtbrick.com 1583 Rob Shakir 1584 Google, Inc. 1585 1600 Amphitheatre Parkway 1586 Mountain View, CA 94043 1587 US 1589 Email: robjs@google.com 1591 Wim Henderickx 1592 Nokia 1593 Copernicuslaan 50 1594 Antwerp 2018 1595 BE 1597 Email: wim.henderickx@nokia.com 1599 Jeff Tantsura 1600 Individual 1601 US 1603 Email: jefftant.ietf@gmail.com