idnits 2.17.1 draft-morin-l3vpn-mvpn-fast-failover-00.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 531. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 542. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 549. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 555. 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: When signaling state for a P2MP TE LSP is removed (e.g. if the ingress of the P2MP TE LSP sends a PathTear message) or the P2MP TE LSP changes state from up to down as determined by procedures in [RFC4875], the status of the corresponding P-Tunnel SHOULD be re-evaluated. If the P-Tunnel transitions from up to down state, the upstream PE, that is the ingress of the P-Tunnel, SHOULD not be considered a valid UMH. -- 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 3, 2008) is 5653 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-07 == Outdated reference: A later version (-08) exists of draft-ietf-l3vpn-2547bis-mcast-bgp-05 == Outdated reference: A later version (-02) exists of draft-katz-ward-bfd-multipoint-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Morin 3 Internet-Draft France Telecom - Orange Labs 4 Intended status: Experimental Y. Rekhter 5 Expires: May 7, 2009 R. Aggarwal 6 Juniper Networks 7 W. Henderickx 8 P. Muley 9 Alcatel-Lucent 10 November 3, 2008 12 Multicast VPN fast upstream failover 13 draft-morin-l3vpn-mvpn-fast-failover-00 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 7, 2009. 40 Abstract 42 This document defines multicast VPN extensions and procedures that 43 allow fast failover for upstream failures, by allowing downstream PEs 44 to take into account the status of Provider-Tunnels (P-tunnels) when 45 selecting the upstream PE for a VPN multicast flow, and extending BGP 46 mVPN routing so that a C-multicast route can be advertised toward a 47 standby upstream PE. 49 Requirements Language 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [RFC2119]. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. UMH Selection based on tunnel status . . . . . . . . . . . . . 3 60 3.1. Determining the status of a tunnel . . . . . . . . . . . . 4 61 3.1.1. mVPN tunnel root tracking . . . . . . . . . . . . . . 5 62 3.1.2. PE-P Upstream link status . . . . . . . . . . . . . . 5 63 3.1.3. P2MP RSVP-TE tunnels . . . . . . . . . . . . . . . . . 5 64 3.1.4. Leaf-initiated P-tunnels . . . . . . . . . . . . . . . 6 65 3.1.5. P2MP LSP OAM . . . . . . . . . . . . . . . . . . . . . 6 66 3.1.6. (S,G) counter information . . . . . . . . . . . . . . 6 67 4. Standby C-multicast route . . . . . . . . . . . . . . . . . . 7 68 4.1. Downstream PE behavior . . . . . . . . . . . . . . . . . . 7 69 4.2. Upstream PE behavior . . . . . . . . . . . . . . . . . . . 8 70 4.3. Reachability determination . . . . . . . . . . . . . . . . 9 71 5. Hot leaf standby . . . . . . . . . . . . . . . . . . . . . . . 9 72 6. Duplicate packets . . . . . . . . . . . . . . . . . . . . . . 9 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 78 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 80 Intellectual Property and Copyright Statements . . . . . . . . . . 13 82 1. Introduction 84 In the context of multicast in BGP/MPLS VPNs, it is desirable to 85 provide mechanisms allowing fast recovery of connectivity on 86 different types of failures. This document addresses failures of 87 elements in the provider network that are upstream of PEs connected 88 to VPN sites with receivers. 90 The two first section describe two independent mechanisms, allowing 91 different levels of resiliency, and providing different failure 92 coverage: 94 o Section 3 describes local procedures allowing an egress PE (a PE 95 connected to a receiver site) to take into account the status of 96 P-Tunnels to determine the Upstream Multicast Hop (UMH) for a 97 given (C-S, C-G). 99 o Section 4 describes protocol extensions that can speed up failover 100 by not requiring any multicast VPN routing message exchange at 101 recovery time. 103 Moreover, section 5 describes a "hot leaf standby" mechanism, that 104 uses a combination of these two mechanisms. 106 2. Terminology 108 The terminology used in this document is the terminology defined in 109 [I-D.ietf-l3vpn-2547bis-mcast] and 110 [I-D.ietf-l3vpn-2547bis-mcast-bgp]. 112 3. UMH Selection based on tunnel status 114 Current multicast VPN specifications [I-D.ietf-l3vpn-2547bis-mcast], 115 section 5.1, describe the procedures used by a multicast VPN 116 downstream PE to determine what the upstream multicast hop (UMH) is 117 for a said (C-S,C-G). 119 The procedure described here is an OPTIONAL procedure that consist in 120 having a downstream PE take into account the status of P-tunnels 121 rooted at each possible upstream PEs, for including or not including 122 each said PE in the list of candidate UMHs for a said (C-S,C-G) 123 state. The result is that, if a P-tunnel is "down" (see 124 Section 3.1), the PE that is the root of the P-Tunnel won't be 125 considered for UMH selection, which will result in the downstream PE 126 to failover to the upstream PE which is next in the list of 127 candidates. 129 More precisely, UMH determination for a said (C-S,C-G) will consider 130 the UMH candidates in the following order: 132 o first, the UMH candidates that advertise a PMSI bound to a tunnel 133 that is "up", and *if* the "allowed-SPMSI-only" configuration flag 134 is set (see below), the UMH candidates that do not advertise any 135 I- or S- PMSI applicable to the said (C-S,C-G) 137 o second, the UMH candidates that advertise a PMSI bound to a tunnel 138 that is "down" -- these will thus be used as a last resort to 139 ensure a graceful fallback to the basic mVPN UMH selection 140 procedures in the hypothetical case where a false negative would 141 occur when determining the status of all tunnels 143 The "allowed-SPMSI-only" configuration flag mentioned above is a 144 configuration flag that MUST be provided, that is necessary to allow 145 an upstream PE to use a policy where no I-PMSI is advertized for a 146 said VRF and where only S-PMSI are used, the S-PMSI advertisement 147 being possibly done only after the upstream PE receives a C-multicast 148 route for (C-S, C-G)/(C-*, C-G) to be carried over the advertised 149 S-PMSI. 151 For a said downstream PE and a said VRF, the P-tunnel corresponding 152 to a said upstream PE for a said (C-S,C-G) state is the S-PMSI tunnel 153 advertized by that upstream PE for this (C-S,C-G) and imported into 154 that VRF, or if there isn't any such S-PMSI, the I-PMSI tunnel 155 advertized by that PE and imported into that VRF. 157 3.1. Determining the status of a tunnel 159 Different factors can be considered to determine the "status" of a 160 P-tunnel and are described in the following sub-sections. The 161 procedure proposed here also allows that all downstream PEs don't 162 apply the same rules to define what the status of a P-tunnel is 163 (please see Section 6), and some of them will produce a result that 164 may be different for different downstream PEs. Thus what is called 165 the "status" of a P-tunnel in this section, is not a characteristic 166 of the tunnel in itself, but is the status of the tunnel, *as seen 167 from a particular downstream PE*. 169 Depending on the criteria used to determine the status of a P-tunnel, 170 there may be an interaction with other resiliency mechanism used for 171 the P-tunnel itself, and the UMH update may happen immediately or may 172 need to be delayed. Each particular case is covered in each separate 173 sub-section below. 175 3.1.1. mVPN tunnel root tracking 177 A condition to consider that the status of a P-tunnel is up is that 178 the root of the tunnel, as determined in the PMSI tunnel attribute, 179 is reachable through unicast routing tables. In this case the 180 downstream PE can immediately update its UMH when the reachability 181 condition changes. 183 This is similar to BGP next-hop tracking for VPNv4 routes, except 184 that the address considered is not the BGP next-hop address, but the 185 root address in the PMSI tunnel attribute. 187 If BGP next-hop tracking is done for VPNv4 routes, and the root 188 address of a said tunnel happens to be the same as the next-hop 189 address in the BGP autodiscovery route advertising the tunnel, then 190 this mechanisms may be omitted for this tunnel, as it will not bring 191 any specific benefit. 193 3.1.2. PE-P Upstream link status 195 A condition to consider a tunnel status as up can be that the last- 196 hop link of the P-tunnel is up. 198 In that case, if the PE can determine that there is no fast 199 restoration mechanism (such as MPLS FRR [RFC4090]) in place for the 200 P-tunnel, it can update the UMH immediately. Else, it should wait 201 before updating the UMH, to let the P-tunnel restoration mechanims 202 happen. A configurable timer MUST be provided for this purpose, and 203 it is recommended to provide a reasonable default value for this 204 timer. 206 3.1.3. P2MP RSVP-TE tunnels 208 For P-Tunnels of type P2MP MPLS-TE, the status of the P-Tunnel is 209 considered up if one or more of the P2MP RSVP-TE LSPs, identified by 210 the P-Tunnel Attribute, are in up state. The determination of 211 whether a P2MP RSVP-TE LSP is in up state requires Path and Resv 212 state for the LSP and is based on procedures in [RFC4875]. In this 213 case the downstream PE can immediately update its UMH when the 214 reachability condition changes. 216 When signaling state for a P2MP TE LSP is removed (e.g. if the 217 ingress of the P2MP TE LSP sends a PathTear message) or the P2MP TE 218 LSP changes state from up to down as determined by procedures in 219 [RFC4875], the status of the corresponding P-Tunnel SHOULD be re- 220 evaluated. If the P-Tunnel transitions from up to down state, the 221 upstream PE, that is the ingress of the P-Tunnel, SHOULD not be 222 considered a valid UMH. 224 3.1.4. Leaf-initiated P-tunnels 226 A PE can be removed from the UMH candidate list for a said (S,G) if 227 the P-tunnel for this S,G (I or S , depending) is leaf triggered 228 (PIM, mLDP), but for some reason internal to the protocol the 229 upstream one-hop branch of the tunnel from P to PE cannot be built. 230 In this case the downstream PE can immediately update its UMH when 231 the reachability condition changes. 233 3.1.5. P2MP LSP OAM 235 When a P2MP connectivity verification mechanism such as 236 [I-D.katz-ward-bfd-multipoint] used in conjunction with bootstraping 237 mechanisms described in [I-D.ietf-mpls-mcast-cv] has been setup for a 238 tunnel, the result of the connectivity verification can be used to 239 define the status of the tree. 241 If a MultipointHead session has been established on a P2MP MPLS LSP 242 so that BFD packets are periodically sent from the root toward 243 leaves, a condition to consider the status of corresponding tunnel as 244 up is that the BFD SessionState is Up. 246 When such a procedure is used, in context where fast restoration 247 mechanisms are used for the P-tunnels, downstream PEs should be 248 configured to wait before updating the UMH, to let the P-tunnel 249 restoration mechanims happen. A configurable timer MUST be provided 250 for this purpose, and it is recommended to provide a reasonable 251 default value for this timer. 253 3.1.6. (S,G) counter information 255 In cases, where the downstream node can be configured so that the 256 maximum inter-packet time is known for all the multicast flows mapped 257 on a P-tunnel, the local per-(C-S,C-G) traffic counter information 258 for traffic received on this P-tunnel can be used to determine the 259 status of the P-tunnel. 261 When such a procedure is used, in context where fast restoration 262 mechanisms are used for the P-tunnels, downstream PEs should be 263 configured to wait before updating the UMH, to let the P-tunnel 264 restoration mechanims happen. A configurable timer MUST be provided 265 for this purpose, and it is recommended to provide a reasonable 266 default value for this timer. 268 This method can be applicable for instance when a (S,G) flow is 269 mapped on an S-PMSI. 271 In cases where this mechanism is used in conjunction with Hot leaf 272 standby, then no prior knowledge of the rate of the multicast streams 273 is required ; downstream PEs can compare reception on the two 274 P-tunnels to determine when one of them is down. 276 4. Standby C-multicast route 278 The procedures described below are limited to the case where the site 279 that contains C-S is connected to exactly two PEs. The procedures 280 require all the PEs of that mVPN to follow the single forwarder PE 281 selection, as specified in [I-D.ietf-l3vpn-2547bis-mcast]. The 282 procedures assume that if a site of a given mVPN that contains C-S is 283 dual-homed to two PEs, then all then other sites of that mVPN would 284 have two VPN-IPv4 routes to C-S, each with its own RD. 286 As long as C-S is reachable via both PEs, a said downstream PE will 287 select one of the PEs connected to C-S as its Upstream PE with 288 respect to C-S. We will refer to the other PE connected to C-S as 289 the "Standby Upstream PE". Note that if the connectivity to C-S 290 through the Primary Upstream PE becomes unavailable, then the PE will 291 select the Standby Upstream PE as its Upstream PE with respect to 292 C-S. 294 For readability, in the following sub-sections, the procedures are 295 described for BGP C-multicast Source Tree Join routes, but they apply 296 equally to BGP C-multicast Shared Tree Join routes failover for the 297 case where the customer RP is dual-homed (substitute "C-RP" to 298 "C-S"). 300 4.1. Downstream PE behavior 302 When a (downstream) PE connected to some site of an mVPN needs to 303 send a C-multicast route (C-S, C-G), then following the procedures 304 specified in Section "Originating C-multicast routes by a PE" of 305 [I-D.ietf-l3vpn-2547bis-mcast-bgp] the PE sends the C-multicast route 306 with RT that identifies the Upstream PE selected by the PE 307 originating the route. As long as C-S is reachable via the Primary 308 Upstream PE, the Upstream PE is the Primary Upstream PE. If C-S is 309 reachable only via the Standby Upstream PE, then the Upstream PE is 310 the Standby Upstream PE. 312 If C-S is reachable via both the Primary and the Standby Upstream PE, 313 then in addition to sending the C-multicast route with an RT that 314 identifies the Primary Upstream PE, the PE also originates and sends 315 a C-multicast route with an RT that identifies the Standby Upstream 316 PE. This route is formed so that it carries the semantic of being a 317 'standby' C-multicast route (to be completed in a further revision). 318 . 320 If at some later point the local PE determines that C-S is no longer 321 reachable through the Primary Upstream PE, the Standby Upstream PE 322 becomes the Upstream PE, and the local PE re-sends the C-multicast 323 route with RT that identifies the Standby Upstream PE, except that 324 now the route does not carry the Standby PE BGP Community (which 325 results in replacing the old route with a new route, with the only 326 difference between these routes being the presence/absence of the 327 Standby PE BGP Community). 329 4.2. Upstream PE behavior 331 When a PE receives a C-multicast route for a particular (C-S, C-G), 332 and the RT carried in the route results in importing the route into a 333 particular VRF on the PE, if the route carries the Standby PE BGP 334 Community, then the PE performs as follows: 336 when the PE determines that C-S is not reachable through some 337 other PE, the PE SHOULD install VRF PIM state corresponding to 338 this BGP C-multicast route (the result will be that a PIM Join 339 message will be sent to the CE towards C-S, and that the PE will 340 receive (C-S,C-G) traffic), and the PE SHOULD forward (C-S, C-G) 341 traffic received by the PE to other PEs through a P-tunnel rooted 342 at the PE. 344 Furthermore, irrespective of whether C-S carried in that route is 345 reachable through some other PE: 347 a) based on local policy, as soon as the PE receives this BGP 348 C-multicast route, the PE MAY install VRF PIM state corresponding 349 to this BGP Source Tree Join route (the result will be that Join 350 messages will be sent to the CE toward C-S, and that the PE will 351 receive (C-S,C-G) traffic) 353 b) based on local policy, as soon as the PE receives this BGP 354 C-multicast route, the PE MAY forward (C-S, C-G) traffic to other 355 PEs through a P-tunnel independently of the reachability of C-S 356 through some other PE. [note that this implies also doing (a)] 358 Doing neither (a), nor (b) for a said (C-S,C-G) is called "cold root 359 standby". 361 Doing (a) but not (b) for a said (C-S,C-G) is called "mild root 362 standby". 364 Doing (b) (which implies also doing (a)) for a said (C-S,C-G) is 365 called "hot root standby". 367 4.3. Reachability determination 369 The standby PE can use the following information to determine that 370 C-S can or cannot be reached through the primary PE: 372 o presence/absence of a VPNv4 route toward C-S 374 o supposing that the standby PE is an egress of the tunnel rooted at 375 the Primary PE, the standby PE can determine the reachability of 376 C-S through the Primary PE based on the status of this tunnel, 377 determined thanks to the same criteria as the ones described in 378 Section 3.1 (without using the UMH selection procedures of 379 Section 3) 381 o other mechanisms MAY be used 383 5. Hot leaf standby 385 The mechanisms defined in the two previous section can be used 386 together as follows. 388 The principle is that, for a said VRF (or possibly only for a said 389 C-S,C-G): 391 o downstream PEs advertise a Standby BGP C-multicast route (based on 392 Section 4) 394 o upstream PEs use the "hot standby" optional behavior and thus will 395 forward traffic for a said multicast state as soon as they have 396 whether a (primary) BGP C-multicast route or a Standby BGP 397 C-multicast route for that state (or both) 399 o downstream PEs accept traffic from the primary or standby tunnel, 400 based on the status of the tunnel (based on Section 3) 402 Other combinations of the mechanisms proposed in Section 4) and 403 Section 3 are for further study. 405 6. Duplicate packets 407 Multicast VPN specifications [I-D.ietf-l3vpn-2547bis-mcast] impose 408 that a PE only forwards to CEs the packets coming from the expected 409 usptream PE (Section 9.1). 411 We highlight the reader's attention to the fact that the respect of 412 this part of multicast VPN specifications is especially important 413 when two distinct upstream PEs are succeptible to forward the same 414 traffic on P-tunnels at the same time in steady state. This will be 415 the case when "hot root standby" mode is used (Section 4), and which 416 can also be the case if procedures of Section 3 are used and (a) the 417 rules determining the status of a tree are not the same on two 418 distinct downstream PEs or (b) the rule determining the status of a 419 tree depend on conditions local to a PE (e.g. the PE-P upstream link 420 being up). 422 7. IANA Considerations 424 Allocation is expected from IANA for the BGP "Standby PE" community. 425 (TBC) 427 [Note to RFC Editor: this section may be removed on publication as an 428 RFC.] 430 8. Security Considerations 432 9. Acknowledgements 434 TBC. 436 10. References 438 10.1. Normative References 440 [I-D.ietf-l3vpn-2547bis-mcast] 441 Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 442 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in 443 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-07 (work 444 in progress), July 2008. 446 [I-D.ietf-l3vpn-2547bis-mcast-bgp] 447 Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 448 Encodings and Procedures for Multicast in MPLS/BGP IP 449 VPNs", draft-ietf-l3vpn-2547bis-mcast-bgp-05 (work in 450 progress), June 2008. 452 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 453 Requirement Levels", BCP 14, RFC 2119, March 1997. 455 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 456 "Extensions to Resource Reservation Protocol - Traffic 457 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 458 Switched Paths (LSPs)", RFC 4875, May 2007. 460 10.2. Informative References 462 [I-D.ietf-mpls-mcast-cv] 463 Swallow, G., "Connectivity Verification for Multicast 464 Label Switched Paths", draft-ietf-mpls-mcast-cv-00 (work 465 in progress), April 2007. 467 [I-D.katz-ward-bfd-multipoint] 468 Katz, D. and D. Ward, "BFD for Multipoint Networks", 469 draft-katz-ward-bfd-multipoint-01 (work in progress), 470 January 2008. 472 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 473 Extensions to RSVP-TE for LSP Tunnels", RFC 4090, 474 May 2005. 476 Authors' Addresses 478 Thomas Morin 479 France Telecom - Orange Labs 480 2, avenue Pierre Marzin 481 Lannion 22307 482 France 484 Email: thomas.morin@orange-ftgroup.com 486 Yakov Rekhter 487 Juniper Networks 488 1194 North Mathilda Ave. 489 Sunnyvale, CA 94089 490 U.S.A. 492 Email: yakov@juniper.net 494 Rahul Aggarwal 495 Juniper Networks 496 1194 North Mathilda Ave. 497 Sunnyvale, CA 94089 498 U.S.A. 500 Email: rahul@juniper.net 501 Wim Henderickx 502 Alcatel-Lucent 503 Copernicuslaan 50 504 Antwerp 2018 505 Belgium 507 Email: wim.henderickx@alcatel-lucent.com 509 Praveen Muley 510 Alcatel-Lucent 511 701 East Middlefield Rd 512 Mountain View, CA 94043 513 U.S.A. 515 Email: praveen.muley@alcatel-lucent.com 517 Full Copyright Statement 519 Copyright (C) The IETF Trust (2008). 521 This document is subject to the rights, licenses and restrictions 522 contained in BCP 78, and except as set forth therein, the authors 523 retain all their rights. 525 This document and the information contained herein are provided on an 526 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 527 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 528 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 529 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 530 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 531 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 533 Intellectual Property 535 The IETF takes no position regarding the validity or scope of any 536 Intellectual Property Rights or other rights that might be claimed to 537 pertain to the implementation or use of the technology described in 538 this document or the extent to which any license under such rights 539 might or might not be available; nor does it represent that it has 540 made any independent effort to identify any such rights. Information 541 on the procedures with respect to rights in RFC documents can be 542 found in BCP 78 and BCP 79. 544 Copies of IPR disclosures made to the IETF Secretariat and any 545 assurances of licenses to be made available, or the result of an 546 attempt made to obtain a general license or permission for the use of 547 such proprietary rights by implementers or users of this 548 specification can be obtained from the IETF on-line IPR repository at 549 http://www.ietf.org/ipr. 551 The IETF invites any interested party to bring to its attention any 552 copyrights, patents or patent applications, or other proprietary 553 rights that may cover technology that may be required to implement 554 this standard. Please address the information to the IETF at 555 ietf-ipr@ietf.org.