idnits 2.17.1 draft-ginsberg-isis-genapp-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 465. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 491. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 498. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 504. 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 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 (May 2007) is 6191 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'BCP9' is defined on line 398, but no explicit reference was found in the text == Unused Reference: 'BCP26' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'BCP79' is defined on line 408, 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 2434 (ref. 'BCP26') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 3979 (ref. 'BCP79') (Obsoleted by RFC 8179) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group L. Ginsberg 2 Internet Draft S. Previdi 3 Intended Status: Standard M. Shand 4 Expiration Date: Nov 2007 Cisco Systems 5 May 2007 7 Advertising Generic Information in IS-IS 8 draft-ginsberg-isis-genapp-01.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Abstract 35 This draft describes the manner in which generic application 36 information (i.e. information not directly related to the operation 37 of the IS-IS protocol) SHOULD be advertised in IS-IS LSPs and 38 defines guidelines which SHOULD be used when flooding such 39 information. 41 Table of Contents 43 1. Conventions used in this document..............................2 44 2. Overview.......................................................2 45 3. Encoding Format for GENINFO....................................3 46 3.1 GENINFO TLV..................................................3 47 3.2 Use of subTLVs in GENINFO TLV................................5 48 3.3 Standardization Requirements.................................6 49 4. GENINFO Flooding Procedures....................................6 50 4.1 Leaking Procedures...........................................6 51 4.2 Minimizing Update Confusion..................................7 52 4.3 Interpreting Attribute Information...........................8 53 5. Use of a Separate Protocol Instance............................8 54 6. Security Considerations........................................8 55 7. IANA Considerations............................................8 56 8. References.....................................................9 57 8.1 Normative References.........................................9 58 8.2 Informative References.......................................9 59 9. Acknowledgments...............................................11 60 10. Authors' Addresses...........................................11 61 11. Full Copyright Statement.....................................11 63 1. Conventions used in this document 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in RFC-2119 [BCP14]. 69 2. Overview 71 [IS-IS] defines the format of TLVs which may be sent in IS-IS PDUs. 72 The first octet of a TLV encodes the "type" or "codepoint" which 73 provides a scope for the information and information format which 74 follows. The protocol is therefore limited to 256 different 75 codepoints which may be assigned. This number has proved generous as 76 regards the information required for correct operation of the IS-IS 77 protocol. However, the increasing use of IS-IS LSPs for 78 advertisement of generic information (GENINFO) not directly related 79 to the operation of the IS-IS protocol places additional demands on 80 the TLV encoding space which has the potential to consume a 81 significant number of TLV codepoints. This document therefore 82 defines an encoding format for GENINFO which minimizes the 83 consumption of TLV codepoints and also maximizes the flexibility of 84 the formats which can be used to represent GENINFO. 86 This document also discusses optimal behavior associated with the 87 advertisement and flooding of LSPs containing GENINFO in order to 88 avoid the advertisement of stale information and minimize the 89 presence of duplicate or conflicting information when advertisements 90 are updated. 92 The manner in which the information contained in GENINFO TLVs is 93 exchanged between an instance of the IS-IS protocol and the 94 application which generates/consumes the GENINFO is outside the 95 scope of this specification. 97 In order to minimize the impact advertisement of GENINFO may have on 98 the operation of routing such advertisements SHOULD occur in the 99 context of a non-zero instance of the IS-IS protocol as defined in 100 [MI-IS-IS]. 102 3. Encoding Format for GENINFO 104 The encoding format defined below has the following goals regarding 105 the advertisement of GENINFO in IS-IS LSPs: 107 o Minimize the number of codepoints required 109 o Minimize the depth of subTLV levels required 111 In order to support these goals, a new IANA registry is required. 112 This registry is required to manage the assignment of IS-IS GENINFO 113 Application Identifiers. These numbers are unsigned 16 bit numbers 114 ranging in value from 1 to 65535. The registry is also required to 115 manage the assignment of application specific subTLV codepoints. 116 These numbers are unsigned 8 bit numbers ranging in value from 0 to 117 255. The assignment of the subTLV codepoints is scoped by the 118 Application Identifier. 120 3.1 GENINFO TLV 122 The GENINFO TLV supports the advertisement of application specific 123 information which is not directly related to the operation of the 124 IS-IS protocol. 126 Type 251 127 Length # of octets in the value field (3 to 255) 128 Value 130 No. of octets 131 +-----------------------+ 132 | Flags | 1 133 +-----------------------+ 134 | Application ID | 2 135 +-----------------------+ 136 | Application | 137 | IP Address Info | 0 to 20 138 +-----------------------+ 139 | Additional Application| 0 to (252 - 140 | Specific Information | len of IP Address info) 141 +-----------------------+ 143 Flags 145 0 1 2 3 4 5 6 7 146 +-+-+-+-+-+-+-+-+ 147 | Rsvd |V|I|D|S| 148 +-+-+-+-+-+-+-+-+ 150 The following bit flags are defined. 152 S bit (0x01): If the S bit is set(1), the GENINFO TLV 153 MUST be flooded across the entire routing domain. If 154 the S bit is not set(0), the TLV MUST NOT be leaked 155 between levels. This bit MUST NOT be altered during the 156 TLV leaking. 158 D bit (0x02): When the GENINFO TLV is leaked from 159 level-2 to level-1, the D bit MUST be set. Otherwise 160 this bit MUST be clear. GENINFO TLVs with the D bit set 161 MUST NOT be leaked from level-1 to level-2. This is to 162 prevent TLV looping. 164 I bit (0x04): When the I bit is set the 4 octet IPv4 165 address associated with the application immediately 166 follows the Application ID. 168 V bit (0x08): When the V bit is set, the 16 octet IPv6 169 address associated with the application immediately 170 follows either the Application ID (if I bit is clear) 171 or the IPv4 address (if I bit is set). 173 Application ID 175 An identifier assigned to this application via the 176 GENINFO-REG. 178 Application IPv4 Address Info 180 The IPv4 address associated with the application. This 181 is not necessarily an address of a router running the 182 IS-IS protocol. 184 Application IPv6 Address Info 186 The IPv6 address associated with the application. This 187 is not necessarily an address of a router running the 188 IS-IS protocol. 190 Additional Application Specific Information 192 Each application may define additional information to 193 be encoded in a GENINFO TLV following the fixed 194 information. Definition of such information is beyond 195 the scope of this document. 197 The Application ID in combination with the Application IPv4/IPv6 198 Address Information uniquely identifies the GENINFO Application 199 Context (GENINFO-CTX). 201 3.2 Use of subTLVs in GENINFO TLV 203 [RFC3784] introduced the definition and use of subTLVs. One of the 204 advantages of using subTLVs rather than fixed encoding of 205 information inside a TLV is to allow for the addition of new 206 information in a backwards compatible manner i.e. just as with TLVs, 207 implementations are required to ignore subTLVs which they do not 208 understand. 210 GENINFO TLVs MAY include subTLVs in the application specific 211 information as deemed necessary and appropriate for each 212 application. The scope of the codepoints used in such subTLVs is 213 defined by the GENINFO TLV codepoint AND the Application ID i.e. the 214 subTLV codepoints are private to the application. Such subTLVs are 215 referred to as APPSUBTLVs and MUST be assigned via the GENINFO-REG 216 IANA registry. 218 Additional levels of APPSUBTLVs may be required when there is 219 variable information which is scoped by a specific APPSUBTLV. These 220 "nested" subTLVs MUST be encoded in the same manner as subTLVs i.e. 221 with a one-octet Type field, a one-octet Length field, and zero or 222 more octets of Value. These types MUST also be assigned via the 223 GENINFO-REG IANA registry. 225 The use of additional levels of subTLVs is discouraged due to the 226 inherent inefficiency in encoding introduced because the parent 227 subTLV must encode the nested subTLV length. While this inefficiency 228 is small (one additional octet), it may be sufficient to extend the 229 total information about a single application object beyond the 230 carrying capacity of a single GENINFO TLV. Given that each 231 Application ID can utilize the full range of subTLV codepoints (0 to 232 255) without conflict with any other application, the need to be 233 frugal in the use of APPSUBTLV codepoints is greatly reduced. 235 3.3 Standardization Requirements 237 GENINFO is intended to advertise information on behalf of 238 applications whose operations have been defined in public documents. 239 Therefore the uses of GENINFO MUST be standardized. 241 GENINFO is NOT intended to be used for proprietary or experimental 242 purposes. 244 4. GENINFO Flooding Procedures 246 This section describes procedures which apply to the propagation of 247 LSPs which contain GENINFO TLVs. These procedures have been 248 previously discussed in [IS-IS-CAP]. This section is intended to 249 serve as a reference specification for future documents which define 250 the use of GENINFO TLV(s) for a specific application - eliminating 251 the need to repeat the definition of these procedures in the 252 application specific documents. 254 Each GENINFO TLV contains information regarding exactly one 255 application instance as identified by the GENINFO-CTX. When it is 256 necessary to advertise sets of information with the same GENINFO-CTX 257 which have different flooding scopes, a router MUST originate a 258 minimum of one GENINFO TLV for each required flooding scope. GENINFO 259 TLVs which contain information having area/level scope will have the 260 S bit clear. These TLVs MUST NOT be leaked into another level. 261 GENINFO TLVs which contain information which has domain scope will 262 have the S bit set. These TLVs MUST be leaked into other IS-IS 263 levels. When a TLV is leaked from level-2 to level-1, the D bit MUST 264 be set in the level-1 LSP advertisement. 266 4.1 Leaking Procedures 268 When leaking GENINFO TLVs downward from Level-2 into Level-1, if the 269 originator of the TLV is a Level-1 router in another area, it is 270 possible that multiple copies of the same TLV may be received from 271 multiple L2 routers in the originating area. A router performing 272 downward leaking MUST check for such duplication by comparing the 273 contents of the TLVs. The set of LSPs generated by a router for a 274 given level MUST NOT contain two or more copies of the same GENTLV. 276 In order to prevent the use of stale GENINFO information, a system 277 MUST NOT use a GENINFO TLV present in an LSP of a system which is 278 not currently reachable via Level-x paths, where "x" is the level (1 279 or 2) associated with the LSP in which the GENINFO TLV appears. Note 280 that leaking a GENINFO TLV is one of the uses which is prohibited 281 under these conditions. The following example illustrates what might 282 occur in the absence of this restriction. 284 Example: If Level-1 router A generates a GENINFO TLV and floods it 285 to two L1/L2 routers S and T, they will flood it into the Level-2 286 sub-domain. Now suppose the Level-1 area partitions, such that A and 287 S are in one partition and T is in another. IP routing will still 288 continue to work, but if A now issues a revised version of the 289 GENINFO TLV, or decides to stop advertising it, S will follow suit, 290 but T will continue to advertise the old version until the LSP times 291 out. 293 Routers in other areas have to choose whether to trust T's copy of 294 A's GENINFO TLV or S's copy of A's information and they have no 295 reliable way to choose. By making sure that T stops leaking A's 296 information, this removes the possibility that other routers will 297 use stale information from A. 299 4.2 Minimizing Update Confusion 301 If an update to a TLV is advertised in an LSP with a different 302 number than the LSP associated with the old advertisement, the 303 possibility exists that other systems can temporarily have either 0 304 copies of a particular advertisement or 2 copies of a particular 305 advertisement, depending on the order in which new copies of the LSP 306 which had the old advertisement and the LSP which has the new 307 advertisement arrive at other systems. 309 Whenever possible, an implementation SHOULD advertise the update to 310 a GENINFO TLV in the LSP with the same number as the advertisement 311 which it replaces. Where this is not possible, the two affected LSPs 312 SHOULD be flooded as an atomic action. 314 Systems which receive an update to an existing GENINFO TLV can 315 minimize the potential disruption associated with the update by 316 employing a holddown time prior to processing the update so as to 317 allow for the receipt of multiple LSPs associated with the same 318 update prior to beginning processing. 320 4.3 Interpreting Attribute Information 322 Where a receiving system has two copies of a GENINFO TLV with the 323 same GENINFO-CTX, attribute information in the two TLVs which does 324 not conflict MUST be considered additive. When information in the 325 two GENINFO TLVs conflicts i.e there are different settings for a 326 given attribute, the procedure used to choose which copy shall be 327 used is undefined. 329 5. Use of a Separate Protocol Instance 331 The use of the IS-IS flooding mechanism as a means of reliably and 332 efficiently propagating information is understandably attractive. 333 However, it is prudent to remember that the primary purpose of that 334 mechanism is to flood information necessary for the correct 335 operation of the IS-IS protocol. Flooding of information not 336 directly related to the use of the IS-IS protocol in support of 337 routing degrades the operation of the protocol. Degradation occurs 338 because the frequency of LSP updates is increased and because the 339 processing of non-routing information in each router consumes 340 resources whose primary responsibility is to efficiently respond to 341 reachability changes in the network. 343 Advertisement of GENINFO therefore SHOULD occur in the context of a 344 non-zero instance of the IS-IS protocol as defined in [MI-IS-IS]. 345 The use of a separate instance of the protocol allows both the 346 flooding and the processing of the non-routing information to be 347 decoupled from the information necessary to support correct routing 348 of data in the network. The flooding and processing of non-routing 349 information can then be prioritized appropriately. 351 Use of a separate protocol instance to advertise GENINFO does not 352 eliminate the need to use prudence in the frequency with which such 353 information is updated. One of the most egregious oversights is a 354 failure to appropriately dampen changes in the information to be 355 advertised, which can lead to flooding storms. Documents which 356 specify the use of the mechanisms defined here MUST define the 357 expected rate of change of the information to be advertised. 359 6. Security Considerations 361 This document raises no new security issues for IS-IS. 363 7. IANA Considerations 365 This document defines a new ISIS TLV that needs to be reflected in 366 the ISIS TLV code-point registry: 368 Type Description IIH LSP SNP 369 ---- ----------------------------------- --- --- --- 370 251 Generic Information n y n 372 This document also defines a new registry which needs to be created. 374 The new registry is required to manage two types of assigned 375 numbers: 377 1)Application Identifiers which may be used in the Generic 378 Information TLV. These identifiers are unsigned 16 bit numbers 379 ranging in value from 1 to 65535. 381 2)Application specific subTLV codepoints which may be used in a 382 GENINFO TLV when a specific Application Identifier is used. These 383 numbers are unsigned 8 bit numbers ranging in value from 0 to 255. 385 8. References 387 8.1 Normative References 389 [IS-IS] ISO, "Intermediate system to Intermediate system routeing 390 information exchange protocol for use in conjunction with the 391 Protocol for providing the Connectionless-mode Network Service 392 (ISO 8473)," ISO/IEC 10589:2002, Second Edition. 394 [RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate 395 System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 396 3784, June 2004. 398 [BCP9] Bradner, S., "The Internet Standards Process -- Revision 399 3", BCP 9, RFC 2026, October 1996. 401 [BCP14] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, March 1997 404 [BCP26] Narten, T. and Alvestrand, H., "Guidelines for Writing an 405 IANA Considerations Section in RFCs", BCP 26 , RFC 2434, October 406 1998 408 [BCP79] Bradner, S. Ed., "Intellectual Property Rights in IETF 409 Technology ", BCP 79 , RFC 3979, March 2005 411 8.2 Informative References 413 [IS-IS-CAP] Vasseur, JP., Shen N., and Aggarwal, R., "IS-IS 414 extensions for advertising router information", draft-ietf-isis- 415 caps-07.txt, February 2007 417 [MI-IS-IS] Previdi, S. et al, "IS-IS Multi-instance", draft- 418 previdi-isis-mi-00.txt, May 2007 420 9. Acknowledgments 422 The authors would like to thank JP Vasseur and David Ward for 423 providing the need to produce this document and Tony Li for making 424 sure it was done with appropriate wisdom and prudence. 426 10. Authors' Addresses 428 Les Ginsberg 429 Cisco Systems 430 510 McCarthy Blvd. 431 Milpitas, Ca. 95035 USA 432 Email: ginsberg@cisco.com 434 Stefano Previdi 435 CISCO Systems, Inc. 436 Via Del Serafico 200 437 00142 - Roma 438 ITALY 439 Email: sprevidi@cisco.com 441 Mike Shand 442 Cisco Systems 443 250 Longwater Avenue, 444 Reading, 445 Berkshire, 446 RG2 6GB 447 UK 448 Email: mshand@cisco.com 450 11. Full Copyright Statement 452 Copyright (C) The IETF Trust (2007). 454 This document is subject to the rights, licenses and restrictions 455 contained in BCP 78, and except as set forth therein, the authors 456 retain all their rights. 458 This document and the information contained herein are provided on 459 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 460 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 461 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 462 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 463 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 464 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 465 FOR A PARTICULAR PURPOSE. 467 This document and translations of it may be copied and furnished to 468 others, and derivative works that comment on or otherwise explain it 469 or assist in its implementation may be prepared, copied, published 470 and distributed, in whole or in part, without restriction of any 471 kind, provided that the above copyright notice and this paragraph 472 are included on all such copies and derivative works. However, this 473 document itself may not be modified in any way, such as by removing 474 the copyright notice or references to the IETF Trust or other 475 Internet organizations, except as needed for the purpose of 476 developing Internet standards in which case the procedures for 477 copyrights defined in the Internet Standards process must be 478 followed, or as required to translate it into languages other than 479 English. 481 The limited permissions granted above are perpetual and will not be 482 revoked by the IETF Trust or its successors or assigns. 484 The IETF takes no position regarding the validity or scope of any 485 Intellectual Property Rights or other rights that might be claimed 486 to pertain to the implementation or use of the technology described 487 in this document or the extent to which any license under such 488 rights might or might not be available; nor does it represent that 489 it has made any independent effort to identify any such rights. 490 Information on the procedures with respect to rights in RFC 491 documents can be found in BCP 78 and BCP 79. 493 Copies of IPR disclosures made to the IETF Secretariat and any 494 assurances of licenses to be made available, or the result of an 495 attempt made to obtain a general license or permission for the use 496 of such proprietary rights by implementers or users of this 497 specification can be obtained from the IETF on-line IPR repository 498 at http://www.ietf.org/ipr. 500 The IETF invites any interested party to bring to its attention any 501 copyrights, patents or patent applications, or other proprietary 502 rights that may cover technology that may be required to implement 503 this standard. Please address the information to the IETF at ietf- 504 ipr@ietf.org.