idnits 2.17.1 draft-gredler-ospf-label-advertisement-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 60 lines 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 32 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 (April 12, 2013) is 4024 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) == Unused Reference: 'I-D.gredler-rtgwg-igp-label-advertisement' is defined on line 695, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) == Outdated reference: A later version (-05) exists of draft-gredler-rtgwg-igp-label-advertisement-03 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: October 12, 2013 Level 3 Communications, Inc. 6 T. Scholl 7 Amazon 8 L. Jalil 9 Verizon 10 April 12, 2013 12 Advertising MPLS labels in OSPF 13 draft-gredler-ospf-label-advertisement-00 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 [I-D.gredler-rtgwg-igp- 24 label-advertisement] describes several use cases where utilizing the 25 flooding machinery of link-state protocols for MPLS label 26 distribution allows to obtain the binding without requiring to 27 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." 52 This Internet-Draft will expire on October 12, 2013. 54 Copyright Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Simplified BSD License text 65 as described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Motivation, Rationale and Applicability . . . . . . . . . . . 3 72 2.1. Issue: Bi-directionality semantics . . . . . . . . . . . . 3 73 2.2. Issue: IP path semantics . . . . . . . . . . . . . . . . . 4 74 2.3. Issue: Lack of 'path' notion . . . . . . . . . . . . . . . 4 75 2.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 76 3. OSPF MPLS LSA Format . . . . . . . . . . . . . . . . . . . . . 5 77 3.1. Common LSA Type . . . . . . . . . . . . . . . . . . . . . 5 78 3.2. OSPFv2 LSA ID . . . . . . . . . . . . . . . . . . . . . . 5 79 3.3. OSPFv2 LSA Format Overview . . . . . . . . . . . . . . . . 5 80 3.4. OSPFv3 LSA ID . . . . . . . . . . . . . . . . . . . . . . 6 81 3.5. OSPFv3 LSA Format Overview . . . . . . . . . . . . . . . . 6 82 3.6. TLV Header . . . . . . . . . . . . . . . . . . . . . . . . 7 83 4. LSA payload details . . . . . . . . . . . . . . . . . . . . . 7 84 4.1. Prefix ERO TLVs . . . . . . . . . . . . . . . . . . . . . 7 85 4.1.1. IPv4 Prefix ERO TLV . . . . . . . . . . . . . . . . . 8 86 4.1.2. IPv6 Prefix ERO TLV . . . . . . . . . . . . . . . . . 8 87 4.2. Flags TLV . . . . . . . . . . . . . . . . . . . . . . . . 9 88 5. Advertising Label Examples . . . . . . . . . . . . . . . . . . 9 89 5.1. Sample Topology . . . . . . . . . . . . . . . . . . . . . 9 90 5.1.1. Transport IP addresses and router-IDs . . . . . . . . 10 91 5.1.2. Link IP addresses . . . . . . . . . . . . . . . . . . 10 92 5.2. One-hop LSP to an adjacent Router . . . . . . . . . . . . 11 93 5.3. One-hop LSP to an adjacent Router using a specific link . 11 94 5.4. One-hop LSP to an adjacent external Router . . . . . . . . 11 95 5.5. Advertisement of an RSVP LSP . . . . . . . . . . . . . . . 11 96 5.6. Advertisement of an LDP LSP . . . . . . . . . . . . . . . 11 97 5.7. Interarea advertisement of diverse paths . . . . . . . . . 12 98 6. Inter Area Protocol Procedures . . . . . . . . . . . . . . . . 13 99 6.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 13 100 6.2. Data plane operations . . . . . . . . . . . . . . . . . . 13 101 6.3. Control plane operations . . . . . . . . . . . . . . . . . 13 102 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 103 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 105 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 106 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 107 10.2. Informative References . . . . . . . . . . . . . . . . . 14 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 110 1. Introduction 112 MPLS label allocations are predominantly distributed by using the LDP 113 [RFC5036], RSVP [RFC5151] or labeled BGP [RFC3107] protocol. All of 114 those protocols have in common that they are session oriented, which 115 means that in order to obtain label binding for a given destination 116 FEC from a given router one needs first to establish a direct control 117 plane (LDP/RSVP/LBGP) session with that router. 119 There are a couple of use cases [I-D.gredler-rtgwg-igp-label- 120 advertisement] where the consumer of a MPLS label binding may not be 121 adjacent to the router that performs the binding. Bringing up an 122 explicit session using the existing label distribution protocols 123 between the non-adjacent router that bind the label and the router 124 that acts as a consumer of this binding is the existing remedy for 125 this dilemma. 127 This document describes a OSPFv2 and OSPFv3 protocol extension which 128 allows routers to advertise MPLS label bindings within and beyond an 129 IGP domain, and controlling inter-area distribution. 131 2. Motivation, Rationale and Applicability 133 Distributing MPLS labels in an IGP (IS-IS) has been described in 134 Segment Routing [I-D.previdi-filsfils-isis-segment-routing]. The 135 authors propose to re-use existing traffic-engineering extensions for 136 carrying the label information. While retrofitting existing protocol 137 machinery for new purposes is generally a good thing, Segment Routing 138 [I-D.previdi-filsfils-isis-segment-routing] falls short of addressing 139 some use-cases defined in [I-D.gredler-rtgwg-igp-label- 140 advertisement]. 142 The dominant issue around re-using traffic-engineering extensions is 143 that both have existing protocol semantics, which might not be 144 applicable to advertising MPLS label switched paths in a generic 145 fashion. These are specifically: 147 o Bi-directionality semantics 149 o IP path semantics 151 o Lack of 'path' notion 153 2.1. Issue: Bi-directionality semantics 154 'Bi-directionality semantics', affects the complexity around 155 advertisement of unidirectional LSPs. Label advertisement of per- 156 link labels or 'Adj-SIDs' [I-D.previdi-filsfils-isis-segment-routing] 157 is done by attaching label information to adjacency advertisment 158 TLVs. Usually implementations need to have an adjacency in 'Up' 159 state prior to advertising this adjacency as TE-Link in its Link 160 State advertisment. In order to advertise a per-link LSP an 161 implementation first needs to have an adjacency, which only 162 transitions to 'Up' state after passing the 3-way check. This 163 implies bi-directionality. If an implementation wants to advertise 164 per-link MPLS LSPs to e.g. outside the IGP domain then it would need 165 to fake-up an adjacency. Changing existing IGP Adjacency code to 166 support such cases defeats the purpose of re-using existing 167 functionality as there is not much common functionality to be shared. 169 2.2. Issue: IP path semantics 171 LSPs pointing to a Node are advertised as 'Node-SIDs' [I-D.previdi- 172 filsfils-isis-segment-routing] using IP Prefix containers. That 173 means that in order to advertise a MPLS LSP, one is inheriting the 174 semantics of advertising an IP path. Consider router A has got 175 existing LSPs to its entire one-hop neighborhood and is re- 176 advertising those LSPs using IP reachability semantics. Now we have 177 two exact matching IP advertisements. One from the owning router 178 (router B) which advertises its stable transport loopback address and 179 another one from router A re-advertising a LSP path to router B. 180 Existing routing software may get confused now as the 'stable 181 transport' address shows up from multiple places in the network and 182 more worse the IP forwarding path for control-plane protocols may get 183 mingled with the MPLS data plane. 185 2.3. Issue: Lack of 'path' notion 187 Both exisiting traffic-engineering extension containers have limited 188 semantics describing MPLS label-switched paths in the sense of a 189 'path'. Both encoding formats allow to express a pointer to some 190 specific router, but not to describe a MPLS label switched path 191 containing all of its path segments. [I-D.previdi-filsfils-isis- 192 segment-routing] allows to define 'Forwarding Adjacencies' as per 193 [RFC4206]. The way to describe a path of a given forwarding 194 adjacency is to enlist a list of "Segment IDs". That implies that 195 nodes which do not yet participate in 'Segment routing' or are 196 outside of a 'Segment routing' domain can not be expressed using 197 those path semantics. 199 A protocol for advertising MPLS label switched paths, should be 200 generic enough to express paths sourced by existing MPLS LSPs, such 201 that ingress routers can flexibly combine them according to 202 application needs. 204 2.4. Motivation 205 IGP advertisement of MPLS label switched paths requires a new set of 206 protocol semantics (undirectional paradigm, path paradigm), which 207 hardly can be expressed using the existing OSPF and OSPF-TE protocol 208 semantics. This document describes protocol extensions which allows 209 generic advertisement of MPLS label switched paths in OSPF. 211 3. OSPF MPLS LSA Format 213 3.1. Common LSA Type 215 One new LSA is defined, the MPLS Label LSA. This LSA advertises MPLS 216 labels along with their path information. The LSA contains more 217 specific information encoded in TLVs. Those TLV extensions are 218 shared between the OSPFv2 and OPSFv3 protocols. 220 3.2. OSPFv2 LSA ID 222 The LSA ID of an Opaque LSA is defined as having eight bits of type 223 data and 24 bits of type-specific data. The MPLS Label LSA uses type 224 149. The remaining 24 bits are 4 zero bits followed by the MPLS Label 225 value as follows: 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | 149 |0|0|0|0| MPLS Label | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 The 'MPLS Label' field holds the 20 Bit MPLS label. Therefore a 234 maximum of 2^20 MPLS Label LSAs may be sourced by a single system. 236 3.3. OSPFv2 LSA Format Overview 238 This extension makes use of the Opaque LSAs [RFC5250]. 240 Three types of Opaque LSAs exist, each of which has a different 241 flooding scope. This proposal uses only Type 10 LSAs, which have an 242 area flooding scope. 244 The MPLS Label LSA for OSPFv2 starts with the standard OSPFv2 LSA 245 header: 247 0 1 2 3 248 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 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | LS age | Options | 10 | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | 149 |0|0|0|0| MPLS Label | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Advertising Router | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | LS sequence number | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | LS checksum | length | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | | 261 +- TLVs -+ 262 | ... | 264 3.4. OSPFv3 LSA ID 266 The OSPFv3 LSA ID of an MPLS Label LSA is defined as having twelve 267 bits of zero followed by the 20-Bit label MPLS Label value as 268 follows: 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 |0|0|0|0|0|0|0|0|0|0|0|0| MPLS Label | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 The 'MPLS Label' field holds the 20 Bit MPLS label. Therefore a 277 maximum of 2^20 MPLS Label LSAs may be sourced by a single system. 279 3.5. OSPFv3 LSA Format Overview 281 The MPLS Label LSA for OSPFv3 starts with the standard OSPFv3 LSA 282 header: 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | LS age |1|0|1| 149 | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 |0|0|0|0|0|0|0|0|0|0|0|0| MPLS Label | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Advertising Router | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | LS sequence number | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | LS checksum | Length | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | | 298 +- TLVs -+ 299 | ... | 301 The OSPFv3 'U' Bit will always be set such that routers which do not 302 understand the new MPLS Label LSA will store and forward it further. 304 In analogy to the OSPFv2 opaque LSA 10 the flooding scope will be set 305 to 'Area scoping'. 307 3.6. TLV Header 309 The LSA payload consists of one or more nested Type/Length/Value 310 (TLV) triplets for extensibility. The format of each TLV is: 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Type | Length | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Value... | 318 . . 319 . . 320 . . 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 The Length field defines the length of the value portion in octets 324 (thus a TLV with no value portion would have a length of zero). The 325 TLV is padded to four-octet alignment; padding is not included in the 326 length field (so a three octet value would have a length of three, 327 but the total size of the TLV would be eight octets). Nested TLVs are 328 also 32-bit aligned. Unrecognized types are ignored. 330 This memo defines Types 1, 2 and 3. See the IANA Considerations 331 section for allocation of new Types. 333 4. LSA payload details 335 The MPLS Label LSA may be originated by any Traffic Engineering 336 [RFC3630] capable router in an OSPF domain. A router may advertise 337 MPLS labels along with so called 'ERO' path segments describing the 338 label switched path. This gets encoded in subsequent TLVs. Since 339 ERO style path notation allows to express pointers to link and node 340 IP addresses. Now any label switched path, sourced by any protocol, 341 can be described. 343 An LSA contains one or more TLVs, describing properties of the 344 advertised MPLS label. 346 The following TLV extensions may be shared in both OSPV2 and OSPFv3. 347 Passing an IP address of the other address family (IPv4 in OPSFv3 or 348 IPv6 in OSPFv2) is possible as the information carried are related 349 describing the hops along a path. The receiver of this information 350 is a protocol agnostic path computation module. 352 4.1. Prefix ERO TLVs 353 All 'Prefix ERO' information represents an ordered set which 354 describes the segments of a label-switched path. The last Prefix ERO 355 TLV describes the segment closest to the egress point of the LSP. 356 Contrary the first Prefix ERO TLV describes the first segment of a 357 label switched path. If a router extends or stitches a label 358 switched path it MUST prepend the new segments path information to 359 the Prefix ERO list. 361 4.1.1. IPv4 Prefix ERO TLV 363 The IPv4 ERO TLV (Type 1) describes a path segment using IPv4 Prefix 364 style of encoding. Its appearance and semantics have been borrowed 365 from Section 4.3.3.2 [RFC3209]. 367 the 'IPv4 Address' is treated as a prefix based on the prefix length 368 value below. Bits beyond the prefix are ignored on receipt and 369 SHOULD be set to zero on transmission. 371 The 'Prefix Length' field contains the length of the prefix in bits. 373 The 'L' bit in the TLV is a one-bit attribute. If the L bit is set, 374 then the value of the attribute is 'loose.' Otherwise, the value of 375 the attribute is 'strict.' 377 The 'Reserved' bits are for future use. They should be zero on 378 transmission and ignored on receipt. 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Type | Length | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | IPv4 Address (4 octets) | 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Prefix Length |L| Reserved | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 4.1.2. IPv6 Prefix ERO TLV 392 The IPv6 ERO TLV (Type 2) describes a path segment using IPv6 Prefix 393 style of encoding. Its appearance and semantics have been borrowed 394 from Section 4.3.3.2 [RFC3209]. 396 the 'IPv6 Address' is treated as a prefix based on the prefix length 397 value below. Bits beyond the prefix are ignored on receipt and 398 SHOULD be set to zero on transmission. 400 The 'Prefix Length' field contains the length of the prefix in bits. 402 The 'L' bit in the TLV is a one-bit attribute. If the L bit is set, 403 then the value of the attribute is 'loose.' Otherwise, the value of 404 the attribute is 'strict.' 405 The 'Reserved' bits are for future use. They should be zero on 406 transmission and ignored on receipt. 408 0 1 2 3 409 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 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Type | Length | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | IPv6 Address (16 octets) | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | IPv6 Address (continued) | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | IPv6 Address (continued) | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | IPv6 Address (continued) | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Prefix Length |L| Reserved | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 4.2. Flags TLV 426 The Flags TLV (Type 3) describes Flags for further MPLS LSA 427 treatment. 429 Up/Down 'U' Bit: A router may flood MPLS label information across 430 area boundaries. In order to prevent flooding loops, a router will 431 Set the Up/Down (U-Bit) when propagating MPLS labels from Area 0 to a 432 non-zero Area. 434 The 'Reserved' bits are for future use. They should be zero on 435 transmission and ignored on receipt. 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | Type | Length | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 |U| Reserved | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 5. Advertising Label Examples 447 5.1. Sample Topology 449 The following topology (Figure 9) and IP addresses shall be used 450 throughout the Label advertisement examples. 452 AS1 : AS 2 453 : 454 : : 455 Level 1 : Level 2 : 456 : : 457 +-----+ +-----+-IP3--IP4--+-----+ : 458 | R1 +-IP1--IP2--+ R2 | | R3 | : 459 +--+--+ +--+--+-IP5--IP6--+--+--+-IP15-IP16- 460 | | | : \ 461 IP3 IP7 IP13 : +--+--+ 462 | | | : | R7 | 463 IP4 IP8 IP14 : +--+--+ 464 | | | : / 465 +--+--+ +--+--+ +--+--+-IP17-IP18- 466 | R4 +-IP19-IP20-+ R5 |-IP11-IP12-| R6 | : 467 +-----+ +-----+ +-----+ : 468 : : 469 : : 470 : : 472 5.1.1. Transport IP addresses and router-IDs 474 o R1: 192.168.1.1 476 o R2: 192.168.1.2 478 o R3: 192.168.1.3 480 o R4: 192.168.1.4 482 o R5: 192.168.1.5 484 o R6: 192.168.1.6 486 o R7: 192.168.1.7 488 5.1.2. Link IP addresses 490 o R1 to R2 link: 10.0.0.1, 10.0.0.2 492 o R1 to R4 link: 10.0.0.3, 10.0.0.4 494 o R2 to R3 link #1: 10.0.0.3, 10.0.0.4 496 o R2 to R3 link #2: 10.0.0.5, 10.0.0.6 498 o R2 to R5 link: 10.0.0.7, 10.0.0.8 500 o R3 to R6 link: 10.0.0.13, 10.0.0.14 502 o R3 to R7 link: 10.0.0.15, 10.0.0.16 503 o R4 to R5 link: 10.0.0.19, 10.0.0.20 505 o R5 to R6 link: 10.0.0.11, 10.0.0.12 507 o R6 to R7 link: 10.0.0.17, 10.0.0.18 509 5.2. One-hop LSP to an adjacent Router 511 If R1 would advertise a label bound to a one-hop LSP from R1 to 512 R2 it would encode as follows: 514 LSA 149, LSA-ID : 516 IPv4 Prefix ERO TLV: 192.168.1.2/32, Strict 518 5.3. One-hop LSP to an adjacent Router using a specific link 520 If R2 would advertise a label bound to a one-hop LSP from R2 to 521 R3, using the link #2 it would encode as follows 523 LSA 149, LSA-ID : 525 IPv4 Prefix ERO TLV: 10.0.0.6/32, Strict 527 5.4. One-hop LSP to an adjacent external Router 529 If R3 would advertise a label bound to a one-hop LSP from R3 to 530 R7 (which is outside of the IGP domain), it would encode as follows: 532 LSA 149, LSA-ID : 534 IPv4 Prefix ERO TLV: 192.168.1.7/32, Strict 536 As you can see the representation of an MPLS label crossing an 537 external link is identical as an internal link Section 5.2. 539 5.5. Advertisement of an RSVP LSP 541 Consider a RSVP LSP name "R2-to-R6" traversing (R2 to R3 using link 542 #1, R6): 544 If R2 would advertise a label bound to the RSVP LSP named 545 'R2-to-R6', it would encode as follows 547 LSA 149, LSA-ID : 549 IPv4 Prefix ERO TLV: 10.0.0.4/32, Strict 551 IPv4 Prefix ERO TLV: 192.168.1.6/32, Strict 553 5.6. Advertisement of an LDP LSP 554 Consider R2 that creates a LDP label binding for FEC 172.16.0.0./12 555 using label . 557 If R2 would re-advertise this binding in IS-IS it would encode as 558 follows 560 LSA 149, LSA-ID : 562 IPv4 Prefix ERO TLV: 172.16.0.0/12, Loose 564 5.7. Interarea advertisement of diverse paths 566 Consider two R2->R6 paths: {R2, R3, R6} and {R2, R5, R6} 568 Consider two R5->R3 paths: {R5, R2, R3} and {R5, R6, R3} 570 R2 encodes its two paths to R6 as follows: 572 LSA 149, LSA-ID : 574 IPv4 Prefix ERO TLV: 192.168.1.3, Loose 576 IPv4 Prefix ERO TLV: 192.168.1.6, Loose 578 Flags TLV: Down 580 LSA 149, LSA-ID : 582 IPv4 Prefix ERO subTLV: 192.168.1.5, Loose 584 IPv4 Prefix ERO subTLV: 192.168.1.6, Loose 586 Flags TLV: Down 588 R5 encodes its two paths to R3 as follows: 590 LSA 149, LSA-ID : 592 IPv4 Prefix ERO subTLV: 192.168.1.2, Loose 594 IPv4 Prefix ERO subTLV: 192.168.1.3, Loose 596 Flags TLV: Down 598 LSA 149, LSA-ID : 600 IPv4 Prefix ERO subTLV: 192.168.1.6, Loose 602 IPv4 Prefix ERO subTLV: 192.168.1.3, Loose 604 Flags TLV: Down 606 A receiving non-backbone router does see now all 4 paths and may 607 decide to load-balance across all or a subset of them. 609 6. Inter Area Protocol Procedures 611 6.1. Applicability 613 Propagation of a MPLS LSP across an area boundary is a local policy 614 decision. 616 6.2. Data plane operations 618 If local policy dictates that a given ABR router needs to re- 619 advertise a MPLS LSPs from one area to another then it MUST allocate 620 a new label and program its label forwarding table to connect the new 621 label to the path in the respective other area. Depending on how to 622 reach the re-advertised LSP, this is typically done using a MPLS 623 'SWAP' or 'SWAP/PUSH' data plane operation. 625 6.3. Control plane operations 627 If local policy dictates that a given ABR router needs to re- 628 advertise a MPLS LSPs from one area to another then it must prepend 629 its "Traffic-Engineering-ID" as a loose hop in the Prefix ERO TLV 630 list. Furthermore it MUST append teh Flags TLV and set the 'Down' 631 Bit. 633 7. Acknowledgements 635 Many thanks to Yakov Rekhter for his useful comments. 637 8. IANA Considerations 639 This documents request allocation for one common OSPFv2 and OSPFv3 640 LSA Type and TLVs contained within. 642 +------------+-----------------+----------+----------+------------+ 643 | LSA | TLV | LSA Type | TLV Type | #Occurence | 644 +------------+-----------------+----------+----------+------------+ 645 | MPLS Label | | 149 | | >=0 | 646 | | IPv4 Prefix ERO | | 1 | >=0 | 647 | | IPv6 Prefix ERO | | 2 | >=0 | 648 | | Flags | | 3 | 0,1 | 649 +------------+-----------------+----------+----------+------------+ 651 The MPLS Label LSA requires a new sub-registry, with a starting TLV 652 value of 1, and managed by Expert Review. 654 9. Security Considerations 655 This document does not introduce any change in terms of OSPF 656 security. It simply proposes to flood MPLS label information via the 657 IGP. All existing procedures to ensure message integrity do apply 658 here. 660 10. References 662 10.1. Normative References 664 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 665 Requirement Levels", BCP 14, RFC 2119, March 1997. 667 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 668 BGP-4", RFC 3107, May 2001. 670 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 671 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 672 Tunnels", RFC 3209, December 2001. 674 [RFC3630] Katz, D., Kompella, K. and D. Yeung, "Traffic Engineering 675 (TE) Extensions to OSPF Version 2", RFC 3630, September 676 2003. 678 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 679 Hierarchy with Generalized Multi-Protocol Label Switching 680 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 682 [RFC5036] Andersson, L., Minei, I. and B. Thomas, "LDP 683 Specification", RFC 5036, October 2007. 685 [RFC5151] Farrel, A., Ayyangar, A. and JP. Vasseur, "Inter-Domain 686 MPLS and GMPLS Traffic Engineering -- Resource Reservation 687 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 688 5151, February 2008. 690 [RFC5250] Berger, L., Bryskin, I., Zinin, A. and R. Coltun, "The 691 OSPF Opaque LSA Option", RFC 5250, July 2008. 693 10.2. Informative References 695 [I-D.gredler-rtgwg-igp-label-advertisement] 696 Gredler, H., Amante, S., Scholl, T. and L. Jalil, 697 "Advertising MPLS labels in IGPs", Internet-Draft draft- 698 gredler-rtgwg-igp-label-advertisement-03, April 2013. 700 [I-D.previdi-filsfils-isis-segment-routing] 701 Previdi, S., Filsfils, C., Bashandy, A., Horneffer, M., 702 Decraene, B., Litkowski, S., Milojevic, I., Shakir, R., 703 Ytti, S., Henderickx, W. and J. Tantsura, "Segment Routing 704 with IS-IS Routing Protocol", Internet-Draft draft- 705 previdi-filsfils-isis-segment-routing-02, March 2013. 707 Authors' Addresses 708 Hannes Gredler, editor 709 Juniper Networks, Inc. 710 1194 N. Mathilda Ave. 711 Sunnyvale, CA 94089 712 US 714 Email: hannes@juniper.net 716 Shane Amante 717 Level 3 Communications, Inc. 718 1025 Eldorado Blvd 719 Broomfield, CO 80021 720 US 722 Email: shane@level3.net 724 Tom Scholl 725 Amazon 726 Seattle, WN 727 US 729 Email: tscholl@amazon.com 731 Luay Jalil 732 Verizon 733 1201 E Arapaho Rd. 734 Richardson, TX 75081 735 US 737 Email: luay.jalil@verizon.com