idnits 2.17.1 draft-ietf-ccamp-automesh-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 653. 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 4 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the flooding scope of an MPLS Traffic Engineering capability is limited to an IS-IS level/area, the sub-TLV MUST not be leaked across level/area and the S flag of the Router CAPABILITY TLV MUST be cleared. Conversely, if the flooding scope of an MPLS Traffic Engineering capability is the entire routing domain, the TLV MUST be leaked across IS-IS levels/areas, and the S flag of the Router CAPABILITY TLV MUST be set. In both cases the flooding rules specified in [I-D.ietf-isis-caps] apply. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 8, 2006) is 6347 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) == Unused Reference: 'RFC1194' is defined on line 543, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-isis-caps-06 == Outdated reference: A later version (-11) exists of draft-ietf-ospf-cap-09 ** Obsolete normative reference: RFC 1194 (Obsoleted by RFC 1196, RFC 1288) ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) ** Obsolete normative reference: RFC 2740 (Obsoleted by RFC 5340) ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group JP. Vasseur, Ed. 2 Internet-Draft Cisco Systems, Inc 3 Intended status: Standards Track JL. Leroux, Ed. 4 Expires: June 11, 2007 France Telecom 5 S. Yasukawa 6 NTT 7 S. Previdi 8 P. Psenak 9 Cisco Systems, Inc 10 P. Mabbey 11 Comcast 12 December 8, 2006 14 Routing extensions for discovery of Multiprotocol (MPLS) Label Switch 15 Router (LSR) Traffic Engineering (TE) mesh membership 16 draft-ietf-ccamp-automesh-03.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on June 11, 2007. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2006). 47 Abstract 49 The set up of a full mesh of Multi-Protocol Label Switching (MPLS) 50 Traffic Engineering (TE) Label Switched Paths (LSP) among a set of 51 Label Switch Routers (LSR) is a common deployment scenario of MPLS 52 Traffic Engineering either for bandwidth optimization, bandwidth 53 guarantees or fast rerouting with MPLS Fast Reroute. Such deployment 54 may require the configuration of potentially a large number of TE 55 LSPs (on the order of the square of the number LSRs). This document 56 specifies Interior Gateway Protocol (IGP) routing extensions for 57 Intermediate System-to-Intermediate System (IS-IS) and Open Shortest 58 Path First (OSPF) so as to provide an automatic discovery of the set 59 of LSRs members of a mesh in order to automate the creation of such 60 mesh of TE LSPs. 62 Requirements Language 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in RFC 2119 [RFC2119]. 68 Table of Contents 70 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Description of a TE Mesh-Group . . . . . . . . . . . . . . . . 5 73 4. TE-MESH-GROUP TLV formats . . . . . . . . . . . . . . . . . . 6 74 4.1. OSPF TE-MESH-GROUP TLV format . . . . . . . . . . . . . . 6 75 4.2. IS-IS TE-MESH-GROUP sub-TLV format . . . . . . . . . . . . 8 76 5. Elements of procedure . . . . . . . . . . . . . . . . . . . . 9 77 5.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 5.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 6. Backward compatibility . . . . . . . . . . . . . . . . . . . . 12 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 7.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 7.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 85 10. Normative References . . . . . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 87 Intellectual Property and Copyright Statements . . . . . . . . . . 16 89 1. Terminology 91 Terminology used in this document 93 IGP: Interior Gateway Protocol. 95 IGP Area: OSPF area or IS-IS level. 97 IS-IS: Intermediate System-to-Intermediate System (IS-IS). 99 LSR: Label Switch Router. 101 OSPF: Open Shortest Path First (OSPF). 103 OSPF LSA: OSPF Link State Advertisement. 105 TE LSP: Traffic Engineering Label Switched Path. 107 TE LSP head-end: head/source of the TE LSP. 109 TE LSP tail-end: tail/destination of the TE LSP. 111 TLV: Type Lenght Value 113 2. Introduction 115 There are two well-known approaches in deploying MPLS Traffic 116 Engineering: 118 (1) The so-called "strategic" approach that consists of setting up a 119 full mesh of TE LSPs between a set of LSRs, 121 (2) The so-called "tactical" approach where a set of TE LSPs are 122 provisioned on well identified "hot spots" in order to alleviate a 123 congestion resulting for instance from an unexpected traffic growth 124 in some parts of the network. 126 The set up of a full mesh of TE LSPs among a set of LSRs is a common 127 deployment scenario of MPLS Traffic Engineering either for bandwidth 128 optimization, bandwidth guarantees or fast rerouting with MPLS Fast 129 Reroute. Setting up a full mesh of TE LSPs between N LSRs requires 130 the configuration of a potentially large number of TE LSPs (O(N^2)). 131 Furthermore, the addition of any new LSR in the mesh requires the 132 configuration of N additional TE LSPs on the new LSR and one new TE 133 LSP on every LSR of the existing mesh destined to this new LSR, which 134 gives a total of 2*N TE LSPs to be configured. Such operation is not 135 only time consuming but also a risky operation (prone to 136 misconfiguration) for Service Providers. Hence, an automatic 137 mechanism for setting up TE LSPs meshes is desirable and requires the 138 ability to automatically discover the set of LSRs that belong to the 139 mesh. This document specifies routing extensions so as to 140 automatically discover the members of a mesh, also referred to as a 141 "TE mesh-group". Note that the mechanism(s) needed for the dynamic 142 creation of TE LSPs is implementation specific and outside the scope 143 of this document. 145 Routing extensions have been defined in [I-D.ietf-ospf-cap] and 146 [I-D.ietf-isis-caps] in order to advertise router capabilities. This 147 document specifies IGP (OSPF and IS-IS) TE Mesh Group (Type Lenght 148 Value) TLVs allowing for the automatic discovery of a TE mesh-group 149 members, to be carried in the OSPF Router Information (Link State 150 Advertisement) LSA [I-D.ietf-ospf-cap] and IS-IS Router Capability 151 TLV [I-D.ietf-isis-caps]. The routing extensions specified in this 152 document provide the ability to signal multiple TE mesh groups. An 153 LSR may belong to more than one TE mesh-group(s). 155 There are relatively tight real-time constraints on the operation of 156 IGPs (such as OSPF and IS-IS). For this reason some care needs to be 157 applied when proposing to carry additional information in an IGP. 158 The information described in this document is both relatively small 159 in total volume (compared with other information already carried in 160 IGPs), and also relatively stable (ie, changes are based on 161 configuration changes, but not based on dynamic events within the 162 network, and not based on dynamic triggers such as the leaking of 163 information from other routing protocols or routing protocol 164 instances). 166 3. Description of a TE Mesh-Group 168 A TE mesh-group is defined as a group of LSRs that are connected by a 169 full mesh of TE LSPs. Routing extensions are specified in this 170 document allowing for dynamic discovery of the TE mesh-group members. 171 Procedures are also specified for a member to join and leave a TE 172 mesh-group. For each TE mesh-group membership announced by an LSR, 173 the following information is avdertized: 175 - A mesh-group number identifying the TE mesh-group the LSR belongs 176 to, 178 - A Tail-end address (used as the TE LSP Tail-end address by other 179 LSRs belonging to the same mesh-group), 181 - A Tail-end name: a display string that is allocated to the Tail-end 182 used to ease the TE-LSP naming. 184 4. TE-MESH-GROUP TLV formats 186 4.1. OSPF TE-MESH-GROUP TLV format 188 The TE-MESH-GROUP TLV is used to advertise the desire of an LSR to 189 join/leave a given TE mesh-group. No sub-TLV is currently defined 190 for the TE-MESH-GROUP TLV. 192 The OSPF TE-MESH-GROUP TLV (advertised in an OSPF router information 193 LSA defined in [I-D.ietf-ospf-cap]) has the following format: 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Type | length | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | | 200 // Value // 201 | | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Figure 1 - OSPF TE-MESH-GROUP TLV format 205 Where 206 Type: identifies the TLV type 207 Length: length of the value field in octets 209 The format of the OSPF TE-MESH-GROUP TLV is the same as the TLV 210 format used by the Traffic Engineering Extensions to OSPF 211 (see[RFC3630]). The TLV is padded to four-octet alignment; padding 212 is not included in the length field (so a three octet value would 213 have a length of three, but the total size of the TLV would be eight 214 octets). Nested TLVs are also 32-bit aligned. Unrecognized types 215 are ignored. All types between 32768 and 65535 are reserved for 216 vendor-specific extensions. All other undefined type codes are 217 reserved for future assignment by IANA. 219 The OSPF TE-MESH-GROUP TLV format for IPv4 (figure 2) and IPv6 220 (figure 3) is as follows: 221 TYPE: To be assigned by IANA (Suggested Value: 3) 222 LENGTH: Variable 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | mesh-group-number 1 | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Tail-end IPv4 address 1 | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Name length | Tail-end name 1 | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 // // 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | mesh-group-number n | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Tail-end IPv4 address n | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Name length | Tail-end name n | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 2 - OSPF TE-MESH-GROUP TLV format (IPv4 Address) 244 TYPE: To be assigned by IANA (Suggested Value: 4) 245 LENGTH: Variable 247 0 1 2 3 248 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | mesh-group-number 1 | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | | 253 | Tail-end IPv6 address 1 | 254 | | 255 | | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Name length | Tail-end name 1 | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 // // 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | mesh-group-number n | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | | 264 | Tail-end IPv6 address n | 265 | | 266 | | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Name length | Tail-end name n | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Figure 3 - OSPF TE-MESH-GROUP TLV format (IPv6 Address) 273 The OSPF TE-MESH-GROUP TLV may contain one or more mesh-group entries 274 where each entry correspond to a TE mesh-group and is made of the 275 following fields: 277 - A mesh-group-number that identifies the mesh-group number, 278 - A Tail-end address: an IPv4 or IPv6 IP address to be used as a 279 tail-end TE LSP address by other LSRs belonging to the same mesh- 280 group, 282 - A Tail-end name: A display string that is allocated to the Tail- 283 end. The field is of variable length field and is used to facilitate 284 the TE LSP identification. - Name length field: An integer, expressed 285 in octets, that indicates the length of the Tail-end name before 286 padding. 288 4.2. IS-IS TE-MESH-GROUP sub-TLV format 290 The TE-MESH-GROUP sub-TLV is used to advertise the desire of an LSR 291 to join/leave a given TE mesh-group. No sub-TLV is currently defined 292 for the TE-MESH-GROUP sub-TLV. 294 The IS-IS TE-MESH-GROUP sub-TLV (advertised in the IS-IS CAPABILITY 295 TLV defined in [I-D.ietf-isis-caps] ) is composed of 1 octet for the 296 type, 1 octet specifying the TLV length and a value field. The 297 format of the TE-MESH-GROUP sub-TLV is identical to the TLV format 298 used by the Traffic Engineering Extensions for IS-IS [RFC3784]. 300 The IS-IS TE-MESH-GROUP sub-TLV format for IPv4 (figure 4) and IPv6 301 (figure 5) is as follows: 302 TYPE: To be assigned by IANA (Suggested value: 3). 303 LENGTH: Variable 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | mesh-group-number 1 | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Tail-end IPv4 address 1 | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Name length | Tail-end name 1 | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 // // 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | mesh-group-number n | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Tail-end IPv4 address n | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Name length | Tail-end name n | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Figure 4 - IS-IS TE-MESH-GROUP sub-TLV format (IPv4 Address) 324 TYPE: To be assigned by IANA (Suggested Value: 4) 325 LENGTH: Variable 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | mesh-group-number 1 | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | | 332 | Tail-end IPv6 address 1 | 333 | | 334 | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Name length | Tail-end name 1 | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 // // 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | mesh-group-number n | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | | 343 | Tail-end IPv6 address n | 344 | | 345 | | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Name length | Tail-end name n | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Figure 5 - IS-IS TE-MESH-GROUP sub-TLV format (IPv6 Address) 352 The IS-IS TE-MESH-GROUP sub-TLV may contain one or more mesh-group 353 entries where each entry correspond to a TE mesh-group and is made of 354 the following fields: 356 - A mesh-group-number that identifies the mesh-group number, 358 - A Tail-end address: an IPv4 or IPv6 IP address to be used as a 359 tail-end TE LSP address by other LSRs belonging to the same mesh- 360 group, 362 - A Tail-end name: A display string that is allocated to the Tail- 363 end. The field is of variable length field and is used to facilitate 364 the TE LSP identification. - Name length field: An integer, expressed 365 in octets, that indicates the length of the Tail-end name before 366 padding. 368 5. Elements of procedure 370 The OSPF TE-MESH-GROUP TLV is carried within the OSPF Routing 371 Information LSA and the TE-MESH-GROUP sub-TLV is caried within the 372 IS-IS Router capability TLV. As such, elements of procedure are 373 inherited from those defined in [I-D.ietf-ospf-cap] and 374 [I-D.ietf-isis-caps] for OSPF and IS-IS respectively. Specifically, 375 a router MUST originate a new LSA/LSP whenever the content of this 376 information changes, or whenever required by regular routing 377 procedure (e.g. update). 379 The TE-MESH-GROUP TLV is OPTIONAL and MUST NOT include more than one 380 of each of the IPv4 instance or the IPv6 instance. If either the 381 IPv4 or the IPv6 OSPF TE-MESH-GROUP TLV occurs more than once within 382 the OSPF Router Information LSA, only the first instance is 383 processed, subsequent TLV(s) SHOULD be silently ignored. Similarly, 384 if either the IPv4 or the IPv6 IS-IS TE-MESH-GROUP sub-TLV occurs 385 more than once within the ISIS Router capability TLV, only the first 386 instance is processed, subsequent TLV(s) SHOULD be silently ignored. 388 5.1. OSPF 390 The TE-MESH-GROUP TLV is advertised within an OSPF Router Information 391 opaque LSA (opaque type of 4, opaque ID of 0) for OSPFv2 ([RFC2328]) 392 and within a new LSA (Router Information LSA) for OSPFv3 ([RFC2740]). 393 The Router Information LSAs for OSPFv2 and OSPFv3 are defined in 394 ([I-D.ietf-ospf-cap]). 396 A router MUST originate a new OSPF router information LSA whenever 397 the content of the any of the advertised TLV changes or whenever 398 required by the regular OSPF procedure (LSA update (every 399 LSRefreshTime)). If an LSR desires to join or leave a particular TE 400 mesh group, it MUST originate a new OSPF Router Information LSA 401 comprising the updated TE-MESH-GROUP TLV. In the case of a join, a 402 new entry will be added to the TE-MESH-GROUP TLV; conversely, if the 403 LSR leaves a mesh-group the corresponding entry will be removed from 404 the TE-MESH-GROUP TLV. Note that both operations can be performed in 405 the context of a single LSA update. An implementation SHOULD be able 406 to detect any change to a previously received TE-MESH-GROUP TLV from 407 a specific LSR. 409 As defined in [RFC2370] for OSPVv2 and in [RFC2740] for OSPFv3, the 410 flooding scope of the Router Information LSA is determined by the LSA 411 Opaque type for OSPFv2 and the values of the S1/S2 bits for OSPFv3. 413 For OSPFv2 Router Information opaque LSA: 415 - Link-local scope: type 9; 417 - Area-local scope: type 10; 418 - Routing-domain scope: type 11. In this case, the flooding scope is 419 equivalent to the Type 5 LSA flooding scope. 421 For OSPFv3 Router Information LSA: 423 - Link-local scope: OSPFV3 Router Information LSA with the S1 and S2 424 bits cleared; 426 - Area-local scope: OSPFV3 Router Information LSA with the S1 bit set 427 and the S2 bit cleared; 429 - Routing-domain scope: OSPFv3 Router Information LSA with S1 bit 430 cleared and the S2 bit set. 432 A router may generate multiple OSPF Router Information LSAs with 433 different flooding scopes. 435 The TE-MESH-GROUP TLV may be advertised within an Area-local or 436 Routing-domain scope Router Information LSA depending on the MPLS TE 437 mesh group profile: 439 - If the MPLS TE mesh-group is contained within a single area (all 440 the LSRs of the mesh-group are contained within a single area), the 441 TE-MESH-GROUP TLV MUST be generated within an Area-local Router 442 Information LSA. 444 - If the MPLS TE mesh-group spans multiple OSPF areas, the TE mesh- 445 group TLV MUST be generated within a Routing-domain scope router 446 information LSA. 448 5.2. IS-IS 450 The TE-MESH-GROUP sub-TLV is advertised within the IS-IS Router 451 CAPABILITY TLV defined in [I-D.ietf-isis-caps]. An IS-IS router MUST 452 originate a new IS-IS LSP whenever the content of the any of the 453 advertised sub-TLV changes or whenever required by regular IS-IS 454 procedure (LSP update). If an LSR desires to join or leave a 455 particular TE mesh group, it MUST originate a new LSP comprising the 456 refreshed IS-IS Router capability TLV comprising the updated TE-MESH- 457 GROUP sub-TLV. In the case of a join, a new entry will be added to 458 the TE-MESH-GROUP sub-TLV; conversely, if the LSR leaves a mesh-group 459 the corresponding entry will be deleted from the TE-MESH-GROUP sub- 460 TLV. Note that both operations can be performed in the context of a 461 single update. An implementation SHOULD be able to detect any change 462 to a previously received TE-MESH-GROUP sub-TLV from a specific LSR. 464 If the flooding scope of an MPLS Traffic Engineering capability is 465 limited to an IS-IS level/area, the sub-TLV MUST not be leaked across 466 level/area and the S flag of the Router CAPABILITY TLV MUST be 467 cleared. Conversely, if the flooding scope of an MPLS Traffic 468 Engineering capability is the entire routing domain, the TLV MUST be 469 leaked across IS-IS levels/areas, and the S flag of the Router 470 CAPABILITY TLV MUST be set. In both cases the flooding rules 471 specified in [I-D.ietf-isis-caps] apply. 473 As specified in [I-D.ietf-isis-caps], a router may generate multiple 474 IS-IS Router CAPABILITY TLVs within an IS-IS LSP with different 475 flooding scopes. 477 6. Backward compatibility 479 The TE-MESH-GROUP TLVs defined in this document do not introduce any 480 interoperability issue. For OSPF, a router not supporting the TE- 481 MESH-GROUP TLV SHOULD just silently ignore the TLV as specified in 482 [RFC2370]. For IS-IS a router not supporting the TE-MESH-GROUP sub- 483 TLV SHOULD just silently ignore the sub-TLV. 485 7. IANA Considerations 487 7.1. OSPF 489 Once a registry for the Router Information LSA defined in 490 [I-D.ietf-ospf-cap] will have been assigned, IANA will assign a new 491 OSPF TLV code-point for the TE-MESH-GROUP TLVs carried within the 492 Router Information LSA. 494 Value Sub-TLV References 495 ----- -------- ---------- 496 3 TE-MESH-GROUP TLV (IPv4) draft-ietf-ospf-cap (to be replaced by RFC number) 497 4 TE-MESH-GROUP TLV (IPv6) draft-ietf-ospf-cap (to be replaced by RFC number) 499 7.2. IS-IS 501 Once a registry for the Router Capability TLV defined in 502 [I-D.ietf-isis-caps] will have been assigned, IANA will assign a new 503 IS-IS sub-TLV code-point for the TE-MESH-GROUP sub-TLVs carried 504 within the IS-IS Router Capability TLV. 506 Value Sub-TLV References 507 ----- -------- ---------- 508 3 TE-MESH-GROUP TLV (IPv4) draft-ietf-isis-caps (to be replaced by RFC number) 509 4 TE-MESH-GROUP TLV (IPv6) draft-ietf-isis-caps (to be replaced by RFC number) 511 8. Security Considerations 513 The function described in this document does not create any new 514 security issues for the OSPF and the IS-IS protocols. Security 515 considerations are covered in [RFC2328] and [RFC2740] for the base 516 OSPF protocol and in [RFC1195] for IS-IS. It must be noted that the 517 advertisement of "fake" TE Mesh Group membership(s) by a mis- 518 configured or malicious LSR Y would not have any major impact on the 519 network (other than overloading the IGP) such as triggering the set 520 up of new MPLS TE LSP: indeed for a new TE LSP originated by another 521 LSR X destined to LSR Y to be set up, the same TE Mesh group 522 membership must be configured on both LSRs. Thus such fake 523 advertisement could not amplify any DoS attack. 525 9. Acknowledgements 527 We would like to thank Dean Cheng, Adrian Farrel, Yannick Le Louedec, 528 Dave Ward, Les Ginsberg, Stephen Nadas, Acee Lindem, Dimitri 529 Papadimitriou and Lakshminath Dondeti for their useful comments. 531 10. Normative References 533 [I-D.ietf-isis-caps] 534 Vasseur, J., "IS-IS Extensions for Advertising Router 535 Information", draft-ietf-isis-caps-06 (work in progress), 536 January 2006. 538 [I-D.ietf-ospf-cap] 539 Lindem, A., "Extensions to OSPF for Advertising Optional 540 Router Capabilities", draft-ietf-ospf-cap-09 (work in 541 progress), October 2006. 543 [RFC1194] Zimmerman, D., "Finger User Information Protocol", 544 RFC 1194, November 1990. 546 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 547 dual environments", RFC 1195, December 1990. 549 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 550 Requirement Levels", BCP 14, RFC 2119, March 1997. 552 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 554 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 555 July 1998. 557 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 558 RFC 2740, December 1999. 560 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 561 (TE) Extensions to OSPF Version 2", RFC 3630, 562 September 2003. 564 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 565 System (IS-IS) Extensions for Traffic Engineering (TE)", 566 RFC 3784, June 2004. 568 Authors' Addresses 570 JP Vasseur (editor) 571 Cisco Systems, Inc 572 1414 Massachusetts Avenue 573 Boxborough, MA 01719 574 USA 576 Email: jpv@cisco.com 578 JL Le Roux (editor) 579 France Telecom 580 2, Avenue Pierre-Marzin 581 Lanion, 22307 582 FRANCE 584 Email: jeanlouis.leroux@francetelecom.com 586 Seisho Yasukawa 587 NTT 588 9-11, Midori-Cho 3-Chome 589 Tokyo, 180-8585 590 JAPAN 592 Email: yasukawa.seisho@lab.ntt.co.jp 593 Stefano Previdi 594 Cisco Systems, Inc 595 Via Del Serafico 200 596 Roma, 00142 597 Italy 599 Email: sprevidi@cisco.com 601 Peter Psenak 602 Cisco Systems, Inc 603 Pegasus Park DE Kleetlaan 6A 604 Diegmen, 1831 605 BELGIUM 607 Email: ppsenak@cisco.com 609 Paul Mabbey 610 Comcast 611 USA 613 Email: 615 Full Copyright Statement 617 Copyright (C) The IETF Trust (2006). 619 This document is subject to the rights, licenses and restrictions 620 contained in BCP 78, and except as set forth therein, the authors 621 retain all their rights. 623 This document and the information contained herein are provided on an 624 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 625 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 626 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 627 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 628 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 629 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 631 Intellectual Property 633 The IETF takes no position regarding the validity or scope of any 634 Intellectual Property Rights or other rights that might be claimed to 635 pertain to the implementation or use of the technology described in 636 this document or the extent to which any license under such rights 637 might or might not be available; nor does it represent that it has 638 made any independent effort to identify any such rights. Information 639 on the procedures with respect to rights in RFC documents can be 640 found in BCP 78 and BCP 79. 642 Copies of IPR disclosures made to the IETF Secretariat and any 643 assurances of licenses to be made available, or the result of an 644 attempt made to obtain a general license or permission for the use of 645 such proprietary rights by implementers or users of this 646 specification can be obtained from the IETF on-line IPR repository at 647 http://www.ietf.org/ipr. 649 The IETF invites any interested party to bring to its attention any 650 copyrights, patents or patent applications, or other proprietary 651 rights that may cover technology that may be required to implement 652 this standard. Please address the information to the IETF at 653 ietf-ipr@ietf.org. 655 Acknowledgment 657 Funding for the RFC Editor function is provided by the IETF 658 Administrative Support Activity (IASA).