Dear,
We have posted a updated I-D: draft-li-l1vpn-enhanced-mode-analysis-01.txt for
which your comments are very welcome! The following is the abstract of this
I-D, please check out the attachment for details.
Abstract
This document presents detailed information with respect to the four
sub-models of the Layer One Virtual Private Network (L1VPN) enhanced
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.
Best regards,
Dan Li
Advanced Technology Department
Wireline Networking Business Unit
Huawei Technologies Co., LTD.
Huawei Base, Bantian, Longgang,
Shenzhen 518129 P.R.China
Tel: +86-755-28972910
Fax: +86-755-28972935
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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
Julien Meuric
France Telecom
2, avenue Pierre Marzin
22307 Lannion Cedex
France
Phone: +33 2 96 05 28 28
Email: [EMAIL PROTECTED]
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: [EMAIL PROTECTED]
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
[EMAIL PROTECTED]
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]
_______________________________________________
L1vpn mailing list
L1vpn@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/l1vpn
