idnits 2.17.1 draft-gredler-isis-label-advertisement-03.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 45 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 21, 2013) is 3983 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 (-10) exists of draft-ietf-rtgwg-mrt-frr-architecture-02 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS for IP Internets H. Gredler, Ed. 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track S. Amante 5 Expires: November 22, 2013 Level 3 Communications, Inc. 6 T. Scholl 7 Amazon 8 L. Jalil 9 Verizon 10 May 21, 2013 12 Advertising MPLS labels in IS-IS 13 draft-gredler-isis-label-advertisement-03 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 a 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 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 label bindings using the IS-IS 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 22, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Motivation, Rationale and Applicability . . . . . . . . . . . 4 74 2.1. Issue: Bi-directionality semantics . . . . . . . . . . . . 5 75 2.2. Issue: IP path semantics . . . . . . . . . . . . . . . . . 5 76 2.3. Issue: Lack of 'path' notion . . . . . . . . . . . . . . . 5 77 2.4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 78 3. MPLS label TLV . . . . . . . . . . . . . . . . . . . . . . . . 6 79 3.1. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 7 80 3.2. subTLV support . . . . . . . . . . . . . . . . . . . . . . 7 81 3.3. IPv4 Prefix ERO subTLV . . . . . . . . . . . . . . . . . . 7 82 3.4. IPv6 Prefix ERO subTLV . . . . . . . . . . . . . . . . . . 8 83 3.5. Unnumbered Interface ID ERO subTLV . . . . . . . . . . . . 9 84 3.6. IPv4 Prefix Bypass ERO subTLV . . . . . . . . . . . . . . 10 85 3.7. IPv6 Prefix Bypass ERO subTLV . . . . . . . . . . . . . . 10 86 3.8. Unnumbered Interface ID Bypass ERO subTLV . . . . . . . . 11 87 3.9. Prefix ERO and Prefix Bypass ERO subTLV path semantics . . 12 88 3.10. All Router Block subTLV . . . . . . . . . . . . . . . . . 12 89 3.11. All Router ID IPv4 Map subTLV . . . . . . . . . . . . . . 14 90 3.12. All Router ID IPv6 Map subTLV . . . . . . . . . . . . . . 15 91 4. Advertising Label Examples . . . . . . . . . . . . . . . . . . 15 92 4.1. Sample Topology . . . . . . . . . . . . . . . . . . . . . 15 93 4.1.1. Transport IP addresses and Router-IDs . . . . . . . . 16 94 4.1.2. Link IP addresses . . . . . . . . . . . . . . . . . . 16 95 4.2. One-hop LSP to an adjacent Router . . . . . . . . . . . . 17 96 4.3. One-hop LSP to an adjacent Router using a specific link . 17 97 4.4. Advertisement of Fast Re-Route LSP for One-Hop LSP . . . . 17 98 4.5. Advertisement of an RSVP LSP . . . . . . . . . . . . . . . 18 99 4.6. Advertisement of an LDP LSP . . . . . . . . . . . . . . . 18 100 4.7. Interarea advertisement of diverse paths . . . . . . . . . 18 101 4.8. Advertisement of SPT labels using 'All Router Block' 102 TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 103 4.9. Expansion of an 'All Router Block' subTLV . . . . . . . . 20 104 5. Inter Area Protocol Procedures . . . . . . . . . . . . . . . . 21 105 5.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 21 106 5.2. Data plane operations . . . . . . . . . . . . . . . . . . 21 107 5.3. Control plane operations . . . . . . . . . . . . . . . . . 21 108 5.3.1. MPLS Label operations . . . . . . . . . . . . . . . . 21 109 5.3.2. MPLS Label Block operations . . . . . . . . . . . . . 22 110 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 111 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 112 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 113 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 114 9.1. Normative References . . . . . . . . . . . . . . . . . . . 23 115 9.2. Informative References . . . . . . . . . . . . . . . . . . 24 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 118 1. Introduction 120 MPLS label allocations are predominantly distributed by using the LDP 121 [RFC5036], RSVP [RFC5151] or labeled BGP [RFC3107] protocol. All of 122 those protocols have in common that they are session oriented, which 123 means that in order to obtain label binding for a given destination 124 FEC from a given router one needs first to establish a direct control 125 plane (LDP/RSVP/LBGP) session with that router. 127 There are a couple of practical use cases 128 [I-D.gredler-rtgwg-igp-label-advertisement] where the consumer of a 129 MPLS label binding may not be adjacent to the router that performs 130 the binding. Bringing up an explicit session using the existing 131 label distribution protocols between the non-adjacent router that 132 binds the label and the router that acts as a consumer of this 133 binding is the existing remedy for this dilemma. 135 This document describes an IS-IS protocol extension which allows 136 routers to advertise MPLS label bindings within and beyond an IGP 137 domain, and controlling inter-area distribution. 139 2. Motivation, Rationale and Applicability 141 One possible way of distributing MPLS labels using IS-IS has been 142 described in Segment Routing 143 [I-D.previdi-filsfils-isis-segment-routing]. The authors propose to 144 re-use the IS-Reach TLVs (22, 23, 222) and Extended IP Prefix TLVs 145 (135, 236) for carrying the label information. While retrofitting 146 existing protocol machinery for new purposes is generally a good 147 thing, Segment Routing [I-D.previdi-filsfils-isis-segment-routing] 148 falls short of addressing some use-cases defined in 149 [I-D.gredler-rtgwg-igp-label-advertisement]. 151 The dominant issue around re-using IS-Reach TLVs and the extended IP 152 Prefix TLVs is that both family of TLVs have existing protocol 153 semantics, which might not be well suitable to advertising MPLS label 154 switched paths in a generic fashion. These are specifically: 156 o Bi-directionality semantics 158 o IP path semantics 160 o Lack of 'path' notion 162 2.1. Issue: Bi-directionality semantics 164 'Bi-directionality semantics', affects the complexity around 165 advertisement of unidirectional LSPs. Label advertisement of per- 166 link labels or 'Adj-SIDs' [I-D.previdi-filsfils-isis-segment-routing] 167 is done using IS-reach TLVs. Usually implementations need to have an 168 adjacency in 'Up' state prior to advertising this adjacency as IS- 169 reach TLV in its Link State PDUs (LSPs). In order to advertise e.g. 170 one-hop MPLS LSP in a given link an implementation first needs to 171 have an adjacency, which only transitions to 'Up' state after passing 172 the 3-way check. This implies bi-directionality. If an 173 implementation wants to advertise per-link LSPs to e.g. outside the 174 IGP domain then it would need to fake-up an adjacency. Changing 175 existing IGP Adjacency code to support such cases defeats the purpose 176 of re-using existing functionality as there is not much common 177 functionality to be shared. 179 2.2. Issue: IP path semantics 181 LSPs pointing to a Node are advertised as 'Node-SIDs' 182 [I-D.previdi-filsfils-isis-segment-routing] using the family of 183 extended IP Reach TLVs. That means that in order to advertise a MPLS 184 LSP, one is inheriting the semantics of advertising an IP path. 185 Consider router A has got existing MPLS LSPs to its entire one-hop 186 neighborhood and is re-advertising those MPLS LSPs using IP 187 reachability semantics. Now we have two exact matching IP 188 advertisements. One from the owning router (router B) which 189 advertises its stable transport loopback address and another one from 190 router A re-advertising a MPLS LSP path to router B. Existing routing 191 software may get confused now as the 'stable transport' address shows 192 up from multiple places in the network and more worse the IP 193 forwarding path for control-plane protocols may get mingled with the 194 MPLS data plane. 196 2.3. Issue: Lack of 'path' notion 198 Both IS-Reach TLVs and IP Prefix Reachability TLVs have a limited 199 semantics describing MPLS label-switched paths in the sense of a 200 'path'. Both encoding formats allow to specify a pointer to some 201 specific router, but not to describe a MPLS label switched path 202 containing all of its path segments. 203 [I-D.previdi-filsfils-isis-segment-routing] allows to define 204 'Forwarding Adjacencies' as per [RFC4206]. The way to describe a 205 path of a given forwarding adjacency is to carry a list of "Segment 206 IDs". That implies that nodes which do not yet participate in 207 'Segment routing' or are outside of a 'Segment routing' domain can 208 not be expressed using those path semantics. 210 A protocol for advertising MPLS label switched paths, should be 211 generic enough to express paths sourced by existing MPLS LSPs, such 212 that ingress routers can flexibly combine them according to 213 application needs. 215 2.4. Motivation 217 IGP advertisement of MPLS label switched paths requires a new set of 218 protocol semantics (path paradigm), which hardly can be expressed 219 using the existing IS-IS protocol. This document describes IS-IS 220 protocol extensions which allows generic advertisement of MPLS label 221 bindings in IS-IS. 223 The Protocol extensions described in this document are equally 224 applicable to IPv4 and IPv6 carried over MPLS. Furthermore the 225 proposed use of distributing MPLS Labels using IGP prototocols 226 adheres to the architectural principles laid out in [RFC3031]. 228 3. MPLS label TLV 230 The MPLS Label TLV may be originated by any Traffic Engineering 231 [RFC5305] capable router in an IS-IS domain. The router may 232 advertise a single label binding or a block of label bindings. For 233 single label binding advertisement a router needs to provide at least 234 a single 'nexthop style' anchor. The protocol supports more than one 235 'nexthop style' anchor to be attached to a Label binding, which 236 results into a simple path description language. In analogy to RSVP 237 the terminology for this is called an 'Explicit Route Object' (ERO). 238 Since ERO style path notation allows to anchor label bindings to to 239 both link and node IP addresses any label switched path, can be 240 described. Furthermore also Label Bindings from other protocols can 241 get easily re-advertised. 243 Due to the limited size of subTLV space (See [RFC5311] section 4.5 244 for details), The MPLS Label TLV has cumulative rather than canceling 245 semantics. If a router originates more than one MPLS Label TLV with 246 the same Label value, then the subTLVs of the second, third, etc. 247 TLV are accumulated. Since some subTLVs represent an ordered set 248 (e.g. ERO subTLVs) allocation and ordering of TLV space inside 249 particular IS-IS LSP fragment is significant and needs to be tracked. 251 The MPLS Label TLV has type 149 and has the following format: 253 0 1 2 3 254 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 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | Type | Length | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 |U|R|R|R| MPLS Label | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Figure 1: MPLS TLV format 263 o 4 bits of flags, consisting of: 265 * 1 bit of up/down information (U bit) 267 * 3 bits are reserved for future use 269 o 20 bits of MPLS label information 271 o 0-252 octets of sub-TLVs, where each sub-TLV consists of a 272 sequence of: 274 * 1 octet of sub-TLV type 276 * 1 octet of length of the value field of the sub-TLV 278 * 0-250 octets of value 280 3.1. Flags 282 Flags 284 Up/Down Bit: A router may flood MPLS label information across 285 level boundaries. In order to prevent flooding loops, a router 286 will Set the Up/Down (U-Bit) when propagating from Level 2 down to 287 Level 1. This is done as per the procedures for IP Prefixes lined 288 out in [RFC5302]. 290 3.2. subTLV support 292 An originating router MAY want to attach one or more subTLVs to the 293 MPLS label TLV. SubTLVs presence is inferred from the length of the 294 MPLS Label TLV. If the MPLS Label TLV Length field is > 3 octets 295 then one or more subTLVs may be present. 297 3.3. IPv4 Prefix ERO subTLV 299 The IPv4 ERO subTLV (Type 1) describes a path segment using IPv4 300 Prefix style of encoding. Its appearance and semantics have been 301 borrowed from Section 4.3.3.2 [RFC3209]. 303 The 'Prefix Length' field contains the length of the prefix in bits. 304 Only the most significant octets of the prefix are encoded. I.e. 1 305 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 306 16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix 307 length 25 up to 32, etc. 309 The 'L' bit in the subTLV is a one-bit attribute. If the L bit is 310 set, then the value of the attribute is 'loose.' Otherwise, the 311 value of the attribute is 'strict.' 313 0 1 2 3 314 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 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 |L| Type | Length | Prefix Length | IPv4 Prefix | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | IPv4 Prefix (continued, variable-length | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 2: IPv4 Prefix ERO subTLV format 323 3.4. IPv6 Prefix ERO subTLV 325 The IPv6 ERO subTLV (Type 2) describes a path segment using IPv6 326 Prefix style of encoding. Its appearance and semantics have been 327 borrowed from Section 4.3.3.3 [RFC3209]. 329 The 'Prefix Length' field contains the length of the prefix in bits. 330 Only the most significant octets of the prefix are encoded. I.e. 1 331 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 332 16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix 333 length 25 up to 32, ...., 16 octets for prefix length 113 up to 128. 335 The 'L' bit in the subTLV is a one-bit attribute. If the L bit is 336 set, then the value of the attribute is 'loose.' Otherwise, the 337 value of the attribute is 'strict.' 338 0 1 2 3 339 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 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 |L| Type | Length | Prefix Length | IPv6 Prefix | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | IPv6 Prefix (continued) | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | IPv6 Prefix (continued) | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | IPv6 Prefix (continued) | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | IPv6 Prefix (continued, variable length) | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Figure 3: IPv6 Prefix ERO subTLV format 354 3.5. Unnumbered Interface ID ERO subTLV 356 The appearance and semantics of the 'Unnumbered Interface ID' have 357 been borrowed from Section 4 [RFC3477]. 359 The Unnumbered Interface-ID ERO subTLV (Type 9) describes a path 360 segment that spans over an unnumbered interface. Unnumbered 361 interfaces are referenced using the interface index. Interface 362 indices are assigned local to the router and therefore not unique 363 within a domain. All elements in an ERO path need to be unique 364 within a domain and hence need to be disambiguated using a domain 365 unique Router-ID. 367 The 'Router-ID' field contains the router ID of the router which has 368 assigned the 'Interface ID' field. Its purpose is to disambiguate 369 the 'Interface ID' field from other routers in the domain. 371 IS-IS supports two Router-ID formats: 373 o (TLV 134, 32-Bit format) [RFC5305] 375 o (TLV 140, 128-Bit format) [RFC6119] 377 The actual Router-ID format gets derived from the 'Length' field. 379 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 381 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 383 The 'Interface ID' is the identifier assigned to the link by the 384 router specified by the router ID. 386 The 'L' bit in the subTLV is a one-bit attribute. If the L bit is 387 set, then the value of the attribute is 'loose.' Otherwise, the 388 value of the attribute is 'strict.' 390 0 1 2 3 391 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 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 |L| Type | Length | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 // Router ID (32 or 128 bits) // 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Interface ID (32 bits) | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Figure 4: Unnumbered Interface ID ERO subTLV format 402 3.6. IPv4 Prefix Bypass ERO subTLV 404 The IPv4 Bypass ERO subTLV (Type 3) describes a Bypass LSP path 405 segment using IPv4 Prefix style of encoding. Its appearance and 406 semantics have been borrowed from Section 4.3.3.2 [RFC3209]. 408 The 'Prefix Length' field contains the length of the prefix in bits. 409 Only the most significant octets of the prefix are encoded, i.e. 1 410 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 411 16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix 412 length 25 up to 32, etc. 414 The 'L' bit in the subTLV is a one-bit attribute. If the L bit is 415 set, then the value of the attribute is 'loose.' Otherwise, the 416 value of the attribute is 'strict.' 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 |L| Type | Length | Prefix Length | IPv4 Prefix | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | IPv4 Prefix (continued, variable-length) | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 Figure 5: IPv4 Prefix Bypass ERO subTLV format 428 3.7. IPv6 Prefix Bypass ERO subTLV 430 The IPv6 ERO subTLV (Type 4) describes a Bypass LSP path segment 431 using IPv6 Prefix style of encoding. Its appearance and semantics 432 have been borrowed from Section 4.3.3.3 [RFC3209]. 434 The 'Prefix Length' field contains the length of the prefix in bits. 435 Only the most significant octets of the prefix are encoded, i.e. 1 436 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 437 16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix 438 length 25 up to 32, ...., 16 octets for prefix length 113 up to 128. 440 The 'L' bit in the subTLV is a one-bit attribute. If the L bit is 441 set, then the value of the attribute is 'loose.' Otherwise, the 442 value of the attribute is 'strict.' 444 0 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 |L| Type | Length | Prefix Length | IPv6 Prefix | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | IPv6 Prefix (continued) | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | IPv6 Prefix (continued) | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | IPv6 Prefix (continued) | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | IPv6 Prefix (continued, variable length) | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Figure 6: IPv6 Prefix Bypass ERO subTLV format 460 3.8. Unnumbered Interface ID Bypass ERO subTLV 462 The appearance and semantics of the 'Unnumbered Interface ID' have 463 been borrowed from Section 4 [RFC3477]. 465 The Unnumbered Interface-ID Bypass ERO subTLV (Type 10) describes a 466 Bypass LSP path segment that spans over an unnumbered interface. 467 Unnumbered interfaces are referenced using the interface index. 468 Interface indices are assigned local to the router and therefore not 469 unique within a domain. All elements in an ERO path need to be 470 unique within a domain and hence need to be disambiguated using a 471 domain unique Router-ID. 473 The 'Router-ID' field contains the router ID of the router which has 474 assigned the 'Interface ID' field. Its purpose is to disambiguate 475 the 'Interface ID' field from other routers in the domain. 477 IS-IS supports two Router-ID formats: 479 o (TLV 134, 32-Bit format) [RFC5305] 481 o (TLV 140, 128-Bit format) [RFC6119] 483 The actual Router-ID format gets derived from the 'Length' field. 485 o For 32-Bit Router-ID width the subTLV length is set to 8 octets. 487 o For 128-Bit Router-ID width the subTLV length is set to 20 octets. 489 The 'Interface ID' is the identifier assigned to the link by the 490 router specified by the router ID. 492 The 'L' bit in the subTLV is a one-bit attribute. If the L bit is 493 set, then the value of the attribute is 'loose.' Otherwise, the 494 value of the attribute is 'strict.' 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 |L| Type | Length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 // Router ID (32 or 128 bits) // 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Interface ID (32 bits) | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Figure 7: Unnumbered Interface ID Bypass ERO subTLV format 508 3.9. Prefix ERO and Prefix Bypass ERO subTLV path semantics 510 All 'Prefix ERO' and 'Prefix Bypass ERO' information represents an 511 ordered set which describes the segments of a label-switched path. 512 The last Prefix ERO subTLV describes the segment closest to the 513 egress point of the LSP. Contrary the first Prefix ERO subTLV 514 describes the first segment of a label switched path. If a router 515 extends or stitches a label switched path it MUST prepend the new 516 segments path information to the Prefix ERO list. The same ordering 517 applies for the Bypass ERO labels. An implementation SHOULD first 518 encode all primary path EROs followed by the bypass EROs. 520 3.10. All Router Block subTLV 522 The 'All Router Block' subTLV (Type 6) denominates the label block 523 size of an MPLS Label advertisement and its semantics to connect to 524 all routers in a given IS-IS domain using a local assigned [RFC3031] 525 label range. Note that the actual mapping of a router within the 526 label range is done using the subTLVs described in Section 3.11 and 527 Section 3.12. Since generation of an 'All Router ID IPv4 Map' or 528 'All Router ID IPv6 Map' subTLV is a local policy decision, it might 529 be the case that connectivity is provided not to 'All' but rather a 530 subset of 'All' routers. Keeping policy decisions aside, for 531 simplicity reasons, assume that All Routers in a domain do generate 532 either the 'All Router ID IPv4 Map' or 'All Router ID IPv6 Map' 533 subTLVs and therefore all routers desire construction of a Label 534 switched path from every source router in the network. The basic 535 concept of using label blocks to provide connectivity to a set of 536 routers has been borrowed from [RFC4761] which allows to advertise 537 labels from multiple end-points using a single control-plane message. 538 The difference to [RFC4761] is that rather than advertising where a 539 particular packet came from (=source semantics), destination 540 semantics (where a particular packet will be going to) is advertised. 542 Along with each label block a router advertises one for more 'IDs'. 543 The 'ID' must be unique within a given domain. The 'ID' serves as 544 ordinal to determine the actual label value inside the set of all 545 advertised label ranges of a given router. A receiving router uses 546 the ordinal to determine the actual label value in order to construct 547 forwarding state to a particular destination router. The 'ID' is 548 separately advertised using the subTLVs described in Section 3.11 and 549 Section 3.12. 551 The ability to advertise more than one label block eases operational 552 procedures for increasing the number of supported routers within a 553 domain. For example consider a given domain has got support for 554 routers and runs out of ID space. It simply advertises one more 555 label block to cover additional ordinals outside the range of the 556 first label block. An example of label-block expansion is described 557 in more detail in Section 4.9 559 0 1 2 3 560 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Type | Length | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | Block Size | Algo | Topology-ID | 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 Figure 8: All Router Block subTLV format 569 The 'Block Size' value contains the size of the label advertisement. 570 The 'value determines the amount of reachable router endpoints within 571 a given Label block. It MUST contain a value greater or equal than 572 two. Note that the label base is inferred from the Label Value in 573 the carrying MPLS Label TLV. For example if a router wants to 574 advertise a label range of 5000-5099 then it would need to generate a 575 MPLS Label TLV with a Label value of 5000 and a Block Size of 100. 577 The 'Algo' value denominates the path computation algorithm in order 578 to calculate the forwarding topology. The basic SPF algorithm has an 579 assigned 'Algo' code point of zero. The purpose of the 'Algo' field 580 is to extend the notion of Label Block Signaling to arbitrary 581 algorithms like for example 'MRT' 582 ([I-D.ietf-rtgwg-mrt-frr-architecture]. Advertised Label Blocks with 583 an unknown, unsupported or non-configured algorithm MUST be silently 584 ignored. 586 The 'Reserved' bits are for future use. They should be zero on 587 transmission and ignored on receipt. 589 The 'Topology-ID' field contains the Multi Topology ID ([RFC5120]) 590 for which the advertised Label Block does apply. The basic IPv4 591 unicast Topology has an assigned 'Topology-ID' code point of zero. 592 The basic IPv6 unicast Topology has an assigned 'Topology=ID' code 593 point of 2. Advertised Label Blocks with an unknown, unsupported or 594 non-configured Topology-ID MUST be silently ignored. 596 A MPLS Label TLV containing the 'All Router Block' subTLV MUST only 597 contain the 'All Router IPv4 Map' subTLV (Section 3.11) or the 'All 598 Router IPv6 Map' subTLV (Section 3.12). 600 3.11. All Router ID IPv4 Map subTLV 602 The 'All Router ID IPv4 Map' TLV (Type 7) maps an 'ID' to a given 603 stable transport IPv4 address. Its purpose is to associate a given 604 transport IPv4 IP address to the ordinal inside a label range as 605 described in Section 3.10. 607 A router MAY advertise more than one 'ID' to 'IPv4 address' mapping 608 pair, in case it has more than one stable transport IPv4 address. 610 0 1 2 3 611 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 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Type | Length | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | IPv4 Address (4 octets) | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | ID | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 Figure 9: All Router ID IPv4 Map subTLV format 622 The 'IPv4 address' contains stable IPv4 transport address of a given 623 router. 625 The 'ID' contains the ordinal value of an advertising router inside 626 the set of all advertised label blocks of a given router. 628 3.12. All Router ID IPv6 Map subTLV 630 The 'All Router ID IPv6 Map' TLV (Type 8) maps an 'ID' to a given 631 stable transport IPv6 address. Its purpose is to associate a given 632 transport IPv6 IP address to the ordinal inside a label range as 633 described in Section 3.10. 635 A router MAY advertise more than one 'ID' to 'IPv6 address' mapping 636 pair, in case it has more than one stable transport IPv6 address. 638 0 1 2 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Type | Length | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | IPv6 Address (16 octets) | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | IPv6 Address (continued) | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | IPv6 Address (continued) | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | IPv6 Address (continued) | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | ID | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 Figure 10: All Router ID IPv6 Map subTLV format 656 The 'IPv6 address' contains the stable IPv6 transport address of a 657 given router. 659 The 'ID' contains the ordinal value of an advertising router inside 660 the set of all advertised label blocks of a given router. 662 4. Advertising Label Examples 664 4.1. Sample Topology 666 The following topology (Figure 11) and IP addresses shall be used 667 throughout the Label advertisement examples. 669 AS1 : AS 2 670 : 671 : : 672 Level 1 : Level 2 : 673 : : 674 : : 675 +-----+ +-----+-IP3--1-IP4--+-----+ : 676 | R1 +-IP1--1-IP2--+ R2 | | R3 | : 677 +--+--+ +--+--+-IP5--3-IP6--+--+--+-IP15-IP16- 678 | | | : \ 679 IP9 IP7 IP13 : \ 680 | | | : +--+--+ 681 1 1 1 : | R7 | 682 | | | : +--+--+ 683 IP10 IP8 IP14 : / 684 | | | : / 685 +--+--+ +--+--+ +--+--+-IP17-IP18- 686 | R4 +-IP19-2-IP20-+ R5 |-IP11-2-IP12-| R6 | : 687 +-----+ +-----+ +-----+ : 688 : : 689 : : 690 : : 692 Figure 11: Sample Topology 694 4.1.1. Transport IP addresses and Router-IDs 696 o R1: 192.168.1.1 698 o R2: 192.168.1.2 700 o R3: 192.168.1.3 702 o R4: 192.168.1.4 704 o R5: 192.168.1.5 706 o R6: 192.168.1.6 708 o R7: 192.168.1.7 710 4.1.2. Link IP addresses 712 o R1 to R2 link: 10.0.0.1, 10.0.0.2 714 o R1 to R4 link: 10.0.0.9, 10.0.0.10 715 o R2 to R3 link #1: 10.0.0.3, 10.0.0.4 717 o R2 to R3 link #2: 10.0.0.5, 10.0.0.6 719 o R2 to R5 link: 10.0.0.7, 10.0.0.8 721 o R3 to R6 link: 10.0.0.13, 10.0.0.14 723 o R3 to R7 link: 10.0.0.15, 10.0.0.16 725 o R4 to R5 link: 10.0.0.19, 10.0.0.20 727 o R5 to R6 link: 10.0.0.11, 10.0.0.12 729 o R6 to R7 link: 10.0.0.17, 10.0.0.18 731 The IGP link metrics are displayed in the middle of the link. All of 732 them are assumed to be bi-directional. 734 4.2. One-hop LSP to an adjacent Router 736 If R1 would advertise a label bound to a one-hop LSP from R1 to 737 R2 it would encode as follows: 739 TLV 149: MPLS label , Flags {}: 741 IPv4 Prefix ERO subTLV: 192.168.1.2/32, Strict 743 4.3. One-hop LSP to an adjacent Router using a specific link 745 If R2 would advertise a label bound to a one-hop LSP from R2 to 746 R3, using the link #2 it would encode as follows 748 TLV 149: MPLS label , Flags {}: 750 IPv4 Prefix ERO subTLV: 10.0.0.6/32, Strict 752 4.4. Advertisement of Fast Re-Route LSP for One-Hop LSP 754 R2 may advertise a one-hop LSP from R2 to R3, along with a Link 755 Protection Bypass for the directly adjacent links between those two 756 nodes. The Link Protection Bypass would use the path: {R2, R5, R6, 757 R3}. R2 would encode both the primary LSP and Link Protection Bypass 758 LSP as follows: 760 TLV 149: MPLS label , Flags {}: 762 IPv4 Prefix ERO subTLV: 192.168.1.3/32, Strict 764 IPv4 Prefix Bypass ERO subTLV: 192.168.1.5/32, Strict 766 IPv4 Prefix Bypass ERO subTLV: 192.168.1.6/32, Strict 768 IPv4 Prefix Bypass ERO subTLV: 192.168.1.3/32, Strict 770 4.5. Advertisement of an RSVP LSP 772 Consider a RSVP LSP name "R2-to-R6" traversing (R2 to R3 using link 773 #1, R6): 775 If R2 would advertise a label bound to the RSVP LSP named 776 'R2-to-R6', it would encode as follows 778 TLV 149: MPLS label , Flags {}: 780 IPv4 Prefix ERO subTLV: 10.0.0.4/32, Strict 782 IPv4 Prefix ERO subTLV: 192.168.1.6/32, Strict 784 4.6. Advertisement of an LDP LSP 786 Consider R2 that creates a LDP label binding for FEC 172.16.0.0/12 787 using label . 789 If R2 would re-advertise this binding in IS-IS it would encode as 790 follows 792 TLV 149: MPLS label , Flags {}: 794 IPv4 Prefix ERO subTLV: 172.16.0.0/12, Loose 796 4.7. Interarea advertisement of diverse paths 798 Consider two R2->R6 paths: {R2, R3, R6} and {R2, R5, R6} 800 Consider two R5->R3 paths: {R5, R2, R3} and {R5, R6, R3} 802 R2 encodes its two paths to R6 as follows: 804 TLV 149: MPLS label , Flags {}: 806 IPv4 Prefix ERO subTLV: 192.168.1.3, Strict 808 IPv4 Prefix ERO subTLV: 192.168.1.6, Strict 810 TLV 149: MPLS label , Flags {}: 812 IPv4 Prefix ERO subTLV: 192.168.1.5, Strict 814 IPv4 Prefix ERO subTLV: 192.168.1.6, Strict 816 R5 encodes its two paths to R3 as follows: 818 TLV 149: MPLS label , Flags {}: 820 IPv4 Prefix ERO subTLV: 192.168.1.2, Strict 822 IPv4 Prefix ERO subTLV: 192.168.1.3, Strict 824 TLV 149: MPLS label , Flags {}: 826 IPv4 Prefix ERO subTLV: 192.168.1.6, Strict 828 IPv4 Prefix ERO subTLV: 192.168.1.3, Strict 830 A receiving L1 router does see now all 4 paths and may decide to 831 load-balance across all or a subset of them. 833 4.8. Advertisement of SPT labels using 'All Router Block' TLV 835 All routers within a given area MUST advertise their Label Blocks 836 along with an 'ID'. 838 If R2 would advertise a label block with a size of 10, declaring 839 SPT label forwarding support to all routers within a given domain, it 840 would encode as follows: 842 TLV 149: MPLS Label , Flags {}: 844 All Router Block subTLV: Block Size 10, Algo 0, Topology 0 846 All Router ID IPv4 Map subTLV: ID 2, 192.168.1.2 848 If R3 would advertise a label block with a size of 10, declaring 849 SPT label forwarding support to all routers within a given domain, it 850 would encode as follows: 852 TLV 149, MPLS Label , Flags {}: 854 All Router Block subTLV: Block Size 10, Algo 0, Topology 0 856 All Router ID IPv4 Map subTLV: ID 3, 192.168.1.3 858 If R5 would advertise a label block with a size of 10, declaring 859 SPT label forwarding support to all routers within a given domain, it 860 would encode as follows: 862 TLV 149, MPLS Label , Flags {}: 864 All Router Block subTLV: Block Size 10, Algo 0, Topology 0 866 All Router ID IPv4 Map subTLV: ID 5, 192.168.1.5 868 If R6 would advertise a label block with a size of 10, declaring 869 SPT label forwarding support to all routers within a given domain, it 870 would encode as follows: 872 TLV 149, MPLS Label , Flags {}: 874 All Router Block subTLV: Block Size 10, Algo 0, Topology 0 876 All Router ID IPv4 Map subTLV: ID 6, 192.168.1.6 878 Consider now R2 constructing a SPT label for R6. R2s SPT to R6 is 879 {R2, IP4, R3, R6}. R2 first determines if its downstream router (R3) 880 has advertised a label-block. Since R3 has advertised a label block 881 'N2' and it has received R6 'ID' of 6 it will be picking the 6th 882 label value inside the advertised range of its downstream neighbor. 883 Specifically R2 MUST be program a MPLS SWAP for its own label range 884 Label(N1+6) to Label(N2+6), NH 10.0.0.4 into its MPLS transit RIB. 885 Furthermore R2 MAY program a MPLS PUSH operation for IP 192.168.1.6 886 to Label (N2+6), NH 10.0.0.4 into its IPv4 tunnel RIB. 888 Next walk down to R3, which is the next router on the SPT tree 889 towards R6. R3s SPT to R6 is {R3, R6}. R3 determines if its 890 downstream router (R6) has advertised a label-block. Since R6 has 891 advertised a label block 'N4' and it has received R6 'ID' of 6 it 892 will be picking the 6th label value inside the advertised range of 893 its downstream neighbor. Since R3 is the penultimate router to R6 it 894 MUST program a MPLS POP for its own label range Label(N2+6) NH 895 10.0.0.14 into its MPLS transit RIB. Furthermore R3 MAY program a 896 MPLS NOP for IP 192.168.1.6, NH 10.0.0.14 into its IPv4 tunnel RIB. 898 4.9. Expansion of an 'All Router Block' subTLV 900 All routers within a given area MUST advertise their Label Blocks 901 along with an 'ID'. Now assume that the initial label block size 902 assignment is too small to support all routers which generate an 903 ordinal within an IGP domain. Consider the seven routers in 904 Figure 11, and assume that R7 advertises a new ID '15' using an 'All 905 Router ID Map' subTLV. ID '15' is outside of the range of '10' as 906 per the previous example in Section 4.8. Now all the routers in an 907 IGP domain need to advertise one more label block in order to map the 908 ID '15' to an actual label value. 910 All routers would advertise in addition to their label block with 911 a size of 10, a second label block with a size sufficient enough 912 that the new ordinal can get covered. In this example the same block 913 size 10 is used also for the second label block. For example router 914 R2 would advertise the following label bindings. 916 TLV 149: MPLS Label , Flags {}: 918 All Router Block subTLV: Block Size 10, Algo 0, Topology 0 920 All Router ID IPv4 Map subTLV: ID 2, 192.168.1.2 922 TLV 149: MPLS Label , Flags {}: 924 All Router Block subTLV: Block Size 10, Algo 0, Topology 0 926 Now the upstream router can map the new ID of R7 to an actual label 927 value, as ID '15' corresponds to the 5th label inside the second 928 Label block. 930 5. Inter Area Protocol Procedures 932 5.1. Applicability 934 Propagation of a MPLS LSP across a level boundary is a local policy 935 decision. 937 5.2. Data plane operations 939 If local policy dictates that a given L1L2 router needs to re- 940 advertise a MPLS LSPs from one Level to another then it MUST allocate 941 a new label and program its label forwarding table to connect the new 942 label to the path in the respective other level. Depending on how to 943 reach the re-advertised LSP, this is typically done using a MPLS 944 'SWAP' or 'SWAP/PUSH' data plane operation. 946 5.3. Control plane operations 948 5.3.1. MPLS Label operations 950 If local policy dictates that a given L1L2 router re-advertises a 951 MPLS LSPs into another Level then it MUST prepend its "Traffic- 952 Engineering-ID" as a loose hop in the Prefix ERO subTLV list. If the 953 LSP is propagated from a higher Level to a lower Level then the 954 'Down' bit MUST be set. 956 5.3.2. MPLS Label Block operations 958 If local policy dictates that a given L1L2 router advertises its 'All 959 Router Block' into another Level, then it also MUST re-advertise all 960 known 'ID' ordinals (again gated by policy) to the respective other 961 Level. Without knowledge of all 'ID's in the network no router is 962 able to construct SPT label switched paths. If a Label Block and its 963 ID mappings are propagated from a higher Level to a lower Level then 964 the 'Down' bit MUST be set. 966 6. Acknowledgements 968 Many thanks to Yakov Rekhter and John Drake for their useful 969 comments. 971 7. IANA Considerations 973 This documents request allocation for the following TLVs and subTLVs. 975 +-----+--------+----------------------+------+---------+------------+ 976 | PDU | TLV | subTLV | Type | subType | #Occurence | 977 +-----+--------+----------------------+------+---------+------------+ 978 | LSP | MPLS | | 149 | | >=0 | 979 | | Label | | | | | 980 | | | IPv4 Prefix ERO | | 1 | >=0 | 981 | | | IPv6 Prefix ERO | | 2 | >=0 | 982 | | | Unnumbered Interface | | 9 | >=0 | 983 | | | ID ERO | | | | 984 | | | IPv4 Prefix Bypass | | 3 | >=0 | 985 | | | ERO | | | | 986 | | | IPv6 Prefix Bypass | | 4 | >=0 | 987 | | | ERO | | | | 988 | | | Unnumbered Interface | | 10 | >=0 | 989 | | | ID Bypass ERO | | | | 990 | | | All Router Block | | 6 | >=0 | 991 | | | All Router ID IPv4 | | 7 | >=0 | 992 | | | Map | | | | 993 | | | All Router ID IPv6 | | 8 | >=0 | 994 | | | Map | | | | 995 +-----+--------+----------------------+------+---------+------------+ 997 Table 1: IANA allocations 999 The MPLS Label TLV requires a new sub-registry. Type value 149 has 1000 been assigned, with a starting sub-TLV value of 1, range from 1-127, 1001 and managed by Expert Review. 1003 8. Security Considerations 1005 This document does not introduce any change in terms of IS-IS 1006 security. It simply proposes to flood MPLS label information via the 1007 IGP. All existing procedures to ensure message integrity do apply 1008 here. 1010 9. References 1012 9.1. Normative References 1014 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1015 Requirement Levels", BCP 14, RFC 2119, March 1997. 1017 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 1018 Label Switching Architecture", RFC 3031, January 2001. 1020 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 1021 BGP-4", RFC 3107, May 2001. 1023 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1024 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1025 Tunnels", RFC 3209, December 2001. 1027 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 1028 in Resource ReSerVation Protocol - Traffic Engineering 1029 (RSVP-TE)", RFC 3477, January 2003. 1031 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 1032 Hierarchy with Generalized Multi-Protocol Label Switching 1033 (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. 1035 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 1036 (VPLS) Using BGP for Auto-Discovery and Signaling", 1037 RFC 4761, January 2007. 1039 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1040 Specification", RFC 5036, October 2007. 1042 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 1043 Topology (MT) Routing in Intermediate System to 1044 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 1046 [RFC5151] Farrel, A., Ayyangar, A., and JP. Vasseur, "Inter-Domain 1047 MPLS and GMPLS Traffic Engineering -- Resource Reservation 1048 Protocol-Traffic Engineering (RSVP-TE) Extensions", 1049 RFC 5151, February 2008. 1051 [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix 1052 Distribution with Two-Level IS-IS", RFC 5302, 1053 October 2008. 1055 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1056 Engineering", RFC 5305, October 2008. 1058 [RFC5311] McPherson, D., Ginsberg, L., Previdi, S., and M. Shand, 1059 "Simplified Extension of Link State PDU (LSP) Space for 1060 IS-IS", RFC 5311, February 2009. 1062 [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic 1063 Engineering in IS-IS", RFC 6119, February 2011. 1065 9.2. Informative References 1067 [I-D.gredler-rtgwg-igp-label-advertisement] 1068 Gredler, H., Amante, S., Scholl, T., and L. Jalil, 1069 "Advertising MPLS labels in IGPs", 1070 draft-gredler-rtgwg-igp-label-advertisement-05 (work in 1071 progress), May 2013. 1073 [I-D.ietf-rtgwg-mrt-frr-architecture] 1074 Atlas, A., Kebler, R., Envedi, G., Csaszar, A., Tantsura, 1075 J., Konstantynowicz, M., White, R., and M. Shand, "An 1076 Architecture for IP/LDP Fast-Reroute Using Maximally 1077 Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture-02 1078 (work in progress), February 2013. 1080 [I-D.previdi-filsfils-isis-segment-routing] 1081 Previdi, S., Filsfils, C., Bashandy, A., Horneffer, M., 1082 Decraene, B., Litkowski, S., Milojevic, I., Shakir, R., 1083 Ytti, S., Henderickx, W., and J. Tantsura, "Segment 1084 Routing with IS-IS Routing Protocol", 1085 draft-previdi-filsfils-isis-segment-routing-02 (work in 1086 progress), March 2013. 1088 Authors' Addresses 1090 Hannes Gredler (editor) 1091 Juniper Networks, Inc. 1092 1194 N. Mathilda Ave. 1093 Sunnyvale, CA 94089 1094 US 1096 Email: hannes@juniper.net 1098 Shane Amante 1099 Level 3 Communications, Inc. 1100 1025 Eldorado Blvd 1101 Broomfield, CO 80021 1102 US 1104 Email: shane@level3.net 1106 Tom Scholl 1107 Amazon 1108 Seattle, WN 1109 US 1111 Email: tscholl@amazon.com 1113 Luay Jalil 1114 Verizon 1115 1201 E Arapaho Rd. 1116 Richardson, TX 75081 1117 US 1119 Email: luay.jalil@verizon.com