idnits 2.17.1 draft-ietf-mpls-upstream-label-05.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 528. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 535. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 541. 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 (April 30, 2008) is 5832 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) == Outdated reference: A later version (-10) exists of draft-ietf-mpls-multicast-encaps-08 == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-06 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Aggarwal 3 Internet Draft Juniper Networks 4 Category: Standards Track 5 Expiration Date: October 2008 Y. Rekhter 6 Juniper Networks 8 E. Rosen 9 Cisco Systems, Inc. 11 April 30, 2008 13 MPLS Upstream Label Assignment and Context-Specific Label Space 15 draft-ietf-mpls-upstream-label-05.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 RFC 3031 limits the MPLS architecture to downstream-assigned MPLS 43 labels. This document introduces the notion of upstream-assigned 44 MPLS labels. It describes the procedures for upstream MPLS label 45 assignment and introduces the concept of a "Context-Specific Label 46 Space". 48 Table of Contents 50 1 Specification of requirements ......................... 2 51 2 Introduction .......................................... 2 52 3 Context-Specific Label Space .......................... 3 53 4 Upstream Label Assignment ............................. 4 54 4.1 Upstream-Assigned and Downstream-Assigned Labels ...... 5 55 5 Assigning Upstream-Assigned Labels .................... 5 56 6 Distributing Upstream-Assigned Labels ................. 6 57 7 Upstream Neighbor Label Space ......................... 6 58 8 Context Label on LANs ................................. 9 59 9 Usage of Upstream-Assigned Labels ..................... 10 60 10 IANA Considerations ................................... 10 61 11 Security Considerations ............................... 11 62 12 Acknowledgements ...................................... 11 63 13 References ............................................ 11 64 13.1 Normative References .................................. 11 65 13.2 Informative References ................................ 11 66 14 Author's Address ...................................... 12 67 15 Intellectual Property Statement ....................... 12 68 16 Copyright Notice ...................................... 13 70 1. Specification of requirements 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 73 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 74 document are to be interpreted as described in [RFC2119]. 76 2. Introduction 78 RFC 3031 [RFC3031] limits the MPLS architecture to downstream- 79 assigned MPLS labels. To quote from RFC 3031: 81 "In the MPLS architecture, the decision to bind a particular label L 82 to a particular Forwarding Equivalence Class (FEC) F is made by the 83 Label Switching Router (LSR) which is DOWNSTREAM with respect to that 84 binding. The downstream LSR then informs the upstream LSR of the 85 binding. Thus labels are "downstream-assigned", and label bindings 86 are distributed in the "downstream to upstream" direction." 88 Upstream assignment of MPLS labels has been discussed and mentioned 89 before [RFC3353, MVPN]. However the architecture for upstream 90 assignment of MPLS labels and the associated procedures have not been 91 described. This document introduces the notion of upstream-assigned 92 MPLS labels to the MPLS architecture. The procedures for upstream 93 assignment of MPLS labels are described. 95 RFC 3031 describes per-platform and per-interface label space. This 96 document generalizes the latter to a "Context-Specific Label Space" 97 and describes a "Neighbor Label Space" as an example of this. 98 upstream-assigned labels are always looked up in a context-specific 99 label space. 101 3. Context-Specific Label Space 103 RFC 3031 describes per-platform and per-interface label spaces. This 104 document introduces the more general concept of a "Context-Specific 105 Label Space". A LSR may contain one or more context-specific label 106 spaces. In general, labels are looked up in the per-platform label 107 space unless something about the context determines that a label be 108 looked up in a particular context-specific label space. 110 One example of a context-specific label space is the per-interface 111 label space discussed in RFC 3031. When a MPLS packet is received 112 over a particular interface the top label of the packet may need to 113 be looked up in the receiving interface's per-interface label space. 114 In this case the receiving interface is the context of the packet. 115 Whether MPLS packets received over a particular interface need to 116 have their top labels looked up in a per-interface label space 117 depends on some characteristic or configuration of the interface. 119 Per-interface label space [RFC3031] is an example of a context- 120 specific label space used for downstream-assigned labels. Context- 121 specific label spaces can also be used for upstream-assigned labels, 122 as described below. 124 When MPLS labels are upstream-assigned the context of a MPLS label L 125 is provided by the LSR that assigns the label and binds the label to 126 a FEC F for a Label Switched Path (LSP) LSP1. The LSR that assigns 127 the label distributes the binding and context to a LSR Lr that then 128 receives MPLS packets on LSP1 with label L. When Lr receives a MPLS 129 packet on LSP1 it MUST be able to determine the context of this 130 packet. 132 An example of such a context is a Tunnel over which MPLS packets on 133 LSP1 may be received and in this case the top label of the MPLS 134 packet, after tunnel decapsulation, is looked up in a label space 135 that is specific to the root of the tunnel. This does imply that Lr 136 be able to determine the tunnel over which the packet was received. 137 Therefore, if the tunnel is a MPLS tunnel, penultimate-hop-popping 138 (PHP) MUST be disabled for the tunnel. 140 Another example of such a context is the neighbor from which MPLS 141 packets on LSP1 may be received. In this case the top label of the 142 MPLS packet, transmitted by the neighbor on LSP1, is looked up in a 143 "Neighbor Specific Label Space". 145 The above two examples are further described in section 7. 147 There may be other sorts of contexts as well. For instance, we define 148 the notion of a MPLS label being used to establish a context, i.e. 149 identify a label space. A "context label" is one which identifies a 150 label table in which the label immediately below the context label 151 should be looked up. A context label carried as an outermost label 152 over a particular multi-access subnet/tunnel MUST be unique within 153 the scope of that subnet/tunnel. 155 4. Upstream Label Assignment 157 When two MPLS LSRs are adjacent in a MPLS label switched path (LSP) 158 one of them can be termed an "upstream LSR" and the other a 159 "downstream LSR" [RFC3031]. Consider two LSRs, Ru and Rd that have 160 agreed to bind Label L to a FEC, F, for packets sent from Ru to Rd. 161 Then with respect to this binding, Ru is the "upstream LSR", and Rd 162 is the "downstream LSR"." 164 When the label binding for F is first made by Rd and distributed by 165 Rd to Ru, the binding is said to be "downstream-assigned". When the 166 label binding for F is first made by Ru and distributed by Ru to Rd, 167 the binding is said to be "upstream-assigned". 169 An important observation about upstream-assigned labels is the 170 following. When an upstream-assigned label L is at the top of the 171 label stack, it must be looked up by an LSR which is not the LSR that 172 assigned and distributed the label binding for L. Therefore an 173 upstream-assigned label must always be looked up in a context- 174 specific label space, as described in section 7. 176 4.1. Upstream-Assigned and Downstream-Assigned Labels 178 It is possible that some LSRs on a LSP for FEC F, distribute 179 downstream-assigned label bindings for FEC F, while other LSRs 180 distribute upstream-assigned label bindings. It is possible for a LSR 181 to distribute a downstream-assigned label binding for FEC F to its 182 upstream adjacent LSR AND distribute an upstream-assigned label 183 binding for FEC F to its downstream adjacent LSR. When two LSRs Ru 184 and Rd are adjacent on an LSP for FEC F (with Ru being the upstream 185 neighbor and Rd the downstream neighbor), either Ru distributes an 186 upstream-assigned label binding for F to Rd, or else Rd distributes a 187 downstream-assigned label binding to Ru, but NOT both. Whether 188 upstream-assigned or downstream-assigned labels are to be used for a 189 particular FEC depends on the application using the LSP. Any 190 application which requires the use of upstream-assigned labels MUST 191 specify that explicitly, or else it is to be assumed that downstream- 192 assigned labels are used. An application on an LSR uses a label 193 distribution protocol to indicate to its peer LSRs whether a 194 particular label binding distributed by the LSR uses upstream- 195 assigned or downstream-assigned label. Details of such procedures are 196 outside the scope of this document. In some cases, the decision as to 197 which is used for a particular application may be made by a 198 configuration option. 200 5. Assigning Upstream-Assigned Labels 202 The only requirement on an upstream LSR assigning upstream-assigned 203 labels is that an upstream-assigned label must be unambiguous in the 204 context-specific label space in which the downstream LSR will look it 205 up. An upstream LSR which is the head end of multiple tunnels SHOULD 206 by default assign the upstream-assigned labels, for all the LSPs 207 carried over these tunnels, from a single label space, which is 208 common to all those tunnels. Further an upstream LSR which is the 209 head of multiple tunnels SHOULD use the same IP address as the head 210 identifier of these tunnels, provided that the head identifier of 211 these tunnels includes an IP address. The LSR could assign the same 212 label value to both a downstream-assigned and an upstream-assigned 213 label. The downstream LSR always looks up upstream-assigned MPLS 214 labels in a context-specific label space as described in section 7. 216 An entry for the upstream-assigned labels is not created in the 217 Incoming Label Map (ILM) [RFC3031] at the upstream LSR as these 218 labels are not incoming labels. Instead an upstream label is an 219 outgoing label, with respect to the upstream LSR, for MPLS packets 220 transmitted on the MPLS LSP in which the upstream LSR is adjacent to 221 the downstream LSR. Hence an upstream label is part of a Next Hop 222 Label Forwarding Entry (NHLFE) at the upstream LSR. 224 When Ru advertises a binding of label L for FEC F to Rd, it creates a 225 NHLFE entry corresponding to L. This NHLFE entry results in imposing 226 the label L on the MPLS label stack of the packet forwarded using the 227 NHLFE entry. If Ru is a transit router on the LSP for FEC F, it 228 binds the ILM for the LSP to this NHLFE. If Ru is an ingress router 229 on the LSP for FEC F, it binds the FEC to the NHLFE entry. 231 6. Distributing Upstream-Assigned Labels 233 Upstream-assigned label bindings MUST NOT be used unless it is known 234 that the downstream LSR supports them. How this is known is outside 235 the scope of this document. 237 MPLS upstream label assignment requires a label distribution protocol 238 to distribute the binding from the upstream LSR to the downstream 239 LSR. Considerations that pertain to a label distribution protocol 240 that are described in [RFC3031] apply. 242 The distribution of the upstream-assigned labels is similar to either 243 the ordered LSP control or independent LSP control of the downstream- 244 assigned labels. In the former case a LSR distributes an upstream- 245 assigned label binding for a FEC F if it is either (a) the ingress 246 LSR for FEC F, or (b) if it has already received an upstream label 247 binding for that FEC from its adjacent upstream LSR for FEC F, or (c) 248 if it has received a request for a downstream label binding from its 249 upstream adjacent LSR. In the latter case each LSR, upon noting that 250 it recognizes a particular FEC, makes an independent decision to bind 251 an upstream-assigned label to that FEC and to distribute that binding 252 to its label distribution peers. 254 7. Upstream Neighbor Label Space 256 If the top label of a MPLS packet being processed by LSR Rd is 257 upstream-assigned, the label is looked up in a context-specific label 258 space, not in a per-platform label space. 260 Rd uses a context-specific label space that it maintains for Ru to 261 "reserve" MPLS labels assigned by Ru. Hence if Ru distributes an 262 upstream assigned label binding L for FEC F to Rd, then Rd reserves L 263 in the separate ILM for Ru's context-specific label space. This is 264 the ILM that Rd uses to lookup a MPLS label which is upstream- 265 assigned by Ru. This label may be the top label on the label stack of 266 a packet received from Ru or it may be exposed as the top label on 267 the label stack, as a result of Rd popping one or more labels off the 268 label stack, from such a packet. 270 This implies that Rd MUST be able to determine whether the top label 271 of a MPLS packet being processed is upstream-assigned and if yes, the 272 "context" of this packet. How this determination is made depends on 273 the mechanism that is used by Ru to transmit the MPLS packet with an 274 upstream-assigned top label L, to Rd. 276 If Ru transmits this packet by encapsulating it in an IP or MPLS 277 tunnel, then the fact that L is upstream-assigned is determined by Rd 278 by the tunnel on which the packet is received. Whether a given tunnel 279 can be used for transmitting MPLS packets with either downstream- 280 assigned or upstream assigned MPLS labels, or both, depends on the 281 tunnel type and is described in [MPLS-MCAST-ENCAPS]. When Rd receives 282 MPLS packets with a top label L on such a tunnel, it determines the 283 "context" of this packet based on the tunnel that the packet is 284 received on. There must be a mechanism for Ru to inform Rd that a 285 particular tunnel from Ru to Rd will be used by Ru for transmitting 286 MPLS packets with upstream-assigned MPLS labels. Such a mechanism 287 will be provided by the label distribution protocol between Ru and Rd 288 and will likely require extensions to existing label distribution 289 protocols. The description of such a mechanism is outside the scope 290 of this document. 292 Rd maintains an "Upstream Neighbor Label Space" for upstream assigned 293 labels, assigned by Ru. When Ru transmits MPLS packets the top label 294 of which is upstream assigned over IP or MPLS tunnels, then Rd MUST 295 be able to determine the root of these IP/MPLS tunnels. Rd MUST then 296 use a separate label space for each unique root. 298 The root is identified by the head-end IP address of the Tunnel. If 299 the same upstream router, Ru, uses different head-end IP addresses 300 for different tunnels then the downstream router, Rd, MUST maintain a 301 different Upstream Neighbor Label Space for each such head-end IP 302 address. 304 Consider the following conditions: 306 1) Ru is the "root" of two tunnels, call them A and B. 308 2) IP address X is an IP address of Ru. 310 3) The signaling protocol used to set up tunnel A identified A's 311 root node as IP address X. 313 4) The signaling protocol used to set up tunnel B identified B's 314 root node as IP address X. 316 5) Packets sent through tunnels A and B may be carrying upstream- 317 assigned labels. 319 6) Ru is the LSR that assigned the upstream-assigned labels 320 mentioned in condition 5. 322 Under these conditions, Ru MUST use the same label space when 323 assigning the upstream-assigned labels. 325 Suppose that Rd is a node that belongs to tunnels A and B, but is not 326 the root node of either tunnel. Then Rd may assume that the same 327 upstream-assigned label space is used on both tunnels IF AND ONLY IF 328 the signaling protocol used to set up tunnel A identified the root 329 node as IP address X and the signaling protocol used to set up tunnel 330 B identified the root node as the same IP address X. 332 In addition, the protocol that is used for distributing the upstream- 333 assigned label to be used over a particular tunnel MUST identify the 334 "assigner" using the same IP address that is used, by the protocol 335 that sets up the tunnel, to identify the root node of the tunnel. 336 Implementors must take note of this, even if the tunnel setup 337 protocol is different from the protocol that is used for distributing 338 the upstream-assigned label to be used over the tunnel. 340 The precise set of procedures for identifying the IP address of the 341 root of the tunnel depend, of course, on the protocol used to set up 342 the tunnel. For P2P tunnels, the intention is that the headend of the 343 tunnel is the "root". For P2MP or MP2MP tunnels, one can always 344 identify one node as being the "root" of the tunnel. 346 Some tunnels may be set up by configuration, rather than by 347 signaling. In these cases, the IP address of the root of the tunnel 348 must be configured. 350 Some tunnels may not even require configuration, e.g., a GRE tunnel 351 can be "created" just by encapsulating packets and transmitting them. 352 In such a case the IP address of the root is considered to be the IP 353 source address of the encapsulated packets. 355 If the tunnel on which Rd receives MPLS packets with a top label L is 356 a MPLS tunnel, then Rd determines a) That L is upstream-assigned and 357 b) The context for L, from the labels above L in the label stack. 358 Note that one or more of these labels may also be upstream-assigned 359 labels. 361 If the tunnel on which Rd receives MPLS packets with a top label L is 362 an IP/GRE tunnel then Rd determines a) That L is upstream-assigned 363 [MPLS-MCAST-ENCAPS] and b) The context for L, from the source address 364 in the IP header. 366 When Ru and Rd are adjacent to each other on a multi-access data link 367 media, if Ru would transmit the packet, with top label L, by 368 encapsulating it in a data link frame, then whether L is upstream- 369 assigned or downstream assigned can be determined by Rd as described 370 in [MPLS-MCAST-ENCAPS]. This is possible because if L is upstream- 371 assigned then [MPLS-MCAST-ENCAPS] uses a different ether type in the 372 data link frame. However this is not sufficient for Rd to determine 373 the context of this packet. In order for Rd to determine the context 374 of this packet, Ru encapsulates the packet, in a one hop MPLS tunnel. 375 This tunnel uses an MPLS context label that is assigned by Ru. 376 Section 8 describes how the context label is assigned. Rd maintains 377 a separate "Upstream Neighbor Label Space" for Ru. The "context" of 378 this packet, i.e. Ru's upstream neighbor label space, in which L was 379 reserved, is determined by Rd from the top context label and the 380 interface on which the packet is received. The ether type in the data 381 link frame is set to indicate that the top label is upstream- 382 assigned. The second label in the stack is L. 384 8. Context Label on LANs 386 The procedure described below applies to LSRs using IPv4 and does not 387 apply to LSRs only using IPv6. A solution for IPv6 LSRs is outside 388 the scope of this document. 390 For a labeled packet with an ether type of 'upstream label 391 assignment' the top label is used as the context. The context label 392 value is assigned by the upstream LSR and advertised to the 393 downstream LSRs. Mechanisms for advertising the context label will 394 be provided by the label distribution protocol between the upstream 395 and downstream LSRs. The description of such a mechanism is outside 396 the scope of this document. 398 The context label assigned by a LSR on a LAN interface MUST be unique 399 across all the context labels assigned by other LSRs on the same LAN. 400 Each LAN interface is normally configured with a primary IPv4 address 401 that is unique on that LAN. The host part of the IPv4 address, 402 identified by the network mask, is unique. If the IPv4 network mask 403 is greater then 12 bits, it is possible to map the remaining 20 bits 404 into an unique context label value. This enables the LSRs on the LAN 405 to assign an unique context label without the need for additional 406 configuration. To avoid assigning context label values that fall into 407 the reserved label space range [RFC3032], the value of the host part 408 of the IPv4 address is offset with 0x10, if this value is not greater 409 then 0xFFFEF. Values of the host part of the IPv4 address greater 410 then 0xFFFEF are not allowed to be used as the context label. 412 Consider LSRs Rm (downstream) connected to Ru1 (upstream) on a LAN 413 interface and to Ru2 (upstream) on a different LAN interface. Rm 414 could receive a context label value derived from the LAN interface 415 from Ru1 and from Ru2. It is possible that the context label values 416 used by Ru1 and Ru2 are the same. This would occur if the LAN 417 interfaces of both Ru1 and Ru2 are configured with a primary IPv4 418 address where the lowest 20 bits are equal. To avoid these conflicts 419 the context label MUST be looked up in the context of the LAN 420 interface on which the packet is received. A receiving LSR that 421 receives a packet with a context label of Lc over LAN interface 422 identified by X, MUST use the label space specific to X to lookup Lc. 423 This determines the context to lookup the label below Lc in the label 424 stack. 426 9. Usage of Upstream-Assigned Labels 428 A typical usage of upstream-assigned labels is when an upstream LSR 429 Ru is adjacent to several downstream LSRs in a LSP LSP1 430 AND Ru is connected to via a multi-access media or tunnel 431 AND Ru wants to transmit a single copy of a MPLS packet on the LSP to 432 . In the case of a tunnel Ru can distribute an upstream- 433 assigned label L that is bound to the FEC for LSP1, to and 434 transmit a MPLS packet, the top label of which is L, on the tunnel. 435 In the case of a multi-access media Ru can distribute an upstream- 436 assigned label L that is bound to the FEC for LSP1, to and 437 transmit a MPLS packet, the top label of which is the context label 438 that identifies Ru, and the label immediately below is L, on the 439 multi-access media. Each of will then interpret this MPLS 440 packet in the context of Ru and forward it appropriately. This 441 implies that MUST all be able to support an Upstream 442 Neighbor Label Space for Ru and Ru MUST be able to determine this. 443 The mechanisms for determining this are specific to the application 444 that is using upstream-assigned labels and is outside the scope of 445 this document. 447 10. IANA Considerations 449 This document has no actions for IANA. 451 11. Security Considerations 453 The security considerations that apply to upstream-assigned labels 454 and context labels are no different in kind than those that apply to 455 downstream-assigned labels. 457 Note that procedures for distributing upstream-assigned labels and/or 458 context labels are not within the scope of this document. Therefore 459 the security considerations that may apply to such procedures are not 460 considered here. 462 Section 8 of this document describes a procedure which enables an LSR 463 to automatically generate a unique context label for a LAN. This 464 procedure assumes that the IP addresses of all the LSR interfaces on 465 the LAN will be unique in their low-order 20 bits. If two LSRs whose 466 IP addresses have the same low-order 20 bits are placed on the LAN, 467 other LSRs are likely to misroute packets transmitted to the LAN by 468 either of the two LSRs in question. 470 12. Acknowledgements 472 Thanks to IJsbrand Wijnands's contribution, specifically for the text 473 on which section 8 is based. 475 13. References 477 13.1. Normative References 479 [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, 480 RFC 3031. 482 [RFC2119] "Key words for use in RFCs to Indicate Requirement 483 Levels.", Bradner, March 1997 485 [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, 486 draft-ietf-mpls-multicast-encaps-08.txt 488 13.2. Informative References 490 [MVPN] E. Rosen, R. Aggarwal [Editors], Multicast in BGP/MPLS VPNs", 491 draft-ietf-l3vpn-2547bis-mcast-06.txt 493 [RFC3353] D. Ooms, et. al., "Overview of IP Multicast in a Multi- 494 Protocol Label Switching (MPLS) Environment.", August 2002. 496 [RFC3032] E. Rosen, et. al., "MPLS Label Stack Encoding", January 497 2001. 499 14. Author's Address 501 Rahul Aggarwal 502 Juniper Networks 503 1194 North Mathilda Ave. 504 Sunnyvale, CA 94089 505 Email: rahul@juniper.net 507 Yakov Rekhter 508 Juniper Networks 509 1194 North Mathilda Ave. 510 Sunnyvale, CA 94089 511 Email: yakov@juniper.net 513 Eric C. Rosen 514 Cisco Systems, Inc. 515 1414 Massachusetts Avenue 516 Boxborough, MA 01719 517 Email: erosen@cisco.com 519 15. Intellectual Property Statement 521 The IETF takes no position regarding the validity or scope of any 522 Intellectual Property Rights or other rights that might be claimed to 523 pertain to the implementation or use of the technology described in 524 this document or the extent to which any license under such rights 525 might or might not be available; nor does it represent that it has 526 made any independent effort to identify any such rights. Information 527 on the procedures with respect to rights in RFC documents can be 528 found in BCP 78 and BCP 79. 530 Copies of IPR disclosures made to the IETF Secretariat and any 531 assurances of licenses to be made available, or the result of an 532 attempt made to obtain a general license or permission for the use of 533 such proprietary rights by implementers or users of this 534 specification can be obtained from the IETF on-line IPR repository at 535 http://www.ietf.org/ipr. 537 The IETF invites any interested party to bring to its attention any 538 copyrights, patents or patent applications, or other proprietary 539 rights that may cover technology that may be required to implement 540 this standard. Please address the information to the IETF at ietf- 541 ipr@ietf.org. 543 16. Copyright Notice 545 Copyright (C) The IETF Trust (2008). 547 This document is subject to the rights, licenses and restrictions 548 contained in BCP 78, and except as set forth therein, the authors 549 retain all their rights. 551 This document and the information contained herein are provided on an 552 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 553 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 554 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 555 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 556 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 557 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.