draft-ietf-l2vpn-vpls-bridge-interop-01.txt   draft-ietf-l2vpn-vpls-bridge-interop-02.txt 
Internet Working Group Ali Sajassi Internet Working Group Ali Sajassi
Internet Draft Cisco Systems Internet Draft Cisco Systems
Intended Status: Informational
Yetik Serbest Yetik Serbest
SBC Communications SBC Communications
Frank Brockners Frank Brockners
Cisco Systems Cisco Systems
Dinesh Mohan Dinesh Mohan
Nortel Nortel
VPLS Interoperability with CE Bridges VPLS Interoperability with CE Bridges
draft-ietf-l2vpn-vpls-bridge-interop-01.txt draft-ietf-l2vpn-vpls-bridge-interop-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 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. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference at any 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 (2006). All Rights Reserved.
Abstract Abstract
One of the main motivations behind VPLS is its ability to provide One of the main motivations behind VPLS is its ability to provide
connectivity not only among customer routers and servers/hosts but connectivity not only among customer routers and servers/hosts but
also among customer bridges. If only connectivity among customer IP also among customer bridges. If only connectivity among customer IP
routers/hosts was desired, then IPLS solution [IPLS] could have been routers/hosts was desired, then IPLS solution [IPLS] could have been
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2006
used. The strength of the VPLS solution is that it can provide used. The strength of the VPLS solution is that it can provide
connectivity to both bridge and non-bridge types of CE devices. VPLS connectivity to both bridge and non-bridge types of CE devices. VPLS
is expected to deliver the same level of service that current is expected to deliver the same level of service that current
enterprise users are accustomed to from their own enterprise bridged enterprise users are accustomed to from their own enterprise bridged
networks today or the same level of service that they receive from networks today or the same level of service that they receive from
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
their Ethernet Service Providers using IEEE 802.1ad-based networks their Ethernet Service Providers using IEEE 802.1ad-based networks
[P802.1ad] (or its predecessor QinQ-based network). [P802.1ad] (or its predecessor, QinQ-based network).
When CE devices are IEEE bridges, then there are certain issues and When CE devices are IEEE bridges, then there are certain issues and
challenges that need to be accounted for in a VPLS network. Majority challenges that need to be accounted for in a VPLS network. Majority
of these issues have currently been addressed in IEEE 802.1ad of these issues have currently been addressed in IEEE 802.1ad
standard for provider bridges and they need to be addressed for VPLS standard for provider bridges and they need to be addressed for VPLS
networks. This draft discusses these issues and wherever possible, networks. This draft discusses these issues and wherever possible,
the recommended solutions to these issues. the recommended solutions to these issues.
Conventions Conventions
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].
Table of Contents Table of Contents
1. Overview........................................................3 1. Introduction....................................................3
2. Ethernet Service Instance.......................................3 2. Ethernet Service Instance.......................................3
3. VPLS-Capable PE Model with Bridge Module........................4 3. VPLS-Capable PE Model with Bridge Module........................4
4. Mandatory Issues................................................7 4. Mandatory Issues................................................7
4.1. Service Mapping...............................................7 4.1. Service Mapping...............................................7
4.2. CE Bridge Protocol Handling...................................9 4.2. CE Bridge Protocol Handling...................................9
4.3. Partial-mesh of Pseudowires..................................10 4.3. Partial-mesh of Pseudowires..................................10
4.4. Multicast Traffic............................................11 4.4. Multicast Traffic............................................11
5. Optional Issues................................................12 5. Optional Issues................................................12
5.1. Customer Network Topology Changes............................12 5.1. Customer Network Topology Changes............................12
5.2. Redundancy...................................................14 5.2. Redundancy...................................................14
5.3. MAC Address Learning.........................................15 5.3. MAC Address Learning.........................................15
6. Interoperability with 802.1ad Networks.........................16 6. Interoperability with 802.1ad Networks.........................16
7. Acknowledgments................................................16 7. Acknowledgments................................................16
8. Security Considerations........................................16 8. IANA Considerations............................................16
9. References.....................................................17 9. Security Considerations........................................17
10. Authors' Addresses............................................17 10. Normative References..........................................17
11. Full Copyright Statement......................................18 11. Informative References........................................17
12. Intellectual Property Statement.....Error! Bookmark not defined. Authors' Addresses................................................18
Full Copyright Statement..........................................18
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2006 Disclaimer of validity:...........................................19
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
1. Overview 1. Introduction
Virtual Private LAN Service is a LAN emulation service intended for Virtual Private LAN Service is a LAN emulation service intended for
providing connectivity between geographically dispersed customer providing connectivity between geographically dispersed customer
sites across MAN/WAN (over MPLS/IP) network(s), as if they were sites across MAN/WAN (over MPLS/IP) network(s), as if they were
connected using a LAN. One of the main motivations behind VPLS is connected using a LAN. One of the main motivations behind VPLS is
its ability to provide connectivity not only among customer routers its ability to provide connectivity not only among customer routers
and servers/hosts but also among customer bridges. If only and servers/hosts but also among customer bridges. If only
connectivity among customer IP routers/hosts was desired, then IPLS connectivity among customer IP routers/hosts was desired, then IPLS
solution [IPLS] could have been used. The strength of the VPLS solution [IPLS] could have been used. The strength of the VPLS
solution is that it can provide connectivity to both bridge and non- solution is that it can provide connectivity to both bridge and non-
bridge types of CE devices. VPLS is expected to deliver the same bridge types of CE devices. VPLS is expected to deliver the same
level of service that current enterprise users are accustomed to level of service that current enterprise users are accustomed to
from their own enterprise bridged networks [802.1D/802.1Q] today or from their own enterprise bridged networks [802.1D/802.1Q] today or
the same level of service that they receive from their Ethernet the same level of service that they receive from their Ethernet
Service Providers using IEEE 802.1ad-based networks [P802.1ad] (or Service Providers using IEEE 802.1ad-based networks [P802.1ad] (or
its predecessor QinQ-based network). its predecessor, QinQ-based network).
When CE devices are IEEE bridges, then there are certain issues and When CE devices are IEEE bridges, then there are certain issues and
challenges that need to be accounted for in a VPLS network. Majority challenges that need to be accounted for in a VPLS network. Majority
of these issues have currently been addressed in IEEE 802.1ad of these issues have currently been addressed in IEEE 802.1ad
standard for provider bridges and they need to be addressed for VPLS standard for provider bridges and they need to be addressed for VPLS
networks. This draft discusses these issues and wherever possible, networks. This draft discusses these issues and wherever possible,
the recommended solutions to these issues. It also discusses the recommended solutions to these issues. It also discusses
interoperability issues between VPLS and IEEE 802.1ad networks when interoperability issues between VPLS and IEEE 802.1ad networks when
the end-to-end service spans across both types of networks, as the end-to-end service spans across both types of networks, as
outlined in [VPLS-LDP]. outlined in [RFC-4762].
This draft categorizes the CE-bridge issues into two groups: 1) This draft categorizes the CE-bridge issues into two groups: 1)
Mandatory and 2) Optional. The issues in group (1) need to be Mandatory and 2) Optional. The issues in group (1) need to be
addressed in order to ensure the proper operation of CE bridges. The addressed in order to ensure the proper operation of CE bridges. The
issues in group (2) would provide additional operational improvement issues in group (2) would provide additional operational improvement
and efficiency and may not be required for interoperability with CE and efficiency and may not be required for interoperability with CE
bridges. Sections four and five discuss the mandatory and optional bridges. Sections four and five discuss the mandatory and optional
issues respectively. issues respectively.
2. Ethernet Service Instance 2. Ethernet Service Instance
skipping to change at page 4, line 4 skipping to change at page 4, line 4
to first clarify the Ethernet Service definition. The term VPLS has to first clarify the Ethernet Service definition. The term VPLS has
different meanings in different contexts. In general, VPLS is used different meanings in different contexts. In general, VPLS is used
in the following contexts [Eth-OAM]: a) as an end-to-end bridged-LAN in the following contexts [Eth-OAM]: a) as an end-to-end bridged-LAN
service over one or more network (one of which being MPLS/IP service over one or more network (one of which being MPLS/IP
network), b) as an MPLS/IP network supporting these bridged LAN network), b) as an MPLS/IP network supporting these bridged LAN
services, and c) as (V)LAN emulation. For better clarity, we services, and c) as (V)LAN emulation. For better clarity, we
differentiate between its usage as network versus service by using differentiate between its usage as network versus service by using
the terms VPLS network and VPLS instance respectively. Furthermore, the terms VPLS network and VPLS instance respectively. Furthermore,
we confine VPLS (both network and service) to only the portion of we confine VPLS (both network and service) to only the portion of
the end-to-end network that spans across an MPLS/IP network. For an the end-to-end network that spans across an MPLS/IP network. For an
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2006 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
end-to-end service (among different sites of a given customer), we end-to-end service (among different sites of a given customer), we
use the term “Ethernet Service Instance” or ESI. use the term "Ethernet Service Instance" or ESI.
[MFA-Ether] defines the Ethernet Service Instance (ESI) as an [MFA-Ether] defines the Ethernet Service Instance (ESI) as an
association of two or more Attachment Circuits (ACs) over which an association of two or more Attachment Circuits (ACs) over which an
Ethernet service is offered to a given customer. An AC can be either Ethernet service is offered to a given customer. An AC can be either
a UNI or a NNI; furthermore, it can be an Ethernet interface or a a UNI or a NNI; furthermore, it can be an Ethernet interface or a
VLAN, it can be an ATM or FR VC, or it can be a PPP/HDLC interface. VLAN, it can be an ATM or FR VC, or it can be a PPP/HDLC interface.
If an ESI is associated with more than two ACs, then it is a If an ESI is associated with more than two ACs, then it is a
multipoint ESI. In this document, where ever the keyword ESI is multipoint ESI. In this document, where ever the keyword ESI is
used, it means multipoint ESI, unless it is stated otherwise. used, it means multipoint ESI, unless it is stated otherwise.
skipping to change at page 4, line 48 skipping to change at page 4, line 48
in service provider networks, its realization shall be done such in service provider networks, its realization shall be done such
that it provides a separate MAC address domain and broadcast domain that it provides a separate MAC address domain and broadcast domain
per ESI. A separate MAC address domain is provided by using a per ESI. A separate MAC address domain is provided by using a
separate filtering database per ESI (for both VPLS and IEEE 802.1ad separate filtering database per ESI (for both VPLS and IEEE 802.1ad
networks) and separate broadcast domain is provided by using a full- networks) and separate broadcast domain is provided by using a full-
mesh of PWs per ESI over the IP/MPLS core in a VPLS network and/or a mesh of PWs per ESI over the IP/MPLS core in a VPLS network and/or a
dedicated Service VLAN per ESI in an IEEE 802.1ad network. dedicated Service VLAN per ESI in an IEEE 802.1ad network.
3. VPLS-Capable PE Model with Bridge Module 3. VPLS-Capable PE Model with Bridge Module
[L2VPN-FRWK] defines three models for VPLS-capable PE (VPLS-PE) [RFC-4664] defines three models for VPLS-capable PE (VPLS-PE) based
based on the bridging functionality that needs to be supported by on the bridging functionality that needs to be supported by the PE.
the PE. If the CE devices can include both routers/hosts and IEEE If the CE devices can include both routers/hosts and IEEE bridges,
bridges, then the second model is the most suitable and adequate one then the second model is the most suitable and adequate one and it
and it is consistent with IEEE standards for Provider Bridges is consistent with IEEE standards for Provider Bridges [P802.1ad].
[P802.1ad]. We briefly describe the second model and then elaborate We briefly describe the second model and then elaborate upon this
upon this model to show its sub-components based on [P802.1ad] model to show its sub-components based on [P802.1ad] Provider Bridge
Provider Bridge model. model.
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2006 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
As described in [L2VPN-FRWK], the second model for VPLS-PE contains As described in [RFC-4664], the second model for VPLS-PE contains a
a single bridge module supporting all the VPLS instances on that PE single bridge module supporting all the VPLS instances on that PE
where each VPLS instance is represented by a unique VLAN inside that where each VPLS instance is represented by a unique VLAN inside that
bridge module (also known as Service VLAN or S-VLAN). The bridge bridge module (also known as Service VLAN or S-VLAN). The bridge
module has at least a single “Emulated LAN” interface over which module has at least a single “Emulated LAN” interface over which
each VPLS instance is represented by a unique S-VLAN tag. Each VPLS each VPLS instance is represented by a unique S-VLAN tag. Each VPLS
instance can consist of a set of PWs and its associated forwarder instance can consist of a set of PWs and its associated forwarder
corresponding to a single Virtual LAN (VLAN) as depicted in the corresponding to a single Virtual LAN (VLAN) as depicted in the
following figure. Thus, sometimes it is referred to as V-LAN following figure. Thus, sometimes it is referred to as V-LAN
emulation. emulation.
+----------------------------------------+ +----------------------------------------+
skipping to change at page 5, line 45 skipping to change at page 5, line 45
| | | | | |
+-------------------------|--------------+ +-------------------------|--------------+
LAN emulation Interface LAN emulation Interface
Figure 1. VPLS-capable PE Model Figure 1. VPLS-capable PE Model
Customer frames associated with a given ESI, carry the S-VLAN ID for Customer frames associated with a given ESI, carry the S-VLAN ID for
that ESI over the LAN emulation interface. The S-VLAN ID is stripped that ESI over the LAN emulation interface. The S-VLAN ID is stripped
before transmitting the frames over the set of PWs associated with before transmitting the frames over the set of PWs associated with
that VPLS instance (assuming raw mode PW is used as specified in that VPLS instance (assuming raw mode PW is used as specified in
[PWE3-Ethernet]). [RFC-4448]).
The bridge module can itself consist of one or two sub-components The bridge module can itself consist of one or two sub-components
depending on the functionality that it needs to perform. The depending on the functionality that it needs to perform. The
following figure depicts the model for bridge module based on following figure depicts the model for bridge module based on
[P802.1ad]. [P802.1ad].
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2006 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
+-------------------------------+ +-------------------------------+
| 802.1ad Bridge Module Model | | 802.1ad Bridge Module Model |
| | | |
+---+ | +------+ +-----------+ | +---+ | +------+ +-----------+ |
|CE |---------|C-VLAN|------| | | |CE |---------|C-VLAN|------| | |
+---+ | |bridge|------| | | +---+ | |bridge|------| | |
| +------+ | | | | +------+ | | |
| o | S-VLAN | | | o | S-VLAN | |
| o | | | | o | | |
skipping to change at page 6, line 57 skipping to change at page 7, line 4
bridge component. bridge component.
The C-VLAN bridge component does service selection and The C-VLAN bridge component does service selection and
identification based on C-VLAN tags. Each frame from the customer identification based on C-VLAN tags. Each frame from the customer
device is assigned to a C-VLAN and presented at one or more internal device is assigned to a C-VLAN and presented at one or more internal
port-based interfaces, each supporting a single service instance port-based interfaces, each supporting a single service instance
that the customer desires to carry that C-VLAN. Similarly frames that the customer desires to carry that C-VLAN. Similarly frames
from the provider network are assigned to an internal interface or from the provider network are assigned to an internal interface or
‘LAN’ (e.g, between C-VLAN and S-VLAN components) on the basis of ‘LAN’ (e.g, between C-VLAN and S-VLAN components) on the basis of
the S-VLAN tag. Since each internal interface supports a single the S-VLAN tag. Since each internal interface supports a single
service instance, the S-VLAN tag can be, and is, removed at this draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2006
service instance, the S-VLAN tag can be, and is, removed at this
interface by the S-VLAN bridge component. If multiple C-VLANs are interface by the S-VLAN bridge component. If multiple C-VLANs are
supported by this service instance (e.g., VLAN bundling or port- supported by this service instance (e.g., VLAN bundling or port-
based), then the frames will have already been tagged with C-VLAN based), then the frames will have already been tagged with C-VLAN
tags. If a single C-VLAN is supported by this service instance tags. If a single C-VLAN is supported by this service instance
(e.g., VLAN-based), then the frames shall not have been tagged with (e.g., VLAN-based), then the frames shall not have been tagged with
C-VLAN tag since C-VLAN can be derived from the S-VLAN (e.g., one to C-VLAN tag since C-VLAN can be derived from the S-VLAN (e.g., one to
one mapping). The C-VLAN aware bridge component applies a port VLAN one mapping). The C-VLAN aware bridge component applies a port VLAN
ID (PVID) to untagged frames received on each internal ‘LAN’, ID (PVID) to untagged frames received on each internal ‘LAN’,
allowing full control over the delivery of frames for each C-VLAN allowing full control over the delivery of frames for each C-VLAN
through the Customer UNI Port. through the Customer UNI Port.
4. Mandatory Issues 4. Mandatory Issues
4.1. Service Mapping 4.1. Service Mapping
Different Ethernet AC types can be associated with a single Ethernet Different Ethernet AC types can be associated with a single Ethernet
Service Instance (ESI). For example, an ESI can be associated with Service Instance (ESI). For example, an ESI can be associated with
only physical Ethernet ports, VLANs, or a combination of two (e.g., only physical Ethernet ports, VLANs, or a combination of two (e.g.,
one end of the service be associated with physical Ethernet ports one end of the service be associated with physical Ethernet ports
and the other end be associated with VLANs). In [VPLS-LDP], and the other end be associated with VLANs). In [RFC-4762],
unqualified and qualified learning is used to refer to port-based unqualified and qualified learning is used to refer to port-based
and VLAN-based operation respectively and it does not describe the and VLAN-based operation respectively and it does not describe the
possible mappings between different types of Ethernet ACs (e.g., possible mappings between different types of Ethernet ACs (e.g.,
802.1D, 802.1Q or 802.1ad frames). In general, the mapping of a 802.1D, 802.1Q or 802.1ad frames). In general, the mapping of a
customer port or VLAN to a given service instance is a local customer port or VLAN to a given service instance is a local
function performed by the local PE and the service provisioning function performed by the local PE and the service provisioning
shall accommodate it. In other words, there is no reason to restrict shall accommodate it. In other words, there is no reason to restrict
and limit an ESI to have only port-based ACs or to have only VLAN- and limit an ESI to have only port-based ACs or to have only VLAN-
based ACs. [P802.1ad] allows for each customer AC (either a physical based ACs. [P802.1ad] allows for each customer AC (either a physical
port, or a VLAN, or a group of VLANs) to be mapped independently to port, or a VLAN, or a group of VLANs) to be mapped independently to
skipping to change at page 7, line 55 skipping to change at page 8, line 4
perform such mapping. In the first scenario, it is assumed that an perform such mapping. In the first scenario, it is assumed that an
Ethernet physical port only carries untagged traffic and all the Ethernet physical port only carries untagged traffic and all the
traffic is mapped to the corresponding service instance or ESI. This traffic is mapped to the corresponding service instance or ESI. This
is referred to as “port-based w/ untagged traffic”. In the second is referred to as “port-based w/ untagged traffic”. In the second
scenario, it is assumed that an Ethernet physical port carries both scenario, it is assumed that an Ethernet physical port carries both
tagged and untagged traffic and all that traffic is mapped to the tagged and untagged traffic and all that traffic is mapped to the
corresponding service instance or ESI. This is referred to as “port- corresponding service instance or ESI. This is referred to as “port-
based w/ tagged and untagged traffic”. In the third scenario, it is based w/ tagged and untagged traffic”. In the third scenario, it is
assumed that only a single VLAN is mapped to the corresponding assumed that only a single VLAN is mapped to the corresponding
service instance or ESI (referred to as VLAN-based). Finally, in the service instance or ESI (referred to as VLAN-based). Finally, in the
fourth scenario, it is assumed that a group of VLANs from the draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2006
fourth scenario, it is assumed that a group of VLANs from the
Ethernet physical interface is mapped to the corresponding service Ethernet physical interface is mapped to the corresponding service
instance or ESI. instance or ESI.
=================================================================== ===================================================================
Ethernet I/F & Associated Service Instance(s) Ethernet I/F & Associated Service Instance(s)
------------------------------------------------------------------- -------------------------------------------------------------------
Port-based port-based VLAN-based VLAN Port-based port-based VLAN-based VLAN
Untagged tagged & bundling Untagged tagged & bundling
untagged untagged
------------------------------------------------------------------- -------------------------------------------------------------------
skipping to change at page 8, line 54 skipping to change at page 9, line 4
the outer tag is S-VLAN and the inner tag is C-VLAN received from the outer tag is S-VLAN and the inner tag is C-VLAN received from
“VLAN bundling” AC. “VLAN bundling” AC.
If a PE uses an S-VLAN tag for a given ESI (either by adding an S- If a PE uses an S-VLAN tag for a given ESI (either by adding an S-
VLAN tag to customer traffic or by replacing a C-VLAN tag with a S- VLAN tag to customer traffic or by replacing a C-VLAN tag with a S-
VLAN tag), then the frame format and EtherType for S-VLAN shall VLAN tag), then the frame format and EtherType for S-VLAN shall
adhere to [P802.1ad]. adhere to [P802.1ad].
As mentioned before, the mapping function between the customer AC As mentioned before, the mapping function between the customer AC
and its associated ESI is a local function and thus when the AC is a and its associated ESI is a local function and thus when the AC is a
single customer VLAN, it is possible to map different customer VLANs draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2006
single customer VLAN, it is possible to map different customer VLANs
at different sites to a single ESI without coordination among those at different sites to a single ESI without coordination among those
sites. sites.
When a port-based or a VLAN-bundling is used, then the PE may use an When a port-based or a VLAN-bundling is used, then the PE may use an
additional S-VLAN tag to mark the customer traffic received over additional S-VLAN tag to mark the customer traffic received over
that AC as belonging to a given ESI. If the PE uses the additional that AC as belonging to a given ESI. If the PE uses the additional
S-VLAN tag, then in the opposite direction the PE shall strip the S- S-VLAN tag, then in the opposite direction the PE shall strip the S-
VLAN tag before sending the customer frames over the same AC. VLAN tag before sending the customer frames over the same AC.
However, when VLAN-mapping mode is used at an AC and if the PE uses However, when VLAN-mapping mode is used at an AC and if the PE uses
S-VLAN tag locally, then if the Ethernet interface is a UNI, the S-VLAN tag locally, then if the Ethernet interface is a UNI, the
skipping to change at page 9, line 54 skipping to change at page 10, line 4
All the above CE bridge protocol handling can be supported via the All the above CE bridge protocol handling can be supported via the
PE model with the bridge module depicted in figure-2 (based on PE model with the bridge module depicted in figure-2 (based on
[802.1ad]). For example, when an Attachment Circuit is port-based, [802.1ad]). For example, when an Attachment Circuit is port-based,
then the bridge module of the PE can operate transparently with then the bridge module of the PE can operate transparently with
respect to the CE’s RSTP/MSTP protocols (and thus no C-VLAN respect to the CE’s RSTP/MSTP protocols (and thus no C-VLAN
component is required for that customer UNI). However, when an component is required for that customer UNI). However, when an
Attachment Circuit is VLAN-based (either VLAN-based or VLAN Attachment Circuit is VLAN-based (either VLAN-based or VLAN
bundling), then the bridge module of the PE needs to peer with the bundling), then the bridge module of the PE needs to peer with the
RSTP/MSTP protocols running on the CE (and thus the C-VLAN bridge RSTP/MSTP protocols running on the CE (and thus the C-VLAN bridge
component is required). There are also protocols that require component is required). There are also protocols that require
peering but are independent from the type of Attachment Circuit. An draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2006
peering but are independent from the type of Attachment Circuit. An
example of such protocol is link aggregation protocol [802.3ad]; example of such protocol is link aggregation protocol [802.3ad];
however, this is a media-dependent protocol as its name implies. however, this is a media-dependent protocol as its name implies.
Therefore, the peering requirement can be generalized such that the Therefore, the peering requirement can be generalized such that the
media-independent protocols (RSTP/MSTP, CFM, etc) that require media-independent protocols (RSTP/MSTP, CFM, etc) that require
peering are for VLAN-based or VLAN-bundling Attachment Circuit. peering are for VLAN-based or VLAN-bundling Attachment Circuit.
[P802.1ad] reserves a block of 16 MAC addresses for the operation of [P802.1ad] reserves a block of 16 MAC addresses for the operation of
C-VLAN and S-VLAN bridge components and it shows which of these C-VLAN and S-VLAN bridge components and it shows which of these
reserved MAC addresses are only for C-VLAN bridge component and reserved MAC addresses are only for C-VLAN bridge component and
which ones are only for S-VLAN bridge component and which ones apply which ones are only for S-VLAN bridge component and which ones apply
skipping to change at page 10, line 55 skipping to change at page 11, line 4
regarding operational aspects of such procedure also need to be regarding operational aspects of such procedure also need to be
worked out. worked out.
If the PE model, with bridge module as depicted in figure-2, is If the PE model, with bridge module as depicted in figure-2, is
used, then [P802.1ag] procedures could be used for detection of used, then [P802.1ag] procedures could be used for detection of
partial-mesh of PWs. [p802.1ag] defines a set of procedures for partial-mesh of PWs. [p802.1ag] defines a set of procedures for
fault detection, verification, isolation, and notification per ESI. fault detection, verification, isolation, and notification per ESI.
Fault detection mechanism of [p8021.ag] can be used to perform Fault detection mechanism of [p8021.ag] can be used to perform
connectivity check among PEs belonging to a given VPLS instance. It connectivity check among PEs belonging to a given VPLS instance. It
checks the integrity of a service instance end-to-end within an draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2006
checks the integrity of a service instance end-to-end within an
administrative domain – e.g., from one AC at one end of the network administrative domain – e.g., from one AC at one end of the network
to another AC at the other end of the network. Therefore, its path to another AC at the other end of the network. Therefore, its path
coverage includes bridge module within a PE and it is not limited to coverage includes bridge module within a PE and it is not limited to
just PWs. Furthermore, [P802.1ag] operates transparently over the just PWs. Furthermore, [P802.1ag] operates transparently over the
full-mesh of PWs for a given service instance since it operates at full-mesh of PWs for a given service instance since it operates at
the Ethernet level (and not at PW level). It should be noted that the Ethernet level (and not at PW level). It should be noted that
[P802.1ag] assumes that the Ethernet links or LAN segments [P802.1ag] assumes that the Ethernet links or LAN segments
connecting provider bridges are full-duplex and the failure in one connecting provider bridges are full-duplex and the failure in one
direction results in the failure of the whole link or LAN segment. direction results in the failure of the whole link or LAN segment.
However, that is not the case for VPLS instance since a PW consists However, that is not the case for VPLS instance since a PW consists
skipping to change at page 11, line 55 skipping to change at page 12, line 4
registration of the customer multicast MAC address(s) at the PE when registration of the customer multicast MAC address(s) at the PE when
there is customer topology change. It should be noted that IGMP there is customer topology change. It should be noted that IGMP
snooping provides a solution for IP multicast packets and is not snooping provides a solution for IP multicast packets and is not
applicable to general multicast data. applicable to general multicast data.
Using the IGMP-snooping as described, the ingress PE can select a Using the IGMP-snooping as described, the ingress PE can select a
sub-set of PWs for packet replication; therefore, avoiding sending sub-set of PWs for packet replication; therefore, avoiding sending
multicast packets to the egress PEs that don’t need them. However, multicast packets to the egress PEs that don’t need them. However,
the replication is still performed by the ingress PE. In order to the replication is still performed by the ingress PE. In order to
avoid, replication at ingress PE, one may want to use multicast avoid, replication at ingress PE, one may want to use multicast
distribution trees (MDTs) in the provider core network; however, draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2006
distribution trees (MDTs) in the provider core network; however,
this comes with its potential pitfalls. If the MDT is used for all this comes with its potential pitfalls. If the MDT is used for all
multicast traffic of a given customer, then this results in customer multicast traffic of a given customer, then this results in customer
multicast and unicast traffic to be forwarded on different PWs and multicast and unicast traffic to be forwarded on different PWs and
even on a different physical topology within the provider network. even on a different physical topology within the provider network.
This is a serious issue for customer bridges because customer BPDUs, This is a serious issue for customer bridges because customer BPDUs,
which are multicast data, can take a different path through the which are multicast data, can take a different path through the
network than the unicast data. Situations might arise where either network than the unicast data. Situations might arise where either
unicast OR multicast connectivity is lost. If unicast connectivity unicast OR multicast connectivity is lost. If unicast connectivity
is lost, but multicast forwarding continues to work, the customer is lost, but multicast forwarding continues to work, the customer
spanning tree would not take notice which results in loss of its spanning tree would not take notice which results in loss of its
unicast traffic. Similarly, if multicast connectivity is lost, but unicast traffic. Similarly, if multicast connectivity is lost, but
unicast is working, then the customer spanning tree will activate unicast is working, then the customer spanning tree will activate
the blocked port which may result in loop within the customer the blocked port which may result in loop within the customer
network. Therefore, the MDT cannot be used for both customer network. Therefore, the MDT cannot be used for both customer
multicast control and data traffic. If it is used, it should only be multicast control and data traffic. If it is used, it SHOULD only be
limited to customer data traffic. However, there can be potential limited to customer data traffic. However, there can be potential
issue even when it is used for customer data traffic since the MDT issue even when it is used for customer data traffic since the MDT
doesn’t fit the PE model described in Figure-1 (it operates doesn’t fit the PE model described in Figure-1 (it operates
independently from the full-mesh of PWs that correspond to an S- independently from the full-mesh of PWs that correspond to an S-
VLAN). It is also not clear how CFM procedures (802.1ag) used for VLAN). It is also not clear how CFM procedures (802.1ag) used for
ESI integrity check (e.g., per service instance) can be applied to ESI integrity check (e.g., per service instance) can be applied to
check the integrity of the customer multicast traffic over the check the integrity of the customer multicast traffic over the
provider MDT. Because of these potential issues, the specific provider MDT. Because of these potential issues, the specific
applications of the provider MDT to customer multicast traffic shall applications of the provider MDT to customer multicast traffic shall
be documented and its limitations be clearly specified. be documented and its limitations be clearly specified.
5. Optional Issues 5. Optional Issues
5.1. Customer Network Topology Changes 5.1. Customer Network Topology Changes
A single CE or a customer network can be connected to a provider A single CE or a customer network can be connected to a provider
network using more than one User-Network Interface (UNI). network using more than one User-Network Interface (UNI).
Furthermore, a single CE or a customer network can be connected to Furthermore, a single CE or a customer network can be connected to
more than one provider network. [L2VPN-REQ] provides some examples more than one provider network. [RFC-4665] provides some examples of
of such customer network connectivity that are depicted in the such customer network connectivity that are depicted in the figure
figure below. Such network topologies are designed to protect below. Such network topologies are designed to protect against the
against the failure or removal of network components with the failure or removal of network components with the customer network
customer network and it is assumed that the customer leverages the and it is assumed that the customer leverages the spanning tree
spanning tree protocol to protect against these cases. Therefore, in protocol to protect against these cases. Therefore, in such
such scenarios, it is important to flush customer MAC addresses in scenarios, it is important to flush customer MAC addresses in the
the provider network upon the customer topology change to avoid provider network upon the customer topology change to avoid black
black holing of customer frames. holing of customer frames.
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2006 draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
+----------- +--------------- +----------- +---------------
| | | |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE | | CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network |device| |device| |device| |device| SP network
+------+\ +------+ +------+\ +------+ +------+\ +------+ +------+\ +------+
| \ | | \ | | \ | | \ |
|Back \ | |Back \ +--------------- |Back \ | |Back \ +---------------
|door \ | SP network |door \ +--------------- |door \ | SP network |door \ +---------------
skipping to change at page 13, line 54 skipping to change at page 13, line 54
Notification (CCN) message with the S-VLAN ID associated with that Notification (CCN) message with the S-VLAN ID associated with that
service instance and a destination MAC address as specified in the service instance and a destination MAC address as specified in the
block of 16 reserved multicast MAC addresses. Upon receiving the block of 16 reserved multicast MAC addresses. Upon receiving the
CCN, the provider bridge will flush all the customer MAC addresses CCN, the provider bridge will flush all the customer MAC addresses
associated with that S-VLAN ID on all the provider bridge interfaces associated with that S-VLAN ID on all the provider bridge interfaces
except the one that the CCN message is received from. except the one that the CCN message is received from.
Based on the provider bridge model depicted in figure (1), there are Based on the provider bridge model depicted in figure (1), there are
two methods of propagating the CCN message over the VPLS network. two methods of propagating the CCN message over the VPLS network.
The first method is to translate the in-band CCN message into an The first method is to translate the in-band CCN message into an
out-of-band “MAC Address Withdrawal” message as specified in [VPLS- out-of-band “MAC Address Withdrawal” message as specified in [RFC-
LDP] and the second method is to treat the CCN message as customer 4762] and the second method is to treat the CCN message as customer
data and pass it transparently over the set of PWs associated with data and pass it transparently over the set of PWs associated with
that VPLS instance. The second method is recommended because of ease draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2006
that VPLS instance. The second method is recommended because of ease
of interoperability between the bridge and the LAN emulation modules of interoperability between the bridge and the LAN emulation modules
of the PE. of the PE.
5.2. Redundancy 5.2. Redundancy
[VPLS-LDP] talks about dual-homing of a given u-PE to two n-PEs over [RFC-4762] talks about dual-homing of a given u-PE to two n-PEs over
a provider MPLS access network to provide protection against link a provider MPLS access network to provide protection against link
and node failure – e.g., in case the primary n-PE fails or the and node failure – e.g., in case the primary n-PE fails or the
connection to it fails, then the u-PE uses the backup PWs to reroute connection to it fails, then the u-PE uses the backup PWs to reroute
the traffic to the backup n-PE. Furthermore, it discusses the the traffic to the backup n-PE. Furthermore, it discusses the
provision of redundancy when a provider Ethernet access network is provision of redundancy when a provider Ethernet access network is
used and how any arbitrary access network topology (not just limited used and how any arbitrary access network topology (not just limited
to hub-and-spoke) can be supported using the provider’s MSTP to hub-and-spoke) can be supported using the provider’s MSTP
protocol and how the provider MSTP for a given access network can be protocol and how the provider MSTP for a given access network can be
confined to that access network and operate independently from MSTP confined to that access network and operate independently from MSTP
protocols running in other access networks. protocols running in other access networks.
skipping to change at page 14, line 55 skipping to change at page 15, line 4
Figure-4 shows two provider access networks each with two n-PEs Figure-4 shows two provider access networks each with two n-PEs
where the n-PEs are connected via a full mesh of PWs for a given where the n-PEs are connected via a full mesh of PWs for a given
VPLS instance. As shown in the figure, only one n-PE in each access VPLS instance. As shown in the figure, only one n-PE in each access
network is serving as a Primary PE (P) for that VPLS instance and network is serving as a Primary PE (P) for that VPLS instance and
the other n-PE is serving as the backup PE (B). In this figure, each the other n-PE is serving as the backup PE (B). In this figure, each
primary PE has two active PWs originating from it. Therefore, when a primary PE has two active PWs originating from it. Therefore, when a
multicast, broadcast, and unknown unicast frame arrives at the multicast, broadcast, and unknown unicast frame arrives at the
primary n-PE from the access network side, the n-PE replicates the primary n-PE from the access network side, the n-PE replicates the
frame over both PWs in the core even though it only needs to send frame over both PWs in the core even though it only needs to send
the frames over a single PW (shown with “==” in the figure) to the draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2006
the frames over a single PW (shown with “==” in the figure) to the
primary n-PE on the other side. This is an unnecessary replication primary n-PE on the other side. This is an unnecessary replication
of the customer frames that consumes core-network bandwidth (half of of the customer frames that consumes core-network bandwidth (half of
the frames get discarded at the receiving n-PE). This issue gets the frames get discarded at the receiving n-PE). This issue gets
aggravated when there are more than two n-PEs per provider access aggravated when there are more than two n-PEs per provider access
network – e.g., if there are three n-PEs or four n-PEs per access network – e.g., if there are three n-PEs or four n-PEs per access
network, then 67% or 75% of core-BW for multicast, broadcast and network, then 67% or 75% of core-BW for multicast, broadcast and
unknown unicast are respectively wasted. unknown unicast are respectively wasted.
Therefore, it is recommended to have a protocol among n-PEs that can Therefore, it is recommended to have a protocol among n-PEs that can
disseminate the status of PWs (active or blocked) among themselves disseminate the status of PWs (active or blocked) among themselves
skipping to change at page 15, line 55 skipping to change at page 16, line 4
within provider Ethernet networks that can equally be applied to within provider Ethernet networks that can equally be applied to
VPLS networks. This mechanism calls for disabling MAC address VPLS networks. This mechanism calls for disabling MAC address
learning for an S-VLAN (or a service instance) within a provider learning for an S-VLAN (or a service instance) within a provider
bridge (or PE) when there is only one ingress and one egress port bridge (or PE) when there is only one ingress and one egress port
associated with that service instance on that PE. In such cases, associated with that service instance on that PE. In such cases,
there is no need to learn customer MAC addresses on that PE since there is no need to learn customer MAC addresses on that PE since
the path through that PE for that service instance is fixed. For the path through that PE for that service instance is fixed. For
example, if a service instance is associated with four CEs at four example, if a service instance is associated with four CEs at four
different sites, then the maximum number of provider bridges (or different sites, then the maximum number of provider bridges (or
PEs), that need to participate in that customer MAC address PEs), that need to participate in that customer MAC address
learning, is only three regardless of how many PEs are in the path draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2006
learning, is only three regardless of how many PEs are in the path
of that service instance. This mechanism can reduce the number of of that service instance. This mechanism can reduce the number of
MAC addressed learned in a H-VPLS with QinQ access configuration. MAC addressed learned in a H-VPLS with QinQ access configuration.
If the provider access network is of type Ethernet (e.g., IEEE If the provider access network is of type Ethernet (e.g., IEEE
802.1ad-based network), then the MSTP protocol can be used to 802.1ad-based network), then the MSTP protocol can be used to
partition access network into several loop-free spanning tree partition access network into several loop-free spanning tree
topologies where Ethernet service instances (S-VLANs) are topologies where Ethernet service instances (S-VLANs) are
distributed among these tree topologies. Furthermore, GVRP can be distributed among these tree topologies. Furthermore, GVRP can be
used to limit the scope of each service instance to a subset of its used to limit the scope of each service instance to a subset of its
associated tree topology (and thus limiting the scope of customer associated tree topology (and thus limiting the scope of customer
skipping to change at page 16, line 29 skipping to change at page 16, line 30
that need to learn customer MAC addresses for that service instance. that need to learn customer MAC addresses for that service instance.
Furthermore, [p802.1ah] provides the capability of encapsulating Furthermore, [p802.1ah] provides the capability of encapsulating
customers’ MAC addresses within the provider MAC header. A u-PE customers’ MAC addresses within the provider MAC header. A u-PE
capable of this functionality can reduce the number of MAC addressed capable of this functionality can reduce the number of MAC addressed
learned significantly within the provider network for H-VPLS with learned significantly within the provider network for H-VPLS with
QinQ access as well as H-VPLS with MPLS access. QinQ access as well as H-VPLS with MPLS access.
6. Interoperability with 802.1ad Networks 6. Interoperability with 802.1ad Networks
[VPLS-LDP] discusses H-VPLS provider-network topologies with both [RFC-4762] discusses H-VPLS provider-network topologies with both
Ethernet [P802.1ad] as well as MPLS access networks. Therefore, it is Ethernet [P802.1ad] as well as MPLS access networks. Therefore, it is
of paramount importance to ensure seamless interoperability between of paramount importance to ensure seamless interoperability between
these two types of networks. these two types of networks.
Provider bridges as specified in [P802.1ad] are intended to operate Provider bridges as specified in [P802.1ad] are intended to operate
seamlessly with customer bridges and provide the required services. seamlessly with customer bridges and provide the required services.
Therefore, if a PE is modeled based on Figures 1&2 which includes a Therefore, if a PE is modeled based on Figures 1&2 which includes a
[802.1ad] bridge module, then it should operate seamlessly with [802.1ad] bridge module, then it should operate seamlessly with
Provider Bridges given that the issues discussed in this draft have Provider Bridges given that the issues discussed in this draft have
been taken into account. been taken into account.
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Norm Finn for his comments and The authors would like to thank Norm Finn for his comments and
feedbacks. feedbacks.
8. Security Considerations 8. IANA Considerations
This document has no actions for IANA.
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
9. Security Considerations
There are no additional security aspects beyond that of VPLS/H-VPLS There are no additional security aspects beyond that of VPLS/H-VPLS
that needs to be discussed here. that needs to be discussed here.
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2006 10. Normative References
9. Normative References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels",
BCP 14, RFC 2119, March 1997.
[L2VPN-REQ] Agustyn, W. et al, "Service Requirements for Layer-2 [RFC-4762] Lasserre, M. and et al, "Virtual Private LAN Services
Provider Provisioned Virtual Provider Networks", work in progress over MPLS", RFC 4762, January 2007
[L2VPN-FRWK] Andersson, L. and et al, "Framework for Layer 2 Virtual [P802.1ad] IEEE Draft P802.1ad/D2.4 "Virtual Bridged Local Area
Private Networks (L2VPNs)", Work in Progress Networks: Provider Bridges", Work in progress, September 2004
[VPLS-LDP] Lasserre, M. and et al, "Virtual Private LAN Services [P802.1ag] IEEE Draft P802.1ag/D0.1 "Virtual Bridge Local Area
over MPLS", work in progress Networks: Connectivity Fault Management", Work in Progress, October
2004
[P802.1ad] IEEE Draft P802.1ad/D2.4 “Virtual Bridged Local Area 11. Informative References
Networks: Provider Bridges”, Work in progress, September 2004
[P802.1ag] IEEE Draft P802.1ag/D0.1 “Virtual Bridge Local Area [RFC-4665] Agustyn, W. et al, "Service Requirements for Layer-2
Networks: Connectivity Fault Management”, Work in Progress, October Provider Provisioned Virtual Provider Networks", RFC 4665, September
2004 2006
10. Informative References [RFC-4664] Andersson, L. and et al, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006
[IPLS] Shah, H. and et al, "IP-Only LAN Service (IPLS) ", work in [IPLS] Shah, H. and et al, "IP-Only LAN Service (IPLS) ", work in
progress, October 2004 progress, October 2004
[MFA-Ether] Sajassi, A. and et al, “Ethernet Service Interworking [MFA-Ether] Sajassi, A. and et al, "Ethernet Service Interworking
Over MPLS”, Work in Progress, September 2004 Over MPLS", Work in Progress, September 2004
[PWE3-Ethernet] "Encapsulation Methods for Transport of Ethernet
Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap-
01.txt, Work in progress, November 2002.
[802.1D-REV] IEEE Std. 802.1D-2003 “Media Access Control (MAC) [RFC-4448] "Encapsulation Methods for Transport of Ethernet Frames
Bridges”. [802.1D-REV] IEEE Std. 802.1D-2003 "Media Access Control (MAC)
Bridges".
[802.1Q] IEEE Std. 802.1Q-2003 "Virtual Bridged Local Area [802.1Q] IEEE Std. 802.1Q-2003 "Virtual Bridged Local Area
Networks". Networks".
[IGMP-SNOOP] Christensen, M. and et al, “Considerations for IGMP and [IGMP-SNOOP] Christensen, M. and et al, "Considerations for IGMP and
[Eth-OAM] Dinesh Mohan, Ali Sajassi, and et al, “L2VPN OAM draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
11. Authors' Addresses
[Eth-OAM] Dinesh Mohan, Ali Sajassi, and et al, "L2VPN OAM
Authors' Addresses
Ali Sajassi Ali Sajassi
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2006
Email: sajassi@cisco.com Email: sajassi@cisco.com
Yetik Serbest Yetik Serbest
SBC Labs SBC Labs
9505 Arboretum Blvd. 9505 Arboretum Blvd.
Austin, TX 78759 Austin, TX 78759
Email: yetik_serbest@labs.sbc.com Email: yetik_serbest@labs.sbc.com
Frank Brockners Frank Brockners
Cisco Systems, Inc. Cisco Systems, Inc.
skipping to change at page 18, line 27 skipping to change at page 18, line 34
40549 Duesseldorf 40549 Duesseldorf
Germany Germany
Email: fbrockne@cisco.com Email: fbrockne@cisco.com
Dinesh Mohan Dinesh Mohan
Nortel Networks Nortel Networks
3500 Carling Ave 3500 Carling Ave
Ottawa, ON K2H8E9 Ottawa, ON K2H8E9
Email: mohand@nortel.com Email: mohand@nortel.com
12. Intellectual Property Considerations Full Copyright Statement
This document is being submitted for use in IETF standards
discussions.
13. Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
14. IPR Notice draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
The IETF takes no position regarding the validity or scope of any Disclaimer of validity:
Intellectual Property Rights or other rights that might be claimed to
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2006
pertain to the implementation or use of the technology described in The IETF takes no position regarding the validity or scope of any
this document or the extent to which any license under such rights Intellectual Property Rights or other rights that might be claimed
might or might not be available; nor does it represent that it has to pertain to the implementation or use of the technology described
made any independent effort to identify any such rights. Information in this document or the extent to which any license under such
on the procedures with respect to rights in RFC documents can be rights might or might not be available; nor does it represent that
found in BCP 78 and BCP 79. 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 Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an 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 attempt made to obtain a general license or permission for the use
such proprietary rights by implementers or users of this of 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
http://www.ietf.org/ipr. at 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.
 End of changes. 65 change blocks. 
127 lines changed or deleted 127 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/