idnits 2.17.1 draft-stein-ldp-auto-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 486. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 463. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 476. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 272: '... The unknown bit MUST be cleared. If ...' RFC 2119 keyword, line 277: '... bit is not used, and MUST be cleared....' RFC 2119 keyword, line 278: '...bits) This field MUST be set to whatev...' RFC 2119 keyword, line 296: '...ion message used MUST be of the Genera...' RFC 2119 keyword, line 385: '...ivate service, the provider MUST check...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (July 10, 2005) is 6864 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) == Missing Reference: 'VPN-ID' is mentioned on line 217, but not defined == Missing Reference: 'RADIUS' is mentioned on line 222, but not defined == Unused Reference: 'LDP' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'MPLS' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'VPNID' is defined on line 415, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-pwe3-ethernet-encap-08 ** Obsolete normative reference: RFC 3036 (ref. 'LDP') (Obsoleted by RFC 5036) == Outdated reference: A later version (-17) exists of draft-ietf-pwe3-control-protocol-16 -- No information found for draft-ietf-l2vpn-vpls-ldp-0n - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'VPLS-LDP' == Outdated reference: A later version (-09) exists of draft-ietf-l3vpn-bgpvpn-auto-05 -- No information found for draft-ietf-l2vpn-l2tp-radius - is the name correct? -- No information found for draft-ietf-l2vpn-vpls-bgp-0n - is the name correct? Summary: 5 errors (**), 0 flaws (~~), 10 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L2VPN Working Group Y(J). Stein 3 Internet-Draft RAD Data Communications 4 Expires: January 11, 2006 S. Delord 5 France Telecom 6 July 10, 2005 8 LDP-based Autodiscovery for L2 Services 9 draft-stein-ldp-auto-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 11, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 Current L2VPN implementations that use LDP for label binding require 43 another protocol to dynamically detect which PEs belong to a given 44 VPN. We herein propose a simple extension to LDP consisting of a 45 message with which a PE announces its desire to join an existing VPN. 46 The technique is equally applicable to HVPLS, multisegment VPLS and 47 VPWS, and may be especially attractive for access networks employing 48 MPLS. 50 1. Introduction 52 VPLS networks based on LDP signaling, as described in [VPLS-LDP], 53 transparently interconnect N physically separated LANs belonging to a 54 single customer. VPLS provides this multipoint to multipoint service 55 based on a full mesh of Ethernet PWs [ETHERNET-PW]. We shall call 56 each multipoint to multipoint network a VPLS instance or simply a 57 VPN. 59 In the following we assume a service provider network, consisting of 60 PE (provider edge) and P (provider) LSRs. The PEs must be VPLS- 61 capable, i.e. they must be able to perform all the functionality 62 described in [VPLS-LDP], including setting up of Ethernet PWs, 63 encapsulating and properly forwarding incoming Ethernet frames, and 64 802.1D learning. The PE LSRs are connected to CE (customer edge) 65 devices in the customer network, which may be Ethernet switches or IP 66 routers. The connection between PE and CE is called the attachment 67 circuit (AC). 69 Before offering VPLS services the service provider must provision a 70 full mesh MPLS tunnels connecting all PEs; this being accomplished by 71 manual configuration, BGP, RSVP-TE or LDP. Each VPLS instance 72 defines a subset of the PEs, namely those connected to CEs that 73 require the VPLS service. We shall call this subset of PEs the Vset. 74 The VPLS service is implemented by means of Ethernet PWs inside the 75 MPLS tunnels that we have assumed to connect every pair of PEs in the 76 Vset. These PWs may be set up manually, or by using the LDP 77 extensions defined in the PWE control protocol [PWE-CONTROL]. 79 When a PE, not originally in the Vset wants to join the VPN, new 80 Ethernet PWs must be set up between it and all the PEs already in the 81 Vset. The act of joining a VPLS instance conceptually consists of 82 two parts, namely discovering the Vset, and thereafter setting up 83 (e.g. by using the PWE control protocol) PWs to all PEs in the Vset. 84 Assuming an efficient mechanism for Vset discovery, the entire VPLS 85 instance may be built iteratively by growing the Vset, starting with 86 a single PE being told that it is in the Vset for the new VPLS 87 instance. 89 Vset discovery may be explicit or implicit. With explicit Vset 90 discovery, PEn determines that PE1 through PE(n-1) are in the Vset, 91 and joins by setting up n-1 Ethernet PWs. With implicit Vset 92 discovery PEn announces to all VPLS-capable PEs that it wishes to 93 join the particular VPLS instance, and PEs already in the Vset 94 initiate the PW setup. We adopt here the implicit method as it 95 minimizes the amount of messaging traffic, and is conceptually more 96 compatible with MPLS downstream label distribution procedures. 97 Rather than trying to directly locate participating PEs (e.g. by 98 requiring all PEs to periodically advertise the list of VPNs they 99 handle), it makes sense for the PE desiring to join the VPN to 100 advertise this fact to all the other PEs, permitting them to respond 101 when they belong to the VPN. This method minimizes overhead and 102 shortens the time it takes until all PEs know of the new VPN member. 104 The discovery of the Vset of an extant VPLS instance is not the only 105 autodiscovery problem involved in provisioning networks capable of 106 providing VPLS services. The VPLS-capable PEs must a priori know 107 each other in order to set up the initial set of MPLS tunnels, and 108 the PE must recognize CEs in order to set up the attachment circuits. 109 However, we contend that the Vset discovery problem is of a different 110 nature than the others. The number of PEs in a network is relatively 111 limited and static, and in most cases autodiscovery protocols already 112 exist for this problem. Provisioning of new attachment circuits is 113 also relatively rare, and will often require management intervention. 114 On the other hand the adding of a LAN to an existing VPN is expected 115 to be much more prevalent. Since a large number of PEs may be 116 involved in any particular VPN, manual configuration of the VPLS is 117 logistically difficult and error-prone. Scalability requires an 118 autodiscovery protocol for this task, and several such mechanisms 119 exist, for example in BGP [BGP-AUTO] and extensions to RADIUS 120 [RADIUS-AUTO]. 122 The autodiscovery protocol described here is limited to the problem 123 of discovering the Vset. We always assume that attachment circuits 124 are in place, and that there is some method to inform the PE that a 125 given CE needs to join a given VPLS, and for the PE to authenticate 126 this request. For the simplest case we further assume that MPLS 127 tunnels capable of supporting Ethernet PWs have been preprovisioned 128 between every two PEs in the provider network, and that LDP sessions 129 are already running between every pair of PEs. For more complex 130 cases, e.g. HVPLS and multisegment VPLS, we assume that the 131 existence of MPLS tunnels and LDP sessions between the end PEs and 132 the stitching nodes. 134 As we deal solely with Vset discovery, the actual setting up of PWs 135 is beyond our scope. This setting up of Ethernet PWs trivially 136 follows for the simple case, but the PW placement problem may be 137 complex for other cases. For example, for HVPLS with MPLS-based 138 spoke PWs, the MTUs that aggregate Ethernet traffic from several 139 customers originate the request for Vset discovery, but as they are 140 directly aware of only one PE, the discovery messaging must be 141 forwarded by that PE to the others with which it is fully 142 interconnected. 144 Another case of interest is multisegment VPLS, which we define as a 145 VPN whose Vset consists of PEs in multiple independently managed 146 domains, and thus requires multisegment PWs [MSPWs]. Here there will 147 be S-PEs that straddle the various domains, and our autodiscovery 148 mechanism will need to traverse these S-PEs as the PEs in distinct 149 domains are not linked by LDP sessions. Note that since our 150 mechanism is limited to Vset discovery, it is sufficient for our 151 purposes for a PE to know of a single S-PE enabling access to each 152 foreign domain, and this S-PE will not necessarily be that which is 153 eventually traversed by the PW. 155 The present document proposes a simple Vset autodiscovery mechanism 156 that requires only the extension of the LDP protocol that has been 157 assumed to already be running between the PEs. The method proposed 158 is distributed and does not require a central server holding VPLS 159 member information. Rather than querying all VPLS-capable PEs to 160 determine whether they belong to the Vset, each PE desiring to join a 161 VPLS instance announces this by a new JOIN TLV, and receiving PEs 162 that belong to the Vset respond by setting up the required PWs. In 163 Section 2 we discuss why this method is most suitable for access 164 networks; in Section 3 we motivate the use of human readable VPN 165 identifiers; in Section 4 we detail the required extensions to LDP; 166 Section 5 extends the discussion to more complex cases; and in 167 Section 6 we briefly cover the security considerations. 169 2. Access Networks 171 The autodiscovery method described herein may be particularly 172 suitable for access networks. Core networks will typically be 173 running BGP-4, and thus have at their disposal the autodiscovery 174 mechanisms described in [VPLS-BGP]. In addition the core network may 175 already be providing L3VPN services, and thus already utilizing BGP- 176 based autodiscovery mechanisms. 178 However, in the case of access networks, such a protocol will 179 frequently not be available to the service provider or not be 180 completely suitable, and this for at least two reasons. 182 First, the processing power of access network forwarding devices may 183 be quite limited as compared to backbone routers. This is due to the 184 fact that the total number of devices is significantly greater in the 185 access/metro segment than in the core network. Typically DSLAMs 186 represent several thousand devices, and so need to be as simple as 187 possible to keep the global network complexity (and cost) low. 189 Second, the topology of an access network may also be much simpler 190 than the topology of a backbone network. For example, it is quite 191 common to have a DSLAM with only a single physical attachment, (or 192 perhaps a dual physical attachment for redundancy) to the metro/ 193 backbone area. Such DSLAMs may not even run an IGP and employ only 194 static routes in order to avoid CPU overload. 196 Despite these constraints, advanced services, such as interconnecting 197 two endpoints located on the same or different access networks (e.g. 198 two DSLAMs that do not belong to the same geographical area) are 199 still required by the service provider. Solutions such as [MSPWs] 200 allow the total number of PWs to grow without impacting the control 201 plane, by limiting the number of targeted LDP sessions between the 202 U-PEs to only a few S-PEs. However such solutions at present still 203 require BGP or RADIUS for the auto-discovery process, in addition to 204 LDP for setting up of the PWs. 206 Our proposal extends LDP with new TLVs thus enabling auto-discovery 207 in the access network without requiring burdening down the access 208 network forwarding devices with additional protocols. The TLVs reuse 209 the endpoint identifiers defined in [PWE-CONTROL]. This same LDP- 210 based autodiscovery method may be used in the core network, but 211 alternatively the core network may employ [BGP-AUTO]. 213 3. Importance of unique and meaningful VPN identifiers 215 According to [VPLS-LDP] each VPLS instance must be assigned a 216 globally unique identifier, a VPNID. This identifier is often 217 numeric, for example, a 7-byte VPN Identifier per RFC 2685 [VPN-ID]. 219 A useful format for the VPN identifier used for the purpose of 220 autodiscovery is a human readable name in URL-like format. This 221 suggestion has been made in this context before, and is realized in 222 the VPN identifier record used in RADIUS discovery [RADIUS]. Such an 223 identifier minimizes the chance of accidental overlap with other 224 VPNIDs, and eliminates the need for maintaining a network-wide 225 directory of VPNIDs. 227 On the other hand, for the purpose of setting up the Ethernet PWs 228 comprising the VPLS, an AGI is required. According to [PWE-CONTROL], 229 the AGI may be of arbitrary format, and 230 "The details of how to construct the AGI and AII fields 231 identifying the pseudowire endpoints are outside the scope of this 232 specification. Different pseudowire application, and different 233 provisioning models, will require different sorts of AGI and AII 234 fields. The specification of each such application and/or model 235 must include the rules for constructing the AGI and AII fields." 237 When possible the AGI should be simply be the URL-like VPNID herein 238 described. When this is not possible, for example, when a RFC 2685 239 VPN-ID is needed, a mechanism must be provided to translate the URL 240 to the requisite format. 242 4. LDP extensions 244 In the standard model, a full mesh of LDP sessions is already running 245 between all PEs that may wish to join the VPN. In the multisegment 246 case, we assume LDP sessions between the U-PE and related S-PEs. It 247 is over these LDP sessions regulating the MPLS transport tunnels that 248 the new TLVs are advertised. 250 When a PE needs to add a CE to a VPN, it first consults a table to 251 determine whether it is already participating in this VPLS instance 252 for some other CE. If it does, then all that needs to be done is to 253 connect the new CE to the existing bridge function and Ethernet PWs. 254 If it does not, the joining PE must first allocate a bridge function 255 to perform the 802.1 functionality and to add the VPNID to the table 256 of VPNs in which it participates. Next, it sends an LDP message 257 containing a VPN JOIN TLV to all the PEs with which it maintains LDP 258 sessions. This TLV has the following format. 260 0 1 2 3 261 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 |U|F| JOIN Type | Length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | AGI Type | Length | AGI Value 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 AGI Value (contd.) | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Optional VPN Parameters | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 U (1 bit) The unknown bit MUST be cleared. If the VPN join format 273 is not understood, the sending PE must be informed that its 274 attempt to join has been ignored. In this case an alternative 275 mechanism must be employed to determine whether the remote PE 276 participates in the VPN. 277 F (1 bit) The forwarding bit is not used, and MUST be cleared. 278 Type (14 bits) This field MUST be set to whatever value is assigned 279 by IANA for this purpose. 280 Length (16 bits) This field specifies the total length of the VPLS 281 identifier in bytes. 282 AGI TLV Attachment Group Identifier TLV per [PWE-CONTROL]. 283 Optional VPN Parameters These optional TLVs may have to be specified 284 for proper or optimal operation of the service. 286 When a PE needs to join a VPLS instance, it sends the JOIN TLV to all 287 VPLS-capable PEs to which it is connected. The JOIN TLV is similar 288 to a label REQUEST, but the corresponding label mapping is contingent 289 on the receiving PE belonging to the VPLS. However, the JOIN TLV 290 does not specify a FEC, rather it specifies a VPNID. 292 When a PE receives a JOIN message it checks the VPNIDs of all the 293 VPLS instances to which it belongs. If it finds a match it adds the 294 joining PE to the VPN-PE table, allocates a PW label, and distributes 295 this label to the sending PE via the LDP-based PW signaling protocol. 296 The label distribution message used MUST be of the Generalized PW ID 297 FEC Element (FEC type 129), with AGI set equal to the VPNID specified 298 in the JOIN message, and SAII and TAII set to zero. AIIs are not 299 needed for VPLS since packets received at the PE with the label 300 mapped to the VPLS instance, since the Ethernet frame is sent to a 301 bridging function that decides to which CE the frame needs to be 302 forwarded. 304 Once the PE that had sent the JOIN message receives the mapping 305 message with an AGI matching the VPNID, it adds the remote PE to its 306 VPN-PE table, allocates and sends back a PW label using the 307 Generalized PW ID FEC Element. This process is repeated for all PEs 308 in the VPN. 310 When a PE needs to leave a VPLS instance, it sends the LEAVE TLV to 311 all PEs to which it is connected that participate in the given VPN. 312 The format of the TLV is identical to the JOIN format, except for the 313 TYPE value, and not having any optional parameters. LEAVE messages 314 are similar to label RELEASE, but specifies a VPNID instead of a FEC. 316 When a PE receives a LEAVE message it checks the VPNIDs of all the 317 VPLS instances to which it belongs. If it finds a match, it frees 318 the corresponding PW label and sends a label WITHDRAWAL message. 320 5. Other Cases 322 The previous section dealt with signaling required for autodiscovery 323 and setting up of PWs for the simple VPLS case. In this section we 324 will extend this treatment to other cases, namely HVPLS [VPLS-LDP], 325 multisegment VPLS based on multisegment PWs [MSPWs], and VPWS. 327 In the HVPLS case the MTU originates the JOIN and LEAVE messages, but 328 it can send these only to the PE to which it is connected. The PE, 329 upon receiving a JOIN request, performs any authentication that is 330 required, and then notes the MTU's VPN participation in a VPN-MTU 331 table. It then forwards the JOIN request to all the PEs with which 332 it maintains LDP sessions. A PE receiving such a request checks its 333 VPN-MTU tables for membership, and if finding that its participation 334 is required adds the originating PE to its VPN-PE table, and send a 335 label mapping message back. Note that it does not need to inform 336 attached MTUs of the new association, as this will be automatically 337 learned by the bridging function. If BGP is running between the PEs, 338 then [BGP-AUTO] could also be used. 340 When the originating PE receives a label mapping with AGI indicating 341 that it is in response to the previously sent JOIN, it adds the 342 remote PE to its VPN-PE table, and returns a label mapping message 343 with the same AGI to set up the other direction. 345 For the multisegment case the S-PE is required to forward JOIN 346 messages between the two segments (in both directions). The 347 assumption here is that LDP sessions are already running between the 348 U-PEs and their related S-PEs. Although there may be many S-PEs 349 between a pair of domains, it is sufficient for a single S-PE to be 350 designated as the point of contact between each pair of domains for 351 the purpose of autodiscovery. When a PE in one domain wants to join 352 a VPLS that extends over multiple domains, it sends JOIN messages 353 with a globally unique VPNID to all VPLS-capable PEs in its domain, 354 and to all S-PEs. The S-PEs forward the JOIN messages in their 355 respective domains. A receiving PE in the same domain as the 356 originating PE sends its label mapping back to the originating PE. A 357 PE in a different domain sends its label mapping to an S-PE, using 358 whatever mechanism is selected by the PWE3 WG for multisegment PW 359 setup. If BGP is running between the PEs, then [BGP-AUTO] could also 360 be used. 362 Although the scalability problem is less for VPWS, it may be 363 necessary to use the mechanism described herein in order to set up a 364 large number of point to point PWs. We shall deal solely with the 365 single segment case, although a similar method is applicable VPWS 366 based on MS-PWs. 368 When the PW can be uniquely identified by a 32-bit identifier, it is 369 sufficient to use the PWid FEC Element; the problem arises when we 370 wish to use a meaningful VPNID. In this case either side can send a 371 JOIN message containing the VPNID as AGI and an AII indication as an 372 optional parameter to all relevant PEs. The PE receiving the JOIN 373 which itself wishes to be part of that PW returns a generalized PW ID 374 label mapping with the VPNID as AGI, SAII as locally identified, and 375 TAII as received in the JOIN message. 377 6. Security Considerations 379 Security mechanisms are important for all automatic admission 380 mechanisms, and for VPNs the issues of security are paramount. The 381 responsibility for admission into a VPN rests with the service 382 provider, as this security is an integral part of the "private 383 service" being offered. 385 In order to provide a pseudo-private service, the provider MUST check 386 the authorization of any request to join a VPN, and MUST ensure that 387 the packets are only delivered to the proper remote CE. 389 By using manual provisioning of the CE-PE portion of the VPN the 390 first component of the joining can be made relatively safe. 391 Mechanization of the PE to PE connection component eliminates errors, 392 and thus mitigates security problems of the second type. 394 It is recommended that LDP authentication methods be utilized to 395 deter unauthorized parties joining a VPLS instance. 397 7. IANA Considerations 399 In order to implement the LDP extensions defined here, we will need 400 two new LDP types, one for the VPN JOIN and one for the VPN LEAVE 401 TLV. 403 8. References 405 8.1 Normative References 406 [ETHERNET-PW] "Encapsulation Methods for Transport of Ethernet Frames 407 Over IP/MPLS Networks", September 2004, 408 draft-ietf-pwe3-ethernet-encap-08.txt (Work In Progress) 409 [LDP] Andersson, et al., "LDP Specification", RFC 3036 410 [MPLS] RFC 3032 "MPLS Label Stack Encoding" 411 [PWE-CONTROL] "Pseudowire Setup and Maintenance using LDP", March 412 2005, draft-ietf-pwe3-control-protocol-16.txt (Work In Progress) 413 [VPLS-LDP] "Virtual Private LAN Services over MPLS", Month 200x, 414 draft-ietf-l2vpn-vpls-ldp-0n.txt (Work In Progress) 415 [VPNID] RFC 2685 "Virtual Private Networks Identifier", September 416 1999 418 8.2 Informative References 419 [BGP-AUTO] "Using BGP as an Auto-Discovery Mechanism for Network- 420 based VPNs", draft-ietf-l3vpn-bgpvpn-auto-05.txt (Work In 421 Progress) 422 [MSPWs] "Pseudo Wire Switching", 423 draft-martini-pwe3-pw-switching-03.txt (Work In Progress) 424 [RADIUS-AUTO] "Radius/L2TP Based VPLS", 425 draft-ietf-l2vpn-l2tp-radius-00.txt (Work In Progress) 426 [VPLS-BGP] "Virtual Private LAN Service", Month 200x, 427 draft-ietf-l2vpn-vpls-bgp-0n.txt (Work In Progress) 429 9. Acknowledgments 431 The authors would like to thank Yuri Gittik and Philippe Niger for 432 interesting discussions and valuable contributions to the work herein 433 presented. 435 Authors' Addresses 437 Yaakov (J) Stein 438 RAD Data Communications 439 24 Raoul Wallenberg St., Bldg C 440 Tel Aviv 69719 441 ISRAEL 443 Phone: +972 3 645-5389 444 Email: yaakov_s@rad.com 446 Simon Delord 447 France Telecom 448 2 av. Pierre Marzin 449 Lannion 22300 450 FRANCE 452 Email: simon.delord@francetelecom.com 454 Intellectual Property Statement 456 The IETF takes no position regarding the validity or scope of any 457 Intellectual Property Rights or other rights that might be claimed to 458 pertain to the implementation or use of the technology described in 459 this document or the extent to which any license under such rights 460 might or might not be available; nor does it represent that it has 461 made any independent effort to identify any such rights. Information 462 on the procedures with respect to rights in RFC documents can be 463 found in BCP 78 and BCP 79. 465 Copies of IPR disclosures made to the IETF Secretariat and any 466 assurances of licenses to be made available, or the result of an 467 attempt made to obtain a general license or permission for the use of 468 such proprietary rights by implementers or users of this 469 specification can be obtained from the IETF on-line IPR repository at 470 http://www.ietf.org/ipr. 472 The IETF invites any interested party to bring to its attention any 473 copyrights, patents or patent applications, or other proprietary 474 rights that may cover technology that may be required to implement 475 this standard. Please address the information to the IETF at 476 ietf-ipr@ietf.org. 478 Disclaimer of Validity 480 This document and the information contained herein are provided on an 481 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 482 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 483 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 484 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 485 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 486 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 488 Copyright Statement 490 Copyright (C) The Internet Society (2005). This document is subject 491 to the rights, licenses and restrictions contained in BCP 78, and 492 except as set forth therein, the authors retain all their rights. 494 Acknowledgment 496 Funding for the RFC Editor function is currently provided by the 497 Internet Society.