idnits 2.17.1 draft-ietf-ccamp-automesh-01.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 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 538. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 545. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 551. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 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 (February 5, 2006) is 6654 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 459, but no explicit reference was found in the text == Unused Reference: 'OSPF-TE' is defined on line 473, but no explicit reference was found in the text == Unused Reference: 'PCE-DISCO' is defined on line 476, 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) -- Duplicate reference: RFC3630, mentioned in 'OSPF-TE', was also mentioned in 'RFC3630'. Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group JP. Vasseur (Editor) 2 Internet-Draft Cisco Systems, Inc 3 Expires: August 9, 2006 JL. Leroux (Editor) 4 France Telecom 5 S. Yasukawa 6 NTT 7 S. Previdi 8 P. Psenak 9 Cisco Systems, Inc 10 P. Mabbey 11 Comcast 12 February 5, 2006 14 Routing extensions for discovery of Multiprotocol (MPLS) Label Switch 15 Router (LSR) Traffic Engineering (TE) mesh membership 17 draft-ietf-ccamp-automesh-01.txt 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on August 9, 2006. 44 Copyright Notice 46 Copyright (C) The Internet Society (2006). 48 Abstract 49 The set up of a full mesh of Multi-Protocol Label Switching (MPLS) 50 Traffic Engineering (TE) Label Switched Path (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 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 87 Intellectual Property and Copyright Statements . . . . . . . . . . 16 89 1. Terminology 91 Terminology used in this document 93 LSR: Label Switch Router. 95 TE LSP: Traffic Engineering Label Switched Path. 97 TE LSP head-end: head/source of the TE LSP. 99 TE LSP tail-end: tail/destination of the TE LSP. 101 IGP Area: OSPF area or IS-IS level. 103 2. Introduction 105 There are two well-known approaches in deploying MPLS Traffic 106 Engineering: 108 (1) The so-called "strategic" approach that consists of setting up a 109 full mesh of TE LSPs between a set of LSRs, 111 (2) The so-called "tactical" approach where a set of TE LSPs are 112 provisioned on well identified "hot spots" in order to alleviate a 113 congestion resulting for instance from an unexpected traffic growth 114 in some parts of the network. 116 The set up of a full mesh of TE LSPs among a set of LSRs is a common 117 deployment scenario of MPLS Traffic Engineering either for bandwidth 118 optimization, bandwidth guarantees or fast rerouting with MPLS Fast 119 Reroute. Setting up a full mesh of TE LSPs between N LSRs requires 120 the configuration of a potentially large number of TE LSPs (O(N^2)). 121 Furthermore, the addition of any new LSR in the mesh requires the 122 configuration of N additional TE LSPs on the new LSR and one new TE 123 LSP on every LSR of the existing mesh destined to this new LSR, which 124 gives a total of 2*N TE LSPs to be configured. Such operation is not 125 only time consuming but also a risky operation (prone to 126 misconfiguration) for Service Providers. Hence, an automatic 127 mechanism for setting up TE LSPs meshes is desirable and requires the 128 ability to automatically discover the LSRs that belong to the mesh. 129 This document specifies routing extensions so as to automatically 130 discover the members of a mesh, also referred to as a "TE mesh- 131 group". Note that the mechanism(s) needed for the dynamic creation 132 of TE LSPs is implementation specific and outside the scope of this 133 document. 135 Routing extensions have been defined in [I-D.ietf-ospf-cap] and 137 [I-D.ietf-isis-caps] in order to advertise router capabilities. This 138 document specifies IGP (OSPF and IS-IS) TE Mesh Group TLVs allowing 139 for the automatic discovery of a TE LSP mesh members, to be carried 140 in the OSPF Router Information LSA [I-D.ietf-ospf-cap] and ISIS 141 Router Capability TLV [I-D.ietf-isis-caps]. The routing extensions 142 specified in this document provide the ability to signal multiple TE 143 mesh groups. An LSR may belong to one or more TE mesh-group(s). 145 3. TE Mesh-Group 147 3.1. Description 149 A TE mesh-group is defined as a group of LSRs that are connected by a 150 full mesh of TE LSPs. Routing extensions are specified in this 151 document allowing for dynamic discovery of the TE mesh-group members. 152 Procedures are also specified for a member to join and leave a TE 153 mesh-group. 155 3.2. Required Information 157 This document specifies a TE-MESH-GROUP TLV that indicates the set of 158 TE mesh-group(s) an LSR belongs to. For each TE mesh-group 159 membership announced by an LSR, the TE-MESH-GROUP TLV advertises the 160 following information: 162 - A mesh-group number identifying the TE mesh-group the LSR belongs 163 to. 165 - A Tail-end address (used as TE LSP tail-end address by other LSRs 166 belonging to the same mesh-group). 168 - A Tail-end name: string used to ease the TE-LSP naming. 170 4. TE-MESH-GROUP TLV formats 172 4.1. OSPF TE-MESH-GROUP TLV format 173 the OSPF TE-MESH-GROUP TLV (advertised in an OSPF router information 174 LSA defined in [I-D.ietf-ospf-cap]) has the following format: 175 0 1 2 3 176 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 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Type | length | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | | 181 // Value // 182 | | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 Figure 1 - OSPF TE-MESH-GROUP TLV format 186 Where 187 Type: identifies the TLV type 188 Length: length of the value field in octets 190 The format of the OSPF TE-MESH-GROUP TLV is the same as the TLV 191 format used by the Traffic Engineering Extensions to OSPF 192 (see[RFC3630]). The TLV is padded to four-octet alignment; padding 193 is not included in the length field (so a three octet value would 194 have a length of three, but the total size of the TLV would be eight 195 octets). Nested TLVs are also 32-bit aligned. Unrecognized types 196 are ignored. All types between 32768 and 65535 are reserved for 197 vendor-specific extensions. All other undefined type codes are 198 reserved for future assignment by IANA. The TE-MESH-GROUP TLV is 199 used to advertise the desire of an LSR to join/leave a given TE mesh- 200 group. No sub-TLV is currently defined 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 (NULL padded display string) | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 // // 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Figure 2 - 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 (NULL padded display string) | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 // // 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 Figure 3 - 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 TLV format 253 The IS-IS TE-MESH-GROUP TLV (advertised in the IS-IS CAPABILITY TLV 254 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 TLV is identical to the TLV format used 257 by the Traffic Engineering Extensions for IS-IS [RFC3784]. The TE- 258 MESH-GROUP TLV is used to advertise the desire of an LSR to join/ 259 leave a given TE mesh-group. No sub-TLV is currently defined for the 260 TE-MESH-GROUP TLV. 262 The TE-MESH-GROUP 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 (NULL padded display string) | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 // // 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Figure 4 - TE-MESH-GROUP 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 (NULL padded display string) | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 // // 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Figure 5 - TE-MESH-GROUP TLV format (IPv6 Address) 298 For each TE mesh-group announced by the LSR, the TE-MESH-GROUP TLV 299 comprises: 301 - A mesh-group-number that identifies the mesh-group number 303 - A Tail-end address: an IPv4 or IPv6 IP address to be used as a 304 tail-end TE LSP address by other LSRs belonging to the same mesh- 305 group 306 - A Tail-end name: a variable length field used to facilitate the TE 307 LSP identification. The Name length field indicates the length of 308 the display string before padding, in bytes. 310 5. Elements of procedure 312 The TE-MESH-GROUP TLV is carried within the OSPF Routing Information 313 LSA or ISIS Router capability TLV. As such, elements of procedure 314 are inherited from those defined in [I-D.ietf-ospf-cap] and 315 [I-D.ietf-isis-caps] for OSPF and ISIS respectively. Specifically, a 316 router MUST originate a new LSA/LSP whenever the content of this 317 information changes, or whenever required by regular routing 318 procedure (e.g. refresh). The TE-MESH-GROUP TLV is OPTIONAL and must 319 at most appear once in a OSPF Router Information LSA or ISIS Router 320 Capability TLV. 322 5.1. OSPF 324 The TE-MESH-GROUP TLV is advertised within an OSPF Router Information 325 opaque LSA (opaque type of 4, opaque ID of 0) as defined in 326 [I-D.ietf-ospf-cap]. 328 A router MUST originate a new OSPF router information LSA whenever 329 the content of the any of the advertised TLV changes or whenever 330 required by the regular OSPF procedure (LSA refresh (every 331 LSRefreshTime)). If an LSR desires to join or leave a particular TE 332 mesh group, it MUST originate a new OSPF Router Information LSA 333 comprising the updated TE-MESH-GROUP TLV. In the case of a join, a 334 new entry will be added to the TE-MESH-GROUP TLV; conversely, if the 335 LSR leaves a mesh-group the corresponding entry will be removed from 336 the TE-MESH-GROUP TLV. Note that both operations can be performed in 337 the context of a single refresh. An implementation SHOULD be able to 338 detect any change to a previously received TE-MESH-GROUP TLV from a 339 specific LSR. 341 As defined in [RFC2370], an opaque LSA has a flooding scope 342 determined by its LSA type: 344 - link-local (type 9); 346 - area-local (type 10); 348 - entire OSPF routing domain (type 11). In this case, the flooding 349 scope is equivalent to the Type 5 LSA flooding scope. A router may 350 generate multiple OSPF Router Information LSAs with different 351 flooding scopes. The TE-MESH-GROUP TLV may be advertised within a 352 type 10 or 11 Router Information LSA depending on the MPLS TE mesh 353 group profile: 355 - If the MPLS TE mesh-group is contained within a single area (all 356 the LSRs of the mesh-group are contained within a single area), the 357 TE-MESH-GROUP TLV MUST be generated within a Type 10 Router 358 Information LSA; 360 - If the MPLS TE mesh-group spans multiple OSPF areas, the TE mesh- 361 group TLV MUST be generated within a Type 11 router information LSA. 363 It is expected that the number of mesh-groups and consequently the 364 number of TE-MESH-GROUP TLVs advertised within a Routing Information 365 LSA will be very limited (to at most 10 or so). Moreover, TE mesh- 366 group membership is fairly static and should not change frequently. 368 5.2. ISIS 370 The TE-MESH-GROUP TLV is advertised within the IS-IS Router 371 CAPABILITY TLV defined in [I-D.ietf-isis-caps]. An IS-IS router MUST 372 originate a new IS-IS LSP whenever the content of the any of the 373 advertised sub-TLV changes or whenever required by regular IS-IS 374 procedure (LSP refresh). If an LSR desires to join or leave a 375 particular TE mesh group, it MUST originate a new LSP comprising the 376 refreshed ISIS Router capability TLV comprising the updated TE-MESH- 377 GROUP TLV. In the case of a join, a new entry will be added to the 378 TE-MESH-GROUP TLV; conversely, if the LSR leaves a mesh-group the 379 corresponding entry will be deleted to the TE-MESH-GROUP TLV. Note 380 that both operations can be performed in the context of a single 381 refresh. An implementation SHOULD be able to detect any change to a 382 previously received TE-MESH-GROUP TLV from a specific LSR. 384 If the flooding scope of an MPLS Traffic Engineering capability is 385 limited to an IS-IS level/area, the TLV MUST not be leaked across 386 level/area and the S flag of the Router CAPABILITY TLV MUST be 387 cleared. Conversely, if the flooding scope of an MPLS Traffic 388 Engineering capability is the entire routing domain, the TLV MUST be 389 leaked across IS-IS levels/areas, and the S flag of the Router 390 CAPABILITY TLV MUST be set. In both cases the flooding rules 391 specified in [I-D.ietf-isis-caps] apply. 393 As specified in [I-D.ietf-isis-caps], a router may generate multiple 394 IS-IS Router CAPABILITY TLVs within an IS-IS LSP with different 395 flooding scopes. 397 It is expected that the number of mesh groups and consequently the 398 number of TE-MESH-GROUP TLV advertised within an ISIS Router 399 Capability TLV will be very limited (to at most 10 or so). Moreover, 400 TE mesh-group membership is fairly static and should not change 401 frequently. 403 6. Backward compatibility 405 The TE-MESH-GROUP TLVs defined in this document do not introduce any 406 interoperability issue. For OSPF, a router not supporting the TE- 407 MESH-GROUP TLV SHOULD just silently ignore the TLV as specified in 408 [RFC2370]. For IS-IS a router not supporting the TE-MESH-GROUP TLV 409 SHOULD just silently ignore the TLV. 411 7. IANA Considerations 413 OSPF 415 IANA will assign new OSPF TLV code-point for the newly defined TE- 416 MESH-GROUP TLVs carried within the Router Information LSA. 418 TE-MESH-GROUP TLV (IPv4) (suggested value=3) 420 TE-MESH-GROUP TLV (IPv6) (suggested value=4) 422 ISIS 424 IANA will assign new ISIS TLV code-point for the newly defined TE- 425 MESH-GROUP TLVs carried within the ISIS Router Capability TLV. 427 TE-MESH-GROUP TLV (IPv4) (suggested value=3) 429 TE-MESH-GROUP TLV (IPv6) (suggested value=4) 431 8. Security Considerations 433 No new security issues are raised in this document. 435 9. Acknowledgements 437 We would like to thank Dean Cheng, Adrian Farrel, Yannick Le Louedec 438 and Dave Ward for their useful comments. 440 10. References 441 10.1. Normative References 443 [I-D.ietf-isis-caps] 444 Vasseur, J., "IS-IS Extensions for Advertising Router 445 Information", draft-ietf-isis-caps-06 (work in progress), 446 January 2006. 448 [I-D.ietf-ospf-cap] 449 Lindem, A., "Extensions to OSPF for Advertising Optional 450 Router Capabilities", draft-ietf-ospf-cap-08 (work in 451 progress), December 2005. 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, March 1997. 456 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 457 July 1998. 459 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 460 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 461 Tunnels", RFC 3209, December 2001. 463 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 464 (TE) Extensions to OSPF Version 2", RFC 3630, 465 September 2003. 467 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 468 System (IS-IS) Extensions for Traffic Engineering (TE)", 469 RFC 3784, June 2004. 471 10.2. Informative References 473 [OSPF-TE] Katz, et al., RFC 3630, "Traffic Engineering (TE) 474 Extensions to OSPF Version 2", September 2003. 476 [PCE-DISCO] 477 J.L Le Roux, JP Vasseur et al, 478 draft-ietf-pce-disco-proto-igp (work in progress)., "IGP 479 protocol extensions for Path Computation Element (PCE) 480 Discovery", May . 482 Authors' Addresses 484 JP Vasseur (Editor) 485 Cisco Systems, Inc 486 1414 Massachusetts Avenue 487 Boxborough, MA 01719 488 USA 490 Email: jpv@cisco.com 492 JL Le Roux (Editor) 493 France Telecom 494 2, Avenue Pierre-Marzin 495 Lanion, 22307 496 FRANCE 498 Email: jeanlouis.leroux@francetelecom.com 500 Seisho Yasukawa 501 NTT 502 9-11, Midori-Cho 3-Chome 503 Tokyo, 180-8585 504 JAPAN 506 Email: yasukawa.seisho@lab.ntt.co.jp 508 Stefano Previdi 509 Cisco Systems, Inc 510 Via Del Serafico 200 511 Roma, 00142 512 Italy 514 Email: sprevidi@cisco.com 516 Peter Psenak 517 Cisco Systems, Inc 518 Pegasus Park DE Kleetlaan 6A 519 Diegmen, 1831 520 BELGIUM 522 Email: ppsenak@cisco.com 523 Paul Mabbey 524 Comcast 525 USA 527 Email: 529 Intellectual Property Statement 531 The IETF takes no position regarding the validity or scope of any 532 Intellectual Property Rights or other rights that might be claimed to 533 pertain to the implementation or use of the technology described in 534 this document or the extent to which any license under such rights 535 might or might not be available; nor does it represent that it has 536 made any independent effort to identify any such rights. Information 537 on the procedures with respect to rights in RFC documents can be 538 found in BCP 78 and BCP 79. 540 Copies of IPR disclosures made to the IETF Secretariat and any 541 assurances of licenses to be made available, or the result of an 542 attempt made to obtain a general license or permission for the use of 543 such proprietary rights by implementers or users of this 544 specification can be obtained from the IETF on-line IPR repository at 545 http://www.ietf.org/ipr. 547 The IETF invites any interested party to bring to its attention any 548 copyrights, patents or patent applications, or other proprietary 549 rights that may cover technology that may be required to implement 550 this standard. Please address the information to the IETF at 551 ietf-ipr@ietf.org. 553 Disclaimer of Validity 555 This document and the information contained herein are provided on an 556 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 557 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 558 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 559 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 560 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 561 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 563 Copyright Statement 565 Copyright (C) The Internet Society (2006). This document is subject 566 to the rights, licenses and restrictions contained in BCP 78, and 567 except as set forth therein, the authors retain all their rights. 569 Acknowledgment 571 Funding for the RFC Editor function is currently provided by the 572 Internet Society.