idnits 2.17.1 draft-ietf-ccamp-automesh-02.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 on line 535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 546. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 553. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 559. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (August 31, 2006) is 6447 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: 'RFC3209' is defined on line 462, 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-08 ** Obsolete normative reference: RFC 2370 (Obsoleted by RFC 5250) ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) Summary: 5 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: March 4, 2007 France Telecom 5 S. Yasukawa 6 NTT 7 S. Previdi 8 P. Psenak 9 Cisco Systems, Inc 10 P. Mabbey 11 Comcast 12 August 31, 2006 14 Routing extensions for discovery of Multiprotocol (MPLS) Label Switch 15 Router (LSR) Traffic Engineering (TE) mesh membership 16 draft-ietf-ccamp-automesh-02.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 March 4, 2007. 43 Copyright Notice 45 Copyright (C) The Internet Society (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 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 IGP routing extensions for ISIS and OSPF so as to provide 57 an automatic discovery of the set of LSRs members of a mesh in order 58 to automate the creation of such mesh. 60 Requirements Language 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119 [RFC2119]. 66 Table of Contents 68 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. TE Mesh-Group . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.2. Required Information . . . . . . . . . . . . . . . . . . . 5 73 4. TE-MESH-GROUP TLV formats . . . . . . . . . . . . . . . . . . 5 74 4.1. OSPF TE-MESH-GROUP TLV format . . . . . . . . . . . . . . 5 75 4.2. IS-IS TE-MESH-GROUP sub-TLV format . . . . . . . . . . . . 8 76 5. Elements of procedure . . . . . . . . . . . . . . . . . . . . 10 77 5.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 5.2. ISIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 6. Backward compatibility . . . . . . . . . . . . . . . . . . . . 12 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 83 10. Normative References . . . . . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 85 Intellectual Property and Copyright Statements . . . . . . . . . . 15 87 1. Terminology 89 Terminology used in this document 91 LSR: Label Switch Router. 93 TE LSP: Traffic Engineering Label Switched Path. 95 TE LSP head-end: head/source of the TE LSP. 97 TE LSP tail-end: tail/destination of the TE LSP. 99 IGP Area: OSPF area or IS-IS level. 101 2. Introduction 103 There are two well-known approaches in deploying MPLS Traffic 104 Engineering: 106 (1) The so-called "strategic" approach that consists of setting up a 107 full mesh of TE LSPs between a set of LSRs, 109 (2) The so-called "tactical" approach where a set of TE LSPs are 110 provisioned on well identified "hot spots" in order to alleviate a 111 congestion resulting for instance from an unexpected traffic growth 112 in some parts of the network. 114 The set up of a full mesh of TE LSPs among a set of LSRs is a common 115 deployment scenario of MPLS Traffic Engineering either for bandwidth 116 optimization, bandwidth guarantees or fast rerouting with MPLS Fast 117 Reroute. Setting up a full mesh of TE LSPs between N LSRs requires 118 the configuration of a potentially large number of TE LSPs (O(N^2)). 119 Furthermore, the addition of any new LSR in the mesh requires the 120 configuration of N additional TE LSPs on the new LSR and one new TE 121 LSP on every LSR of the existing mesh destined to this new LSR, which 122 gives a total of 2*N TE LSPs to be configured. Such operation is not 123 only time consuming but also a risky operation (prone to 124 misconfiguration) for Service Providers. Hence, an automatic 125 mechanism for setting up TE LSPs meshes is desirable and requires the 126 ability to automatically discover the LSRs that belong to the mesh. 127 This document specifies routing extensions so as to automatically 128 discover the members of a mesh, also referred to as a "TE mesh- 129 group". Note that the mechanism(s) needed for the dynamic creation 130 of TE LSPs is implementation specific and outside the scope of this 131 document. 133 Routing extensions have been defined in [I-D.ietf-ospf-cap] and 135 [I-D.ietf-isis-caps] in order to advertise router capabilities. This 136 document specifies IGP (OSPF and IS-IS) TE Mesh Group TLVs allowing 137 for the automatic discovery of a TE LSP mesh members, to be carried 138 in the OSPF Router Information LSA [I-D.ietf-ospf-cap] and ISIS 139 Router Capability TLV [I-D.ietf-isis-caps]. The routing extensions 140 specified in this document provide the ability to signal multiple TE 141 mesh groups. An LSR may belong to more than one TE mesh-group. 143 3. TE Mesh-Group 145 3.1. Description 147 A TE mesh-group is defined as a group of LSRs that are connected by a 148 full mesh of TE LSPs. Routing extensions are specified in this 149 document allowing for dynamic discovery of the TE mesh-group members. 150 Procedures are also specified for a member to join and leave a TE 151 mesh-group. 153 3.2. Required Information 155 This document specifies a TE-MESH-GROUP TLV that indicates the set of 156 TE mesh-group(s) an LSR belongs to. For each TE mesh-group 157 membership announced by an LSR, the TE-MESH-GROUP TLV advertises the 158 following information: 160 - A mesh-group number identifying the TE mesh-group the LSR belongs 161 to. 163 - A Tail-end address (used as the TE LSP tail-end address by other 164 LSRs belonging to the same mesh-group). 166 - A Tail-end name: string used to ease the TE-LSP naming. 168 4. TE-MESH-GROUP TLV formats 170 4.1. OSPF TE-MESH-GROUP TLV format 171 the OSPF TE-MESH-GROUP TLV (advertised in an OSPF router information 172 LSA defined in [I-D.ietf-ospf-cap]) has the following format: 173 0 1 2 3 174 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 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Type | length | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | | 179 // Value // 180 | | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 Figure 1 - OSPF TE-MESH-GROUP TLV format 184 Where 185 Type: identifies the TLV type 186 Length: length of the value field in octets 188 The format of the OSPF TE-MESH-GROUP TLV is the same as the TLV 189 format used by the Traffic Engineering Extensions to OSPF 190 (see[RFC3630]). The TLV is padded to four-octet alignment; padding 191 is not included in the length field (so a three octet value would 192 have a length of three, but the total size of the TLV would be eight 193 octets). Nested TLVs are also 32-bit aligned. Unrecognized types 194 are ignored. All types between 32768 and 65535 are reserved for 195 vendor-specific extensions. All other undefined type codes are 196 reserved for future assignment by IANA. 198 The TE-MESH-GROUP TLV is used to advertise the desire of an LSR to 199 join/leave a given TE mesh-group. No sub-TLV is currently defined 200 for the TE-mesh-group TLV. 202 The TE-MESH-GROUP TLV has the following format: 203 TYPE: To be assigned by IANA (Suggested Value: 3) 204 LENGTH: Variable 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | mesh-group-number | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Tail-end IPv4 address | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Name length | Tail-end name | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 // // 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 2 - OSPF TE-MESH-GROUP TLV format (IPv4 Address) 219 TYPE: To be assigned by IANA (Suggested Value: 4) 220 LENGTH: Variable 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | mesh-group-number | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | | 227 | Tail-end IPv6 address | 228 | | 229 | | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Name length | Tail-end name | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 // // 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Figure 3 - OSPF TE-MESH-GROUP TLV format (IPv6 Address) 238 For each TE mesh-group announced by the LSR, the TE-MESH-GROUP TLV 239 comprises: 241 - A mesh-group-number that identifies the mesh-group number 243 - A Tail-end address: an IPv4 or IPv6 IP address to be used as a 244 tail-end TE LSP address by other LSRs belonging to the same mesh- 245 group 247 - A Tail-end name: a variable length field used to facilitate the TE 248 LSP identification. The Name length field indicates the length of 249 the display string before padding, in bytes. 251 4.2. IS-IS TE-MESH-GROUP sub-TLV format 253 The IS-IS TE-MESH-GROUP sub-TLV (advertised in the IS-IS CAPABILITY 254 TLV defined in [I-D.ietf-isis-caps] ) is composed of 1 octet for the 255 type, 1 octet specifying the TLV length and a value field. The 256 format of the TE-MESH-GROUP sub-TLV is identical to the TLV format 257 used by the Traffic Engineering Extensions for IS-IS [RFC3784]. The 258 TE-MESH-GROUP sub-TLV is used to advertise the desire of an LSR to 259 join/leave a given TE mesh-group. No sub-TLV is currently defined 260 for the TE-MESH-GROUP sub-TLV. 262 The ISIS TE-MESH-GROUP sub-TLV has the following format: 263 TYPE: To be assigned by IANA (Suggested value: 3). 264 LENGTH: Variable 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | mesh-group-number | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Tail-end IPv4 address | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Name length | Tail-end name | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 // // 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Figure 4 - ISIS TE-MESH-GROUP sub-TLV format (IPv4 Address) 279 TYPE: To be assigned by IANA (Suggested Value: 4) 280 LENGTH: Variable 282 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 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | mesh-group-number | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | | 287 | Tail-end IPv6 address | 288 | | 289 | | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Name length | Tail-end name | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 // // 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Figure 5 - ISIS TE-MESH-GROUP sub-TLV format (IPv6 Address) 298 The OSPF TE-MESH-GROUP TLV and the ISIS TE-MESH-GROUP sub-TLV may 299 contain one or more mesh-group entries where each entry correspond to 300 a TE mesh-group and is made of the following fields: 302 - A mesh-group-number that identifies the mesh-group number, 304 - A Tail-end address: an IPv4 or IPv6 IP address to be used as a 305 tail-end TE LSP address by other LSRs belonging to the same mesh- 306 group, 307 - A Tail-end name: a variable length field used to facilitate the TE 308 LSP identification. The Name length field indicates the length of 309 the display string before padding, in bytes. 311 5. Elements of procedure 313 The OSPF TE-MESH-GROUP TLV is carried within the OSPF Routing 314 Information LSA and the TE-MESH-GROUP sub-TLV is caried within the 315 ISIS Router capability TLV. As such, elements of procedure are 316 inherited from those defined in [I-D.ietf-ospf-cap] and 317 [I-D.ietf-isis-caps] for OSPF and ISIS respectively. Specifically, a 318 router MUST originate a new LSA/LSP whenever the content of this 319 information changes, or whenever required by regular routing 320 procedure (e.g. refresh). The TE-MESH-GROUP TLV is OPTIONAL and MUST 321 at most appear once in a OSPF Router Information LSA or ISIS Router 322 Capability TLV. If the OSPF TE-MESH-GROUP TLV occurs more than once 323 within the OSPF Router Information LSA, only the first instance is 324 processed, subsequent TLV(s) will be silently ignored. Similarly, If 325 the ISIS TE-MESH-GROUP sub-TLV occurs more than once within the ISIS 326 Router capability TLV, only the first instance is processed, 327 subsequent TLV(s) will be silently ignored. 329 5.1. OSPF 331 The TE-MESH-GROUP TLV is advertised within an OSPF Router Information 332 opaque LSA (opaque type of 4, opaque ID of 0) as defined in 333 [I-D.ietf-ospf-cap]. 335 A router MUST originate a new OSPF router information LSA whenever 336 the content of the any of the advertised TLV changes or whenever 337 required by the regular OSPF procedure (LSA refresh (every 338 LSRefreshTime)). If an LSR desires to join or leave a particular TE 339 mesh group, it MUST originate a new OSPF Router Information LSA 340 comprising the updated TE-MESH-GROUP TLV. In the case of a join, a 341 new entry will be added to the TE-MESH-GROUP TLV; conversely, if the 342 LSR leaves a mesh-group the corresponding entry will be removed from 343 the TE-MESH-GROUP TLV. Note that both operations can be performed in 344 the context of a single refresh. An implementation SHOULD be able to 345 detect any change to a previously received TE-MESH-GROUP TLV from a 346 specific LSR. 348 As defined in [RFC2370], an opaque LSA has a flooding scope 349 determined by its LSA type: 351 - link-local (type 9); 353 - area-local (type 10); 354 - entire OSPF routing domain (type 11). In this case, the flooding 355 scope is equivalent to the Type 5 LSA flooding scope. A router may 356 generate multiple OSPF Router Information LSAs with different 357 flooding scopes. The TE-MESH-GROUP TLV may be advertised within a 358 type 10 or 11 Router Information LSA depending on the MPLS TE mesh 359 group profile: 361 - If the MPLS TE mesh-group is contained within a single area (all 362 the LSRs of the mesh-group are contained within a single area), the 363 TE-MESH-GROUP TLV MUST be generated within a Type 10 Router 364 Information LSA; 366 - If the MPLS TE mesh-group spans multiple OSPF areas, the TE mesh- 367 group TLV MUST be generated within a Type 11 router information LSA. 369 It is expected that the number of mesh-groups be very limited (to at 370 most 10 or so). Moreover, TE mesh-group membership is fairly static 371 and should not change frequently. 373 5.2. ISIS 375 The TE-MESH-GROUP sub-TLV is advertised within the IS-IS Router 376 CAPABILITY TLV defined in [I-D.ietf-isis-caps]. An IS-IS router MUST 377 originate a new IS-IS LSP whenever the content of the any of the 378 advertised sub-TLV changes or whenever required by regular IS-IS 379 procedure (LSP refresh). If an LSR desires to join or leave a 380 particular TE mesh group, it MUST originate a new LSP comprising the 381 refreshed ISIS Router capability TLV comprising the updated TE-MESH- 382 GROUP sub-TLV. In the case of a join, a new entry will be added to 383 the TE-MESH-GROUP sub-TLV; conversely, if the LSR leaves a mesh-group 384 the corresponding entry will be deleted from the TE-MESH-GROUP sub- 385 TLV. Note that both operations can be performed in the context of a 386 single refresh. An implementation SHOULD be able to detect any 387 change to a previously received TE-MESH-GROUP sub-TLV from a specific 388 LSR. 390 If the flooding scope of an MPLS Traffic Engineering capability is 391 limited to an IS-IS level/area, the sub-TLV MUST not be leaked across 392 level/area and the S flag of the Router CAPABILITY TLV MUST be 393 cleared. Conversely, if the flooding scope of an MPLS Traffic 394 Engineering capability is the entire routing domain, the TLV MUST be 395 leaked across IS-IS levels/areas, and the S flag of the Router 396 CAPABILITY TLV MUST be set. In both cases the flooding rules 397 specified in [I-D.ietf-isis-caps] apply. 399 As specified in [I-D.ietf-isis-caps], a router may generate multiple 400 IS-IS Router CAPABILITY TLVs within an IS-IS LSP with different 401 flooding scopes. 403 It is expected that the number of TE mesh-groups will be very limited 404 (to at most 10 or so). Moreover, TE mesh-group membership is fairly 405 static and should not change frequently. 407 6. Backward compatibility 409 The TE-MESH-GROUP TLVs defined in this document do not introduce any 410 interoperability issue. For OSPF, a router not supporting the TE- 411 MESH-GROUP TLV SHOULD just silently ignore the TLV as specified in 412 [RFC2370]. For IS-IS a router not supporting the TE-MESH-GROUP sub- 413 TLV SHOULD just silently ignore the sub-TLV. 415 7. IANA Considerations 417 OSPF 419 IANA will assign new OSPF TLV code-point for the newly defined TE- 420 MESH-GROUP TLVs carried within the Router Information LSA. 422 TE-MESH-GROUP TLV (IPv4) (suggested value=3) 424 TE-MESH-GROUP TLV (IPv6) (suggested value=4) 426 ISIS 428 IANA will assign new ISIS TLV code-point for the newly defined TE- 429 MESH-GROUP sub-TLVs carried within the ISIS Router Capability TLV. 431 TE-MESH-GROUP TLV (IPv4) (suggested value=3) 433 TE-MESH-GROUP TLV (IPv6) (suggested value=4) 435 8. Security Considerations 437 No new security issues are raised in this document. 439 9. Acknowledgements 441 We would like to thank Dean Cheng, Adrian Farrel, Yannick Le Louedec, 442 Dave Ward, Les Ginsberg and Stephen Nadas for their useful comments. 444 10. Normative References 446 [I-D.ietf-isis-caps] 447 Vasseur, J., "IS-IS Extensions for Advertising Router 448 Information", draft-ietf-isis-caps-06 (work in progress), 449 January 2006. 451 [I-D.ietf-ospf-cap] 452 Lindem, A., "Extensions to OSPF for Advertising Optional 453 Router Capabilities", draft-ietf-ospf-cap-08 (work in 454 progress), December 2005. 456 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 457 Requirement Levels", BCP 14, RFC 2119, March 1997. 459 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 460 July 1998. 462 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 463 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 464 Tunnels", RFC 3209, December 2001. 466 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 467 (TE) Extensions to OSPF Version 2", RFC 3630, 468 September 2003. 470 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 471 System (IS-IS) Extensions for Traffic Engineering (TE)", 472 RFC 3784, June 2004. 474 Authors' Addresses 476 JP Vasseur (editor) 477 Cisco Systems, Inc 478 1414 Massachusetts Avenue 479 Boxborough, MA 01719 480 USA 482 Email: jpv@cisco.com 483 JL Le Roux (editor) 484 France Telecom 485 2, Avenue Pierre-Marzin 486 Lanion, 22307 487 FRANCE 489 Email: jeanlouis.leroux@francetelecom.com 491 Seisho Yasukawa 492 NTT 493 9-11, Midori-Cho 3-Chome 494 Tokyo, 180-8585 495 JAPAN 497 Email: yasukawa.seisho@lab.ntt.co.jp 499 Stefano Previdi 500 Cisco Systems, Inc 501 Via Del Serafico 200 502 Roma, 00142 503 Italy 505 Email: sprevidi@cisco.com 507 Peter Psenak 508 Cisco Systems, Inc 509 Pegasus Park DE Kleetlaan 6A 510 Diegmen, 1831 511 BELGIUM 513 Email: ppsenak@cisco.com 515 Paul Mabbey 516 Comcast 517 USA 519 Email: 521 Full Copyright Statement 523 Copyright (C) The Internet Society (2006). 525 This document is subject to the rights, licenses and restrictions 526 contained in BCP 78, and except as set forth therein, the authors 527 retain all their rights. 529 This document and the information contained herein are provided on an 530 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 531 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 532 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 533 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 534 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 535 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 537 Intellectual Property 539 The IETF takes no position regarding the validity or scope of any 540 Intellectual Property Rights or other rights that might be claimed to 541 pertain to the implementation or use of the technology described in 542 this document or the extent to which any license under such rights 543 might or might not be available; nor does it represent that it has 544 made any independent effort to identify any such rights. Information 545 on the procedures with respect to rights in RFC documents can be 546 found in BCP 78 and BCP 79. 548 Copies of IPR disclosures made to the IETF Secretariat and any 549 assurances of licenses to be made available, or the result of an 550 attempt made to obtain a general license or permission for the use of 551 such proprietary rights by implementers or users of this 552 specification can be obtained from the IETF on-line IPR repository at 553 http://www.ietf.org/ipr. 555 The IETF invites any interested party to bring to its attention any 556 copyrights, patents or patent applications, or other proprietary 557 rights that may cover technology that may be required to implement 558 this standard. Please address the information to the IETF at 559 ietf-ipr@ietf.org. 561 Acknowledgment 563 Funding for the RFC Editor function is provided by the IETF 564 Administrative Support Activity (IASA).