idnits 2.17.1 draft-li-ccamp-role-based-automesh-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 17, 2014) is 3595 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: 3 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: December 19, 2014 G. Mirsky 6 Ericsson 7 June 17, 2014 9 Routing Extensions for Discovery of Role-based MPLS Label Switching 10 Router (MPLS LSR) Traffic Engineering (TE) Mesh Membership 11 draft-li-ccamp-role-based-automesh-02 13 Abstract 15 A Traffic Engineering (TE) mesh-group is defined as a group of Label 16 Switch Routers (LSRs) that are connected by a full mesh of TE LSPs. 17 Routing (OSPF and IS-IS) extensions for discovery Multiprotocol Label 18 Switching (MPLS) LSR TE mesh membership has been defined to automate 19 the creation of mesh of TE LSPs. 21 This document introduces a role-based TE mesh-group that applies to 22 the scenarios where full mesh TE LSPs is not necessary and TE LSPs 23 setup depends on the roles of LSRs in a TE mesh-group. Interior 24 Gateway Protocol (IGP) routing extensions for automatic discovery of 25 role-based TE mesh membership are defined accordingly. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 19, 2014. 50 Copyright Notice 52 Copyright (c) 2014 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Role-based TE Mesh Group . . . . . . . . . . . . . . . . . . 4 70 3. IGP Role-based TE Mesh-group Extensions . . . . . . . . . . . 4 71 3.1. OSPF TE-ROLE-MESH-GROUP TLV Format . . . . . . . . . . . 4 72 3.2. IS-IS TE-ROLE-MESH-GROUP Sub-TLV Format . . . . . . . . . 7 73 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 10 74 4.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 4.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 12 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 78 6.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 6.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 84 9.2. Informative References . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 87 1. Introduction 89 A TE mesh-group [RFC4972] is defined as a group of LSRs that are 90 connected by a full mesh of TE LSPs. [RFC4972] specifies 91 Intermediate System-to-Intermediate System (IS-IS) and Open Shortest 92 Path First (OSPF) extensions to provide an automatic discovery of the 93 set of LSR members of a TE mesh-group in order to automate the 94 creation of such mesh of TE LSPs. This is called "auto-mesh TE" or 95 "auto-mesh". The auto-mesh TE significantly simplifies the 96 configuration and deployment of TE LSPs. 98 In some scenarios, it may not be necessary to establish full mesh TE 99 LSPs among all the LSRs of a TE mesh-group. An example of the use 100 case of non-full mesh of TE LSPs in the mobile backhaul (MBH) 101 networks is presented in ([I-D.li-mpls-seamless-mpls-mbb]). In MBH 102 network TE LSPs are usually setup between the Cell Site 103 Gateways(CSGs) and the Radio Network Controller (RNC) Site 104 Gateways(RSGs). TE LSPs interconnecting CSGs and TE LSPs 105 interconnecting RSGs are not necessary. In most deployments the 106 number of CSGs is very large and there are much more CSGs than RSGs 107 in an MBH domain. With the auto-mesh mechanism defined[RFC4972] full 108 mesh of TE LSPs will be established interconnecting CSGs and RSGs. 109 As result large number of unnecessary TE LSPs will be established 110 interconnecting CSGs and interconnecting RSGs. This likely will not 111 scale well with addition of more CSG devices, would stress control 112 plane with unwarranted RSVP state. 114 Thus there are requirements to optimize the auto-mesh TE and to 115 reduce the number of unnecessary TE LSPs. This document introduces a 116 "role-based auto-mesh TE" or "role-based auto-mesh" where the setup 117 of the TE LSPs is based on the role of the LSRs within a particular 118 TE mesh-group. Therefore, besides the discovery of the membership of 119 a TE mesh-group, it needs to discover the role of each node in the TE 120 mesh-group. 122 Another scenario to which the role-based auto-mesh TE can apply is 123 the Resource Reservation Protocol-Traffic Engineering (RSVP-TE) 124 Point-to-Multipoint (P2MP) TE LSP[RFC4875] scenario. For a RSVP-TE 125 P2MP TE LSP, the root LSR has to know all the leaf LSRs before 126 signalling the P2MP TE LSP. The automatic discovery mechanisms 127 defined in this document can be used to discover the leaf LSRs for 128 P2MP TE LSPs. 130 This document defines IGP routing extensions to automatically 131 discover of the members and their roles of a TE mesh-group. 133 1.1. Terminology 135 RSVP-TE - Resource Reservation Protocol-Traffic Engineering 137 P2MP - Point-to-Multipoint 139 IS-IS - Intermediate System-to-Intermediate System 141 OSPF - Open Shortest Path First 143 CSG - Cell Site Gateway 145 RNC - Radio Network Controller 146 MBH - Mobile Backhaul 148 MPLS - Multiprotocol Label Switching 150 LSP - Label Switched Path 152 TE LSP - Traffic Engineered LSP 154 2. Role-based TE Mesh Group 156 A role-based TE mesh-group is a special TE mesh-group where TE LSPs 157 will not be established among all member LSRs. In a role-based TE 158 mesh-group LSRs will have different roles. TE LSPs setup depends on 159 the roles of the LSRs in a TE mesh-group. This document introduces 160 two types of role-based TE mesh group: Hub-Spoke and Root-Leaf. 162 For a Hub-Spoke TE mesh-group, an LSR can be a Hub, Spoke or both Hub 163 and Spoke LSR in a group. The rules for Hub-Spoke TE mesh-group are 164 as follows: 166 TE LSPs SHOULD only be setup between Spoke and Hub LSRs. 168 TE LSPs MUST NOT be setup between/among Spoke LSRs. 170 TE LSPs MUST NOT be setup between/among Hub LSRs. 172 For a Root-Leaf TE mesh-group, an LSR can be a Root, a Leaf or both a 173 Root and Leaf LSR. Once the membership and roles are determined, the 174 root LSRs can signal the P2MP TE LSPs toward all the Leaf LSRs. 175 There may be multiple P2MP TE LSPs within a TE mesh-group. 177 3. IGP Role-based TE Mesh-group Extensions 179 3.1. OSPF TE-ROLE-MESH-GROUP TLV Format 181 The OSPF TE-ROLE-MESH-GROUP TLV is used to advertise that an LSR 182 joins/leaves a role-based TE mesh-group and the role of the LSR in 183 the TE mesh-group. The OSPF TE-ROLE-MESH-GROUP TLV format for IPv4 184 (Figure 2) and IPv6 (Figure 3) is as follows: 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type | Length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | mesh-group-number 1 | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 |H|S|R|L| Reserved | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Tail-end IPv4 address 1 | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Name length | Tail-end name 1 | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 ~ ~ 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | mesh-group-number n | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 |H|S|R|L| Reserved | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Tail-end IPv4 address n | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Name length | Tail-end name n | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 Figure 2 - OSPF TE-ROLE-MESH-GROUP TLV format (IPv4 Address) 212 0 1 2 3 213 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 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Type | Length | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | mesh-group-number 1 | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 |H|S|R|L| Reserved | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | | 222 | Tail-end IPv6 address 1 | 223 | | 224 | | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Name length | Tail-end name 1 | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 ~ ~ 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | mesh-group-number n | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 |H|S|R|L| Reserved | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | | 235 | Tail-end IPv6 address n | 236 | | 237 | | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Name length | Tail-end name n | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 3 - OSPF TE-ROLE-MESH-GROUP TLV format (IPv6 Address) 244 The Type of OSPF TE-ROLE-MESH-GROUP TLV for IPv4 is TBD1, the value 245 of the Length is variable. 247 The Type of OSPF TE-ROLE-MESH-GROUP TLV for IPv6 is TBD2, the value 248 of the Length is variable. 250 The OSPF TE-ROLE-MESH-GROUP TLV may contain one or more role-based 251 mesh-group entries. Each entry corresponds to a role-based TE mesh- 252 group. The definition of the mesh-group-number, the Tail-end 253 address, the Name length and the Tail-end name in each role-based 254 mesh group entry is the same as that of OSPF TE-MESH-GROUP TLV 255 defined in [RFC4972]. 257 In addition, for each mesh group entry, an four-octet flag field is 258 introduced and four flags are defined in this document. Other bits 259 are reserved for future use and MUST be set to zero when sent, and 260 MUST be ignored when received. 262 The H (Hub) bit, when set, it indicates the LSR is a Hub LSR. 264 The S (Spoke) bit, when set, it indicates the LSR is a Spoke LSR. 266 The R (Root) bit, when set, it indicates an LSR is a Root LSR. 268 The L (Leaf) bit, when set, it indicates an LSR is a Leaf. 270 The H and S bit are dedicated for Hub-Spoke TE mesh-group and can be 271 both set. When both bits set, it indicates that an LSR has both the 272 Hub and Spoke role in the group. 274 The R and Leaf bit can be both set, when both bits set, in indicates 275 an LSR is a Root and Leaf LSR. The R bit and Leaf bit are only used 276 for Root-Leaf TE mesh-group, for other TE mesh-groups, it MUST be set 277 to zero and MUST be ignored when received. 279 3.2. IS-IS TE-ROLE-MESH-GROUP Sub-TLV Format 281 The IS-IS TE-ROLE-MESH-GROUP sub-TLV is used to advertise that an LSR 282 joins/leaves a TE mesh-group and the role of the LSR in the TE mesh- 283 group. The IS-IS TE-ROLE-MESH-GROUP sub-TLV format for IPv4 284 (Figure 4) and IPv6 (Figure 5) is as follows: 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Type | Length | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | mesh-group-number 1 | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 |H|S|R|L| Reserved | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Tail-end IPv4 address 1 | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | Name length | Tail-end name 1 | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 ~ ~ 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | mesh-group-number n | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 |H|S|R|L| Reserved | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Tail-end IPv4 address n | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Name length | Tail-end name n | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Figure 4 - IS-IS TE-ROLE-MESH-GROUP sub-TLV format (IPv4 Address) 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 | mesh-group-number 1 | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 |H|S|R|L| Reserved | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | | 322 | Tail-end IPv6 address 1 | 323 | | 324 | | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Name length | Tail-end name 1 | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 ~ ~ 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | mesh-group-number n | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 |H|S|R|L| Reserved | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | | 335 | Tail-end IPv6 address n | 336 | | 337 | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Name length | Tail-end name n | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Figure 5 - IS-IS TE-ROLE-MESH-GROUP sub-TLV format (IPv6 Address) 344 The Type of IS-IS TE-ROLE-MESH-GROUP sub-TLV for IPv4 is TBD3, the 345 value of the Length is variable. 347 The Type of IS-IS TE-ROLE-MESH-GROUP sub-TLV for IPv6 is TBD4, the 348 value of the Length is variable. 350 The IS-IS Role-based TE-ROLE-MESH-GROUP sub-TLV may contain one or 351 more role-based mesh-group entries. Each entry corresponds to a 352 role-based TE mesh-group. The definition of the fields, mesh-group- 353 number, Tail-end address, Name length and Tail-end name in each role- 354 based mesh group entry is the same as that of IS-IS TE-MESH-GROUP 355 sub-TLV defined in [RFC4972]. 357 The H, S, R and L bits are defined as in Section 3.1 of this 358 document. 360 4. Elements of Procedure 362 The OSPF TE-ROLE-MESH-GROUP TLV is carried within the OSPF Routing 363 Information LSA, and the IS-IS TE-ROLE-MESH-GROUP sub-TLV is carried 364 within the IS-IS Router capability TLV. As such, elements of 365 procedure are inherited from those defined in [RFC4970] and [RFC4971] 366 for OSPF and IS-IS respectively. Specifically, a router MUST 367 originate a new LSA/LSP whenever the content of this information 368 changes, or whenever required by regular routing procedure (e.g., 369 updates). 371 The TE-ROLE-MESH-GROUP TLV is OPTIONAL and MUST NOT include more than 372 one of each of the IPv4 instances or the IPv6 instance. If either 373 the IPv4 or the IPv6 OSPF TE-ROLE-MESH-GROUP TLV occurs more than 374 once within the OSPF Router Information LSA, only the first instance 375 is processed, subsequent TLV(s) MUST be ignored. Similarly, if 376 either the IPv4 or the IPv6 IS-IS TE-ROLE-MESH-GROUP sub-TLV occurs 377 more than once within the IS-IS Router capability TLV, only the first 378 instance is processed, subsequent TLV(s) MUST be ignored. 380 4.1. OSPF 382 The TE-ROLE-MESH-GROUP TLV is advertised within an OSPF Router 383 Information opaque LSA (opaque type of 4, opaque ID of 0) for OSPFv2 384 [RFC2328] and within a new LSA (Router Information LSA) for OSPFv3 385 [RFC5340]. The Router Information LSAs for OSPFv2 and OSPFv3 are 386 defined in [RFC4970]. 388 A router MUST originate a new OSPF router information LSA whenever 389 the content of any of the advertised TLV changes or whenever required 390 by the regular OSPF procedure (LSA update (every LSRefreshTime)). If 391 an LSR desires to join or leave a particular role-based TE mesh group 392 or an LSR desires to change its role in a mesh group, it MUST 393 originate a new OSPF Router Information LSA comprising the updated 394 TE-ROLE-MESH-GROUP TLV. In the case of a join, a new entry will be 395 added to the TE-ROLE-MESH-GROUP TLV; if the LSR leaves a mesh-group, 396 the corresponding entry will be removed from the TE-ROLE-MESH-GROUP 397 TLV; if the LSR changes its role in the role-based mesh group, the 398 corresponding entry will be updated in the TE-ROLE-MESH-GROUP TLV. 399 Note that these operations can be performed in the context of a 400 single LSA update. An implementation SHOULD be able to detect any 401 change to a previously received TE-ROLE-MESH-GROUP TLV from a 402 specific LSR. 404 As defined in [RFC5250] for OSPVv2 and in [RFC5340] for OSPFv3, the 405 flooding scope of the Router Information LSA is determined by the LSA 406 Opaque type for OSPFv2 and the values of the S1/S2 bits for OSPFv3. 408 For OSPFv2 Router Information opaque LSA: 410 - Link-local scope: type 9; 412 - Area-local scope: type 10; 414 - Routing-domain scope: type 11. In this case, the flooding scope is 415 equivalent to the Type 5 LSA flooding scope. 417 For OSPFv3 Router Information LSA: 419 - Link-local scope: OSPFv3 Router Information LSA with the S1 and S2 420 bits cleared; 422 - Area-local scope: OSPFv3 Router Information LSA with the S1 bit set 423 and the S2 bit cleared; 425 - Routing-domain scope: OSPFv3 Router Information LSA with S1 bit 426 cleared and the S2 bit set. 428 A router may generate multiple OSPF Router Information LSAs with 429 different flooding scopes. 431 The Role-based TE-MESH-GROUP TLV may be advertised within an Area- 432 local or Routing-domain scope Router Information LSA, depending on 433 the MPLS TE mesh group profile: 435 - If the MPLS TE mesh-group is contained within a single area (all 436 the LSRs of the mesh-group are contained within a single area), the 437 TE-ROLE-MESH-GROUP TLV MUST be generated within an Area-local Router 438 Information LSA. 440 - If the MPLS TE mesh-group spans multiple OSPF areas, the TE Role- 441 based mesh- group TLV MUST be generated within a Routing-domain scope 442 router information LSA. 444 When the router receives TE-ROLE-MESH-GROUP TLV, it SHOULD setup MPLS 445 TE LSPs according rules which defined in the Section 3. 447 4.2. IS-IS 449 The TE-ROLE-MESH-GROUP sub-TLV is advertised within the IS-IS Router 450 CAPABILITY TLV defined in [RFC4971]. 452 An IS-IS router MUST originate a new IS-IS LSP whenever the content 453 of any of the advertised sub-TLV changes or whenever required by 454 regular IS-IS procedure (LSP updates). If an LSR desires to join or 455 leave a particular role-based TE mesh group or an LSR desires to 456 change its role in a mesh group, it MUST originate a new LSP 457 comprising the refreshed IS-IS Router capability TLV comprising the 458 updated TE-ROLE-MESH-GROUP sub-TLV. In the case of a join, a new 459 entry will be added to the TE-ROLE-MESH-GROUP sub-TLV; if the LSR 460 leaves a mesh-group, the corresponding entry will be deleted from the 461 TE-ROLE-MESH-GROUP sub-TLV; if the LSR changes its role in the role- 462 based mesh group, the corresponding entry will be updated in the TE- 463 ROLE-MESH-GROUP sub-TLV. Note that these operations can be performed 464 in the context of a single update. An implementation SHOULD be able 465 to detect any change to a previously received TE-ROLE-MESH-GROUP sub- 466 TLV from a specific LSR. 468 If the flooding scope of a TE-ROLE-MESH-GROUP sub-TLV is limited to 469 an IS-IS level/area, the sub-TLV MUST NOT be leaked across level/area 470 and the S flag of the Router CAPABILITY TLV MUST be cleared. 471 Conversely, if the flooding scope of a TE-ROLE-MESH-GROUP sub-TLV is 472 the entire routing domain, the TLV MUST be leaked across IS-IS 473 levels/areas, and the S flag of the Router CAPABILITY TLV MUST be 474 set. In both cases, the flooding rules specified in [RFC4971] apply. 476 As specified in [RFC4971], a router may generate multiple IS-IS 477 Router CAPABILITY TLVs within an IS-IS LSP with different flooding 478 scopes. 480 When the router receives TE-ROLE-MESH-GROUP sub-TLV, it SHOULD setup 481 MPLS TE LSPs according rules which defined in the Section 3. 483 5. Backward Compatibility 485 For a role-based TE mesh-group, if there are some LSRs only 486 supporting mechanisms defined [RFC4972], all the LSRs of the mesh- 487 group MUST process as defined in [RFC4972]. The operators should 488 avoid to add an LSR that does not support role-based auto-mesh TE to 489 a role-based TE mesh-group. 491 6. IANA Considerations 493 6.1. OSPF 495 The registry for the Router Information LSA is defined in [RFC4970]. 496 IANA assigned a new OSPF TLV code-point for the TE-ROLE-MESH-GROUP 497 TLVs carried within the Router Information LSA. 499 Value TLV References 500 ----- -------- ---------- 501 TBD1 TE-ROLE-MESH-GROUP TLV (IPv4) this document 502 TBD2 TE-ROLE-MESH-GROUP TLV (IPv6) this document 504 6.2. IS-IS 506 The registry for the Router Capability TLV is defined in [RFC4971]. 507 IANA assigned a new IS-IS sub-TLV code-point for the TE-ROLE-MESH- 508 GROUP sub-TLVs carried within the IS-IS Router Capability TLV. 510 Value Sub-TLV References 511 ----- -------- ---------- 512 TBD3 TE-ROLE-MESH-GROUP sub-TLV (IPv4) this document 513 TBD4 TE-ROLE-MESH-GROUP sub-TLV (IPv6) this document 515 7. Security Considerations 517 The function described in this document does not create any new 518 security issues for the OSPF and IS-IS protocols, the security 519 considerations described in [RFC4972] apply here. 521 8. Acknowledgements 523 The authors would like to thank Loa Andersson for his valuable 524 comments. 526 The authors would also like to thank the authors of [RFC4972] from 527 where we have taken most of the elements procedures. 529 9. References 531 9.1. Normative References 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14, RFC 2119, March 1997. 536 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 538 [RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S. 539 Shaffer, "Extensions to OSPF for Advertising Optional 540 Router Capabilities", RFC 4970, July 2007. 542 [RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate 543 System to Intermediate System (IS-IS) Extensions for 544 Advertising Router Information", RFC 4971, July 2007. 546 [RFC4972] Vasseur, JP., Leroux, JL., Yasukawa, S., Previdi, S., 547 Psenak, P., and P. Mabbey, "Routing Extensions for 548 Discovery of Multiprotocol (MPLS) Label Switch Router 549 (LSR) Traffic Engineering (TE) Mesh Membership", RFC 4972, 550 July 2007. 552 [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The 553 OSPF Opaque LSA Option", RFC 5250, July 2008. 555 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 556 for IPv6", RFC 5340, July 2008. 558 9.2. Informative References 560 [I-D.li-mpls-seamless-mpls-mbb] 561 Li, Z., Li, L., Morillo, M., and T. Yang, "Seamless MPLS 562 for Mobile Backhaul", draft-li-mpls-seamless-mpls-mbb-01 563 (work in progress), February 2014. 565 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 566 "Extensions to Resource Reservation Protocol - Traffic 567 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 568 Switched Paths (LSPs)", RFC 4875, May 2007. 570 Authors' Addresses 572 Zhenbin Li 573 Huawei 575 Email: lizhenbin@huawei.com 577 Mach(Guoyi) Chen 578 Huawei 580 Email: mach.chen@huawei.com 582 Greg Mirsky 583 Ericsson 585 Email: gregory.mirsky@ericsson.com