idnits 2.17.1 draft-ietf-isis-wg-multi-topology-12.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 637. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 607. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 614. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 620. 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 (November 5, 2007) is 6010 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3567 (Obsoleted by RFC 5304) -- Obsolete informational reference (is this intentional?): RFC 3784 (ref. 'LS01') (Obsoleted by RFC 5305) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Tony Przygienda 2 prz@net4u.ch 3 Naiming Shen 4 Cisco Systems 5 Nischal Sheth 6 Juniper Networks 7 Expires: May 2008 November 5, 2007 8 Intended Status: Proposed Standard 10 M-ISIS: Multi Topology (MT) Routing in 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 document describes an optional mechanism within ISIS used today 43 by many ISPs for IGP routing within their clouds. This document 44 describes how to run within a single ISIS domain a set of 45 independent IP topologies that we call Multi-Topologies (MTs). 46 This MT extension can be used for variety of purposes such as an 47 in-band management network ``on top'' of the original IGP topology, 48 maintain separate IGP routing domains for isolated multicast or 49 IPv6 islands within the backbone, or force a subset of an address 50 space to follow a different topology. 52 1. Introduction 54 Maintaining multiple MTs for ISIS [ISO10589] [RFC1195] in a 55 backwards-compatible manner necessitates several extensions to the 56 packet encoding and additional SPF procedures. The problem can 57 be partitioned into forming of adjacencies, and advertising of 58 prefixes and reachable intermediate systems within each topology. 59 Having put all the necessary additional information in place, it 60 must be properly used by MT capable SPF computation. The following 61 sections describe each of the problems separately. To simplify the 62 text, "standard" ISIS topology is defined to be MT ID #0 (zero). 64 1.1 Conventions Used in This Document 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119 [RFC2119]. 70 1.2 Definitions of Terms Used in This Document 72 CSNP Complete Sequence Number Packet. Used to describe all the 73 contents of a link state database of IS-IS. 75 DIS Designated Intermediate System. The intermediate system 76 elected to advertise the pseudonode for a broadcast 77 network. 79 IIH IS-IS Hello. Packets that are used to discover adjacent 80 intermediate systems. 82 LSP Link State Packet. Packet generated by an intermediate 83 system and lists adjacent systems, prefixes and other 84 information. 86 PSNP Partial Sequence Number Packet. Used to request information 87 from an adjacent intermediate system's link state 88 database. 90 SPF Shortest Path First. An algorithm that takes a database 91 of nodes within a domain and builds a tree of connectivity 92 along the shortest paths through the entire network. 94 2. Maintaining MT Adjacencies 96 Each adjacency formed MUST be classified as belonging to a set of 97 MTs on the interface. This is achieved by adding a new TLV into 98 IIH packets that advertises which topologies the interface belongs 99 to. If MT #0 is the only MT on the interface, it is optional to 100 advertise it in the new TLV. Thus not including such a TLV in the 101 IIH implies MT ID #0 capability only. Through this exchange of MT 102 capabilities, a router is able to advertise the IS TLVs in LSPs 103 with common MT set over those adjacencies. 105 In the case of adjacency contains multiple MTs on an interface, and 106 if there exists overlapping IP address space among the topologies, 107 additional mechanism MUST be used to resolve the topology identity 108 of the incoming IP packets on the interface. See more discussion in 109 section 8.2.2 of this document. 111 2.1. Forming Adjacencies on Point-to-Point Interfaces 113 Adjacencies on point-to-point interfaces are formed as usual with 114 ISIS routers not implementing MT extensions. If local router does 115 not participate in certain MTs, it will not advertise those MTIDs 116 in its IIHs and thus will not include that neighbor within it's 117 LSPs. On the other hand, if a MTID is not detected in remote 118 side's IIHs, the local router MUST NOT include that neighbor 119 within its LSPs. The local router SHOULD NOT form an adjacency if 120 they don't have at least one common MT over the interface. 122 2.2. Forming Adjacencies on Broadcast Interfaces 124 On a LAN, all the routers on the LAN which implement the MT 125 extension MAY advertise their MT capability TLV in their IIHs. 126 If there is at least one adjacency on the LAN interface which 127 belongs to this MT, the MT capable router MUST include the 128 corresponding MT IS Reachable TLV in its LSP, otherwise it MAY 129 include this MT IS Reachable TLV in its LSP if the LAN interface 130 participates in this MT set. 132 Two Routers on a LAN SHALL always establish adjacency regardless 133 whether they have common MT or not. This is to ensure all 134 the routers on the LAN can correctly elect the same DIS. The IS 135 SHOULD NOT include the MT IS TLV in its LSP if none of the 136 adjacencies on the LAN contains this MT. 138 The DIS, CSNP and PSNP functions are not changed by MT extension. 140 3. Advertising MT Reachable Intermediate Systems in LSPs 142 A router MUST include within its LSPs in the Reachable Intermediate 143 Systems TLVs only adjacent nodes that are participating in the 144 corresponding topology and advertise such TLVs only if it 145 participates itself in the corresponding topology. Standard 146 Reachable Intermediate Systems TLV is acting here as MT ID #0 147 equivalent of the newly introduced MT Reachable Intermediate Systems 148 TLV. A router MUST announce the MT IS TLV when there is at least 149 one adjacency on the interface that belongs to this MT, otherwise 150 it MAY announce the MT IS TLV of an adjacency for a given MT if this 151 interface participates in the LAN. 153 Since it is not possible to prevent a router that does not 154 understand MT extensions from being responsible for generation of 155 the according pseudo-node, it is not possible either to introduce 156 special TLVs in the pseudo-node LSPs nor run distinct DIS elections 157 per MT. Therefore, a generated pseudo-node LSP by DIS MUST contain 158 in its IS Reachable TLV all nodes on the LAN as usual regardless 159 of their MT capabilities. In other words, there is no change to the 160 pseudo-node LSP construction. 162 4. MTs and Overload, Partition and Attached Bits 164 A router could for each of the MTs become potentially 165 partitioned, overloaded and attached independently. To prevent 166 unnecessary complexity, MT extensions does not support MT based 167 partition repair. The overload, partition and attached bits in LSP 168 header only reflect the status of the default topology. 170 Attached bit and overload bit are part of the MT TLV being 171 distributed within a node's LSP fragment zero. Since each adjacency 172 can belong to different MTs, it is possible that some MTs are L2 173 attached, and others are not on the same router. The overload 174 bit in the MT TLV can be used to signal the topology being 175 overloaded. A MT based system is considered being overloaded if 176 the overload bit in the MT is set. 178 Route leaking between the levels SHOULD only be performed within 179 the same MT. 181 5. Advertising MT Specific IP Prefixes 183 Each of the MTs commands its own address space so a new TLV is 184 necessary for prefixes stored in MTs other than MT ID #0. To 185 make the encoding less confusing when same prefixes are present in 186 multiple MTs and accelerate SPF per MT, rather than adding a sub-TLV 187 in TE extensions, a new TLV is introduced for that purpose that 188 closely follows TE encoding [LS01]. 190 6. MT SPF Computation 192 Each MT MUST run its own instance of the decision process. 193 The pseudo-node LSPs are used by all topologies during computation. 194 Each non-default topology MAY have it's attached bit and overload 195 bit set in the MT TLV. Reverse connectivity check within SPF MUST 196 follow the according MT to assure the bi-directional reachability 197 within the same MT. 199 The results of each computation SHOULD be stored in a separate RIB 200 in normal cases, otherwise overlapping addresses in different 201 topologies could lead to undesirable routing behavior such as 202 forwarding loops. The forwarding logic and configuration need to 203 ensure the same MT is traversed from the source to the destination 204 for packets. The nexthops derived from the MT SPF MUST belong to 205 the adjacencies conforming to the same MT for correct forwarding. 206 It is recommended for the administrators to ensure consistent 207 configuration of all routers in the domain to prevent undesirable 208 forwarding behavior. 210 No attempt is made in this document to allow one topology to 211 calculate routes using the routing information from another 212 topology inside SPF. Even though it is possible to redistribute 213 and leak routes from another IS-IS topology or from external 214 sources, and the exact mechanism is beyond the scope of this 215 document. 217 7. Packet Encoding 219 Three new TLVs are added to support MT extensions. One of them is 220 common for the LSPs and IIHs. Encoding of Intermediate System TLV 221 and IPv4 Reachable Prefixes is tied to traffic engineering 222 extensions [LS01] to simplify the implementation effort. The main 223 reasons we choose using new TLVs instead of using sub-TLVs inside 224 existing TLV type-22 and type-135 are: In many cases, 225 multi-topologies are non-congruent, using sub-TLV approach will 226 not save LSP space; Many sub-TLVs are already being used in TLV 227 type-22, and many more are being proposed while there is a maximum 228 limit on the TLV size, from the existing TLVs; If traffic 229 engineering or some other applications are being applied per 230 topology level later, the new TLVs can automatically inherit the 231 same attributes already defined for the "standard" IPv4 topology 232 without going through long standard process to redefine them per 233 topology. 235 7.1. Multi-Topology TLV 237 TLV number of this TLV is 229. It contains one or more MTs 238 the router is participating in the following structure: 240 x CODE - 229 241 x LENGTH - total length of the value field, it SHOULD be 2 242 times the number of MT components. 243 x VALUE - one or more 2-byte MT components, structured 244 as follows: 245 No. of Octets 246 +--------------------------------+ 247 |O |A |R |R | MT ID | 2 248 +--------------------------------+ 250 Bit O represents the OVERLOAD bit for the MT (only valid 251 in LSP fragment zero for MTs other than ID #0, otherwise 252 SHOULD be set to 0 on transmission and ignored on receipt.) 254 Bit A represents the ATTACH bit for the MT (only valid 255 in LSP fragment zero for MTs other than ID #0, otherwise 256 SHOULD be set to 0 on transmission and ignored on receipt.) 258 Bits R are reserved, SHOULD be set to 0 on transmission 259 and ignored on receipt. 261 MT ID is a 12-bit field containing the ID of the topology 262 being announced. 264 This MT TLV can advertise up to 127 MTs and it can occur multiple 265 times if needed within IIHs and LSP fragment zero. The result MT 266 set SHOULD be the union of all the MT TLV occurrence in the packet. 267 Any other ISIS PDU occurrence of this TLV MUST be ignored. Lack 269 of MT TLV in hellos and fragment zero LSP MUST be interpreted as 270 participation of the advertising interface or router in 271 MT ID #0 only. If a router advertises MT TLV, it has to advertise 272 all the MTs it participates in, specifically including topology 273 ID #0 also. 275 7.2. MT Intermediate Systems TLV 277 TLV number of this TLV is 222. It is aligned with extended IS 278 reachability TLV type 22 beside an additional two bytes in front at 279 the beginning of the TLV. 281 x CODE - 222 282 x LENGTH - total length of the value field 283 x VALUE - 2-byte MT membership plus the format of extended IS 284 reachability TLV, structured as follows: 286 No. of Octets 287 +--------------------------------+ 288 |R |R |R |R | MT ID | 2 289 +--------------------------------+ 290 | extended IS TLV format | 11 - 253 291 +--------------------------------+ 292 . . 293 . . 294 +--------------------------------+ 295 | extended IS TLV format | 11 - 253 296 +--------------------------------+ 298 Bits R are reserved, SHOULD be set to 0 on transmission 299 and ignored on receipt. 301 MT ID is a 12-bit field containing the non-zero MT ID of the 302 topology being announced. The TLV MUST be ignored if the ID 303 is zero. This is to ensure the consistent view of the standard 304 unicast topology. 306 After the 2-byte MT membership format, the MT IS content is 307 in the same format as extended IS TLV, type 22 [LS01]. It 308 can contain up to 23 neighbors of the same MT if no sub-TLVs 309 are used. 311 This TLV can occur multiple times. 313 7.3. Multi-Topology Reachable IPv4 Prefixes TLV 315 TLV number of this TLV is 235. It is aligned with extended IP 316 reachability TLV type 135 beside an additional two bytes in front. 318 x CODE - 235 319 x LENGTH - total length of the value field 320 x VALUE - 2-byte MT membership plus the format of extended 321 extended IP reachability TLV, structured as follows: 323 No. of Octets 324 +--------------------------------+ 325 |R |R |R |R | MT ID | 2 326 +--------------------------------+ 327 | extended IP TLV format | 5 - 253 328 +--------------------------------+ 329 . . 330 . . 331 +--------------------------------+ 332 | extended IP TLV format | 5 - 253 333 +--------------------------------+ 335 Bits R are reserved, SHOULD be set to 0 on transmission 336 and ignored on receipt. 338 MT ID is a 12-bit field containing the non-zero ID of the 339 topology being announced. The TLV MUST be ignored if the ID 340 is zero. This is to ensure the consistent view of the standard 341 unicast topology. 343 After the 2-byte MT membership format, the MT IPv4 content 344 is in the same format as extended IP reachability TLV, 345 type 135 [LS01]. 347 This TLV can occur multiple times. 349 7.4. Multi-Topology Reachable IPv6 Prefixes TLV 351 TLV number of this TLV is 237. It is aligned with IPv6 Reachability 352 TLV type 236 beside an additional two bytes in front. 354 x CODE - 237 355 x LENGTH - total length of the value field 356 x VALUE - 2-byte MT membership plus the format of IPv6 357 Reachability TLV, structured as follows: 359 No. of Octets 360 +--------------------------------+ 361 |R |R |R |R | MT ID | 2 362 +--------------------------------+ 363 | IPv6 Reachability format | 6 - 253 364 +--------------------------------+ 365 . . 366 +--------------------------------+ 367 | IPv6 Reachability format | 6 - 253 368 +--------------------------------+ 370 Bits R are reserved, SHOULD be set to 0 on transmission 371 and ignored on receipt. 373 MT ID is a 12-bit field containing the ID of the topology 374 being announced. The TLV MUST be ignored if the ID 375 is zero. 377 After the 2-byte MT membership format, the MT IPv6 context 378 is in the same format as IPv6 Reachability TLV, 379 type 236 [H01]. 381 This TLV can occur multiple times. 383 7.5. Reserved MT ID Values 385 Certain MT topologies are assigned to serve pre-determined purposes: 387 - MT ID #0: Equivalent to the "standard" topology. 388 - MT ID #1: Reserved for IPv4 in-band management 389 purposes. 390 - MT ID #2: Reserved for IPv6 routing topology. 391 - MT ID #3: Reserved for IPv4 multicast routing topology. 392 - MT ID #4: Reserved for IPv6 multicast routing topology. 393 - MT ID #5: Reserved for IPv6 in-band management 394 purposes. 395 - MT ID #6-#3995: Reserved for IETF consensus. 396 - MT ID #3996-#4095: Reserved for development, experimental and 397 proprietary features [RFC3692]. 399 8. MT IP Forwarding Considerations 400 Using MT extension for ISIS routing can result in multiple RIBs 401 on the system. In this section we 402 list some of the known considerations for IP forwarding in various 403 MT scenario. Certain deployment scenarios presented here 404 imply different trade-offs in terms of deployment difficulties 405 and advantages obtained. 407 8.1. Each MT belong to a distinct address family 409 In this case, each MT related routes are installed into a 410 separate RIB. Multiple topologies can share the same ISIS interface 411 on detecting the incoming packet address family. As an example, 412 IPv4 and IPv6 can share the same interface without any further 413 considerations under MT ISIS. 415 8.2. Some MTs belong to the same address family 417 8.2.1. Each interface belongs to one and only one MT 419 In this case, MTs can be used to forward packets from the 420 same address family, even with overlapping addresses. Since the 421 MTs have their dedicated interfaces, and those interfaces can be 422 associated with certain MT RIBs and FIBs. 424 8.2.2. Multiple MTs share an interface with overlapping addresses 426 Some additional mechanism is needed to select the correct RIBs 427 for the incoming IP packets to determine the correct RIB to make 428 a forwarding decision. For example, if the topologies are 429 QoS partitioned, then the DSCP bits in the IP packet header can 430 be utilized to make the decision. Some IP header or even packet 431 data information MAY be checked to make the forwarding table 432 selection, such as source IP address in the header can be used 433 to determine the desired forwarding behavior. 435 This topic is not unique to IS-IS or even to Multi-topology, it 436 is a local policy and configuration decision to make sure the 437 inbound traffic uses the correct forwarding tables. For example, 438 preferred customer packets are sent through a L2TP towards the 439 high-bandwidth upstream provider, and other packets are sent 440 through a different L2TP to a normal-bandwidth provider. Those 441 mechanism are not part of the L2TP protocol specifications. 443 The generic approach of packet to multiple MT RIB mapping over 444 the same inbound interface is outside the scope of this document. 446 8.2.3. Multiple MTs share an interface with non-overlapping addresses 448 When there is no overlap in the address space among all the MTs, 449 strictly speaking the destination address space classifies the 450 topology a packet belongs to. It is possible to install routes 451 from different MTs into a shared RIB. As an example of such a 452 deployment, a special ISIS topology can be setup for certain 453 EBGP nexthop addresses. 455 8.3 Some MTs are not used for forwarding purpose 457 MT in ISIS MAY be used even if the resulting RIB is not used for 458 forwarding purposes. As an example, multicast RPF check can be 459 performed on a different RIB than the standard unicast RIB albeit 460 an entirely different RIB is used for the multicast forwarding. 461 However, an incoming packet MUST be still clearly identified as 462 belonging to a unique topology. 464 9. MT Network Management Considerations 466 When multiple ISIS topologies exist within a domain, some of the 467 routers can be configured to participate in a subset of the MTs 468 in the network. This section discusses some of the options we 469 have to enable operations or the network management stations to 470 access those routers. 472 9.1. Create dedicated management topology to include all the nodes 474 This approach is to setup a dedicated management topology or 475 'in-band' management topology. This 'mgmt' topology will include 476 all the routers need to be managed. The computed routes in the 477 topology will be installed into the 'mgmt' RIB. In the condition 478 of the 'mgmt' topology uses a set of non-overlapping address space 479 with the default topology, those 'mgmt' routes can also be 480 optionally installed into the default RIB. 481 The advantages of duplicate 'mgmt' routes in both RIBs include: 482 the network management utilities on the system does not have to be 483 modified to use specific RIB other than the default RIB; the 'mgmt' 484 topology can share the same link with the default topology if so 485 designed. 487 9.2. Extend the default topology to all the nodes 489 Even in the case default topology is not used on some of the nodes 490 in the IP forwarding, we MAY want to extend the default topology 491 to those nodes for the purpose of network management. Operators 492 SHOULD set high cost on the links which belong to the extended 493 portion of the default topology. This way the IP data traffic 494 will not be forwarded through those nodes during network topology 495 changes. 497 10. Acknowledgments 499 The authors would like to thank Andrew Partan, Dino Farinacci, 500 Derek Yeung, Alex Zinin, Stefano Previdi, Heidi Ou, Steve Luong, 501 Pekka Savola, Mike Shand, Shankar Vemulapalli and Les Ginsberg 502 for the discussion, their review, comments and contributions to 503 this document. 505 11. Security Consideration 507 ISIS security applies to the work presented. No specific security 508 issues with the proposed solutions are known. The authentication 509 procedure for ISIS PDUs is the same regardless of MT information 510 inside the ISIS PDUs. 512 Note that an authentication mechanism, such as the one defined in 513 [RFC3567] SHOULD be applied if there is high risk resulting 514 from modification of multi-topology information. 516 As described in section 8.2.2, multiple topologies share an 517 interface in the same address space, some mechanism beyond 518 IS-IS need to be used to select the right forwarding table 519 for an inbound packet. A misconfiguration on the system or 520 a packet with spoofed source address for example can lead to 521 packet loss or unauthorized use of premium network resource. 523 12. IANA Considerations 525 This document defines the following new IS-IS TLV types, which have 526 already been reflected in the IANA IS-IS TLV code-point registry: 528 Name Value 530 MT-ISN 222 531 M-Topologies 229 532 MT IP. Reach 235 533 MT IPv6 IP. Reach 237 535 IANA is requested to create a new registry, "IS-IS multi-topology ID 536 values" with the assignment listed in Section 7.5 of this document 537 and registration policies [RFC2434] for future assignments. The 538 MT ID values range 6-3095 are allocated through Expert Review; 539 values in the range of 3096-4095 are reserved for Private Use. 540 In all cases, assigned values are to be registered with IANA. 542 13. References 544 13.1. Normative References 546 [ISO10589] ISO. Intermediate System to Intermediate System Routing 547 Exchange Protocol for Use in Conjunction with the 548 Protocol for Providing the Connectionless-Mode Network 549 Service. ISO 10589, 1992. 551 [RFC1195] R. Callon. Use of OSI ISIS for Routing in TCP/IP and 552 Dual Environments. RFC 1195, December 1990. 554 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 555 Requirement Levels", BCP 14, RFC 2119, March 1997. 557 [RFC3692] Narten, T., "Assigning Experimental and Testing 558 Numbers Considered Useful", BCP 82, RFC 3692, January 559 2004. 561 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing 562 an IANA Considerations Section in RFCs", BCP 26, 563 RFC 2434, October 1998. 565 13.2. Informative References 567 [RFC3567] Li, T. and R. Atkinson, "Intermediate System to 568 Intermediate System (IS-IS) Cryptographic 569 Authentication", RFC 3567, July 2003. 571 [LS01] T. Li and H. Smit. IS-IS Extensions for Traffic 572 Engineering. RFC 3784, May 2005. 574 [H01] C. Hopps. Routing IPv6 with IS-IS. 575 draft-ietf-isis-ipv6-07.txt, October 2007. 576 (work in progress) 578 14. Authors' Addresses 580 Tony Przygienda 581 Z2 Sagl 582 Via Rovello 32 583 CH-6942 Savosa 584 prz@net4u.ch 586 Naiming Shen 587 Cisco Systems 588 225 West Tasman Drive 589 San Jose, CA, 95134 USA 590 naiming@cisco.com 592 Nischal Sheth 593 Juniper Networks 594 1194 North Mathilda Avenue 595 Sunnyvale, CA 94089 USA 596 nsheth@juniper.net 598 Intellectual Property Statement 600 The IETF takes no position regarding the validity or scope of any 601 Intellectual Property Rights or other rights that might be claimed to 602 pertain to the implementation or use of the technology described in 603 this document or the extent to which any license under such rights 604 might or might not be available; nor does it represent that it has 605 made any independent effort to identify any such rights. Information 606 on the procedures with respect to rights in RFC documents can be 607 found in BCP 78 and BCP 79. 609 Copies of IPR disclosures made to the IETF Secretariat and any 610 assurances of licenses to be made available, or the result of an 611 attempt made to obtain a general license or permission for the use of 612 such proprietary rights by implementers or users of this 613 specification can be obtained from the IETF on-line IPR repository at 614 http://www.ietf.org/ipr. 616 The IETF invites any interested party to bring to its attention any 617 copyrights, patents or patent applications, or other proprietary 618 rights that may cover technology that may be required to implement 619 this standard. Please address the information to the IETF at 620 ietf-ipr@ietf.org. 622 Copyright Statement 624 Copyright (C) The IETF Trust (2007). 626 This document is subject to the rights, licenses and restrictions 627 contained in BCP 78, and except as set forth therein, the authors 628 retain all their rights. 630 This document and the information contained herein are provided on an 631 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 632 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 633 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 634 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 635 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 636 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 637 PURPOSE. 639 Acknowledgment 641 Funding for the RFC Editor function is provided by the IETF 642 Administrative Support Activity (IASA).