draft-ietf-l2vpn-oam-req-frmk-02.txt   draft-ietf-l2vpn-oam-req-frmk-03.txt 
Internet Draft Document Dinesh Mohan (Editor) Internet Draft Document Dinesh Mohan (Editor)
Internet Draft Nortel Internet Draft Nortel
Expires: August 2005 Ali Sajassi (Editor) Expires: January 2006 Ali Sajassi (Editor)
Cisco Systems Cisco Systems
February 2005 July 2005
L2VPN OAM Requirements and Framework L2VPN OAM Requirements and Framework
draft-ietf-l2vpn-oam-req-frmk-02.txt draft-ietf-l2vpn-oam-req-frmk-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, we represent that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which we are aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
or will be disclosed, and any of which we are aware have been or will have been or will be disclosed, and any of which he or she becomes
be disclosed, and any of which we become aware will be disclosed in aware will be disclosed, in accordance with Section 6 of BCP 79.
accordance with RFC 3668.
This document is an Internet-Draft and is in full conformance with
Sections 5 and 6 of RFC 3667 and Section 5 of RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract Abstract
This draft provides framework and requirements for Virtual Private
LAN Service (VPLS) Operation, Administration and Maintenance (OAM).
Conventions This draft provides framework and requirements for Layer 2 Virtual
Private Networks (L2VPN) Operation, Administration and Maintenance
(OAM). The OAM framework is intended to provide OAM layering across
L2VPN services, Pseudo Wires (PWs) and Public Switched Network (PSN)
tunnels. The requirements are intended to identify OAM requirement
for L2VPN services (i.e. VPLS, VPWS, and IPLS). Furthermore, if
L2VPN services OAM requirements impose specific requirements on PW
OAM and/or PSN OAM, those specific PW and/or PSN OAM requirements
are also identified.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 document are to be interpreted as described in RFC 2119
RELATED DOCUMENTS
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-l2-framework-
05.txt
http://www.ietf.org/internet-drafts/draft-ietf-l2vpn-requirements-
03.txt
Table of Contents Table of Contents
Status of this Memo................................................1 Status of this Memo................................................1
Copyright Notice...................................................1
Abstract...........................................................1 Abstract...........................................................1
Conventions........................................................1 Conventions used in this document..................................2
1. Introduction....................................................3 1. Introduction....................................................3
2. L2VPN Services & Networks.......................................4 2. L2VPN Services & Networks.......................................4
3. L2VPN OAM Framework.............................................5 3. L2VPN OAM Framework.............................................6
3.1. OAM Layering..................................................5 3.1. OAM Layering..................................................6
3.2. OAM Domains...................................................6 3.2. OAM Domains...................................................6
3.3. MEPs and MIPs.................................................6 3.3. MEPs and MIPs.................................................7
3.4. MEP and MIP Identifiers.......................................7 3.4. MEP and MIP Identifiers.......................................7
3.5. OAM Framework for VPLS........................................7 3.5. OAM Framework for VPLS........................................7
3.5.1. VPLS as Bridged LAN Service.................................7 3.5.1. VPLS as Bridged LAN Service.................................8
3.5.2. VPLS as a Network...........................................8 3.5.2. VPLS as a Network...........................................8
3.5.3. VPLS as LAN/VLAN Emulation..................................8 3.5.3. VPLS as (V)LAN Emulation....................................8
3.5.4. VPLS OAM Layering...........................................9 3.5.4. VPLS OAM Layering...........................................9
3.5.5. VPLS OAM Domains............................................9 3.5.5. VPLS OAM Domains...........................................10
3.5.6. VPLS MEPs & MIPs...........................................10 3.5.6. VPLS MEPs & MIPs...........................................10
3.5.7. VPLS MEP and MIP Identifiers...............................11 3.5.7. VPLS MEP and MIP Identifiers...............................11
3.6. OAM Framework for VPWS.......................................11 3.6. OAM Framework for VPWS.......................................12
3.7. OAM Framework for IPLS.......................................11 3.7. OAM Framework for IPLS.......................................12
4. L2VPN OAM Requirements.........................................11 4. L2VPN Services OAM Requirements................................12
4.1. VPLS OAM Requirements........................................11 4.1. VPLS Service OAM Requirements................................12
4.1.1. Discovery..................................................11 4.1.1. Discovery..................................................12
4.1.2. Connectivity Fault Management..............................11 4.1.2. Connectivity Fault Management..............................12
4.1.3. Connectivity Fault Detection...............................12 4.1.3. Connectivity Fault Detection...............................12
4.1.4. Connectivity Fault Verification............................12 4.1.4. Connectivity Fault Verification............................12
4.1.5. Connectivity Fault Localization............................12 4.1.5. Connectivity Fault Localization............................13
4.1.6. Connectivity Fault Alarm...................................12 4.1.6. Connectivity Fault Alarm...................................13
4.1.7. Frame Loss.................................................12 4.1.7. Frame Loss.................................................13
4.1.8. Frame Delay................................................13 4.1.8. Frame Delay................................................13
4.1.9. Frame Delay Variation......................................13 4.1.9. Frame Delay Variation......................................14
4.1.10. Data Path Execution.......................................13 4.1.10. Data Path Execution.......................................14
4.1.11. Scalability...............................................14 4.1.11. Scalability...............................................14
4.1.12. Extensibility.............................................14 4.1.12. Extensibility.............................................15
4.1.13. Security..................................................14 4.1.13. Security..................................................15
4.1.14. Transport Independence....................................15 4.1.14. Transport Independence....................................15
4.1.15. Application Independence..................................15
4.1.16. Backward Compatibility....................................15
4.1.17. Availability..............................................15 4.1.15. Application Independence..................................16
4.1.16. Backward Compatibility....................................16
4.1.17. Availability..............................................16
4.2. VPWS OAM Requirements........................................16 4.2. VPWS OAM Requirements........................................16
4.3. IPLS OAM Requirements........................................16 4.3. IPLS OAM Requirements........................................16
5. Acknowledgments................................................16 5. L2VPN Network OAM Requirements.................................16
6. Security Considerations........................................16 5.1. VPLS (V)LAN Emulation OAM Requirements.......................16
7. Intellectual Property Considerations...........................16 5.1.1. Partial-mesh of PWs........................................17
8. Full Copyright Statement.......................................16 5.1.2. PW Fault Recovery..........................................17
9. IPR Notice.....................................................17 5.1.3. Connectivity Fault Notification............................17
10. Normative References..........................................17 6. Acknowledgments................................................18
11. Informative References........................................17 7. Security Considerations........................................18
12. Authors' Addresses............................................18 8. Intellectual Property Considerations...........................18
9. Full Copyright Statement.......................................18
10. IPR Notice....................................................18
11. Normative References..........................................19
12. Informative References........................................19
13. Authors Addresses.............................................20
1. Introduction 1. Introduction
This draft provides framework and requirements for Virtual Private This draft provides framework and requirements for Layer 2 Virtual
LAN Service (VPLS) Operation, Administration and Maintenance (OAM). Private Networks (L2VPN) Operation, Administration and Maintenance
(OAM).
The scope of OAM for any service and/or transport/network The scope of OAM for any service and/or transport/network
infrastructure technologies can be very broad in nature. OSI has infrastructure technologies can be very broad in nature. OSI has
defined the following five generic functional areas for network defined the following five generic functional areas for network
management, commonly abbreviated as "FCAPS" [NM-Standards]: a) Fault management, commonly abbreviated as "FCAPS" [NM-Standards]: a) Fault
Management, b) Performance Management, c) Configuration Management, Management, b) Performance Management, c) Configuration Management,
d) Accounting Management, and e) Security Management. d) Accounting Management, and e) Security Management.
This draft focuses on the Fault and Performance Management aspects. This draft focuses on the Fault and Performance Management aspects.
Other functional aspects of FCAPS are for further study. Other functional aspects of FCAPS are for further study.
skipping to change at page 4, line 35 skipping to change at page 4, line 44
level metric objectives/specifications. Performance Management level metric objectives/specifications. Performance Management
typically consists of measurement of Performance Parameters e.g. typically consists of measurement of Performance Parameters e.g.
Frame Loss, Frame Delay, Frame Delay Variation (aka Jitter) etc Frame Loss, Frame Delay, Frame Delay Variation (aka Jitter) etc
across managed entities when the managed entity are in available across managed entities when the managed entity are in available
state. Performance Management is suspended across unavailable state. Performance Management is suspended across unavailable
managed entities. This draft introduces some of these performance managed entities. This draft introduces some of these performance
parameters. parameters.
This document provides a description and a reference model for OAM This document provides a description and a reference model for OAM
layering and furthermore emphasizes the importance of proper layering and furthermore emphasizes the importance of proper
independent layering in design and development of OAM functionality. independent layering in design and development of OAM functionality
across L2VPN services, Pseudo Wires (PWs) and Public Switched
Network (PSN) tunnels. The requirements are intended to identify OAM
requirement for L2VPN services (i.e. VPLS, VPWS, and IPLS).
Furthermore, if L2VPN services OAM requirements impose specific
requirements on PW OAM and/or PSN OAM, those specific PW and/or PSN
OAM requirements are also identified.
2. L2VPN Services & Networks 2. L2VPN Services & Networks
As described in [L2VPN-REQ], following Figure 1 shows a L2VPN As described in [L2VPN-REQ], following Figure 1 shows a L2VPN
reference model. L2VPN A represents a point-to-point service while reference model. L2VPN A represents a point-to-point service while
L2VPN B represents a bridged service. L2VPN B represents a bridged service.
+-----+ +-----+ +-----+ +-----+
+ CE1 +--+ +--| CE2 | + CE1 +--+ +--| CE2 |
+-----+ | ..................... | +-----+ +-----+ | ..................... | +-----+
skipping to change at page 7, line 35 skipping to change at page 7, line 52
As mentioned previously, OAM at each layer should be independent of As mentioned previously, OAM at each layer should be independent of
other layers e.g. service layer OAM should be independent of other layers e.g. service layer OAM should be independent of
underlying transport layer. MEPs and MIPs at each layer should be underlying transport layer. MEPs and MIPs at each layer should be
identified with layer specific identifiers. identified with layer specific identifiers.
3.5. OAM Framework for VPLS 3.5. OAM Framework for VPLS
Virtual Private LAN Service (VPLS) is used in different contexts. In Virtual Private LAN Service (VPLS) is used in different contexts. In
general, VPLS is used in the following contexts: a) as a bridged LAN general, VPLS is used in the following contexts: a) as a bridged LAN
service over networks, some of which are MPLS/IP, b) as an MPLS/IP service over networks, some of which are MPLS/IP, b) as an MPLS/IP
network supporting these bridged LAN services, and c) as LAN/VLAN network supporting these bridged LAN services, and c) as (V)LAN
emulation. emulation.
3.5.1. VPLS as Bridged LAN Service 3.5.1. VPLS as Bridged LAN Service
The most common definition for VPLS is for bridged LAN service over The most common definition for VPLS is for bridged LAN service over
an MPLS/IP network. The service coverage is considered end-to-end an MPLS/IP network. The service coverage is considered end-to-end
from UNI to UNI (or AC to AC) among the CE devices and it provides a from UNI to UNI (or AC to AC) among the CE devices and it provides a
virtual LAN service to the attach CEs belonging to that service virtual LAN service to the attach CEs belonging to that service
instance. The reason it is called bridged LAN service is because the instance. The reason it is called bridged LAN service is because the
VPLS-capable PE provide this end-to-end virtual LAN service VPLS-capable PE provide this end-to-end virtual LAN service
skipping to change at page 8, line 20 skipping to change at page 8, line 38
network consisting of MPLS/IP core and Ethernet access network as in network consisting of MPLS/IP core and Ethernet access network as in
H-VPLS with QinQ access. In either case, the network consists of a H-VPLS with QinQ access. In either case, the network consists of a
set of VPLS-capable PE devices capable of performing bridging set of VPLS-capable PE devices capable of performing bridging
functions (either full or a subset). These VPLS-capable PE devices functions (either full or a subset). These VPLS-capable PE devices
can be arranged in a certain topology such as hierarchical topology can be arranged in a certain topology such as hierarchical topology
(H-VPLS) or distributed topology (D-VPLS) or some other topologies (H-VPLS) or distributed topology (D-VPLS) or some other topologies
such as multi-tier or star topologies. To check the network such as multi-tier or star topologies. To check the network
integrity regardless of the network topology, network level OAM integrity regardless of the network topology, network level OAM
mechanisms are needed for the VPLS networks. mechanisms are needed for the VPLS networks.
3.5.3. VPLS as LAN/VLAN Emulation 3.5.3. VPLS as (V)LAN Emulation
Sometimes VPLS also refers to LAN/VLAN emulation. In such context, Sometimes VPLS also refers to (V)LAN emulation. In such context,
VPLS only refers to the full mesh of PWs with split horizon that VPLS only refers to the full mesh of PWs with split horizon that
emulates a LAN segment over MPLS/IP network for a given service emulates a LAN segment over MPLS/IP network for a given service
instance. Since the emulated LAN segment is presented as a Virtual instance. Since the emulated LAN segment is presented as a Virtual
LAN (VLAN) to the bridge module of a VPLS-capable PE, emulated LAN (VLAN) to the bridge module of a VPLS-capable PE, emulated
segment is also referred to as an emulated VLAN. The OAM mechanisms segment is also referred to as an emulated VLAN. The OAM mechanisms
in this context refer primarily to integrity check of the full mesh in this context refer primarily to integrity check of the full mesh
of PWs and the ability to detect and recover from partial mesh of PWs and the ability to detect and recover from partial mesh
failure. failure.
When discussing the OAM mechanisms for VPLS, it is important to When discussing the OAM mechanisms for VPLS, it is important to
consider that the end-to-end service can span across different types consider that the end-to-end service can span across different types
of L2VPN networks. As an example, in case of [VPLS-LDP], the access of L2VPN networks. As an example, in case of [VPLS-LDP], the access
network on one side can be bridged network e.g. [IEEE 802.1ad], as network on one side can be bridged network e.g. [IEEE 802.1ad], as
described in section 11 of [VPLS-LDP]. The access network on other described in section 11 of [VPLS-LDP]. The access network can also
side can be MPLS based as described in section 10 of [VPLS-LDP]; and be a [IEEE 802.1ah] based bridged network. The access network on
the core network connecting them can be IP, MPLS, ATM, or SONET. other side can be MPLS based as described in section 10 of [VPLS-
Similarly, the VPLS service instance can span across [VPLS-BGP], and
distributed VPLS as described in [ROSEN-SIG]. LDP]; and the core network connecting them can be IP, MPLS, ATM, or
SONET. Similarly, the VPLS service instance can span across [VPLS-
BGP], and distributed VPLS as described in [ROSEN-SIG].
Therefore, it is important that the OAM mechanisms can be applied to Therefore, it is important that the OAM mechanisms can be applied to
all these network types. Each such network may be associated with a all these network types. Each such network may be associated with a
separate administrative domain and also multiple such networks may separate administrative domain and also multiple such networks may
be associated with a single administrative domain. Different types be associated with a single administrative domain. Different types
of pseudo wires may be in use to support end-to-end L2VPNs. of pseudo wires may be in use to support end-to-end L2VPNs.
Therefore, for L2VPN OAM, it is important to ensure that the OAM Therefore, for L2VPN OAM, it is important to ensure that the OAM
mechanisms are independent of the underlying transport mechanisms mechanisms are independent of the underlying transport mechanisms
and solely rely on layer 2 services, e.g. for VPLS service, the and solely rely on layer 2 services, e.g. for VPLS service, the
transparency of OAM mechanisms must be ensured over underlying transparency of OAM mechanisms must be ensured over underlying
skipping to change at page 11, line 25 skipping to change at page 12, line 6
the OAM domains. the OAM domains.
For Ethernet services e.g. VPLS, Ethernet frames are used for OAM For Ethernet services e.g. VPLS, Ethernet frames are used for OAM
messages and the source MAC address of the OAM frames represent the messages and the source MAC address of the OAM frames represent the
source MEP in that domain. For unicast Ethernet OAM frames, the source MEP in that domain. For unicast Ethernet OAM frames, the
destination MAC address represents the destination MEP in that destination MAC address represents the destination MEP in that
domain. For multicast Ethernet OAM frames, the destination MAC domain. For multicast Ethernet OAM frames, the destination MAC
addresses corresponds to all MEPs in that domain. addresses corresponds to all MEPs in that domain.
3.6. OAM Framework for VPWS 3.6. OAM Framework for VPWS
TBD
This work is expected to be related to [PWE3-OAM]. TBD.
3.7. OAM Framework for IPLS 3.7. OAM Framework for IPLS
FFS FFS
4. L2VPN OAM Requirements 4. L2VPN Services OAM Requirements
4.1. VPLS OAM Requirements 4.1. VPLS Service OAM Requirements
4.1.1. Discovery 4.1.1. Discovery
Discovery allows a service aware device to learn about other devices Discovery allows a service aware device to learn about other devices
that support the same service instance within a given domain. that support the same service instance within a given domain.
Discovery also allows a service aware device to learn sufficient Discovery also allows a service aware device to learn sufficient
information (e.g. IP addresses, MAC addressed etc.) from other information (e.g. IP addresses, MAC addressed etc.) from other
service aware devices such that OAM messages can be exchanged among service aware devices such that OAM messages can be exchanged among
the service aware devices. the service aware devices.
skipping to change at page 16, line 22 skipping to change at page 16, line 49
frame/packet loss, frame/packet delay and frame/packet delay frame/packet loss, frame/packet delay and frame/packet delay
variation measurements, no additional requirements are specified variation measurements, no additional requirements are specified
currently. currently.
4.2. VPWS OAM Requirements 4.2. VPWS OAM Requirements
TBD TBD
4.3. IPLS OAM Requirements 4.3. IPLS OAM Requirements
FFS FFS
5. Acknowledgments 5. L2VPN Network OAM Requirements
5.1. VPLS (V)LAN Emulation OAM Requirements
5.1.1. Partial-mesh of PWs
As indicated in [BRIDGE-INTEROP], VPLS service OAM relies upon
bidirectional Ethernet links or (V)LAN segments and failure in one
direction or link results in failure of the whole link or (V)LAN
segment. Therefore, when partial-mesh failure occurs in (V)LAN
emulation, either the entire PW mesh should be shutdown when only an
entire VPLS service is acceptable or a subset of PW with full PW
mesh should be realized when partial VPLS service is acceptable.
(R13a) PW OAM for PWs related to a (V)LAN emulation MUST allow
detection of partial-mesh failure condition.
(R13b) PW OAM for PWs related to a (V)LAN emulation MUST allow the
entire mesh of PWs to be shutdown upon detection of a partial-mesh
failure condition.
(R13c) PW OAM for PWs related to a (V)LAN emulation MAY allow the
subset of PWs to be shutdown upon detection of a partial-mesh
failure condition in a manner such that full mesh is present across
the remaining subset.
5.1.2. PW Fault Recovery
As indicated in [BRIDGE-INTEROP], VPLS service OAM fault detection
and recovery relies upon (V)LAN emulation recovery such that fault
detection and recovery time in (V)LAN emulation should be less than
the VPLS service fault detection and recovery time to prevent
unnecessary switch-over and temporary flooding/loop within customer
OAM domain that is dual-homed to provider OAM domain.
(R14a) PW OAM for PWs related to a (V)LAN emulation MUST support a
fault detection time in the provider OAM domain faster than the VPLS
fault detection time in the customer OAM domain.
(R14b) PW OAM for PWs related to a (V)LAN emulation MUST support a
fault recovery time in the provider OAM domain faster than the VPLS
fault recovery time in the customer OAM domain.
5.1.3. Connectivity Fault Notification
When connectivity fault is detected in (V)LAN emulation, PE devices
may notify the EMS/NMS (Element Management System/Network Management
System). However, a single (V)LAN emulation fault may result in CE
devices or U-PE devices detecting connectivity fault in VPLS service
and therefore also notifying the EMS/NMS. To prevent multiple
notifications for the same fault, (V)LAN emulation OAM should
provide alarm suppression capability in the VPLS service OAM.
(R15) PW OAM for PWs related to a (V)LAN emulation MUST support
interworking with VPLS service OAM to allow alarm suppression in the
VPLS service upon fault detection in (V)LAN emulation.
6. Acknowledgments
The authors would like to thank Shahram Davari, Norm Finn, Vasile The authors would like to thank Shahram Davari, Norm Finn, Vasile
Radoaca, Thomas Nadeau, and Monique Morrow for their contributions Radoaca, Thomas Nadeau, and Monique Morrow for their contributions
and review. and review.
The authors would also like to thank Yoav Cohen, Marc Holness, The authors would also like to thank Yoav Cohen, Marc Holness,
Malcolm Betts, Paul Bottorff, Dave Allan, and Hamid-ould Brahim for Malcolm Betts, Paul Bottorff, Dave Allan, and Hamid-ould Brahim for
their valuable feedback. their valuable feedback.
6. Security Considerations 7. Security Considerations
Security issues resulting from this draft will be discussed in Security issues resulting from this draft will be discussed in
greater depth at a later point. It is recommended in [RFC3036] that greater depth at a later point. It is recommended in [RFC3036] that
LDP security (authentication) methods be applied. This would LDP security (authentication) methods be applied. This would
prevent unauthorized participation by a PE in a VPLS. Traffic prevent unauthorized participation by a PE in a VPLS. Traffic
separation for a VPLS is effected by using VC labels. However, for separation for a VPLS is effected by using VC labels. However, for
additional levels of security, the customer MAY deploy end-to-end additional levels of security, the customer MAY deploy end-to-end
security, which is out of the scope of this draft. In addition, the security, which is out of the scope of this draft. In addition, the
L2FRAME] document describes security issues in greater depth. L2FRAME] document describes security issues in greater depth.
7. Intellectual Property Considerations 8. Intellectual Property Considerations
This document is being submitted for use in IETF standards This document is being submitted for use in IETF standards
discussions. discussions.
8. Full Copyright Statement 9. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005).
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights. 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 This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
9. IPR Notice 10. IPR Notice
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 17, line 37 skipping to change at page 19, line 27
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
10. Normative References 11. Normative References
[NM-Standards] "TMN Management Functions", M.3400, February 2000. [NM-Standards] "TMN Management Functions", M.3400, February 2000.
[RFC3036] "LDP Specification", RFC 3036, January 2001. [RFC3036] "LDP Specification", RFC 3036, January 2001.
11. Informative References 12. Informative References
[PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet [PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet
Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap- Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-
08.txt, Work in progress, September 2004. 08.txt, Work in progress, September 2004.
[L2VPN-REQ] "Service Requirements for Layer-2 Provider Provisioned [L2VPN-REQ] "Service Requirements for Layer-2 Provider Provisioned
Virtual Private Networks", draft-ietf-l2vpn-requirements-02.txt, Virtual Private Networks", draft-ietf-l2vpn-requirements-02.txt,
Work in progress, September 2004. Work in progress, September 2004.
[L2VPN-FRWK] "Framework for Layer 2 Virtual Private Networks [L2VPN-FRWK] "Framework for Layer 2 Virtual Private Networks
(L2VPNs)", draft-ietf-l2vpn-l2-framework-05.txt, Work in Progress, (L2VPNs)", draft-ietf-l2vpn-l2-framework-05.txt, Work in Progress,
June 2004. June 2004.
[IEEE 802.1ad] "IEEE standard for Provider Bridges", Work in [IEEE 802.1ad] "IEEE standard for Provider Bridges", Work in
Progress, September 2004. Progress, July 2005.
[IEEE 802.1ah] "IEEE standard for Provider Backbone Bridges", Work
in Progress, July 2005.
[ROSEN-SIG] "Provisioning Models and Endpoint Identifiers in L2VPN [ROSEN-SIG] "Provisioning Models and Endpoint Identifiers in L2VPN
Signaling", draft-ietf-l2vpn-signaling-02.txt, Work in progress, Signaling", draft-ietf-l2vpn-signaling-02.txt, Work in progress,
September 2004. September 2004.
[VPLS-LDP] "Virtual Private LAN Services over MPLS", [VPLS-LDP] "Virtual Private LAN Services over MPLS",
draft-ietf-l2vpn-vpls-ldp-05.txt, Work in progress, September 2004. draft-ietf-l2vpn-vpls-ldp-05.txt, Work in progress, September 2004.
[VPLS-BGP] "Virtual Private LAN Service", [VPLS-BGP] "Virtual Private LAN Service",
draft-ietf-l2vpn-vpls-bgp-02.txt, Work in progress, May 2004. draft-ietf-l2vpn-vpls-bgp-02.txt, Work in progress, May 2004.
12. Authors' Addresses [BRIDGE-INTEROP] "VPLS Interoperability with CE Bridges", draft-
sajassi-l2vpn-vpls-bridge-interop-01.txt, Work in progress, July
2005.
[PWE3-OAM] "PWE3 Applications and OAM Scenarios", draft-delord-pwe2-
oam-applications-01.txt, Work in progress, May 2005.
13. Authors Addresses
Dinesh Mohan Dinesh Mohan
Nortel Nortel
3500 Carling Ave 3500 Carling Ave
Ottawa, ON K2H8E9 Ottawa, ON K2H8E9
Email: mohand@nortel.com Email: mohand@nortel.com
Ali Sajassi Ali Sajassi
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
 End of changes. 

This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/