idnits 2.17.1 draft-li-teas-role-based-automesh-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 31, 2015) is 3151 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) ** Obsolete normative reference: RFC 4971 (Obsoleted by RFC 7981) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei 5 Expires: March 3, 2016 G. Mirsky 6 Ericsson 7 August 31, 2015 9 Routing Extensions for Discovery of Role-based MPLS Label Switching 10 Router (MPLS LSR) Traffic Engineering (TE) Mesh Membership 11 draft-li-teas-role-based-automesh-01 13 Abstract 15 A Traffic Engineering (TE) mesh-group is defined as a group of Label 16 Switching Routers (LSRs) that are connected by a full mesh of TE 17 LSPs. Routing protocol (OSPF and IS-IS) extensions facilitate 18 discovery of Multiprotocol Label Switching (MPLS) LSR TE mesh 19 membership and automate the creation of a full mesh of TE Label 20 Switched Paths (LSPs). 22 This document introduces a role-based TE mesh-group that applies to 23 the scenarios where full mesh TE LSPs are not necessary and TE LSPs 24 setup depends on the roles of LSRs in a TE mesh-group. Interior 25 Gateway Protocol (IGP) routing extensions for automatic discovery of 26 role-based TE mesh membership are defined accordingly. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on March 3, 2016. 50 Copyright Notice 52 Copyright (c) 2015 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 1.1. Motivation and Scope . . . . . . . . . . . . . . . . . . 3 69 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Role-based TE Mesh Group . . . . . . . . . . . . . . . . . . 4 71 3. IGP Role-based TE Mesh-group Extensions . . . . . . . . . . . 4 72 3.1. OSPF TE-ROLE-MESH-GROUP TLV Format . . . . . . . . . . . 4 73 3.2. IS-IS TE-ROLE-MESH-GROUP Sub-TLV Format . . . . . . . . . 7 74 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 9 75 4.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 78 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 79 6.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 6.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 82 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 85 9.2. Informative References . . . . . . . . . . . . . . . . . 12 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 88 1. Introduction 90 A Traffic Engineering (TE) mesh-group [RFC4972] is defined as a group 91 of Label Switching Routers (LSRs) that are connected by a full mesh 92 of TE LSPs. [RFC4972] specifies Intermediate System-to-Intermediate 93 System (IS-IS) and Open Shortest Path First (OSPF) extensions to 94 provide an automatic discovery of the set of LSR members of a TE 95 mesh-group in order to automate the creation of such mesh of TE LSPs. 97 This is called "auto-mesh TE" or "auto-mesh". Therefore auto-mesh TE 98 largely simplifies the configuration required for the deployment of 99 full mesh TE Label Switched Paths (LSPs). 101 1.1. Motivation and Scope 103 In some deployment scenarios, auto configuration of TE LSPs among 104 specific nodes is useful but a full mesh may not be needed . An 105 example where a full mesh is not required, but a partial mesh would 106 significantly reduce operational overhead, is deployment and 107 operation of TE LSPs in a mobile backhaul network 108 ([I-D.li-mpls-seamless-mpls-mbb]). In this scenario, auto-mesh of TE 109 LSPs between the Cell Site Gateways (CSGs), and Radio Network 110 Controller (RNC) Site Gateways (RSGs) would be useful, and TE LSPs 111 between CSGs, and TE LSPs between RSGs, would not be necessary. The 112 amount of CSGs in mobile backhaul networks are very large. If using 113 the auto-mesh mechanism as defined in [RFC4972], a full mesh TE LSPs 114 will be established among all the CSGs and RSGs, thus resulting in 115 large amount of unnecessary TE LSPs being established from CSGs-to- 116 CSGs, and RSGs-to-RSGs. Potentially causing scaling issues and 117 wasting network resources. 119 Therefore, there are clear requirements to optimize the auto-mesh 120 function for setup of TE LSPs, and allowing specific group membership 121 rather than a full TE mesh between all LSRs. 123 This document introduces a "role-based auto-mesh TE group" or "role- 124 based auto-mesh" where the setup of the TE LSPs are dependent on the 125 roles of the LSRs within a TE mesh-group. The method and procedure 126 for signaling the TE LSPs is out the scope of this document. 128 1.2. Terminology 130 RSVP-TE - Resource Reservation Protocol-Traffic Engineering 132 P2MP - Point-to-Multipoint 134 IS-IS - Intermediate System-to-Intermediate System 136 OSPF - Open Shortest Path First 138 CSG - Cell Site Gateway 140 RNC - Radio Network Controller 142 MBH - Mobile Backhaul 144 MPLS - Multiprotocol Label Switching 145 LSP - Label Switched Path 147 TE LSP - Traffic Engineered LSP 149 2. Role-based TE Mesh Group 151 A role-based TE mesh-group is a special TE mesh-group where TE LSPs 152 will not be established among all member LSRs. LSRs in a role-based 153 TE mesh-group will have different roles. The TE LSPs setup depends 154 on the roles of the LSRs in a TE mesh-group. 156 This document introduces the Hub-Spoke LSR TE mesh-group, where an 157 LSR can be a Hub, a Spoke or both Hub and Spoke (Hub-Spoke) LSR in a 158 mesh-group. The rules for Hub-Spoke TE mesh-group are as follows: 160 - TE LSPs SHOULD only be setup between Spoke and Hub LSRs. 162 - TE LSPs MUST NOT be setup between/among Spoke LSRs. 164 - TE LSPs MUST NOT be setup between/among Hub LSRs. 166 A Hub-Spoke LSR has two roles, for a mesh-group, it allows that a 167 Hub-Spoke LSR can connect to any other Hub, Spoke and Hub-Spoke LSRs. 168 This gives a choice to control whether an LSR can connect to any 169 other LSRs through TE LSPs. When an LSR wants to setup TE LSPs with 170 any other LSRs, configure it to Hub-Spoke LSR, otherwise, keep it as 171 pure Hub or Spoke LSR role. 173 3. IGP Role-based TE Mesh-group Extensions 175 3.1. OSPF TE-ROLE-MESH-GROUP TLV Format 177 The OSPF TE-ROLE-MESH-GROUP TLV is used to advertise that an LSR 178 joins/leaves a role-based TE mesh-group and the role of the LSR in 179 the TE mesh-group. The OSPF TE-ROLE-MESH-GROUP TLV format for IPv4 180 (Figure 2) and IPv6 (Figure 3) is as follows: 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Type | Length | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | mesh-group-number 1 | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 |H|S| Reserved | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Tail-end IPv4 address 1 | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Name length | Tail-end name 1 | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 ~ ~ 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | mesh-group-number n | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 |H|S| Reserved | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Tail-end IPv4 address n | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Name length | Tail-end name n | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 2 - OSPF TE-ROLE-MESH-GROUP TLV format (IPv4) 208 0 1 2 3 209 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 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Type | Length | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | mesh-group-number 1 | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 |H|S| Reserved | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | | 218 | Tail-end IPv6 address 1 | 219 | | 220 | | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Name length | Tail-end name 1 | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 ~ ~ 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | mesh-group-number n | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 |H|S| Reserved | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | | 231 | Tail-end IPv6 address n | 232 | | 233 | | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Name length | Tail-end name n | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 3 - OSPF TE-ROLE-MESH-GROUP TLV format (IPv6) 240 The Type of OSPF TE-ROLE-MESH-GROUP TLV for IPv4 is TBD1, the value 241 of the Length is variable. 243 The Type of OSPF TE-ROLE-MESH-GROUP TLV for IPv6 is TBD2, the value 244 of the Length is variable. 246 The OSPF TE-ROLE-MESH-GROUP TLV may contain one or more role-based 247 mesh-group entries. Each entry corresponds to a role-based TE mesh- 248 group. The definition of the mesh-group-number, the Tail-end 249 address, the Name length and the Tail-end name in each role-based 250 mesh group entry is the same as that of OSPF TE-MESH-GROUP TLV 251 defined in [RFC4972]. 253 In addition, for each mesh group entry, an four-octet flag field is 254 introduced and four flags are defined in this document. Other bits 255 are reserved for future use and MUST be set to zero when sent, and 256 MUST be ignored when received. 258 The H (Hub) bit, when set, it indicates the LSR is a Hub LSR. 260 The S (Spoke) bit, when set, it indicates the LSR is a Spoke LSR. 262 The H and S bit are dedicated for Hub-Spoke TE mesh-group and can be 263 both set. When both bits set, it indicates that an LSR has both the 264 Hub and Spoke role in the group. When neither H or S bit set, the 265 element SHOULD be silently ignored. 267 3.2. IS-IS TE-ROLE-MESH-GROUP Sub-TLV Format 269 The IS-IS TE-ROLE-MESH-GROUP sub-TLV is used to advertise that an LSR 270 joins/leaves a TE mesh-group and the role of the LSR in the TE mesh- 271 group. The IS-IS TE-ROLE-MESH-GROUP sub-TLV format for IPv4 272 (Figure 4) and IPv6 (Figure 5) is as follows: 274 0 1 2 3 275 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 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Type | Length | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | mesh-group-number 1 | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 |H|S| Reserved | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Tail-end IPv4 address 1 | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Name length | Tail-end name 1 | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 ~ ~ 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | mesh-group-number n | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 |H|S| Reserved | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Tail-end IPv4 address n | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Name length | Tail-end name n | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Figure 4 - IS-IS TE-ROLE-MESH-GROUP sub-TLV format (IPv4) 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Type | Length | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | mesh-group-number 1 | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 |H|S| Reserved | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | | 310 | Tail-end IPv6 address 1 | 311 | | 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Name length | Tail-end name 1 | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 ~ ~ 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | mesh-group-number n | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 |H|S| Reserved | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | | 323 | Tail-end IPv6 address n | 324 | | 325 | | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Name length | Tail-end name n | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 Figure 5 - IS-IS TE-ROLE-MESH-GROUP sub-TLV format (IPv6) 332 The Type of IS-IS TE-ROLE-MESH-GROUP sub-TLV for IPv4 is TBD3, the 333 value of the Length is variable. 335 The Type of IS-IS TE-ROLE-MESH-GROUP sub-TLV for IPv6 is TBD4, the 336 value of the Length is variable. 338 The IS-IS Role-based TE-ROLE-MESH-GROUP sub-TLV may contain one or 339 more role-based mesh-group entries. Each entry corresponds to a 340 role-based TE mesh-group. The definition of the fields, mesh-group- 341 number, Tail-end address, Name length and Tail-end name in each role- 342 based mesh group entry is the same as that of IS-IS TE-MESH-GROUP 343 sub-TLV defined in [RFC4972]. 345 The H and S bits are defined as in Section 3.1 of this document. 347 4. Elements of Procedure 349 4.1. OSPF 351 The TE-ROLE-MESH-GROUP TLV is advertised within an OSPF Router 352 Information opaque LSA (opaque type of 4, opaque ID of 0) for OSPFv2 353 [RFC2328] and within a new LSA (Router Information LSA) for OSPFv3 354 [RFC5340]. The Router Information LSAs for OSPFv2 and OSPFv3 are 355 defined in [RFC4970]. 357 A router MUST originate a new OSPF router information LSA whenever 358 the content of any of the advertised TLV changes or whenever required 359 by the regular OSPF procedure (LSA update (every LSRefreshTime)). If 360 an LSR desires to join or leave a particular role-based TE mesh group 361 or an LSR desires to change its role in a mesh group, it MUST 362 originate a new OSPF Router Information LSA comprising the updated 363 TE-ROLE-MESH-GROUP TLV. In the case of a join, a new entry will be 364 added to the TE-ROLE-MESH-GROUP TLV; if the LSR leaves a mesh-group, 365 the corresponding entry will be removed from the TE-ROLE-MESH-GROUP 366 TLV; if the LSR changes its role in the role-based mesh group, the 367 corresponding entry will be updated in the TE-ROLE-MESH-GROUP TLV. 368 Note that these operations can be performed in the context of a 369 single LSA update. An implementation SHOULD be able to detect any 370 change to a previously received TE-ROLE-MESH-GROUP TLV from a 371 specific LSR. 373 As defined in [RFC5250] for OSPVv2 and in [RFC5340] for OSPFv3, the 374 flooding scope of the Router Information LSA is determined by the LSA 375 Opaque type for OSPFv2 and the values of the S1/S2 bits for OSPFv3. 377 If the flooding scope is area local, then the TE-ROLE-MESH-GROUP TLV 378 MUST be carried within an OSPFv2 type 10 router information LSA or an 379 OSPFV3 Router Information LSA with the S1 bit set and the S2 bit 380 clear. If the flooding scope is the entire IGP domain, then the TE- 381 ROLE-MESH-GROUP TLV MUST be carried within an OSPFv2 type 11 Router 382 Information LSA or OSPFv3 Router Information LSA with the S1 bit 383 clear and the S2 bit set. 385 When the router receives TE-ROLE-MESH-GROUP TLV, it SHOULD setup MPLS 386 TE LSPs according rules which defined in the Section 3. 388 4.2. IS-IS 390 The TE-ROLE-MESH-GROUP sub-TLV is advertised within the IS-IS Router 391 CAPABILITY TLV defined in [RFC4971]. 393 An IS-IS router MUST originate a new IS-IS LSP whenever the content 394 of any of the advertised sub-TLV changes or whenever required by 395 regular IS-IS procedure (LSP updates). If an LSR desires to join or 396 leave a particular role-based TE mesh group or an LSR desires to 397 change its role in a mesh group, it MUST originate a new LSP 398 comprising the refreshed IS-IS Router capability TLV comprising the 399 updated TE-ROLE-MESH-GROUP sub-TLV. In the case of a join, a new 400 entry will be added to the TE-ROLE-MESH-GROUP sub-TLV; if the LSR 401 leaves a mesh-group, the corresponding entry will be deleted from the 402 TE-ROLE-MESH-GROUP sub-TLV; if the LSR changes its role in the role- 403 based mesh group, the corresponding entry will be updated in the TE- 404 ROLE-MESH-GROUP sub-TLV. Note that these operations can be performed 405 in the context of a single update. An implementation SHOULD be able 406 to detect any change to a previously received TE-ROLE-MESH-GROUP sub- 407 TLV from a specific LSR. 409 If the flooding scope of a TE-ROLE-MESH-GROUP sub-TLV is limited to 410 an IS-IS level/area, the sub-TLV MUST NOT be leaked across level/area 411 and the S flag of the Router CAPABILITY TLV MUST be cleared. 412 Conversely, if the flooding scope of a TE-ROLE-MESH-GROUP sub-TLV is 413 the entire routing domain, the TLV MUST be leaked across IS-IS 414 levels/areas, and the S flag of the Router CAPABILITY TLV MUST be 415 set. In both cases, the flooding rules specified in [RFC4971] apply. 417 When the router receives TE-ROLE-MESH-GROUP sub-TLV, it SHOULD setup 418 MPLS TE LSPs according rules which defined in the Section 3. 420 5. Backward Compatibility 422 For a role-based TE mesh-group, if there are some LSRs only 423 supporting mechanisms defined [RFC4972], all the LSRs of the mesh- 424 group MUST process as defined in [RFC4972]. The operators should 425 avoid to add an LSR that does not support role-based auto-mesh TE to 426 a role-based TE mesh-group. 428 6. IANA Considerations 430 6.1. OSPF 432 The registry for the Router Information LSA is defined in [RFC4970]. 433 IANA is requested to assign two new TLV types from the Standards 434 Action allocation range of the registry "OSPF Router Information (RI) 435 TLVs". 437 Value TLV References 438 ----- -------- ---------- 439 TBD1 TE-ROLE-MESH-GROUP TLV (IPv4) this document 440 TBD2 TE-ROLE-MESH-GROUP TLV (IPv6) this document 442 6.2. IS-IS 444 The registry for the Router Capability TLV is defined in [RFC4971]. 445 IANA is requested to assign two new sub-TLV code-point for the TE- 446 ROLE-MESH-GROUP sub-TLVs carried within the IS-IS Router Capability 447 TLV. 449 Value Sub-TLV References 450 ----- -------- ---------- 451 TBD3 TE-ROLE-MESH-GROUP sub-TLV (IPv4) this document 452 TBD4 TE-ROLE-MESH-GROUP sub-TLV (IPv6) this document 454 7. Security Considerations 456 The function described in this document does not create any new 457 security issues for the OSPF and IS-IS protocols, the security 458 considerations described in [RFC4972] apply here. 460 8. Acknowledgements 462 The authors would like to thank Loa Andersson for his valuable 463 comments. 465 The authors would also like to thank the authors of [RFC4972] from 466 where we have taken most of the elements procedures. 468 9. References 470 9.1. Normative References 472 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 473 Requirement Levels", BCP 14, RFC 2119, 474 DOI 10.17487/RFC2119, March 1997, 475 . 477 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, 478 DOI 10.17487/RFC2328, April 1998, 479 . 481 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 482 S. Shaffer, "Extensions to OSPF for Advertising Optional 483 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 484 2007, . 486 [RFC4971] Vasseur, JP., Ed., Shen, N., Ed., and R. Aggarwal, Ed., 487 "Intermediate System to Intermediate System (IS-IS) 488 Extensions for Advertising Router Information", RFC 4971, 489 DOI 10.17487/RFC4971, July 2007, 490 . 492 [RFC4972] Vasseur, JP., Ed., Leroux, JL., Ed., Yasukawa, S., 493 Previdi, S., Psenak, P., and P. Mabbey, "Routing 494 Extensions for Discovery of Multiprotocol (MPLS) Label 495 Switch Router (LSR) Traffic Engineering (TE) Mesh 496 Membership", RFC 4972, DOI 10.17487/RFC4972, July 2007, 497 . 499 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 500 OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, 501 July 2008, . 503 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 504 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 505 . 507 9.2. Informative References 509 [I-D.li-mpls-seamless-mpls-mbb] 510 Li, Z., Li, L., Morillo, M., and T. Yang, "Seamless MPLS 511 for Mobile Backhaul", draft-li-mpls-seamless-mpls-mbb-01 512 (work in progress), February 2014. 514 Authors' Addresses 516 Zhenbin Li 517 Huawei 519 Email: lizhenbin@huawei.com 521 Mach(Guoyi) Chen 522 Huawei 524 Email: mach.chen@huawei.com 526 Greg Mirsky 527 Ericsson 529 Email: gregory.mirsky@ericsson.com