idnits 2.17.1 draft-ietf-isis-wg-extlsp-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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 569. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 540. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 547. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 553. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([ISO10589], [RFC3786]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (October 20, 2007) is 6027 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ISO 10589' is mentioned on line 43, but not defined == Missing Reference: 'IS- IS' is mentioned on line 84, but not defined == Missing Reference: 'RFC 2119' is mentioned on line 110, but not defined == Unused Reference: 'RFC 3784' is defined on line 484, but no explicit reference was found in the text == Unused Reference: 'RFC 4205' is defined on line 492, but no explicit reference was found in the text == Unused Reference: 'BCP9' is defined on line 500, but no explicit reference was found in the text == Unused Reference: 'BCP14' is defined on line 503, but no explicit reference was found in the text == Unused Reference: 'BCP26' is defined on line 506, but no explicit reference was found in the text == Unused Reference: 'BCP79' is defined on line 509, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 3784 (Obsoleted by RFC 5305) ** Obsolete normative reference: RFC 3786 (Obsoleted by RFC 5311) ** Obsolete normative reference: RFC 4205 (Obsoleted by RFC 5307) == Outdated reference: A later version (-12) exists of draft-ietf-isis-wg-multi-topology-11 ** Obsolete normative reference: RFC 2434 (ref. 'BCP26') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3979 (ref. 'BCP79') (Obsoleted by RFC 8179) Summary: 7 errors (**), 0 flaws (~~), 11 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Danny McPherson (Ed.) 2 Arbor Networks 3 Les Ginsberg 4 Stefano Previdi 5 Mike Shand 6 Cisco Systems 7 Expires: April 2008 October 20, 2007 8 Intended Status: Proposed Standard 10 Simplified Extension of LSP Space for IS-IS 11 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This draft describes a simplified method for extending the LSP space 43 beyond the 256 Link State PDU (LSP) limit defined in [ISO 10589]. 44 This method is intended as a preferred replacement for the method 45 defined in [RFC 3786]. 47 Table of Contents 49 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 2. Specification of Requirements. . . . . . . . . . . . . . . . . 4 51 3. Definition of Commonly Used Terms. . . . . . . . . . . . . . . 4 52 4. Possible Solutions . . . . . . . . . . . . . . . . . . . . . . 5 53 5. Utilizing Additional System IDs. . . . . . . . . . . . . . . . 6 54 5.1. Additional Information in Extended LSPs . . . . . . . . . . 6 55 5.1.1. Extended LSP Restrictions. . . . . . . . . . . . . . . . 6 56 5.1.2. Leaf Advertisements in Extended LSP. . . . . . . . . . . 7 57 5.1.3. IS Neigbor Advertisement Restrictions. . . . . . . . . . 8 58 5.1.4. Area Adresses. . . . . . . . . . . . . . . . . . . . . . 8 59 5.1.5. Overload, Attached, and Partition Repair 60 Bits. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 5.2. Originating LSP Requirements. . . . . . . . . . . . . . . . 9 62 5.3. IS Alias ID TLV (IS-Alias). . . . . . . . . . . . . . . . . 9 63 5.4. New TLVs in Support of IS Neighbor 64 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 6. Comparison with the RFC 3786 Solution. . . . . . . . . . . . . 11 66 7. Deployment Considerations. . . . . . . . . . . . . . . . . . . 11 67 7.1. Advertising New TLVs in Extended LSPs . . . . . . . . . . . 11 68 7.2. Reachability and non-SPF TLV Staleness. . . . . . . . . . . 12 69 7.3. Normal LSP OL State and Use of Extended LSPs. . . . . . . . 12 70 7.4. Moving Neighbor Attribute Informaiton to 71 Extended LSPs. . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 7.5. Advertising New TLVs in Extended LSPs . . . . . . . . . . . 13 73 8. Security Considerations. . . . . . . . . . . . . . . . . . . . 13 74 9. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 13 75 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 76 11. References. . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 11.1. Normative References . . . . . . . . . . . . . . . . . . . 15 78 11.2. Informative References . . . . . . . . . . . . . . . . . . 15 79 12. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 16 81 1. Overview 83 [IS-IS] defines the set of LSP fragments which may be originated by a 84 system at each level. This set is limited to 256 fragments. [IS- IS] 85 also defines a maximum value for an LSP fragment 86 (originatingLxLSPBufferSize) as 1492 bytes. The carrying capacity of 87 an LSP set, while bounded, has thus far been sufficient for 88 advertisements associated with an area/domain in existing deployment 89 scenarios. However, the definition of additional information to be 90 included in LSPs (e.g. multitopology support, traffic engineering 91 information, router capabilities, etc.) has the potential to exceed 92 the carrying capacity of an LSP set. 94 This issue first drew interest when traffic engineering extensions 95 were introduced. This interest resulted in the solution defined in 96 RFC 3786. However, that solution suffers from restrictions required 97 to maintain interoperability with systems which do not support the 98 extensions. 100 This document defines extensions which allow a system to exceed the 101 256 fragment limit and do so in a way which has no interoperability 102 issues with systems which do not support the extension. It is seen as 103 a simpler and therefore preferred solution to the problem. 105 2. Specification of Requirements 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC 2119]. 111 3. Definition of Commonly Used Terms 113 This section provides definitions for terms that are used throughout 114 the text. The terminology is consistent with that used in RFC 3786. 116 Originating System: A physical IS running the IS-IS protocol. As 117 this document describes a method which allows a single physical IS to 118 originate LSPs on behalf of multiple virtual ISs, the Originating 119 System represents the single physical IS. 121 Normal system-id: The system-id of an Originating System as defined 122 by [IS-IS]. 124 Additional system-id: A system-id other than the "Normal system-id" 125 that is assigned by the network administrator to an Originating 126 System in order to allow the generation of extended LSP fragments. 127 The Additional system-id, like the Normal system-id, must be unique 128 throughout the routing area (Level-1) or domain (Level-2). 130 Original LSP: An LSP using the Normal system-id in its LSP ID. 132 Extended LSP: An LSP using an Additional system-id in its LSP ID. 134 LSP set: Logical LSP. A group of LSP fragments (for a given level) 135 which have the same LSPID. This term is used to resolve the ambiguity 136 between a logical LSP and an LSP fragment, both of which are 137 sometimes termed "LSP". 139 Extended LSP set: An LSP set consisting of LSP fragments using an 140 Additional system-id. 142 Extension-capable IS: An IS implementing the mechanisms described in 143 this document. 145 4. Possible Solutions 147 The obvious drawback of static configuration of mappings is the issue 148 of scalability and maintainability. The network operators have to 149 maintain the name tables. They have to maintain an entry in the table 150 for every router in the network, on every router in the network. The 151 effort to create and maintain these static tables grows with the 152 total number of routers on the network. Changing the name or 153 systemID of one router, or adding one new router introduced will 154 affect the configurations of all the other routers on the network. 155 This will make it very likely that those static tables are outdated. 157 Having one table that can be updated in a centralized place would be 158 helpful. One could imagine using the DNS system for this. A drawback 159 is that during the time of network problems, the response time of DNS 160 services might not be satisfactory or the DNS services might not even 161 be available. Another possible drawback might be the added complexity 162 of DNS. Also, some DNS implementations might not support A and PTR 163 records for CLNS NSAPs. 165 A third way to build dynamic mappings would be to use the transport 166 mechanism of the routing protocol itself to advertise symbolic names 167 in IS-IS link-state PDUs. This document defines a new TLV which 168 allows the IS-IS routers to include the name-to-systemID mapping data 169 in their LSPs. This will allow simple and reliable transport of name 170 mapping information across the IS-IS network. 172 5. Utilizing Additional System IDs 174 This extension allows an Originating System to be assigned additional 175 system-ids which may be used to generate additional LSP sets. The 176 additional system-ids are subject to the same restrictions as normal 177 system-ids i.e. when used at Level-1 the additional system-id MUST be 178 unique within the Level-1 area. When used at Level-2 the additional 179 system-id MUST be unique within the domain. 181 Extended LSPs are treated by the IS-IS Update Process in the same 182 manner as normal LSPs i.e. the same rules as to generation, flooding, 183 purging, etc. apply. In particular, if the Extended LSP with LSP 184 Number zero and remaining lifetime > 0 is not present for a 185 particular additional system-id then none of the extended LSPs in 186 that Extended LSP set shall be processed. 188 5.1. Additional Information in Extended LSPs 190 Fragment 0 of an Extended LSP Set MUST include the new IS alias ID 191 TLV defined in Section 4.4. This allows the Extended LSP set to be 192 associated with the Originating System which generated the LSP(s). 194 5.1.1. Extended LSP Restrictions 196 The following restrictions on the information which may appear in an 197 Extended LSP are defined in order to avoid interoperability issues 198 with systems which do not support the extensions defined in this 199 document. All TLV references are based on the current definitions in 200 the IANA IS-IS TLV Codepoints Registry. 202 TLVs Which MUST NOT Appear 204 The following TLVs MUST NOT appear in an Extended LSP: 206 TLV Name (#) 207 ----------- 208 ES Neighbors (3) 209 Part. DIS (4) 210 Prefix Neighbors (5) 212 If any of the TLVs listed above appear in an Extended LSP, an Extension 213 Capable IS MUST ignore those TLVs on receipt and SHOULD report an error. 214 Other TLVs in that extended LSP set MUST be processed normally. 216 5.1.2. Leaf Advertisements in Extended LSP 218 Advertisement of leaf information in Extended LSPs is allowed. 219 Inclusion of such information requires the advertisement of a 220 neighbor between the Originating System and the Virtual IS associated 221 with the extended LSP set in which the leaf advertisements appear. 222 See section 4.2.3. 224 When leaf advertisements for multiple topologies (see [M-IS-IS]) are 225 included in an Extended LSP set, the multi-topology TLV (229) MUST 226 include all topologies for which a leaf advertisement is included. 228 The following TLVs fall into this category: 230 TLV Name (#) 231 ----------- 232 IP Int. Reach (128) 233 IP Ext. Address (130) 234 The extended IP reachability TLV (135) 235 MT IP Reach (235) 236 IPv6 IP Reach (236) 237 MT IPv6 IP Reach (237) 239 5.1.3. IS Neigbor Advertisement Restrictions 241 Advertisement of IS Neighbor Reachability in an Extended LSP is 242 restricted to advertisement of neighbor reachability to the 243 Originating System. A neighbor to the Originating System MUST be 244 advertised in Extended LSPs. If multi-topology capability [M-IS-IS] 245 is supported, an MT IS Neighbor advertisement to the Originating 246 System IS MUST be included for every topology advertised in the 247 Extended LSP set. Neighbor advertisement(s) to the Originating System 248 in an Extended LSP MUST use a non-zero metric and SHOULD use a metric 249 of MaxLinkMetric-1. 251 The restrictions defined here apply to all TLVs used to advertise 252 neighbor reachability. These include the following TLVs: 254 TLV Name (#) 255 ----------- 256 IS Neighbors (2) 257 The extended IS reachability TLV (22) 258 MT-ISN (222) 260 5.1.4. Area Adresses 262 Fragment #0 of an Extended LSP set MUST include an Area Address TLV. 263 The set of area addresses advertised MUST be a subset of the set of 264 Area Addresses advertised in the normal LSP fragment #0 at the 265 corresponding level. Preferably the advertisement SHOULD be 266 syntactically identical to that included in the normal LSP fragment 267 #0 at the corresponding level. 269 5.1.5. Overload, Attached, and Partition Repair Bits 271 The Overload (OL), Attached (ATT), and Partition Repair (P) bits MUST 272 be set to 0 in all Extended LSP fragments. 274 Note that ISs NOT supporting these extensions will interpret these 275 bits normally in Extended LSPs they receive. If the ATT bit were set 276 in an Extended LSP this could indicate that the Virtual IS is 277 attached to other areas when the Originating System is not. This 278 might cause legacy systems to use the Virtual IS as a default exit 279 point from the area. 281 5.2. Originating LSP Requirements 283 The Original LSP set MUST include a neighbor to the Virtual IS 284 associated with each Extended LSP set generated. If multi-topology 285 capability [M-IS-IS] is supported, an MT IS Neighbor advertisement to 286 the Virtual IS MUST be included for every topology advertised in the 287 Extended LSP set. The neighbor advertisement(s) in the Original LSP 288 MUST specify a metric of zero. This guarantees that the two way 289 connectivity check between Originating System and Virtual IS will 290 succeed and that the cost of reaching the Virtual IS is the same as 291 the cost to reach the Originating System. 293 5.3. IS Alias ID TLV (IS-Alias) 295 The IS-Alias TLV allows extension-capable ISs to recognize the 296 Originating System of an Extended LSP set. It identifies the Normal 297 system-id of the Originating System. 299 Type 24 Length # of octets in the value field (7 to 255) 301 Value No. of octets 302 +-----------------------+ 303 | Normal System-id | 6 304 +-----------------------+ 305 | Sub-TLV length | 1 306 +-----------------------+ 307 | Sub-TLVs (optional) | 0 to 248 308 +-----------------------+ 310 Normal system-id 312 The Normal system-id of the Originating System 314 Sub-TLVs length 316 Total length of all sub-TLVs. 318 Sub-TLVs 320 No subTLVs are defined in this document. Should future extensions 321 define subTLVs, the subTLVs MUST be formatted as described in RFC 322 3784. 324 5.4. New TLVs in Support of IS Neighbor Attributes 326 One of the major sources of additional information in LSPs is the 327 subTLV information associated with the extended IS reachability TLV 328 (22) and MT IS Neighbor TLV (222). This includes (but is not limited 329 to) information required in support of Traffic Engineering (TE) as 330 defined in RFC 3784 and RFC 4205. The restrictions defined in this 331 document prohibit the presence of TLV 22 and/or TLV 222 in Extended 332 LSPs except to advertise the neighbor relationship to the Originating 333 System. In the event that there is a need to advertise in Extended 334 LSPs such information associated with neighbors of the Originating 335 System, it is necessary to define new TLVs to carry the subTLV 336 information. 338 Two new TLVs are therefore defined. 340 1) IS Neighbor Attribute TLV (23). It is identical in format to the 341 Extended IS Reachability TLV (22). 343 2) MT IS Neighbor Attribute TLV (223). It is identical in format to 344 the MT IS Neighbor TLV (222). 346 These new TLVs MAY be included in Original LSPs or Extended LSPs. 347 Regardless of the type of LSP in which the TLVs appear, the 348 information pertains to the neighbor relationship between the 349 Originating System and the IS identified in the TLV. 351 These TLVs MUST NOT be used to infer that a neighbor relationship 352 exists in the absence of TLV 22 or TLV 222 (whichever applies) in the 353 Originating LSP set for the specified neighbor. This restriction is 354 necessary in order to maintain compatibility with systems which do 355 not support these extensions. 357 6. Comparison with the RFC 3786 Solution 359 This document utilizes the same basic mechanism (additional system- 360 ids) as RFC 3786 to allow an originating system to generate more than 361 256 LSP fragments. It differs from RFC 3786 in that it restricts the 362 content of Extended LSPs to information which does NOT impact the 363 building of a Shortest Path Tree (SPT). 365 Legacy IS-IS implementations which do not support the extensions 366 defined in this document see the extended LSPs as information 367 associated with a system which is reachable only via the Originating 368 System. As no other systems are reachable via the Virtual ISs, the 369 SPF calculation in legacy ISs is therefore consistent with that 370 performed by extension capable ISs. There is therefore no need for 371 the two different operating modes defined in RFC 3786. 373 There is also no need for the special handling of the original LSP 374 set and the extended LSP set(s) as a single Logical LSP during the 375 SPF as specified in Section 5 of RFC 3786. 377 7. Deployment Considerations 379 There are a number of deployment considerations which limit the 380 usefulness of extended LSPs unless all systems are extension-capable 381 ISs. 383 7.1. Advertising New TLVs in Extended LSPs 385 As extended LSPs MAY be utilized to advertise TLVs associated with 386 other protocol extensions (definition of which is outside the scope 387 of this document) and/or the extensions defined in Section 4.5 of 388 this document, it is obvious that the utilization of the information 389 in extended LSPs by legacy IS-IS implementations will be limited. 390 The implication of this is that as implementations are revised to 391 support the protocol extensions which define new TLVs/subTLVs that 392 MAY be advertised in extended LSPs, the implementation SHOULD also be 393 revised to support the extensions defined in this document so that it 394 is capable of processing the new information whether it appears in 395 normal or extended LSPs. 397 7.2. Reachability and non-SPF TLV Staleness 399 In cases where non-SPF information is advertised in LSPs, it is 400 necessary to determine whether the system which originated the 401 advertisement is reachable in order to guarantee that a receiving IS 402 does not use or leak stale information. So long as the OL bit is NOT 403 set by the Originating System in normal LSPs, reachability to the 404 Virtual IS will be consistent with reachability to the Originating 405 System. Therefore, no special rules are required in this case. 407 7.3. Normal LSP OL State and Use of Extended LSPs 409 If the Originating System sets the OL bit in a normal LSP, legacy 410 systems will see the Virtual ISs associated with that Originating 411 System as unreachable and therefore will not use the information in 412 the corresponding Extended LSPs. Under these circumstances, Extension 413 capable ISs MUST also see the Virtual ISs as unreachable. This 414 avoids potential routing loops in cases where leaf information is 415 advertised in Extended LSPs. 417 7.4. Moving Neighbor Attribute Informaiton to Extended LSPs 419 Section 4.5 defines new TLVs which MAY be used to advertise neighbor 420 attribute information in extended LSPs. In cases where neighbor 421 attribute information associated with the same context (e.g. the same 422 link) appears in both an Original LSP and in one or more Extended LSP 423 Sets, the following rules apply for each attribute: 425 o If the attribute information does not conflict, it MUST be 426 considered additive 428 o If the attribute information conflicts, then the information in 429 the Original LSP, if present, MUST be used. If no information is 430 in the Original LSP, then the information from the Extended LSP 431 with the lowest system-id SHALL be preferred. 433 Utilization of the new TLVs for neighbor attribute information would 434 provide additional benefits which include: 436 o Elimination of the need for redundant IS neighbor TLVs to be 437 processed as part of the SPF. 439 o Easier support for a set of TE information associated with a 440 single link which exceeds the 255 byte TLV limit by allowing the 441 interpretation of multiple TLVs to be considered additive rather 442 than mutually exclusive. 444 7.5. Advertising New TLVs in Extended LSPs 446 The need to advertise leaf information in Extended LSPs may arise 447 because of extensive leaking of inter-level information or because of 448 the support of multiple topologies as described in [M-IS-IS]. When 449 leaf information is advertised in Extended LSPs, these LSPs now 450 contain information which MUST be processed in order to correctly 451 update the forwarding plane of an IS. This may increase the frequency 452 of SPF calculations by ISs in the network. It is therefore 453 recommended that, when possible, leaf information be restricted to 454 the normal LSP set. 456 8. Security Considerations 458 This document raises no new security issues for IS-IS. 460 9. IANA Considerations 462 This document defines the following new ISIS TLVs that need to be 463 reflected in the ISIS TLV code-point registry: 465 Type Description IIH LSP SNP 466 ---- ----------------------------------- --- --- --- 467 23 IS Neighbor Attribute n y n 468 24 IS Alias ID n y n 469 223 MT IS Neighbor Attribute n y n 471 10. Acknowledgments 473 To be provided.... 475 11. References 477 11.1. Normative References 479 [IS-IS] ISO, "Intermediate system to Intermediate system routeing 480 information exchange protocol for use in conjunction with the 481 Protocol for providing the Connectionless-mode Network Service (ISO 482 8473)," ISO/IEC 10589:2002, Second Edition. 484 [RFC 3784] Smit, H. and T. Li, "Intermediate System to Intermediate 485 System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, 486 June 2004. 488 [RFC 3786] Hermelin, A., Previdi, S. and Shand, M., "Extending the 489 Number of Intermediate to Intermediate (IS-IS) Link State PDU (LSP) 490 Fragments Beyond the 256 Limit," RFC 3786, May 2004. 492 [RFC 4205] Kompella, K. and Rehkter, Y., "Intermediate System to 493 Intermediate System (IS-IS) Extensions in Support of Generalized 494 Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005. 496 [M-IS-IS] Pryzgienda, T., Shen, N., and Sheth, N., "Multi Topology 497 (MT) Routing in IS-IS", draft-ietf-isis-wg-multi-topology-11.txt 498 (work in progress), October 2005. 500 [BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", 501 BCP 9, RFC 2026, October 1996. 503 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, March 1997 506 [BCP26] Narten, T. and Alvestrand, H., "Guidelines for Writing an 507 IANA Considerations Section in RFCs", BCP 26 , RFC 2434, October 1998 509 [BCP79] Bradner, S. Ed., "Intellectual Property Rights in IETF 510 Technology ", BCP 79 , RFC 3979, March 2005 512 11.2. Informative References 513 12. Authors' Addresses 515 Les Ginsberg 516 Cisco Systems 517 Email: ginsberg@cisco.com 519 Stefano Previdi 520 Cisco Systems 521 Email: sprevidi@cisco.com 523 Mike Shand 524 Cisco Systems 525 Email: mshand@cisco.com 527 Danny McPherson 528 Arbor Networks, Inc. 529 Email: danny@arbor.net 531 Intellectual Property Statement 533 The IETF takes no position regarding the validity or scope of any 534 Intellectual Property Rights or other rights that might be claimed to 535 pertain to the implementation or use of the technology described in 536 this document or the extent to which any license under such rights 537 might or might not be available; nor does it represent that it has 538 made any independent effort to identify any such rights. Information 539 on the procedures with respect to rights in RFC documents can be 540 found in BCP 78 and BCP 79. 542 Copies of IPR disclosures made to the IETF Secretariat and any 543 assurances of licenses to be made available, or the result of an 544 attempt made to obtain a general license or permission for the use of 545 such proprietary rights by implementers or users of this 546 specification can be obtained from the IETF on-line IPR repository at 547 http://www.ietf.org/ipr. 549 The IETF invites any interested party to bring to its attention any 550 copyrights, patents or patent applications, or other proprietary 551 rights that may cover technology that may be required to implement 552 this standard. Please address the information to the IETF at 553 ietf-ipr@ietf.org. 555 Copyright Statement 556 Copyright (C) The IETF Trust (2007). 558 This document is subject to the rights, licenses and restrictions 559 contained in BCP 78, and except as set forth therein, the authors 560 retain all their rights. 562 This document and the information contained herein are provided on an 563 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 564 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 565 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 566 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 567 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 568 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 569 PURPOSE. 571 Acknowledgment 573 Funding for the RFC Editor function is provided by the IETF 574 Administrative Support Activity (IASA).