Network Working Group Dan Li Internet Draft Qiliang Yi Huawei Julien Meuric France Telecom Lyndon Ong Ciena Category: Informational Expires: August 2007 February, 2007 Analysis of the Enhanced Mode in Layer One Virtual Private Networks (L1VPNs) draft-li-l1vpn-enhanced-mode-analysis-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document presents detailed information with respect to the four sub-models of the Layer One Virtual Private Network (L1VPN) enhanced Li Expires August 2007 [Page 1] draft-li-l1vpn-enhanced-mode-analysis-01.txt February 2007 mode. Each sub-model is evaluated from different points of view, such as Topology Confidentiality, scalability, and reliability. The requirements on GMPLS to support each sub-model of the L1VPN enhanced mode are also discussed in this document. Table of Contents 1. Introduction................................................3 2. Enhanced Mode Overview.......................................3 3. Analysis of the Sub-models...................................4 3.1. Overlay Extension Service Sub-Model.....................4 3.1.1. Topology Confidentiality...........................4 3.1.2. Scalability........................................5 3.1.3. Reliability........................................5 3.1.4. Other Issues.......................................5 3.2. Virtual Node Service Sub-Model..........................6 3.2.1. Topology Confidentiality...........................6 3.2.2. Scalability........................................6 3.2.3. Reliability........................................6 3.2.4. Other Issues.......................................7 3.3. Virtual Link Service Sub-Model..........................7 3.3.1. Topology Confidentiality...........................7 3.3.2. Scalability........................................8 3.3.3. Reliability........................................8 3.3.4. Other Issues.......................................8 3.4. Per-VPN Peer Service Sub-Model..........................9 3.4.1. Topology Confidentiality...........................9 3.4.2. Scalability........................................9 3.4.3. Reliability........................................9 3.4.4. Other Issues......................................10 4. Requirements for GMPLS......................................10 4.1. Overlay Extension Service Sub-Model....................10 4.2. Virtual Node Service Sub-Model.........................11 4.3. Virtual Link Service Sub-Model.........................11 4.4. Per-VPN Peer Service Sub-Model.........................12 5. Security Considerations.....................................13 6. Acknowledgments............................................13 7. References.................................................13 7.1. Normative References...................................13 7.2. Informative References.................................13 8. Author's Addresses.........................................14 9. Full Copyright Statement....................................15 10. Intellectual Property Statement............................15 Li Expires August 2007 [Page 2] draft-li-l1vpn-enhanced-mode-analysis-01.txt February 2007 1. Introduction In [L1VPN-FRMWK] and [L1VPN-APPL], the signaling and routing service model (Enhanced Mode) is introduced for Layer One Virtual Private Networks (L1VPNs). In this service model, the interface between Provider Edge and Customer Edge nodes (the PE-CE interface) exchanges not only signaling information as in the Basic Mode, but also some limited routing information. Four sub-models are described to represent the network depending on how customers perceive the provider network through signaling and routing. The four sub-models of the signaling and routing service model are the Overlay Extension service model, the Virtual Node service model, the Virtual Link service model, and the Per-VPN Peer service model. It would be costly for a device to support all four sub-models, so it is desirable to limit the choice of which sub-model should be supported by an implementation. The motivation of this document is to discuss these sub-models, and make it easy to make the decision. Each sub-model is evaluated from different points of view, such as Topology Confidentiality, scalability, and reliability. The requirements on GMPLS to support each sub-model of L1VPN enhanced mode are also discussed. 2. Enhanced Mode Overview As defined in [L1VPN-FRMWK], the Enhanced Mode has four sub-models which are the Overlay Extension service model, the Virtual Node service model, the Virtual Link service model, the Per-VPN Peer service model. In the Overlay Extension service model, the routing information a CE can receive from a PE is limited to information about the list of CE- PE TE link addresses, and may also include additional information concerning these TE links. The information includes Customer Port Identifier (CPI) and the per-VPN Provider Port Identifier (VPN-PPI) of the remote CE-PE TE links in a VPN, and may contain TE attributes such as the switching type and encoding type of these TE links. In the Virtual Node service model, the VPN backbone is represented as a virtual node, and the customer perceives the VPN backbone as one single node which can be entered and exited by LSPs over CE-PE links in a specific VPN. A CE receives routing information about remote CE- PE links and the customer network (i.e., remote customer sites which may include TE attribute in customer network). Li Expires August 2007 [Page 3] draft-li-l1vpn-enhanced-mode-analysis-01.txt February 2007 In the Virtual Link service model, more routing information is leaked from PE to CE compared with the Virtual Node service mode. This information includes CE-PE links and remote customer sites as in the Virtual Node service model. In addition, the routing information also includes virtual TE links interconnecting PEs in a specific VPN. The Per-VPN Peer service model is the most complicated of the four sub-models, due to the routing information exchanged between CE and PE. Besides the routing information of CE-PE links and remote customer sites, the PE advertises routing information about the partitioned portions of the provider network to the CEs. Such information contains at least one virtual P node which represents one real P-node or a set of P-nodes, and virtual links connecting PEs to the virtual P-nodes. 3. Analysis of the Sub-models Each sub-model is evaluated from the following three aspects: Topology Confidentiality, scalability, and reliability. An additional section presents any other considerations such as manageability and optimality. Topology Confidentiality means whether a sub-model is secure from the service provider's point of view. Namely, the more details of the provider network are exposed to customer the more dangerous (not secure) it will be. Scalability means whether the solution for one sub-model in the single domain scenario can be applied to multi-domain/AS scenario without any changes or with few changes. The size of the routing information is another scaling issue which also should be considered in each sub-model. Reliability represents how each sub-model can improve the availability of the L1VPN service by using the routing information which CE receives from PE. 3.1. Overlay Extension Service Sub-Model 3.1.1. Topology Confidentiality The Overlay Extension service sub-model is the simplest of the four sub-models. The provider network is a black box to the CE, and the CE only receives CE-PE link information from the PE. From the service provider's perspective, this model is the most secure model of the four sub-models because only the VPN-PPI of the PE port associated with each CE in a VPN is disclosed to the customer. Thanks to the Li Expires August 2007 [Page 4] draft-li-l1vpn-enhanced-mode-analysis-01.txt February 2007 character of the VPN-PPI, the CE really knows nothing about provider network. The routing information of provider network is not disclosed to CE. 3.1.2. Scalability In the Overlay Extension service model, because no provider network routing information is leaked to the customer, whether the VPN backbone is composed of a single area, multiple areas, or multiple ASs has no impact on the protocol solutions. Consider this aspect, the scalability of this service sub-model is the best of the four sub-models. In this service model, no provider network routing information is leaked to CEs, only CE-PE TE link routing information is carried through the backbone. The size of such routing information is relatively small, but if the customers needed to form routing adjacency between CEs over CE-CE connections in order to exchange customer site routing information, it may cause up to N-square routing adjacencies between CEs (if a full mesh was aimed at). So in this situation, scalability may become an issue. 3.1.3. Reliability The remote CE-PE TE link information available in this sub-model can help the ingress CE judge whether the remote CE-PE link has enough resources or whether the encoding type matches the local CE-PE link, etc. Also, this information can help in making the choice of route when the remote CE can be reached through more than one remote PE. On the other hand, because the routing information about the customer sites is not exchanged between CEs, the LSPs between two customer devices must be established as in inter-domain context. Thus, in the event of the failure of an LSP connecting two customer devices, the failed LSP sould be rerouted as in case of inter-domain recovery. 3.1.4. Other Issues This service sub-model allows carriers to keep a tight control over their network and to give to the client the minimum amount of information they need to take benefit from the L1VPN service. Consequently, clients do not have a detailed view on the way the backbone routing is done, as it is completely devoted to carriers and is part of the service provided. Li Expires August 2007 [Page 5] draft-li-l1vpn-enhanced-mode-analysis-01.txt February 2007 3.2. Virtual Node Service Sub-Model 3.2.1. Topology Confidentiality As for the Virtual Node service sub-model, the provider network is represented to the CE as a single node. This kind of abstraction makes the provider network relatively secure, because the address of the virtual node disclosed to CE can be set to a value having no relationship to the address space of the provider network. Virtual Node is also sometimes referred to as Abstract Node. In the Virtual Node sub-model, Border Nodes are not visible, being aggregated into a single node. In this case, mapping must be supported between Border Node links/ports and Abstract Node links/ports. As a result the Virtual Node service sub-model provides minimal topology information but requires mapping of abstract node port identifiers to real port identifiers in the general case to avoid duplication of port identifiers at the abstract node. 3.2.2. Scalability How the VPN backbone routing information is represented in a single domain/AS and in multi-domain/AS network may impact the solution details. Thus, in terms of scalability, under this circumstance the Virtual Node service sub-model may not be as good as the Overlay Extension service sub-model. Besides the CE-PE TE link information, the remote customer sites routing information is carried across the backbone. Considering large quantity of remote customer sites information, scalability may become an issue in this service model, and solution should be carefully considered to avoid overload of the core routing protocol. In this service model, the N-square routing adjacency problem mentioned in Overlay Extension sub-model can be avoided because CE receives remote customer sites routing information from PE. 3.2.3. Reliability Compared with the Overlay Extension service sub-model, the benefit of using the Virtual Node service sub-model is that C-to-C LSPs can be established from the head-end C because the customer sites' routing information is available to all CEs in a specific VPN. Hence, in the event of the failure of an LSP connecting two C-nodes, the failed LSP can be rerouted automatically from the C-node in an easier way than in the overlay model, where inter-domain recovery is required to handle failure in any location. Li Expires August 2007 [Page 6] draft-li-l1vpn-enhanced-mode-analysis-01.txt February 2007 3.2.4. Other Issues If a dedicated data plane within the core network is used for a VPN, the Virtual Node service sub-model does not give a detailed view on the actual topology because the whole VPN backbone is represented as a virtual node. When the controller on a C-node or a CE performs a path computation, it will treat the abstract Virtual Node just as any other vertex in the VPN TE topology. This makes such requirement as monitoring alarm and performance of the dedicated resources hard. Further, like in the Overlay Extension sub-model, the customer network cannot exert any influence over the path of the VPN connection through the core network. On the other hand, in a virtual node abstraction, the path computing engine will take it for granted the virtual node can provide an internal path of the required quality between any pair of access ports. But this is not always true since the abstraction may hide limited connectivity within the network. Hence, in a virtual node abstraction it may be necessary to supply additional routing information in the form of the constraints of internal connectivity between any pair access ports. In the context of the Virtual Node service sub-model, the customer assumes connectivity between any pair of PE ports in a specific VPN. This connectivity may not exist, and routing information in the form of the constraints of internal connectivity, between any pair of PE- CE links in the context of a VPN could be provided to solve this problem. Note, however, that the Virtual Node service sub-model has narrower applicability than the general virtual node abstraction. The customer sites are typically connected by a single VPN service provider and each has access to a limited set of PEs. Further, the provider usually contracts to provide VPN connectivity so the customer may be right to assume the connectivity of the virtual node. 3.3. Virtual Link Service Sub-Model 3.3.1. Topology Confidentiality As described in section 2, in the Virtual Link service sub-model, the provider network's routing information is provided to the customer, as a set of virtual links. In order to disclose such information to a CE, a PE needs to advertise the virtual links connecting it with other PEs, thus the addresses of the virtual links must be visible to customer. From the provider's point of view, exposing the real addresses of PEs connected by virtual link reveals some information about the provider's network. In this situation, technique such as address translation may be needed, to keep the provider network Li Expires August 2007 [Page 7] draft-li-l1vpn-enhanced-mode-analysis-01.txt February 2007 secret, but this definitely depends on the trust relationship between a customer and a provider. Virtual Link is also referred to as Abstract link. The virtual links represent "potential" connectivity rather than any specific link in the domain. Various means could be used to determine the associated cost and bandwidth, and typically they would always be in an available state. 3.3.2. Scalability Scalability may become an issue, in the Virtual Link service sub- model. Consider the situation where the VPN backbone is composed of multiple domains or ASes; in this case, the abstraction of topology into a virtual link may differ from the abstraction in a single domain. This may require different routing and signaling protocol solutions. The scalability of the backbone routing protocol should be carefully considered as described in the Virtual Node sub-model. An additional scalability issue introduced by the Virtual Link sub-model is that when the topology of a specific VPN is full-mesh, in the data plane of this VPN, a logical full-mesh topology comprised by virtual links among the corresponding PEs is needed. Thus, the so called N-square problem may arise when PE advertises provider network routing information to Ces, i.e., the number of link advertisements increases by order N-square, where N is the number of PE nodes in the VPN. 3.3.3. Reliability Same as the Virtual Node service sub-model, in Virtual Link service sub-model the reliability of the C-to-C LSP can be improved because the customer knows some routing information of the provider network. 3.3.4. Other Issues The Virtual Link service sub-model is suitable for a dedicated data plane. Depending on the virtual link TE information received, the CE might control in some way how the L1VPN connection traverses the VPN backbone. Also, the customer may monitor the status of the virtual links in this service sub-model. In this service sub-model each PE is viewed by a CE as a separate node when computing path, so the problem that the internal connectivity constraint of the Virtual Node service sub-model is invisible to CEs (discussed above for Virtual Node service model) is more limited in the Virtual Link service sub-model. Nevertheless, some constraints remain when resources towards different PEs are shared. Li Expires August 2007 [Page 8] draft-li-l1vpn-enhanced-mode-analysis-01.txt February 2007 3.4. Per-VPN Peer Service Sub-Model 3.4.1. Topology Confidentiality From the provider's perspective, this service sub-model is the most open of the four sub-models because the largest amount of routing information is advertised to the customer. To keep this service model in a secure mode (i.e., to keep the real addresses of PE and P-nodes invisible to the CE), techniques such as address translation may be required so that the addresses of virtual P-nodes and PEs disclosed to customer have no relationship with the provider network address realm. Again, this definitely depends on the trust relationship between a customer and a provider. Per-VPN Peer is also referred to as a Pseudonode model, due to the potential use of virtual P-nodes in the advertised topology. The Per- VPN Peer sub-model potentially scales better with the number of border nodes (and clients!) although abstraction is more complex. 3.4.2. Scalability Scalability must be carefully considered if this service sub-model is deployed. Because the routing information represented in a single domain may differ from that in multi-domain/AS networks, different solution details may be required. In this service model, the scalability of the backbone routing protocol should be carefully considered as described in the Virtual Node sub-model. As far as the service provider network routing information is concerned, the N-square issue discussed in Virtual Link service model may be avoided in this service model, since PE- nodes may connect through a small number of virtual P nodes rather than a full mesh of virtual links between PE-nodes, but the virtual P nodes should be carefully designed so that the routing information propagated to CEs would be more scalable. 3.4.3. Reliability Depending on the provider network routing information received from a PE, customers can have a relatively strong influence on the resources dedicated to them. For example, a customer can set up diverse paths which traverse different P-nodes, so that there will be less chance of both paths failing at the same time. Li Expires August 2007 [Page 9] draft-li-l1vpn-enhanced-mode-analysis-01.txt February 2007 3.4.4. Other Issues The Per-VPN Peer service sub-model is suitable for a dedicated data plane just as is the Virtual Link service sub-model. But compared with the Virtual Link service sub-model, the provider network exposes more routing information to the customer. By using the routing information about the VPN backbone, customers can have finer control of the resources dedicated to them and can have more visibility of the network resources in cases such as alarm monitoring, performance collection, and path computation, etc. 4. Requirements for GMPLS The functional requirements such as auto-discovery, signaling, and resource management play important roles in the implementation of L1VPN. [L1VPN-BM] describes the possible methods which may be used to implement these functional requirements in the Basic Mode. This section analyzes the application of the functional requirements in each signaling and routing service sub-models, and analyzes the impact may have on a GMPLS-enabled network. 4.1. Overlay Extension Service Sub-Model This service sub-model is like the Overlay service model (Basic Mode), but routing information about CE-PE TE link attributes is also exchanged between CE and PE. Routing protocol-based auto-discovery mechanisms are described in [L1VPN-BGP] and [L1VPN-OSPF], and other mechanisms such as Directory Server based auto-discovery have also been discussed. In the Overlay Extension service sub-model, routing extensions are required to describe the CE-PE TE link information, and the mechanisms described for auto-discovery can easily be used to satisfy the routing requirements of this sub-model. In Overlay Extension service sub-model, any routing protocols can be chosen between CEs. As far as signaling is concerned, the Overlay Extension service sub- model is identical to the Basic Mode Overlay service model, and Shuffling or Nesting/Stitching described in [L1VPN-BM] can be used. The Overlay Extension service model is suitable for a shared or dedicated data plane. With a shared data plane a resource management function is not necessary, but with a dedicated data plane a resource management function is required to allocate provider network link resources to a specific VPN or to a specific set of VPNs. The method of allocation of link resources may be through manual configuration or signaling. From the provider's point of view, manual configuration Li Expires August 2007 [Page 10] draft-li-l1vpn-enhanced-mode-analysis-01.txt February 2007 may be time consuming, error-prone, and means high operational expenditure. So if the link resources can be allocated in an automatic way (for example, using signaling), it may help providers to reduce their operational costs. 4.2. Virtual Node Service Sub-Model In the Virtual Node service sub-model the provider network is presented as a virtual node to the customer. The routing information about CE-PE TE link attributes and customer site routing information is advertised from PE to CE. Routing protocols can be extended to support CE-PE TE link information advertisement. Because the customer site routing information is exchanged between CE and PE, the CE-PE routing protocol is restricted to the one that the provider network supports. The above mentioned core routing techniques can be extended to exchange customer site routing information, but considering the large quantity of customer site information the core routing protocols may be overloaded especially when the TE routing information of customer sites is also exchanged. Under such circumstances an LSP (which may be an LSP established on Layer 3) may be established between PE sites to carry the customer site TE routing protocol information exchanges across the provider network. Such LSPs can be automatically established as part of the auto-dsicovery process and can be used to provide control plane connectivity between CEs. This approach may also be applied to the Virtual Link and Per-VPN Peer service sub- models. A shared or dedicated data plane can be deployed in the Virtual Node service sub-model. At the same time, manual or automatic resource management methods described in section 4.1 can be used to achieve the requirement. Shuffling or Nesting/Stitching described in [L1VPN-BM] can be used to achieve the Virtual Node service sub-model. 4.3. Virtual Link Service Sub-Model In the Virtual Link service sub-model, virtual links are constructed between PEs, and the CE receives information about the CE-PE TE links, customer site routing information, and information about the virtual links between PEs. Same as the Virtual Node service sub-model, the CE-PE routing protocol is restricted to the one that the provider network supports. Li Expires August 2007 [Page 11] draft-li-l1vpn-enhanced-mode-analysis-01.txt February 2007 To keep the provider network secure, the virtual links disclosed to the CE should not contain the real address within the provider network, so a technique to hide them is needed in this case. To be more precise, when advertising virtual link information to the CE, the addresses of PEs interconnected by the virtual links may be translated into private addresses or the virtualization process should be able to turn a set of actual addresses to a (possibly smaller) set of virtual address. 4.4. Per-VPN Peer Service Sub-Model The Per-VPN Peer service sub-model is more complex than the Virtual Link service sub-model. Besides receiving information about CE-PE TE links and customer site routing information, the CE receives abstract VPN backbone routing information advertised from PE. The abstract VPN backbone routing information is the partitioned subset of the provider network that contains at least one virtual P-node and virtual links connecting virtual P-nodes and PEs. Same as the Virtual Node service sub-model, the CE-PE routing protocol is restricted to the one that the provider network supports. How to represent the virtual provider network topology becomes an issue when advertising the abstract routing information to the CE,. To keep the provider network secure, address masking may be needed in this service sub-model. Before advertising the virtual topology to the CEs using routing protocols, it is required to build this virtual view including the routing information about virtual P-nodes and virtual links interconnecting the virtual P-nodes and PEs. In the Per-VPN Peer service sub-model, the application of resource management is the same as in the Virtual Link service sub-model. Manual or automatic resource allocation methods can be applied to this service sub-model. Depending on the abstract routing information the CE may designate an Explicit Route object (ERO) with an abstract route through the VPN backbone and use this to signal the L1VPN connection LSP. When the PE receives this ERO it must translate the abstract route into a real route through the provider network. In this case, a "devirtualization" mechanism to expand and translate the ERO may be required. On the other hand, when a Record Route object (RRO) is requested, the RRO passed to the CE must be re-translated into an abstract route. So new applicability to current signaling protocol may be needed. Li Expires August 2007 [Page 12] draft-li-l1vpn-enhanced-mode-analysis-01.txt February 2007 5. IANA Considerations None. 6. Security Considerations Security issue for the four Extended Mode sub-models which we mostly focus on is Topology Confidentiality, that is described in separate sub-sections of Section 3. 7. Acknowledgments We would like to thank Adrian Farrel for his useful comments. 8. References 8.1. Normative References [L1VPN-FRMWK] Tomonori Takeda, et al., "Framework and Requirements for Layer 1 Virtual Private Networks", draft-ietf-l1vpn- framework-04.txt, September 2006. [L1VPN-APPL] Tomonori Takeda "Applicability analysis of Generalized Multiprotocol Label Switching (GMPLS) protocols to Layer 1 Virtual Private Networks", draft-ietf-l1vpn-applicability- 01.txt, March 2006. 8.2. Informative References [L1VPN-BM] Fedyk, D., Rekhter, Y. (Eds.), "Layer 1 VPN Basic Mode", draft-ietf-l1vpn-basic-mode-00.txt, May 2006. [L1VPN-BGP] Ould-Brahim H., Fedyk D., Rekhter, Y., "BGP-based Auto- Discovery for L1VPNs ", draft-ietf-l1vpn-bgp-auto-discovery- 00.txt, May 2006. [L1VPN-OSPF] Igor Bryskin, Lou Berger, "OSPF Based L1VPN Auto-Discovery", draft-ietf-l1vpn-ospf-auto-discovery-00.txt, May 2006. Li Expires August 2007 [Page 13] draft-li-l1vpn-enhanced-mode-analysis-01.txt February 2007 9. Author's Addresses Qiliang Yi Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972913 Email: yiqiliang@huawei.com Jianhua Gao Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972902 Email: gjhhit@huawei.com Dan Li Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base, Bantian, Longgang District Shenzhen 518129 P.R.China Phone: +86-755-28972910 Email: danli@huawei.com Julien Meuric France Telecom 2, avenue Pierre Marzin 22307 Lannion Cedex France Phone: +33 2 96 05 28 28 Email: julien.meuric@orange-ftgroup.com Lyndon Ong Ciena PO Box 308 Cupertino, CA 95015 United States of America Li Expires August 2007 [Page 14] draft-li-l1vpn-enhanced-mode-analysis-01.txt February 2007 Phone: +1 408 962 4929 Email: lyong@ciena.com 10. Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 11. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Li Expires August 2007 [Page 15] draft-li-l1vpn-enhanced-mode-analysis-01.txt February 2007 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". Li Expires August 2007 [Page 16]