idnits 2.17.1 draft-gredler-ospf-label-advertisement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.gredler-rtgwg-igp-label-advertisement]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 41 instances 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 5, 2013) is 4008 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) == Outdated reference: A later version (-05) exists of draft-gredler-rtgwg-igp-label-advertisement-03 == Outdated reference: A later version (-10) exists of draft-ietf-rtgwg-mrt-frr-architecture-02 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Open Shortest Path First IGP H. Gredler, Ed. 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track S. Amante 5 Expires: November 6, 2013 Level 3 Communications, Inc. 6 T. Scholl 7 Amazon 8 L. Jalil 9 Verizon 10 May 5, 2013 12 Advertising MPLS labels in OSPF 13 draft-gredler-ospf-label-advertisement-01 15 Abstract 17 Historically MPLS label distribution was driven by protocols like 18 LDP, RSVP and LBGP. All of those protocols are session oriented. In 19 order to obtain label binding for a given destination FEC from a 20 given router one needs first to establish an LDP/RSVP/LBGP session 21 with that router. 23 Advertising MPLS labels in IGPs advertisement 24 [I-D.gredler-rtgwg-igp-label-advertisement] describes several use 25 cases where utilizing the flooding machinery of link-state protocols 26 for MPLS label distribution allows to obtain the binding without 27 requiring to establish an LDP/RSVP/LBGP session with that router. 29 This document describes the protocol extension to distribute MPLS 30 labels by the OSPFv2 and OSPFv3 protocol. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on November 6, 2013. 55 Copyright Notice 57 Copyright (c) 2013 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2. Motivation, Rationale and Applicability . . . . . . . . . . . 5 74 2.1. Issue: Bi-directionality semantics . . . . . . . . . . . . 6 75 2.2. Issue: IP path semantics . . . . . . . . . . . . . . . . . 6 76 2.3. Issue: Lack of 'path' notion . . . . . . . . . . . . . . . 6 77 2.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 7 78 3. OSPF MPLS LSA Format . . . . . . . . . . . . . . . . . . . . . 7 79 3.1. Common LSA Type . . . . . . . . . . . . . . . . . . . . . 7 80 3.2. OSPFv2 LSA ID . . . . . . . . . . . . . . . . . . . . . . 7 81 3.3. OSPFv2 LSA Format Overview . . . . . . . . . . . . . . . . 7 82 3.4. OSPFv3 LSA ID . . . . . . . . . . . . . . . . . . . . . . 8 83 3.5. OSPFv3 LSA Format Overview . . . . . . . . . . . . . . . . 8 84 3.6. TLV Header . . . . . . . . . . . . . . . . . . . . . . . . 9 85 4. LSA payload details . . . . . . . . . . . . . . . . . . . . . 10 86 4.1. Prefix ERO TLVs . . . . . . . . . . . . . . . . . . . . . 10 87 4.1.1. IPv4 Prefix ERO TLV . . . . . . . . . . . . . . . . . 10 88 4.1.2. IPv6 Prefix ERO TLV . . . . . . . . . . . . . . . . . 11 89 4.2. IPv4 Prefix Bypass ERO TLV . . . . . . . . . . . . . . . . 12 90 4.3. IPv6 Prefix Bypass ERO TLV . . . . . . . . . . . . . . . . 13 91 4.4. Flags TLV . . . . . . . . . . . . . . . . . . . . . . . . 13 92 4.5. All Router Block TLV . . . . . . . . . . . . . . . . . . . 14 93 4.6. All Router ID IPv4 Map TLV . . . . . . . . . . . . . . . . 15 94 4.7. All Router ID IPv6 Map TLV . . . . . . . . . . . . . . . . 16 95 5. Advertising Label Examples . . . . . . . . . . . . . . . . . . 17 96 5.1. Sample Topology . . . . . . . . . . . . . . . . . . . . . 17 97 5.1.1. Transport IP addresses and router-IDs . . . . . . . . 18 98 5.1.2. Link IP addresses . . . . . . . . . . . . . . . . . . 18 99 5.2. One-hop LSP to an adjacent Router . . . . . . . . . . . . 19 100 5.3. One-hop LSP to an adjacent Router using a specific link . 19 101 5.4. One-hop LSP to an adjacent external Router . . . . . . . . 19 102 5.5. Advertisement of an RSVP LSP . . . . . . . . . . . . . . . 20 103 5.6. Advertisement of an LDP LSP . . . . . . . . . . . . . . . 20 104 5.7. Interarea advertisement of diverse paths . . . . . . . . . 20 105 5.8. Advertisement of SPT labels using 'All Router Block' 106 TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 107 6. Inter Area Protocol Procedures . . . . . . . . . . . . . . . . 22 108 6.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 22 109 6.2. Data plane operations . . . . . . . . . . . . . . . . . . 23 110 6.3. Control plane operations . . . . . . . . . . . . . . . . . 23 111 6.3.1. MPLS Label operations . . . . . . . . . . . . . . . . 23 112 6.3.2. MPLS Label Block operations . . . . . . . . . . . . . 23 113 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 114 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 115 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 116 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 117 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 118 10.2. Informative References . . . . . . . . . . . . . . . . . . 25 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 121 1. Introduction 123 MPLS label allocations are predominantly distributed by using the LDP 124 [RFC5036], RSVP [RFC5151] or labeled BGP [RFC3107] protocol. All of 125 those protocols have in common that they are session oriented, which 126 means that in order to obtain label binding for a given destination 127 FEC from a given router one needs first to establish a direct control 128 plane (LDP/RSVP/LBGP) session with that router. 130 There are a couple of use cases 131 [I-D.gredler-rtgwg-igp-label-advertisement] where the consumer of a 132 MPLS label binding may not be adjacent to the router that performs 133 the binding. Bringing up an explicit session using the existing 134 label distribution protocols between the non-adjacent router that 135 bind the label and the router that acts as a consumer of this binding 136 is the existing remedy for this dilemma. 138 This document describes a OSPFv2 and OSPFv3 protocol extension which 139 allows routers to advertise MPLS label bindings within and beyond an 140 IGP domain, and controlling inter-area distribution. 142 2. Motivation, Rationale and Applicability 144 Distributing MPLS labels in an IGP (IS-IS) has been described in 145 Segment Routing [I-D.previdi-filsfils-isis-segment-routing]. The 146 authors propose to re-use existing traffic-engineering extensions for 147 carrying the label information. While retrofitting existing protocol 148 machinery for new purposes is generally a good thing, Segment Routing 149 [I-D.previdi-filsfils-isis-segment-routing] falls short of addressing 150 some use-cases defined in 151 [I-D.gredler-rtgwg-igp-label-advertisement]. 153 The dominant issue around re-using traffic-engineering extensions is 154 that both have existing protocol semantics, which might not be 155 applicable to advertising MPLS label switched paths in a generic 156 fashion. These are specifically: 158 o Bi-directionality semantics 160 o IP path semantics 162 o Lack of 'path' notion 164 2.1. Issue: Bi-directionality semantics 166 'Bi-directionality semantics', affects the complexity around 167 advertisement of unidirectional LSPs. Label advertisement of per- 168 link labels or 'Adj-SIDs' [I-D.previdi-filsfils-isis-segment-routing] 169 is done by attaching label information to adjacency advertisment 170 TLVs. Usually implementations need to have an adjacency in 'Up' 171 state prior to advertising this adjacency as TE-Link in its Link 172 State advertisment. In order to advertise a per-link LSP an 173 implementation first needs to have an adjacency, which only 174 transitions to 'Up' state after passing the 3-way check. This 175 implies bi-directionality. If an implementation wants to advertise 176 per-link MPLS LSPs to e.g. outside the IGP domain then it would need 177 to fake-up an adjacency. Changing existing IGP Adjacency code to 178 support such cases defeats the purpose of re-using existing 179 functionality as there is not much common functionality to be shared. 181 2.2. Issue: IP path semantics 183 LSPs pointing to a Node are advertised as 'Node-SIDs' 184 [I-D.previdi-filsfils-isis-segment-routing] using IP Prefix 185 containers. That means that in order to advertise a MPLS LSP, one is 186 inheriting the semantics of advertising an IP path. Consider router 187 A has got existing LSPs to its entire one-hop neighborhood and is re- 188 advertising those LSPs using IP reachability semantics. Now we have 189 two exact matching IP advertisements. One from the owning router 190 (router B) which advertises its stable transport loopback address and 191 another one from router A re-advertising a LSP path to router B. 192 Existing routing software may get confused now as the 'stable 193 transport' address shows up from multiple places in the network and 194 more worse the IP forwarding path for control-plane protocols may get 195 mingled with the MPLS data plane. 197 2.3. Issue: Lack of 'path' notion 199 Both exisiting traffic-engineering extension containers have limited 200 semantics describing MPLS label-switched paths in the sense of a 201 'path'. Both encoding formats allow to express a pointer to some 202 specific router, but not to describe a MPLS label switched path 203 containing all of its path segments. 204 [I-D.previdi-filsfils-isis-segment-routing] allows to define 205 'Forwarding Adjacencies' as per [RFC4206]. The way to describe a 206 path of a given forwarding adjacency is to enlist a list of "Segment 207 IDs". That implies that nodes which do not yet participate in 208 'Segment routing' or are outside of a 'Segment routing' domain can 209 not be expressed using those path semantics. 211 A protocol for advertising MPLS label switched paths, should be 212 generic enough to express paths sourced by existing MPLS LSPs, such 213 that ingress routers can flexibly combine them according to 214 application needs. 216 2.4. Motivation 218 IGP advertisement of MPLS label switched paths requires a new set of 219 protocol semantics (undirectional paradigm, path paradigm), which 220 hardly can be expressed using the existing OSPF and OSPF-TE protocol 221 semantics. This document describes protocol extensions which allows 222 generic advertisement of MPLS label switched paths in OSPF. 224 3. OSPF MPLS LSA Format 226 3.1. Common LSA Type 228 One new LSA is defined, the MPLS Label LSA. This LSA advertises MPLS 229 labels along with their path information. The LSA contains more 230 specific information encoded in TLVs. Those TLV extensions are 231 shared between the OSPFv2 and OPSFv3 protocols. 233 3.2. OSPFv2 LSA ID 235 The LSA ID of an Opaque LSA is defined as having eight bits of type 236 data and 24 bits of type-specific data. The MPLS Label LSA uses type 237 149. The remaining 24 bits are 4 zero bits followed by the MPLS 238 Label value as follows: 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | 149 |0|0|0|0| MPLS Label | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Figure 1: OSPFv2 MPLS Label LSA-ID format 248 The 'MPLS Label' field holds the 20 Bit MPLS label. Therefore a 249 maximum of 2^20 MPLS Label LSAs may be sourced by a single system. 251 3.3. OSPFv2 LSA Format Overview 253 This extension makes use of the Opaque LSAs [RFC5250]. 255 Three types of Opaque LSAs exist, each of which has a different 256 flooding scope. This proposal uses only Type 10 LSAs, which have an 257 area flooding scope. 259 The MPLS Label LSA for OSPFv2 starts with the standard OSPFv2 LSA 260 header: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | LS age | Options | 10 | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | 149 |0|0|0|0| MPLS Label | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Advertising Router | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | LS sequence number | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | LS checksum | length | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | | 276 +- TLVs -+ 277 | ... | 279 Figure 2: OSPFv2 MPLS Label LSA format 281 3.4. OSPFv3 LSA ID 283 The OSPFv3 LSA ID of an MPLS Label LSA is defined as having twelve 284 bits of zero followed by the 20-Bit label MPLS Label value as 285 follows: 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 |0|0|0|0|0|0|0|0|0|0|0|0| MPLS Label | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Figure 3: OSPFv3 MPLS Label LSA-ID format 295 The 'MPLS Label' field holds the 20 Bit MPLS label. Therefore a 296 maximum of 2^20 MPLS Label LSAs may be sourced by a single system. 298 3.5. OSPFv3 LSA Format Overview 300 The MPLS Label LSA for OSPFv3 starts with the standard OSPFv3 LSA 301 header: 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | LS age |1|0|1| 149 | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 |0|0|0|0|0|0|0|0|0|0|0|0| MPLS Label | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Advertising Router | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | LS sequence number | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | LS checksum | Length | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | | 317 +- TLVs -+ 318 | ... | 320 Figure 4: OSPFv3 MPLS Label LSA format 322 The OSPFv3 'U' Bit will always be set such that routers which do not 323 understand the new MPLS Label LSA will store and forward it further. 325 In analogy to the OSPFv2 opaque LSA 10 the flooding scope will be set 326 to 'Area scoping'. 328 3.6. TLV Header 330 The LSA payload consists of one or more nested Type/Length/Value 331 (TLV) triplets for extensibility. The format of each TLV is: 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Type | Length | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Value... | 339 . . 340 . . 341 . . 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 Figure 5: TLV format 346 The Length field defines the length of the value portion in octets 347 (thus a TLV with no value portion would have a length of zero). The 348 TLV is padded to four-octet alignment; padding is not included in the 349 length field (so a three octet value would have a length of three, 350 but the total size of the TLV would be eight octets). Nested TLVs 351 are also 32-bit aligned. Unrecognized types are ignored. 353 This memo defines Types 1, 2 and 3. See the IANA Considerations 354 section for allocation of new Types. 356 4. LSA payload details 358 The MPLS Label LSA may be originated by any Traffic Engineering 359 [RFC3630] capable router in an OSPF domain. A router may advertise 360 MPLS labels along with so called 'ERO' path segments describing the 361 label switched path. This gets encoded in subsequent TLVs. Since 362 ERO style path notation allows to express pointers to link and node 363 IP addresses. Now any label switched path, sourced by any protocol, 364 can be described. 366 An LSA contains one or more TLVs, describing properties of the 367 advertised MPLS label. 369 The following TLV extensions may be shared in both OSPV2 and OSPFv3. 370 Passing an IP address of the other address family (IPv4 in OPSFv3 or 371 IPv6 in OSPFv2) is possible as the information carried are related 372 describing the hops along a path. The receiver of this information 373 is a protocol agnostic path computation module. 375 4.1. Prefix ERO TLVs 377 All 'Prefix ERO' information represents an ordered set which 378 describes the segments of a label-switched path. The last Prefix ERO 379 TLV describes the segment closest to the egress point of the LSP. 380 Contrary the first Prefix ERO TLV describes the first segment of a 381 label switched path. If a router extends or stitches a label 382 switched path it MUST prepend the new segments path information to 383 the Prefix ERO list. 385 4.1.1. IPv4 Prefix ERO TLV 387 The IPv4 ERO TLV (Type 1) describes a path segment using IPv4 Prefix 388 style of encoding. Its appearance and semantics have been borrowed 389 from Section 4.3.3.2 [RFC3209]. 391 the 'IPv4 Address' is treated as a prefix based on the prefix length 392 value below. Bits beyond the prefix are ignored on receipt and 393 SHOULD be set to zero on transmission. 395 The 'Prefix Length' field contains the length of the prefix in bits. 397 The 'L' bit in the TLV is a one-bit attribute. If the L bit is set, 398 then the value of the attribute is 'loose.' Otherwise, the value of 399 the attribute is 'strict.' 401 The 'Reserved' bits are for future use. They should be zero on 402 transmission and ignored on receipt. 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Type | Length | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | IPv4 Address (4 octets) | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Prefix Length |L| Reserved | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 Figure 6: IPv4 Prefix ERO TLV format 416 4.1.2. IPv6 Prefix ERO TLV 418 The IPv6 ERO TLV (Type 2) describes a path segment using IPv6 Prefix 419 style of encoding. Its appearance and semantics have been borrowed 420 from Section 4.3.3.2 [RFC3209]. 422 the 'IPv6 Address' is treated as a prefix based on the prefix length 423 value below. Bits beyond the prefix are ignored on receipt and 424 SHOULD be set to zero on transmission. 426 The 'Prefix Length' field contains the length of the prefix in bits. 428 The 'L' bit in the TLV is a one-bit attribute. If the L bit is set, 429 then the value of the attribute is 'loose.' Otherwise, the value of 430 the attribute is 'strict.' 432 The 'Reserved' bits are for future use. They should be zero on 433 transmission and ignored on receipt. 435 0 1 2 3 436 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 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 | Type | Length | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | IPv6 Address (16 octets) | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | IPv6 Address (continued) | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | IPv6 Address (continued) | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | IPv6 Address (continued) | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Prefix Length |L| Reserved | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 Figure 7: IPv6 Prefix ERO TLV format 453 4.2. IPv4 Prefix Bypass ERO TLV 455 The IPv4 Bypass ERO TLV (Type 3) describes a Bypass LSP path segment 456 using IPv4 Prefix style of encoding. Its appearance and semantics 457 have been borrowed from Section 4.3.3.2 [RFC3209]. 459 The 'Prefix Length' field contains the length of the prefix in bits. 461 The 'L' bit in the TLV is a one-bit attribute. If the L bit is set, 462 then the value of the attribute is 'loose.' Otherwise, the value of 463 the attribute is 'strict.' 465 The 'Reserved' bits are for future use. They should be zero on 466 transmission and ignored on receipt. 468 0 1 2 3 469 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 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Type | Length | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | IPv4 Address (4 octets) | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Prefix Length |L| Reserved | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Figure 8: IPv4 Prefix Bypass ERO TLV format 480 4.3. IPv6 Prefix Bypass ERO TLV 482 The IPv6 ERO TLV (Type 4) describes a Bypass LSP path segment using 483 IPv6 Prefix style of encoding. Its appearance and semantics have 484 been borrowed from Section 4.3.3.3 [RFC3209]. 486 The 'Prefix Length' field contains the length of the prefix in bits. 488 The 'L' bit in the subTLV is a one-bit attribute. If the L bit is 489 set, then the value of the attribute is 'loose.' Otherwise, the 490 value of the attribute is 'strict.' 492 0 1 2 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Type | Length | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | IPv6 Address (16 octets) | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | IPv6 Address (continued) | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | IPv6 Address (continued) | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | IPv6 Address (continued) | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Prefix Length |L| Reserved | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Figure 9: IPv6 Prefix Bypass ERO TLV format 510 4.4. Flags TLV 512 The Flags TLV (Type 5) describes Flags for further MPLS LSA 513 treatment. 515 Up/Down 'U' Bit: A router may flood MPLS label information across 516 area boundaries. In order to prevent flooding loops, a router will 517 Set the Up/Down (U-Bit) when propagating MPLS labels from Area 0 to a 518 non-zero Area. 520 The 'Reserved' bits are for future use. They should be zero on 521 transmission and ignored on receipt. 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Type | Length | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 |U| Reserved | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 Figure 10: Flags TLV format 533 4.5. All Router Block TLV 535 The 'All Router Block' TLV (Type 6) denominates the label block size 536 of an MPLS Label advertisement and its semantics to connect to all 537 routers in a given OSPF domain using a local assigned [RFC3031] label 538 range. Note that the actual mapping of a router within the label 539 range is done using the TLVs described in Section 4.6 and 540 Section 4.7. Since generation of an IPv4 or IPv6 Map TLV is a local 541 policy decision, it might be the case that connectivity is provided 542 not to 'All' but rather a subset of 'All' routers. Keeping policy 543 decisions aside, for simplicity reasons, assume that All Routers in a 544 domain do generate either the 'All Router ID IPv4 Map' or 'All Router 545 ID IPv6 Map' TLVs and therefore all routers desire construction of a 546 Label switched path from every source router in the network. The 547 basic concept of using label blocks to provide connectivity to a set 548 of routers has been borrowed from [RFC4761] which allows to advertise 549 labels from multiple end-points using a single control-plane message. 550 The difference to [RFC4761] is that rather than advertising where a 551 particular packet came from (=source semantics), destination 552 semantics (where a particular packet will be going to) is advertised. 554 Along with each label block a router advertises one for more 'IDs'. 555 The 'ID' must be unique within a given domain. The 'ID' serves as 556 ordinal to determine the actual label value inside the set of all 557 advertised label ranges of a given router. A receiving router uses 558 the ordinal to determine the actual label value in order to construct 559 forwarding state to a particular destination router. The 'ID' is 560 separately advertised using the TLVs described in Section 4.6 and 561 Section 4.7. 563 The ability to advertise more than one label block eases operational 564 procedures for increasing the number of supported routers within a 565 domain. For example consider a given domain has got support for 566 routers and runs out of ID space. It simply advertises one more 567 label block to cover additional ordinals outside the range of the 568 first label block. An example of this is described in more detail in 569 Section 5.8 570 0 1 2 3 571 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 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | Type | Length | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | Block Size | Algo | Reserved| Topology-ID | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 578 Figure 11: All Router Block TLV format 580 The 'Block Size' value contains the size of the label advertisement. 581 The 'value determines the amount of reachable router endpoints within 582 a given domain. It MUST contain a value greater or equal than two. 583 Note that the label base is inferred from the LSA-ID in the LSA 584 header. For example if a router wants to advertise a label range of 585 5000-5099 then it would need to generate a LSA-ID of 5000 (= 586 0.0.19.136) and a Block Size of 100. 588 The 'Algo' value denominates the path computation algorithm in order 589 to calculate the forwarding topology. The basic SPF algorithm has an 590 assigned 'Algo' code point of zero. The purpose of the 'Algo' field 591 is to extend the notion of Label Block Signaling to arbitrary 592 algorithms like for example 'MRT' 593 ([I-D.ietf-rtgwg-mrt-frr-architecture]. Advertised Label Blocks with 594 an unknown, unsupported or non-configured algorithm MUST be silently 595 ignored. 597 The 'Reserved' bits are for future use. They should be zero on 598 transmission and ignored on receipt. 600 The 'Topology-ID' field contains the Multi Topology ID ([RFC4915]) 601 for which the advertised Label Block does apply. The basic IPv4 602 unicast Topology has an assigned 'Topology-ID' code point of zero. 603 Advertised Label Blocks with an unknown, unsupported or non- 604 configured Topology-ID MUST be silently ignored. 606 An LSA containing the 'All Router Block' TLV MUST only contain the 607 Flags TLV (Section 4.4, the 'All Router IPv4 Map' TLV (Section 4.6) 608 or the 'All Router IPv6 Map' TLV (Section 4.7). 610 4.6. All Router ID IPv4 Map TLV 612 The 'All Router ID IPv4 Map' TLV (Type 7) maps an 'ID' to a given 613 stable transport IPv4 address. Its purpose is to associate a given 614 transport IPv4 IP address to the ordinal inside a label range as 615 described in Section 4.5. 617 A router MAY advertise more than one 'ID' to 'IPv4 address' mapping 618 pair, in case it has more than one stable transport IPv4 address. 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Type | Length | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | IPv4 Address (4 octets) | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | ID | Reserved | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 Figure 12: All Router ID IPv4 Map TLV format 632 The 'IPv4 address' contains stable IPv4 transport address of a given 633 router. 635 The 'ID' contains the ordinal value of an advertising router inside 636 the set of all advertised label blocks of a given router. 638 The 'Reserved' bits are for future use. They should be zero on 639 transmission and ignored on receipt. 641 4.7. All Router ID IPv6 Map TLV 643 The 'All Router ID IPv6 Map' TLV (Type 8) maps an 'ID' to a given 644 stable transport IPv6 address. Its purpose is to associate a given 645 transport IPv6 IP address to the ordinal inside a label range as 646 described in Section 4.5. 648 A router MAY advertise more than one 'ID' to 'IPv6 address' mapping 649 pair, in case it has more than one stable transport IPv6 address. 651 0 1 2 3 652 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 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Type | Length | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | IPv6 Address (16 octets) | 657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 | IPv6 Address (continued) | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 | IPv6 Address (continued) | 661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 | IPv6 Address (continued) | 663 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 | ID | Reserved | 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 667 Figure 13: All Router ID IPv6 Map TLV format 669 The 'IPv6 address' contains the stable IPv6 transport address of a 670 given router. 672 The 'ID' contains the ordinal value of an advertising router inside 673 the set of all advertised label blocks of a given router. 675 The 'Reserved' bits are for future use. They should be zero on 676 transmission and ignored on receipt. 678 5. Advertising Label Examples 680 5.1. Sample Topology 682 The following topology (Figure 14) and IP addresses shall be used 683 throughout the Label advertisement examples. 685 AS1 : AS 2 686 : 687 : : 688 Area 1 : Area 0 : 689 : : 690 +-----+ +-----+-IP3--1-IP4--+-----+ : 691 | R1 +-IP1--1-IP2--+ R2 | | R3 | : 692 +--+--+ +--+--+-IP5--3-IP6--+--+--+-IP15-IP16- 693 | | | : \ 694 IP3 IP7 IP13 : \ 695 | | | : +--+--+ 696 1 1 1 : | R7 | 697 | | | : +--+--+ 698 IP4 IP8 IP14 : / 699 | | | : / 700 +--+--+ +--+--+ +--+--+-IP17-IP18- 701 | R4 +-IP19-2-IP20-+ R5 |-IP11-2-IP12-| R6 | : 702 +-----+ +-----+ +-----+ : 703 : : 704 : : 705 : : 707 Figure 14: Sample Topology 709 5.1.1. Transport IP addresses and router-IDs 711 o R1: 192.168.1.1 713 o R2: 192.168.1.2 715 o R3: 192.168.1.3 717 o R4: 192.168.1.4 719 o R5: 192.168.1.5 721 o R6: 192.168.1.6 723 o R7: 192.168.1.7 725 5.1.2. Link IP addresses 727 o R1 to R2 link: 10.0.0.1, 10.0.0.2 729 o R1 to R4 link: 10.0.0.3, 10.0.0.4 731 o R2 to R3 link #1: 10.0.0.3, 10.0.0.4 732 o R2 to R3 link #2: 10.0.0.5, 10.0.0.6 734 o R2 to R5 link: 10.0.0.7, 10.0.0.8 736 o R3 to R6 link: 10.0.0.13, 10.0.0.14 738 o R3 to R7 link: 10.0.0.15, 10.0.0.16 740 o R4 to R5 link: 10.0.0.19, 10.0.0.20 742 o R5 to R6 link: 10.0.0.11, 10.0.0.12 744 o R6 to R7 link: 10.0.0.17, 10.0.0.18 746 The IGP link metrics are displayed in the middle of the link. All of 747 them are assumed to be bi-directional. 749 5.2. One-hop LSP to an adjacent Router 751 If R1 would advertise a label bound to a one-hop LSP from R1 to 752 R2 it would encode as follows: 754 LSA 149, LSA-ID : 756 IPv4 Prefix ERO TLV: 192.168.1.2/32, Strict 758 5.3. One-hop LSP to an adjacent Router using a specific link 760 If R2 would advertise a label bound to a one-hop LSP from R2 to 761 R3, using the link #2 it would encode as follows 763 LSA 149, LSA-ID : 765 IPv4 Prefix ERO TLV: 10.0.0.6/32, Strict 767 5.4. One-hop LSP to an adjacent external Router 769 If R3 would advertise a label bound to a one-hop LSP from R3 to 770 R7 (which is outside of the IGP domain), it would encode as follows: 772 LSA 149, LSA-ID : 774 IPv4 Prefix ERO TLV: 192.168.1.7/32, Strict 776 As you can see the representation of an MPLS label crossing an 777 external link is identical as an internal link Section 5.2. 779 5.5. Advertisement of an RSVP LSP 781 Consider a RSVP LSP name "R2-to-R6" traversing (R2 to R3 using link 782 #1, R6): 784 If R2 would advertise a label bound to the RSVP LSP named 785 'R2-to-R6', it would encode as follows 787 LSA 149, LSA-ID : 789 IPv4 Prefix ERO TLV: 10.0.0.4/32, Strict 791 IPv4 Prefix ERO TLV: 192.168.1.6/32, Strict 793 5.6. Advertisement of an LDP LSP 795 Consider R2 that creates a LDP label binding for FEC 172.16.0.0./12 796 using label . 798 If R2 would re-advertise this label binding in OSPF it would encode 799 as follows 801 LSA 149, LSA-ID : 803 IPv4 Prefix ERO TLV: 172.16.0.0/12, Loose 805 5.7. Interarea advertisement of diverse paths 807 Consider two R2->R6 paths: {R2, R3, R6} and {R2, R5, R6} 809 Consider two R5->R3 paths: {R5, R2, R3} and {R5, R6, R3} 811 R2 encodes its two paths to R6 as follows: 813 LSA 149, LSA-ID : 815 IPv4 Prefix ERO TLV: 192.168.1.3, Loose 817 IPv4 Prefix ERO TLV: 192.168.1.6, Loose 819 Flags TLV: Down 821 LSA 149, LSA-ID : 823 IPv4 Prefix ERO subTLV: 192.168.1.5, Loose 825 IPv4 Prefix ERO subTLV: 192.168.1.6, Loose 826 Flags TLV: Down 828 R5 encodes its two paths to R3 as follows: 830 LSA 149, LSA-ID : 832 IPv4 Prefix ERO subTLV: 192.168.1.2, Loose 834 IPv4 Prefix ERO subTLV: 192.168.1.3, Loose 836 Flags TLV: Down 838 LSA 149, LSA-ID : 840 IPv4 Prefix ERO subTLV: 192.168.1.6, Loose 842 IPv4 Prefix ERO subTLV: 192.168.1.3, Loose 844 Flags TLV: Down 846 A receiving non-backbone router does see now all 4 paths and may 847 decide to load-balance across all or a subset of them. 849 5.8. Advertisement of SPT labels using 'All Router Block' TLV 851 All routers within a given area MUST advertise their Label Blocks 852 along with an 'ID'. 854 If R2 would advertise a label block with a size of 10, declaring 855 SPT label forwarding support to all routers within a given domain, it 856 would encode as follows: 858 LSA 149, LSA-ID : 860 All Router Block TLV: Block Size 10 862 All Router ID IPv4 Map TLV: ID 2, 192.168.1.2 864 If R3 would advertise a label block with a size of 10, declaring 865 SPT label forwarding support to all routers within a given domain, it 866 would encode as follows: 868 LSA 149, LSA-ID : 870 All Router Block TLV: Block Size 10 872 All Router ID IPv4 Map TLV: ID 3, 192.168.1.3 874 If R5 would advertise a label block with a size of 10, declaring 875 SPT label forwarding support to all routers within a given domain, it 876 would encode as follows: 878 LSA 149, LSA-ID : 880 All Router Block TLV: Block Size 10 882 All Router ID IPv4 Map TLV: ID 5, 192.168.1.5 884 If R6 would advertise a label block with a size of 10, declaring 885 SPT label forwarding support to all routers within a given domain, it 886 would encode as follows: 888 LSA 149, LSA-ID : 890 All Router Block TLV: Block Size 10 892 All Router ID IPv4 Map TLV: ID 6, 192.168.1.6 894 Consider now R2 constructing a SPT label for R6. R2s SPT to R6 is 895 {R2, IP4, R3, R6}. R2 first determines if its downstream router (R3) 896 has advertised a label-block. Since R3 has advertised a label block 897 'N2' and it has received R6 'ID' of 6 it will be picking the 6th 898 label value inside the advertised range of its downstream neighbor. 899 Specifically R2 MUST be program a MPLS SWAP for its own label range 900 Label(N1+6) to Label(N2+6), NH 10.0.0.4 into its MPLS transit RIB. 901 Furthermore R2 MAY program a MPLS PUSH operation for IP 192.168.1.6 902 to Label (N2+6), NH 10.0.0.04 into its IPv4 tunnel RIB. 904 Next walk down to R3, which is the next router on the SPT tree 905 towards R6. R3s SPT to R6 is {R3, R6}. R3 determines if its 906 downstream router (R6) has advertised a label-block. Since R6 has 907 advertised a label block 'N4' and it has received R6 'ID' of 6 it 908 will be picking the 6th label value inside the advertised range of 909 its downstream neighbor. Since R3 is the penultimate router to R6 it 910 MUST program a MPLS POP for its own label range Label(N2+6) NH 911 10.0.0.14 into its MPLS transit RIB. Furthermore R3 MAY program a 912 MPLS NOP for IP 192.168.1.6, NH 10.0.0.14 into its IPv4 tunnel RIB. 914 6. Inter Area Protocol Procedures 916 6.1. Applicability 918 Propagation of a MPLS LSPs and MPLS Block LSPs across an area 919 boundary is a local policy decision. 921 6.2. Data plane operations 923 If local policy dictates that a given ABR router needs to re- 924 advertise a MPLS LSPs from one area to another then it MUST allocate 925 a new label and program its label forwarding table to connect the new 926 label to the path in the respective other area. Depending on how to 927 reach the re-advertised LSP, this is typically done using a MPLS 928 'SWAP' or 'SWAP/PUSH' data plane operation. 930 6.3. Control plane operations 932 6.3.1. MPLS Label operations 934 If local policy dictates that a given ABR router needs to re- 935 advertise MPLS LSPs from one area to another then it must prepend its 936 "Traffic-Engineering-ID" as a loose hop in the Prefix ERO TLV list. 937 Furthermore it MUST append the Flags TLV and set the 'Down' Bit. 939 6.3.2. MPLS Label Block operations 941 If local policy dictates that a given ABR router advertises its 'All 942 Router Block' into another area, then it also MUST re-advertise all 943 known 'ID' ordinals (again gated by policy) to the respective other 944 area. Without knowledge of all 'ID's in the network no router is 945 able to construct SPT label switched paths. Furthermore an ABR MUST 946 append the Flags TLV and set the 'Down' Bit for all re-advertised 947 'CE' IDs. 949 7. Acknowledgements 951 Many thanks to Yakov Rekhter and Shraddha Hedge for their useful 952 comments. 954 8. IANA Considerations 956 This documents request allocation for one common OSPFv2 and OSPFv3 957 LSA Type and TLVs contained within. 959 +----------+------------------------+----------+------------+ 960 | LSA Type | TLV | TLV Type | #Occurence | 961 +----------+------------------------+----------+------------+ 962 | 149 | | | >=0 | 963 | | IPv4 Prefix ERO | 1 | >=0 | 964 | | IPv6 Prefix ERO | 2 | >=0 | 965 | | IPv4 Prefix Bypass ERO | 3 | >=0 | 966 | | IPv6 Prefix Bypass ERO | 4 | >=0 | 967 | | Flags | 5 | 0,1 | 968 | | All Router Block | 6 | >=0 | 969 | | All Router ID IPv4 Map | 7 | >=0 | 970 | | All Router ID IPv6 Map | 8 | >=0 | 971 +----------+------------------------+----------+------------+ 973 Table 1: IANA allocations 975 The MPLS Label LSA requires a new sub-registry, with a starting TLV 976 value of 1, and managed by Expert Review. 978 9. Security Considerations 980 This document does not introduce any change in terms of OSPF 981 security. It simply proposes to flood MPLS label information via the 982 IGP. All existing procedures to ensure message integrity do apply 983 here. 985 10. References 987 10.1. Normative References 989 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 990 Requirement Levels", BCP 14, RFC 2119, March 1997. 992 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 993 Label Switching Architecture", RFC 3031, January 2001. 995 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 996 BGP-4", RFC 3107, May 2001. 998 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 999 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1000 Tunnels", RFC 3209, December 2001. 1002 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 1003 (TE) Extensions to OSPF Version 2", RFC 3630, 1004 September 2003. 1006 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1007 Hierarchy with Generalized Multi-Protocol Label Switching 1008 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 1010 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 1011 (VPLS) Using BGP for Auto-Discovery and Signaling", 1012 RFC 4761, January 2007. 1014 [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. 1015 Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", 1016 RFC 4915, June 2007. 1018 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1019 Specification", RFC 5036, October 2007. 1021 [RFC5151] Farrel, A., Ayyangar, A., and JP. Vasseur, "Inter-Domain 1022 MPLS and GMPLS Traffic Engineering -- Resource Reservation 1023 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1024 RFC 5151, February 2008. 1026 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 1027 OSPF Opaque LSA Option", RFC 5250, July 2008. 1029 10.2. Informative References 1031 [I-D.gredler-rtgwg-igp-label-advertisement] 1032 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1033 "Advertising MPLS labels in IGPs", 1034 draft-gredler-rtgwg-igp-label-advertisement-03 (work in 1035 progress), April 2013. 1037 [I-D.ietf-rtgwg-mrt-frr-architecture] 1038 Atlas, A., Kebler, R., Envedi, G., Csaszar, A., Tantsura, 1039 J., Konstantynowicz, M., White, R., and M. Shand, "An 1040 Architecture for IP/LDP Fast-Reroute Using Maximally 1041 Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-02 1042 (work in progress), February 2013. 1044 [I-D.previdi-filsfils-isis-segment-routing] 1045 Previdi, S., Filsfils, C., Bashandy, A., Horneffer, M., 1046 Decraene, B., Litkowski, S., Milojevic, I., Shakir, R., 1047 Ytti, S., Henderickx, W., and J. Tantsura, "Segment 1048 Routing with IS-IS Routing Protocol", 1049 draft-previdi-filsfils-isis-segment-routing-02 (work in 1050 progress), March 2013. 1052 Authors' Addresses 1054 Hannes Gredler (editor) 1055 Juniper Networks, Inc. 1056 1194 N. Mathilda Ave. 1057 Sunnyvale, CA 94089 1058 US 1060 Email: hannes@juniper.net 1062 Shane Amante 1063 Level 3 Communications, Inc. 1064 1025 Eldorado Blvd 1065 Broomfield, CO 80021 1066 US 1068 Email: shane@level3.net 1070 Tom Scholl 1071 Amazon 1072 Seattle, WN 1073 US 1075 Email: tscholl@amazon.com 1077 Luay Jalil 1078 Verizon 1079 1201 E Arapaho Rd. 1080 Richardson, TX 75081 1081 US 1083 Email: luay.jalil@verizon.com