idnits 2.17.1 draft-ietf-ccamp-automesh-04.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 635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 646. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 653. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 659. 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 (January 23, 2007) is 6293 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 547, 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 informational reference (is this intentional?): RFC 3784 (Obsoleted by RFC 5305) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 8 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: July 27, 2007 France Telecom 5 S. Yasukawa 6 NTT 7 S. Previdi 8 P. Psenak 9 Cisco Systems, Inc 10 P. Mabbey 11 Comcast 12 January 23, 2007 14 Routing extensions for discovery of Multiprotocol (MPLS) Label Switch 15 Router (LSR) Traffic Engineering (TE) mesh membership 16 draft-ietf-ccamp-automesh-04.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 July 27, 2007. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2007). 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. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 87 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 89 Intellectual Property and Copyright Statements . . . . . . . . . . 16 91 1. Terminology 93 Terminology used in this document 95 IGP: Interior Gateway Protocol. 97 IGP Area: OSPF area or IS-IS level. 99 IS-IS: Intermediate System-to-Intermediate System (IS-IS). 101 LSR: Label Switch Router. 103 OSPF: Open Shortest Path First (OSPF). 105 OSPF LSA: OSPF Link State Advertisement. 107 TE LSP: Traffic Engineering Label Switched Path. 109 TE LSP head-end: head/source of the TE LSP. 111 TE LSP tail-end: tail/destination of the TE LSP. 113 TLV: Type Lenght Value 115 2. Introduction 117 There are two well-known approaches in deploying MPLS Traffic 118 Engineering: 120 (1) The so-called "strategic" approach that consists of setting up a 121 full mesh of TE LSPs between a set of LSRs, 123 (2) The so-called "tactical" approach where a set of TE LSPs are 124 provisioned on well identified "hot spots" in order to alleviate a 125 congestion resulting for instance from an unexpected traffic growth 126 in some parts of the network. 128 The set up of a full mesh of TE LSPs among a set of LSRs is a common 129 deployment scenario of MPLS Traffic Engineering either for bandwidth 130 optimization, bandwidth guarantees or fast rerouting with MPLS Fast 131 Reroute. Setting up a full mesh of TE LSPs between N LSRs requires 132 the configuration of a potentially large number of TE LSPs (O(N^2)). 133 Furthermore, the addition of any new LSR in the mesh requires the 134 configuration of N additional TE LSPs on the new LSR and one new TE 135 LSP on every LSR of the existing mesh destined to this new LSR, which 136 gives a total of 2*N TE LSPs to be configured. Such operation is not 137 only time consuming but also a risky operation (prone to 138 misconfiguration) for Service Providers. Hence, an automatic 139 mechanism for setting up TE LSPs meshes is desirable and requires the 140 ability to automatically discover the set of LSRs that belong to the 141 mesh. This document specifies routing extensions so as to 142 automatically discover the members of a mesh, also referred to as a 143 "TE mesh-group". Note that the mechanism(s) needed for the dynamic 144 creation of TE LSPs is implementation specific and outside the scope 145 of this document. 147 Routing extensions have been defined in [I-D.ietf-ospf-cap] and 148 [I-D.ietf-isis-caps] in order to advertise router capabilities. This 149 document specifies IGP (OSPF and IS-IS) TE Mesh Group (Type Lenght 150 Value) TLVs allowing for the automatic discovery of a TE mesh-group 151 members, to be carried in the OSPF Router Information (Link State 152 Advertisement) LSA [I-D.ietf-ospf-cap] and IS-IS Router Capability 153 TLV [I-D.ietf-isis-caps]. The routing extensions specified in this 154 document provide the ability to signal multiple TE mesh groups. An 155 LSR may belong to more than one TE mesh-group(s). 157 There are relatively tight real-time constraints on the operation of 158 IGPs (such as OSPF and IS-IS). For this reason some care needs to be 159 applied when proposing to carry additional information in an IGP. 160 The information described in this document is both relatively small 161 in total volume (compared with other information already carried in 162 IGPs), and also relatively stable (ie, changes are based on 163 configuration changes, but not based on dynamic events within the 164 network, and not based on dynamic triggers such as the leaking of 165 information from other routing protocols or routing protocol 166 instances). 168 3. Description of a TE Mesh-Group 170 A TE mesh-group is defined as a group of LSRs that are connected by a 171 full mesh of TE LSPs. Routing extensions are specified in this 172 document allowing for dynamic discovery of the TE mesh-group members. 173 Procedures are also specified for a member to join and leave a TE 174 mesh-group. For each TE mesh-group membership announced by an LSR, 175 the following information is avdertized: 177 - A mesh-group number identifying the TE mesh-group the LSR belongs 178 to, 180 - A Tail-end address (used as the TE LSP Tail-end address by other 181 LSRs belonging to the same mesh-group), 183 - A Tail-end name: a display string that is allocated to the Tail-end 184 used to ease the TE-LSP naming. 186 4. TE-MESH-GROUP TLV formats 188 4.1. OSPF TE-MESH-GROUP TLV format 190 The TE-MESH-GROUP TLV is used to advertise the desire of an LSR to 191 join/leave a given TE mesh-group. No sub-TLV is currently defined 192 for the TE-MESH-GROUP TLV. 194 The OSPF TE-MESH-GROUP TLV (advertised in an OSPF router information 195 LSA defined in [I-D.ietf-ospf-cap]) has the following format: 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Type | length | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | | 202 // Value // 203 | | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 1 - OSPF TE-MESH-GROUP TLV format 207 Where 208 Type: identifies the TLV type 209 Length: length of the value field in octets 211 The format of the OSPF TE-MESH-GROUP TLV is the same as the TLV 212 format used by the Traffic Engineering Extensions to OSPF 213 (see[RFC3630]). The TLV is padded to four-octet alignment; padding 214 is not included in the length field (so a three octet value would 215 have a length of three, but the total size of the TLV would be eight 216 octets). Nested TLVs are also 32-bit aligned. Unrecognized types 217 are ignored. All types between 32768 and 65535 are reserved for 218 vendor-specific extensions. All other undefined type codes are 219 reserved for future assignment by IANA. 221 The OSPF TE-MESH-GROUP TLV format for IPv4 (figure 2) and IPv6 222 (figure 3) is as follows: 223 TYPE: To be assigned by IANA (Suggested Value: 3) 224 LENGTH: Variable 226 0 1 2 3 227 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 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | mesh-group-number 1 | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Tail-end IPv4 address 1 | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Name length | Tail-end name 1 | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 // // 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | mesh-group-number n | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Tail-end IPv4 address n | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Name length | Tail-end name n | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 2 - OSPF TE-MESH-GROUP TLV format (IPv4 Address) 246 TYPE: To be assigned by IANA (Suggested Value: 4) 247 LENGTH: Variable 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | mesh-group-number 1 | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | | 255 | Tail-end IPv6 address 1 | 256 | | 257 | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Name length | Tail-end name 1 | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 // // 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | mesh-group-number n | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | | 266 | Tail-end IPv6 address n | 267 | | 268 | | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Name length | Tail-end name n | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Figure 3 - OSPF TE-MESH-GROUP TLV format (IPv6 Address) 275 The OSPF TE-MESH-GROUP TLV may contain one or more mesh-group entries 276 where each entry correspond to a TE mesh-group and is made of the 277 following fields: 279 - A mesh-group-number that identifies the mesh-group number, 280 - A Tail-end address: an IPv4 or IPv6 IP address to be used as a 281 tail-end TE LSP address by other LSRs belonging to the same mesh- 282 group, 284 - A Tail-end name: A display string that is allocated to the Tail- 285 end. The field is of variable length field and is used to facilitate 286 the TE LSP identification. - Name length field: An integer, expressed 287 in octets, that indicates the length of the Tail-end name before 288 padding. 290 4.2. IS-IS TE-MESH-GROUP sub-TLV format 292 The TE-MESH-GROUP sub-TLV is used to advertise the desire of an LSR 293 to join/leave a given TE mesh-group. No sub-TLV is currently defined 294 for the TE-MESH-GROUP sub-TLV. 296 The IS-IS TE-MESH-GROUP sub-TLV (advertised in the IS-IS CAPABILITY 297 TLV defined in [I-D.ietf-isis-caps] ) is composed of 1 octet for the 298 type, 1 octet specifying the TLV length and a value field. The 299 format of the TE-MESH-GROUP sub-TLV is identical to the TLV format 300 used by the Traffic Engineering Extensions for IS-IS [RFC3784]. 302 The IS-IS TE-MESH-GROUP sub-TLV format for IPv4 (figure 4) and IPv6 303 (figure 5) is as follows: 304 TYPE: To be assigned by IANA (Suggested value: 3). 305 LENGTH: Variable 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | mesh-group-number 1 | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Tail-end IPv4 address 1 | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Name length | Tail-end name 1 | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 // // 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | mesh-group-number n | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Tail-end IPv4 address n | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Name length | Tail-end name n | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 4 - IS-IS TE-MESH-GROUP sub-TLV format (IPv4 Address) 326 TYPE: To be assigned by IANA (Suggested Value: 4) 327 LENGTH: Variable 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | mesh-group-number 1 | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | | 334 | Tail-end IPv6 address 1 | 335 | | 336 | | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Name length | Tail-end name 1 | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 // // 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | mesh-group-number n | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | | 345 | Tail-end IPv6 address n | 346 | | 347 | | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Name length | Tail-end name n | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 Figure 5 - IS-IS TE-MESH-GROUP sub-TLV format (IPv6 Address) 354 The IS-IS TE-MESH-GROUP sub-TLV may contain one or more mesh-group 355 entries where each entry correspond to a TE mesh-group and is made of 356 the following fields: 358 - A mesh-group-number that identifies the mesh-group number, 360 - A Tail-end address: an IPv4 or IPv6 IP address to be used as a 361 tail-end TE LSP address by other LSRs belonging to the same mesh- 362 group, 364 - A Tail-end name: A display string that is allocated to the Tail- 365 end. The field is of variable length field and is used to facilitate 366 the TE LSP identification. - Name length field: An integer, expressed 367 in octets, that indicates the length of the Tail-end name before 368 padding. 370 5. Elements of procedure 372 The OSPF TE-MESH-GROUP TLV is carried within the OSPF Routing 373 Information LSA and the TE-MESH-GROUP sub-TLV is caried within the 374 IS-IS Router capability TLV. As such, elements of procedure are 375 inherited from those defined in [I-D.ietf-ospf-cap] and 376 [I-D.ietf-isis-caps] for OSPF and IS-IS respectively. Specifically, 377 a router MUST originate a new LSA/LSP whenever the content of this 378 information changes, or whenever required by regular routing 379 procedure (e.g. update). 381 The TE-MESH-GROUP TLV is OPTIONAL and MUST NOT include more than one 382 of each of the IPv4 instance or the IPv6 instance. If either the 383 IPv4 or the IPv6 OSPF TE-MESH-GROUP TLV occurs more than once within 384 the OSPF Router Information LSA, only the first instance is 385 processed, subsequent TLV(s) SHOULD be silently ignored. Similarly, 386 if either the IPv4 or the IPv6 IS-IS TE-MESH-GROUP sub-TLV occurs 387 more than once within the ISIS Router capability TLV, only the first 388 instance is processed, subsequent TLV(s) SHOULD be silently ignored. 390 5.1. OSPF 392 The TE-MESH-GROUP TLV is advertised within an OSPF Router Information 393 opaque LSA (opaque type of 4, opaque ID of 0) for OSPFv2 ([RFC2328]) 394 and within a new LSA (Router Information LSA) for OSPFv3 ([RFC2740]). 395 The Router Information LSAs for OSPFv2 and OSPFv3 are defined in 396 ([I-D.ietf-ospf-cap]). 398 A router MUST originate a new OSPF router information LSA whenever 399 the content of the any of the advertised TLV changes or whenever 400 required by the regular OSPF procedure (LSA update (every 401 LSRefreshTime)). If an LSR desires to join or leave a particular TE 402 mesh group, it MUST originate a new OSPF Router Information LSA 403 comprising the updated TE-MESH-GROUP TLV. In the case of a join, a 404 new entry will be added to the TE-MESH-GROUP TLV; conversely, if the 405 LSR leaves a mesh-group the corresponding entry will be removed from 406 the TE-MESH-GROUP TLV. Note that both operations can be performed in 407 the context of a single LSA update. An implementation SHOULD be able 408 to detect any change to a previously received TE-MESH-GROUP TLV from 409 a specific LSR. 411 As defined in [RFC2370] for OSPVv2 and in [RFC2740] for OSPFv3, the 412 flooding scope of the Router Information LSA is determined by the LSA 413 Opaque type for OSPFv2 and the values of the S1/S2 bits for OSPFv3. 415 For OSPFv2 Router Information opaque LSA: 417 - Link-local scope: type 9; 419 - Area-local scope: type 10; 420 - Routing-domain scope: type 11. In this case, the flooding scope is 421 equivalent to the Type 5 LSA flooding scope. 423 For OSPFv3 Router Information LSA: 425 - Link-local scope: OSPFV3 Router Information LSA with the S1 and S2 426 bits cleared; 428 - Area-local scope: OSPFV3 Router Information LSA with the S1 bit set 429 and the S2 bit cleared; 431 - Routing-domain scope: OSPFv3 Router Information LSA with S1 bit 432 cleared and the S2 bit set. 434 A router may generate multiple OSPF Router Information LSAs with 435 different flooding scopes. 437 The TE-MESH-GROUP TLV may be advertised within an Area-local or 438 Routing-domain scope Router Information LSA depending on the MPLS TE 439 mesh group profile: 441 - If the MPLS TE mesh-group is contained within a single area (all 442 the LSRs of the mesh-group are contained within a single area), the 443 TE-MESH-GROUP TLV MUST be generated within an Area-local Router 444 Information LSA. 446 - If the MPLS TE mesh-group spans multiple OSPF areas, the TE mesh- 447 group TLV MUST be generated within a Routing-domain scope router 448 information LSA. 450 5.2. IS-IS 452 The TE-MESH-GROUP sub-TLV is advertised within the IS-IS Router 453 CAPABILITY TLV defined in [I-D.ietf-isis-caps]. An IS-IS router MUST 454 originate a new IS-IS LSP whenever the content of the any of the 455 advertised sub-TLV changes or whenever required by regular IS-IS 456 procedure (LSP update). If an LSR desires to join or leave a 457 particular TE mesh group, it MUST originate a new LSP comprising the 458 refreshed IS-IS Router capability TLV comprising the updated TE-MESH- 459 GROUP sub-TLV. In the case of a join, a new entry will be added to 460 the TE-MESH-GROUP sub-TLV; conversely, if the LSR leaves a mesh-group 461 the corresponding entry will be deleted from the TE-MESH-GROUP sub- 462 TLV. Note that both operations can be performed in the context of a 463 single update. An implementation SHOULD be able to detect any change 464 to a previously received TE-MESH-GROUP sub-TLV from a specific LSR. 466 If the flooding scope of an MPLS Traffic Engineering capability is 467 limited to an IS-IS level/area, the sub-TLV MUST not be leaked across 468 level/area and the S flag of the Router CAPABILITY TLV MUST be 469 cleared. Conversely, if the flooding scope of an MPLS Traffic 470 Engineering capability is the entire routing domain, the TLV MUST be 471 leaked across IS-IS levels/areas, and the S flag of the Router 472 CAPABILITY TLV MUST be set. In both cases the flooding rules 473 specified in [I-D.ietf-isis-caps] apply. 475 As specified in [I-D.ietf-isis-caps], a router may generate multiple 476 IS-IS Router CAPABILITY TLVs within an IS-IS LSP with different 477 flooding scopes. 479 6. Backward compatibility 481 The TE-MESH-GROUP TLVs defined in this document do not introduce any 482 interoperability issue. For OSPF, a router not supporting the TE- 483 MESH-GROUP TLV SHOULD just silently ignore the TLV as specified in 484 [RFC2370]. For IS-IS a router not supporting the TE-MESH-GROUP sub- 485 TLV SHOULD just silently ignore the sub-TLV. 487 7. IANA Considerations 489 7.1. OSPF 491 Once a registry for the Router Information LSA defined in 492 [I-D.ietf-ospf-cap] will have been assigned, IANA will assign a new 493 OSPF TLV code-point for the TE-MESH-GROUP TLVs carried within the 494 Router Information LSA. 496 Value Sub-TLV References 497 ----- -------- ---------- 498 3 TE-MESH-GROUP TLV (IPv4) draft-ietf-ospf-cap (to be replaced by RFC number) 499 4 TE-MESH-GROUP TLV (IPv6) draft-ietf-ospf-cap (to be replaced by RFC number) 501 7.2. IS-IS 503 Once a registry for the Router Capability TLV defined in 504 [I-D.ietf-isis-caps] will have been assigned, IANA will assign a new 505 IS-IS sub-TLV code-point for the TE-MESH-GROUP sub-TLVs carried 506 within the IS-IS Router Capability TLV. 508 Value Sub-TLV References 509 ----- -------- ---------- 510 3 TE-MESH-GROUP TLV (IPv4) draft-ietf-isis-caps (to be replaced by RFC number) 511 4 TE-MESH-GROUP TLV (IPv6) draft-ietf-isis-caps (to be replaced by RFC number) 513 8. Security Considerations 515 The function described in this document does not create any new 516 security issues for the OSPF and the IS-IS protocols. Security 517 considerations are covered in [RFC2328] and [RFC2740] for the base 518 OSPF protocol and in [RFC1195] for IS-IS. It must be noted that the 519 advertisement of "fake" TE Mesh Group membership(s) by a mis- 520 configured or malicious LSR Y would not have any major impact on the 521 network (other than overloading the IGP) such as triggering the set 522 up of new MPLS TE LSP: indeed for a new TE LSP originated by another 523 LSR X destined to LSR Y to be set up, the same TE Mesh group 524 membership must be configured on both LSRs. Thus such fake 525 advertisement could not amplify any DoS attack. 527 9. Acknowledgements 529 We would like to thank Dean Cheng, Adrian Farrel, Yannick Le Louedec, 530 Dave Ward, Les Ginsberg, Stephen Nadas, Acee Lindem, Dimitri 531 Papadimitriou and Lakshminath Dondeti for their useful comments. 533 10. References 535 10.1. Normative References 537 [I-D.ietf-isis-caps] 538 Vasseur, J., "IS-IS Extensions for Advertising Router 539 Information", draft-ietf-isis-caps-06 (work in progress), 540 January 2006. 542 [I-D.ietf-ospf-cap] 543 Lindem, A., "Extensions to OSPF for Advertising Optional 544 Router Capabilities", draft-ietf-ospf-cap-09 (work in 545 progress), October 2006. 547 [RFC1194] Zimmerman, D., "Finger User Information Protocol", 548 RFC 1194, November 1990. 550 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 551 dual environments", RFC 1195, December 1990. 553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, March 1997. 556 [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 558 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, 559 July 1998. 561 [RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", 562 RFC 2740, December 1999. 564 10.2. Informative References 566 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 567 (TE) Extensions to OSPF Version 2", RFC 3630, 568 September 2003. 570 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 571 System (IS-IS) Extensions for Traffic Engineering (TE)", 572 RFC 3784, June 2004. 574 Authors' Addresses 576 JP Vasseur (editor) 577 Cisco Systems, Inc 578 1414 Massachusetts Avenue 579 Boxborough, MA 01719 580 USA 582 Email: jpv@cisco.com 584 JL Le Roux (editor) 585 France Telecom 586 2, Avenue Pierre-Marzin 587 Lanion, 22307 588 FRANCE 590 Email: jeanlouis.leroux@francetelecom.com 591 Seisho Yasukawa 592 NTT 593 9-11, Midori-Cho 3-Chome 594 Tokyo, 180-8585 595 JAPAN 597 Email: yasukawa.seisho@lab.ntt.co.jp 599 Stefano Previdi 600 Cisco Systems, Inc 601 Via Del Serafico 200 602 Roma, 00142 603 Italy 605 Email: sprevidi@cisco.com 607 Peter Psenak 608 Cisco Systems, Inc 609 Pegasus Park DE Kleetlaan 6A 610 Diegmen, 1831 611 BELGIUM 613 Email: ppsenak@cisco.com 615 Paul Mabbey 616 Comcast 617 USA 619 Email: 621 Full Copyright Statement 623 Copyright (C) The IETF Trust (2007). 625 This document is subject to the rights, licenses and restrictions 626 contained in BCP 78, and except as set forth therein, the authors 627 retain all their rights. 629 This document and the information contained herein are provided on an 630 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 631 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 632 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 633 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 634 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 635 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 637 Intellectual Property 639 The IETF takes no position regarding the validity or scope of any 640 Intellectual Property Rights or other rights that might be claimed to 641 pertain to the implementation or use of the technology described in 642 this document or the extent to which any license under such rights 643 might or might not be available; nor does it represent that it has 644 made any independent effort to identify any such rights. Information 645 on the procedures with respect to rights in RFC documents can be 646 found in BCP 78 and BCP 79. 648 Copies of IPR disclosures made to the IETF Secretariat and any 649 assurances of licenses to be made available, or the result of an 650 attempt made to obtain a general license or permission for the use of 651 such proprietary rights by implementers or users of this 652 specification can be obtained from the IETF on-line IPR repository at 653 http://www.ietf.org/ipr. 655 The IETF invites any interested party to bring to its attention any 656 copyrights, patents or patent applications, or other proprietary 657 rights that may cover technology that may be required to implement 658 this standard. Please address the information to the IETF at 659 ietf-ipr@ietf.org. 661 Acknowledgment 663 Funding for the RFC Editor function is provided by the IETF 664 Administrative Support Activity (IASA).