draft-ietf-l2vpn-vpls-bridge-interop-05.txt   draft-ietf-l2vpn-vpls-bridge-interop-06.txt 
Internet Working Group Ali Sajassi, Ed. Internet Working Group Ali Sajassi, Ed.
Internet Draft Frank Brockners Internet Draft Frank Brockners
Intended Status: Informational Cisco Systems Category: Informational Cisco Systems
Dinesh Mohan, Ed. Dinesh Mohan, Ed.
Nortel
Yetik Serbest Yetik Serbest
Expires: September 8, 2010 March 8, 2010 Expires: April 24, 2010 October 24, 2010
VPLS Interoperability with CE Bridges VPLS Interoperability with CE Bridges
draft-ietf-l2vpn-vpls-bridge-interop-05.txt draft-ietf-l2vpn-vpls-bridge-interop-06.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
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 at any time. It is inappropriate to use Internet-Drafts as reference
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.
This Internet-Draft will expire on July 8, 2010.
Copyright Notice Copyright and License Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007 This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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 IEEE bridges. VPLS is expected to deliver the also among customer IEEE bridges. VPLS is expected to deliver the
same level of service that current enterprise users are accustomed same level of service that current enterprise users are accustomed
to from their own enterprise bridged networks or their Ethernet to from their own enterprise bridged networks or their Ethernet
Service Providers. Service Providers.
skipping to change at page 2, line 45 skipping to change at page 3, line 6
1. Introduction.................................................... 3 1. Introduction.................................................... 3
2. Ethernet Service Instance....................................... 4 2. Ethernet Service Instance....................................... 4
3. VPLS-Capable PE Model with Bridge Module........................ 5 3. VPLS-Capable PE Model with Bridge Module........................ 5
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............................ 13
5.2. Redundancy................................................... 14 5.2. Redundancy................................................... 14
5.3. MAC Address Learning......................................... 15 5.3. MAC Address Learning......................................... 16
6. Interoperability with 802.1ad Networks......................... 16 6. Interoperability with 802.1ad Networks......................... 17
7. Acknowledgments................................................ 16 7. Acknowledgments................................................ 17
8. IANA Considerations............................................ 17 8. IANA Considerations............................................ 17
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
9. Security Considerations........................................ 17 9. Security Considerations........................................ 17
10. Normative References.......................................... 17 10. Normative References.......................................... 18
11. Informative References........................................ 17 11. Informative References........................................ 18
Authors' Addresses................................................ 18 Authors' Addresses................................................ 19
1. Introduction 1. Introduction
Virtual Private LAN Service (VPLS) is a LAN emulation service Virtual Private LAN Service (VPLS) is a LAN emulation service
intended for providing connectivity between geographically dispersed intended for providing connectivity between geographically dispersed
customer sites across MAN/WAN (over MPLS/IP) network(s), as if they customer sites across MAN/WAN (over MPLS/IP) network(s), as if they
were connected using a LAN. One of the main motivations behind VPLS were connected using a LAN. One of the main motivations behind VPLS
is its ability to provide connectivity not only among customer is its ability to provide connectivity not only among customer
routers and servers/hosts but also among IEEE customer bridges. If routers and servers/hosts but also among IEEE customer bridges. If
only connectivity among customer IP routers/hosts was desired, then only connectivity among customer IP routers/hosts was desired, then
skipping to change at page 4, line 5 skipping to change at page 4, line 17
of networks, as outlined in [RFC-4762]. of networks, as 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 five and six discuss the mandatory and optional bridges. Sections five and six discuss the mandatory and optional
issues respectively. issues respectively.
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
2. Ethernet Service Instance 2. Ethernet Service Instance
Before starting the discussion of bridging issues, it is important Before starting the discussion of bridging issues, it is important
to clarify the Ethernet Service definition. The term VPLS has to 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
skipping to change at page 4, line 48 skipping to change at page 5, line 7
networks. An ESI can span across different networks (e.g., IEEE networks. An ESI can span across different networks (e.g., IEEE
802.1ad and VPLS) belonging to the same or different administrative 802.1ad and VPLS) belonging to the same or different administrative
domains. domains.
An ESI most often represents a customer or a specific service An ESI most often represents a customer or a specific service
requested by a customer. Since traffic isolation among different requested by a customer. Since traffic isolation among different
customers (or their associated services) is of paramount importance customers (or their associated services) is of paramount importance
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 (e.g., FIB) per ESI (for both VPLS and separate MAC forwarding table (e.g., FIB - also known as filtering
IEEE 802.1ad networks) and separate broadcast domain is provided by database [IEEE 802.1D]) per ESI (for both VPLS and IEEE 802.1ad
using a full-mesh of pseudowires per ESI over the IP/MPLS core in a networks) and separate broadcast domain is provided by using a full-
VPLS network and/or a dedicated Service VLAN per ESI in an IEEE mesh of pseudowires per ESI over the IP/MPLS core in a VPLS network
802.1ad network. and/or a dedicated Service VLAN per ESI in an IEEE 802.1ad network.
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
3. VPLS-Capable PE Model with Bridge Module 3. VPLS-Capable PE Model with Bridge Module
[RFC-4664] defines three models for VPLS-capable PE (VPLS-PE) based [RFC-4664] defines three models for VPLS-capable PE (VPLS-PE) based
on the bridging functionality that needs to be supported by the PE. on the bridging functionality that needs to be supported by the PE.
If the CE devices can be routers/hosts or IEEE bridges, the second If the CE devices can be routers/hosts or IEEE bridges, the second
model from [RFC-4664] is the most suitable, and it is both adequate model from [RFC-4664] is the most suitable, and it is both adequate
to provide the VPLS level of service and consistent with the IEEE to provide the VPLS level of service and consistent with the IEEE
standards for Provider Bridges [P802.1ad]. We briefly describe the standards for Provider Bridges [P802.1ad]. We briefly describe the
second model and then expand upon this model to show its sub- second model and then expand upon this model to show its sub-
skipping to change at page 6, line 4 skipping to change at page 6, line 12
| +---------------+ | +------+ | | +---------------+ | +------+ |
| | | | | |
+-----------------------|----------------+ +-----------------------|----------------+
| |
LAN emulation (multi-access) Interface LAN emulation (multi-access) 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
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
before transmitting the frames over the set of pseudowires before transmitting the frames over the set of pseudowires
associated with that VPLS instance (assuming raw mode PWs are used associated with that VPLS instance (assuming raw mode PWs are used
as specified in [RFC-4448]). as specified in [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 2 depicts the model for the bridge module based on following Figure 2 depicts the model for the bridge module based on
[P802.1ad]. [P802.1ad].
+-------------------------------+ +-------------------------------+
| 802.1ad Bridge Module Model | | 802.1ad Bridge Module Model |
| | | |
+---+ | +------+ +-----------+ | +---+ AC | +------+ +-----------+ |
|CE |---------|C-VLAN|------| | | |CE |---------|C-VLAN|------| | |
+---+ | |bridge|------| | | +---+ | |bridge|------| | |
| +------+ | | | | +------+ | | |
| o | S-VLAN | | | o | S-VLAN | |
| o | | | | o | | | ---> to VPLS Fwdr
| o | Bridge | | | o | Bridge | |
+---+ | +------+ | | | +---+ AC | +------+ | | |
|CE |---------|C-VLAN|------| | | |CE |---------|C-VLAN|------| | |
+---+ | |bridge|------| | | +---+ | |bridge|------| | |
| +------+ +-----------+ | | +------+ | | |
+---+ AC | | | |
|CE |-----------------------| | |
+---+ | +-----------+ |
+-------------------------------+ +-------------------------------+
Figure 2. The Model of 802.1ad Bridge Module Figure 2. The Model of 802.1ad Bridge Module
The S-VLAN bridge component is always required and it is responsible The S-VLAN bridge component is always required and it is responsible
for tagging customer frames with S-VLAN tags in the ingress for tagging customer frames with S-VLAN tags in the ingress
direction (from customer UNIs) and removing S-VLAN tags in the direction (from customer UNIs) and removing S-VLAN tags in the
egress direction (toward customer UNIs). It is also responsible for egress direction (toward customer UNIs). It is also responsible for
running the provider's bridge protocol such as RSTP, MSTP, GVRP, running the provider's bridge protocol such as RSTP, MSTP, GVRP,
GMRP, etc. among provider bridges within a single administrative GMRP, etc. among provider bridges within a single administrative
skipping to change at page 7, line 4 skipping to change at page 7, line 15
such as RSTP and MSTP. The reason that such participation is such as RSTP and MSTP. The reason that such participation is
required is because a customer VLAN (C-VLAN) at one site can be required is because a customer VLAN (C-VLAN) at one site can be
mapped into a different C-VLAN at a different site or in case of mapped into a different C-VLAN at a different site or in case of
asymmetric mapping, a customer Ethernet port at one site can be asymmetric mapping, a customer Ethernet port at one site can be
mapped into a customer VLAN (or group of C-VLANs) at a different mapped into a customer VLAN (or group of C-VLANs) at a different
site. site.
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
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
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 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
skipping to change at page 8, line 4 skipping to change at page 8, line 16
capabilities in terms of customer ACs mapping to the customer capabilities in terms of customer ACs mapping to the customer
service instance. service instance.
The following table lists possible mappings that can exist between The following table lists possible mappings that can exist between
customer ACs and its associated ESI - this table is extracted from customer ACs and its associated ESI - this table is extracted from
[MFA-Ether]. As it can be seen, there are several possible ways to [MFA-Ether]. As it can be seen, there are several possible ways to
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 with untagged traffic". In the second is referred to as "port-based with untagged traffic". In the second
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
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 with tagged and untagged traffic". In the third scenario, it based with tagged and untagged traffic". In the third scenario, it
is assumed that only a single VLAN is mapped to the corresponding is 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 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.
skipping to change at page 9, line 5 skipping to change at page 9, line 16
two tags; where the outer tag is S-VLAN and the inner tag is C-VLAN two tags; where the outer tag is S-VLAN and the inner tag is C-VLAN
received from "port-based" AC. One application example for such CE received from "port-based" AC. One application example for such CE
device is in a BRAS for DSL aggregation over Metro Ethernet network. device is in a BRAS for DSL aggregation over Metro Ethernet network.
Note-3: In this asymmetric mapping scenario, it is assumed that the Note-3: In this asymmetric mapping scenario, it is assumed that the
CE device with "VLAN-based" AC can support the [P802.1ad] frame CE device with "VLAN-based" AC can support the [P802.1ad] frame
format because it will receive Ethernet frames with two tags; where format because it will receive Ethernet frames with two tags; where
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.
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
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 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 mapping or a VLAN-bundling mapping is used, then When a port-based mapping or a VLAN-bundling mapping is used, then
the PE may use an additional S-VLAN tag to mark the customer traffic the PE may use an additional S-VLAN tag to mark the customer traffic
received over that AC as belonging to a given ESI. If the PE uses received over that AC as belonging to a given ESI. If the PE uses
the additional S-VLAN tag, then in the opposite direction the PE the additional S-VLAN tag, then in the opposite direction the PE
shall strip the S-VLAN tag before sending the customer frames over SHALL strip the S-VLAN tag before sending the customer frames over
the same AC. However, when VLAN-mapping mode is used at an AC and if the same AC. 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 the PE uses S-VLAN tag locally, then if the Ethernet interface is a
UNI, the tagged frames over this interface shall have a frame format UNI, the tagged frames over this interface SHALL have a frame format
based on [802.1Q] and the PE shall translate the customer tag (C- based on [802.1Q] and the PE SHALL translate the customer tag (C-
VLAN) into the provider tag (S-VLAN) upon receiving a frame from the VLAN) into the provider tag (S-VLAN) upon receiving a frame from the
customer and in the opposite direction, the PE shall translate from customer and in the opposite direction, the PE shall translate from
provider frame format (802.1ad) back to customer frame format provider frame format (802.1ad) back to customer frame format
(802.1Q). (802.1Q).
All the above asymmetric services can be supported via the PE model All the above asymmetric services can be supported via the PE model
with the bridge module depicted in Figure 2 (based on [802.1ad]). with the bridge module depicted in Figure 2 (based on [802.1ad]).
4.2. CE Bridge Protocol Handling 4.2. CE Bridge Protocol Handling
When a VPLS-capable PE is connected to a CE bridge, then depending When a VPLS-capable PE is connected to a CE bridge, then depending
on the type of Attachment Circuit, different protocol handling may on the type of Attachment Circuit, different protocol handling may
be required by the bridge module of the PE. [P802.1ad] states that be required by the bridge module of the PE. [P802.1ad] states that
when a PE is connected to a CE bridge, then the service offered by when a PE is connected to a CE bridge, then the service offered by
the PE may appear to specific customer protocols running on the CE the PE may appear to specific customer protocols running on the CE
in one of the four ways: in one of the four ways:
i) Transparent to the operation of the protocol among CEs of a) Transparent to the operation of the protocol among CEs of
different sites using the service provided, appearing as an different sites using the service provided, appearing as an
individual LAN without bridges; or, individual LAN without bridges; or,
i i) Discarding frames, acting as a non-participating barrier to the b) Discarding frames, acting as a non-participating barrier to the
operation of the protocol; or, operation of the protocol; or,
i i i) Peering, with a local protocol entity at the point of provider c) Peering, with a local protocol entity at the point of provider
ingress and egress, participating in and terminating the ingress and egress, participating in and terminating the
operation of the protocol; or, operation of the protocol; or,
iv) Participation in individual instances of customer protocols. d) Participation in individual instances of customer protocols.
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
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
[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). In other words, when the AC is VLAN-based, component is required). In other words, when the AC is VLAN-based,
then protocol peering between CE and PE devices may be needed. There then protocol peering between CE and PE devices may be needed. There
are also protocols that require peering but are independent from the are also protocols that require peering but are independent from the
skipping to change at page 10, line 42 skipping to change at page 11, line 5
routing protocols that use LAN procedures over that ESI, then a routing protocols that use LAN procedures over that ESI, then a
partial-mesh of PWs can result in "black holing" traffic among the partial-mesh of PWs can result in "black holing" traffic among the
selected set of routers. And if the CE devices belonging to an ESI selected set of routers. And if the CE devices belonging to an ESI
are IEEE bridges, then a partial-mesh of PWs can cause broadcast are IEEE bridges, then a partial-mesh of PWs can cause broadcast
storms in the customer and provider networks. Furthermore, it can storms in the customer and provider networks. Furthermore, it can
cause multiple copies of a single frame to be received by the CE cause multiple copies of a single frame to be received by the CE
and/or PE devices. Therefore, it is of paramount importance to be and/or PE devices. Therefore, it is of paramount importance to be
able to detect PW failure and to take corrective action to prevent able to detect PW failure and to take corrective action to prevent
creation of partial-mesh of PWs. creation of partial-mesh of PWs.
One option is to define a procedure for detection of partial mesh in When the PE model depicted in Figure 2 is used, then [P802.1ag]
which each PE keeps track of the status of PW Endpoint Entities (EEs procedures could be used for detection of partial-mesh of PWs.
- e.g., VPLS forwarders) for itself as well as the ones reported by [p802.1ag] defines a set of procedures for fault detection,
other PEs. Therefore, upon a PW failure, the PE that detects the
failure not only takes notice locally but it notifies other PEs
belonging to that service instance of such failure so that all the
participant PEs have a consistent view of the PW mesh. Such a
procedure is for the detection of partial mesh per service instance
and in turn it relies on additional procedure for PW failure
detection such as BFD or VCCV. Given that there can be tens (or even
hundreds) of thousands of PWs in a PE, there can be scalability
issues with such fault detection/notification procedures.
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
However, if the PE model as depicted in Figure 2, is used, then
[P802.1ag] procedures could be used for detection of partial-mesh of
PWs. [p802.1ag] defines a set of procedures for fault detection,
verification, isolation, and notification per ESI. verification, isolation, and notification per ESI.
The fault detection mechanism of [p8021.ag] can be used to perform The 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 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 since a PW consists of two uni-directional LSPs, then one direction
connecting provider bridges are full-duplex and the failure in one can fail independently of the other. Even in this case, the
direction results in the failure of the whole link or LAN segment. procedures of [p802.1ag] can provide a consistent view of the full-
However, that is not the case for VPLS instance since a PW consists mesh to the participating PEs by relying on remote defect indication
of two uni-directional LSPs and one direction can fail independently (RDI).
of the other causing an inconsistent view of the full-mesh by the
participating PEs till the detected failure in one side is Another, less preferred, option is to define a procedure for
propagated to the other side. detection of partial mesh in which each PE keeps track of the status
of PW Endpoint Entities (EEs - e.g., VPLS forwarders) for itself as
well as the ones reported by other PEs. Therefore, upon a PW
failure, the PE that detects the failure not only takes notice
locally but it notifies other PEs belonging to that service instance
of such failure so that all the participant PEs have a consistent
view of the PW mesh. Such a procedure is for the detection of
partial mesh per service instance and in turn it relies on
additional procedure for PW failure detection such as BFD or VCCV.
Given that there can be tens (or even hundreds) of thousands of PWs
in a PE, there can be scalability issues with such fault
detection/notification procedures.
4.4. Multicast Traffic 4.4. Multicast Traffic
VPLS follows a centralized model for multicast replication within an VPLS follows a centralized model for multicast replication within an
ESI. VPLS relies on ingress replication. The ingress PE replicates ESI. VPLS relies on ingress replication. The ingress PE replicates
the multicast packet for each egress PE and sends it to the egress the multicast packet for each egress PE and sends it to the egress
PE using PtP PW over a unicast tunnel. VPLS operates on an overlay PE using PtP PW over a unicast tunnel. VPLS operates on an overlay
topology formed by the full mesh of pseudo-wires. Thus, depending on topology formed by the full mesh of pseudo-wires. Thus, depending on
the underlying topology, the same datagram can be sent multiple the underlying topology, the same datagram can be sent multiple
times down the same physical link. VPLS currently does not offer any times down the same physical link. VPLS currently does not offer any
skipping to change at page 12, line 4 skipping to change at page 12, line 16
a VPLS network, is to include the use of IGMP snooping in order to a VPLS network, is to include the use of IGMP snooping in order to
send the packet only to the PEs that have receivers for that send the packet only to the PEs that have receivers for that
traffic, rather than to all the PEs in the VPLS instance. If the traffic, rather than to all the PEs in the VPLS instance. If the
customer bridge or its network has dual-home connectivity, then for customer bridge or its network has dual-home connectivity, then for
proper operation of IGMP snooping, the PE must generate a "General proper operation of IGMP snooping, the PE must generate a "General
Query" over that customer's UNIs upon receiving a customer topology Query" over that customer's UNIs upon receiving a customer topology
change notification as described in Section 7 of [RFC-4541]. A change notification as described in Section 7 of [RFC-4541]. A
"General Query" by the PE results in proper registration of the "General Query" by the PE results in proper registration of the
customer multicast MAC address(s) at the PE when there is customer customer multicast MAC address(s) at the PE when there is customer
topology change. It should be noted that IGMP snooping provides a topology change. It should be noted that IGMP snooping provides a
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
solution for IP multicast packets and is not applicable to general solution for IP multicast packets and is not applicable to general
multicast data. 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 the ingress PE, one may want to use multicast avoid, replication at the ingress PE, one may want to use multicast
distribution trees (MDTs) in the provider core network; however, distribution trees (MDTs) in the provider core network; however,
this brings with it some potential pitfalls. If the MDT is used for this brings with it some potential pitfalls. If the MDT is used for
skipping to change at page 13, line 4 skipping to change at page 13, line 15
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. [RFC-4665] provides some examples of more than one provider network. [RFC-4665] provides some examples of
such customer network connectivity that are depicted in Figure 3 such customer network connectivity that are depicted in Figure 3
below. Such network topologies are designed to protect against the below. Such network topologies are designed to protect against the
failure or removal of network components from the customer network failure or removal of network components from the customer network
and it is assumed that the customer leverages the spanning tree and it is assumed that the customer leverages the spanning tree
protocol to protect against these cases. Therefore, in such protocol to protect against these cases. Therefore, in such
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
scenarios, it is important to flush customer MAC addresses in the scenarios, it is important to flush customer MAC addresses in the
provider network upon the customer topology change to avoid black provider network upon the customer topology change to avoid black
holing of customer frames. holing of customer frames.
+----------- +--------------- +----------- +---------------
| | | |
+------+ +------+ +------+ +------+ +------+ +------+ +------+ +------+
| CE |-----| PE | | CE |-----| PE | | CE |-----| PE | | CE |-----| PE |
|device| |device| |device| |device| SP network |device| |device| |device| |device| SP network
+------+\ +------+ +------+\ +------+ +------+\ +------+ +------+\ +------+
skipping to change at page 14, line 5 skipping to change at page 14, line 15
To address this issue, [P802.1ad] requires that customer topology To address this issue, [P802.1ad] requires that customer topology
change notification to be detected at the ingress of the S-VLAN change notification to be detected at the ingress of the S-VLAN
bridge component and the S-VLAN bridge transmits a Customer Change bridge component and the S-VLAN bridge transmits a Customer Change
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.
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
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 [RFC- out-of-band "MAC Address Withdrawal" message as specified in [RFC-
4762] 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 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.
skipping to change at page 15, line 4 skipping to change at page 15, line 24
| (B) |----------------------| (B) |_ | (B) |----------------------| (B) |_
+------+ . . +------+ +------+ . . +------+
. . . .
------------------------+ +----------------------- ------------------------+ +-----------------------
Figure 4. Bridge Module Model Figure 4. Bridge Module Model
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
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
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 Figure 4) to the the frames over a single PW (shown with "==" in Figure 4) 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
skipping to change at page 16, line 4 skipping to change at page 16, line 23
number of MAC addresses per customer sites is very limited (most number of MAC addresses per customer sites is very limited (most
often one MAC address per CE). However, when CEs are bridges, then often one MAC address per CE). However, when CEs are bridges, then
there can be many customer MAC addresses (e.g., hundreds of MAC there can be many customer MAC addresses (e.g., hundreds of MAC
addresses) associated with each CE. addresses) associated with each CE.
[P802.1ad] has devised a mechanism to alleviate MAC address learning [P802.1ad] has devised a mechanism to alleviate MAC address learning
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
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
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 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 addresses learned in a H-VPLS with QinQ access configuration. MAC addresses learned in a H-VPLS with QinQ access configuration.
skipping to change at page 16, line 50 skipping to change at page 17, line 21
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 and 2 which includes Therefore, if a PE is modeled based on Figures 1 and 2 which includes
a [802.1ad] bridge module, then it should operate seamlessly with a [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 and Samer Salam for their
feedbacks. comments and valuable feedbacks.
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9. Security Considerations 9. Security Considerations
The security considerations in this document are the same as the In addition to the security issues described in [RFC-4762], the
ones described in [RFC-4762], and there are no additional security following considerations apply:
aspects that need to be considered beyond the ones described in
[RFC-4762]. - When a CE that is a customer bridge is connected to the VPLS
network, it may be desirable to secure the end-to-end communication
between the customer bridge nodes across the VPLS network. This can
be accomplished by running [802.1AE] MAC Security between the C-VLAN
components of the customer bridges. In this case, the VPLS PEs must
ensure transparent delivery of the encryption/security protocol
datagrams using the Bridge Group Address [802.1ad].
- When a CE that is a customer bridge is connected to the VPLS
network, it may be desirable to secure the communication between the
customer bridge and its directly connected PE. If the PE is modeled
to include a [802.1ad] bridge module, then this can be achieved by
running MAC Security between the customer bridge and the S-VLAN
Component of the VPLS PE as described in section 7.7.2 of [802.1AX].
- When and 802.1ad network is connected to a VPLS network, it is
possible to secure the NNI between the two networks using the
procedures of [802.1AE] and [802.1AX] between the S-VLAN Components
of the Provider Edge Bridge and the VPLS PE connecting to it, as
long as the PE is modeled to include a [802.1ad] bridge module.
10. Normative References 10. Normative References
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-4762] Lasserre, M. and et al, "Virtual Private LAN Services [RFC-4762] Lasserre, M. and et al, "Virtual Private LAN Services
over MPLS", RFC 4762, January 2007 over MPLS", RFC 4762, January 2007
[P802.1ad] IEEE Draft P802.1ad/D2.4 "Virtual Bridged Local Area [P802.1ad] IEEE Draft P802.1ad/D2.4 "Virtual Bridged Local Area
skipping to change at page 17, line 43 skipping to change at page 18, line 32
11. Informative References 11. Informative References
[RFC-4665] Agustyn, W. et al, "Service Requirements for Layer-2 [RFC-4665] Agustyn, W. et al, "Service Requirements for Layer-2
Provider Provisioned Virtual Provider Networks", RFC 4665, September Provider Provisioned Virtual Provider Networks", RFC 4665, September
2006 2006
[RFC-4664] Andersson, L. and et al, "Framework for Layer 2 Virtual [RFC-4664] Andersson, L. and et al, "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", RFC 4664, September 2006 Private Networks (L2VPNs)", RFC 4664, September 2006
[IPLS] Shah, H. and et al, "IP-Only LAN Service (IPLS)", draft-ietf- [IPLS] Shah, H. and et al, "IP-Only LAN Service (IPLS)", draft-ietf-
l2vpn-ipls-08.txt, work in progress, February 2008 l2vpn-ipls-09.txt, work in progress, February 2009
[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
[RFC-4448] "Encapsulation Methods for Transport of Ethernet Frames [RFC-4448] "Encapsulation Methods for Transport of Ethernet Frames
Over IP/MPLS Networks", RFC 4448, April 2006 Over IP/MPLS Networks", RFC 4448, April 2006
draft-ietf-l2vpn-vpls-bridge-interop.txt November 2007
[802.1D-REV] IEEE Std. 802.1D-2003 "Media Access Control (MAC) [802.1D-REV] IEEE Std. 802.1D-2003 "Media Access Control (MAC)
Bridges". 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".
[RFC-4541] Christensen, M. and et al, "Considerations for IGMP and [RFC-4541] Christensen, M. and et al, "Considerations for IGMP and
MLD Snooping Switches", Work in progress, May 2004 MLD Snooping Switches", Work in progress, May 2004
[Eth-OAM] Dinesh Mohan, Ali Sajassi, and et al, "L2VPN OAM [Eth-OAM] Dinesh Mohan, Ali Sajassi, and et al, "L2VPN OAM
Requirements and Framework", draft-ietf-l2vpn-oam-req-frmk-10.txt, Requirements and Framework", draft-ietf-l2vpn-oam-req-frmk-10.txt,
Work in progress, July 2008 Work in progress, November 2010
Authors' Addresses 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
Email: sajassi@cisco.com Email: sajassi@cisco.com
Yetik Serbest Yetik Serbest
 End of changes. 44 change blocks. 
100 lines changed or deleted 96 lines changed or added

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