draft-ietf-l2vpn-vpls-ldp-08.txt   draft-ietf-l2vpn-vpls-ldp-09.txt 
Internet Draft Document Marc Lasserre Internet Draft Document Marc Lasserre
L2VPN Working Group Vach Kompella L2VPN Working Group Vach Kompella
draft-ietf-l2vpn-vpls-ldp-08.txt (Editors) draft-ietf-l2vpn-vpls-ldp-09.txt (Editors)
Expires: May 2006 November 2005 Virtual Private LAN Services Using LDP
Virtual Private LAN Services over MPLS
Status of this Memo Status of this Memo
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 months and may be updated, replaced, or obsoleted by other
skipping to change at page 1, line 48 skipping to change at page 1, line 46
This document describes a Virtual Private LAN Service (VPLS) This document describes a Virtual Private LAN Service (VPLS)
solution using pseudo-wires, a service previously implemented over solution using pseudo-wires, a service previously implemented over
other tunneling technologies and known as Transparent LAN Services other tunneling technologies and known as Transparent LAN Services
(TLS). A VPLS creates an emulated LAN segment for a given set of (TLS). A VPLS creates an emulated LAN segment for a given set of
users, i.e., it creates a Layer 2 broadcast domain that is fully users, i.e., it creates a Layer 2 broadcast domain that is fully
capable of learning and forwarding on Ethernet MAC addresses that capable of learning and forwarding on Ethernet MAC addresses that
is closed to a given set of users. Multiple VPLS services can be is closed to a given set of users. Multiple VPLS services can be
supported from a single PE node. supported from a single PE node.
This document describes the control plane functions of signaling This document describes the control plane functions of signaling
pseudo-wire labels using LDP [RFC3036], extending [PWE3-CTRL]. It pseudo-wire labels using LDP [RFC3036], extending [RFC4447]. It is
is agnostic to discovery protocols. The data plane functions of agnostic to discovery protocols. The data plane functions of
forwarding are also described, focusing, in particular, on the forwarding are also described, focusing, in particular, on the
learning of MAC addresses. The encapsulation of VPLS packets is learning of MAC addresses. The encapsulation of VPLS packets is
described by [PWE3-ETHERNET]. described by [RFC4448].
1. Conventions 1. 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 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119. this document are to be interpreted as described in RFC 2119
[RFC2119].
2. Table of Contents 2. Table of Contents
1. Conventions.....................................................2 1. Conventions.....................................................2
2. Table of Contents...............................................2 2. Table of Contents...............................................2
3. Introduction....................................................3 3. Introduction....................................................3
3.1. Terminology...................................................3 3.1. Terminology...................................................3
3.2. Acronyms......................................................4 3.2. Acronyms......................................................4
4. Topological Model for VPLS......................................4 4. Topological Model for VPLS......................................5
4.1. Flooding and Forwarding.......................................5 4.1. Flooding and Forwarding.......................................5
4.2. Address Learning..............................................6 4.2. Address Learning..............................................6
4.3. Tunnel Topology...............................................6 4.3. Tunnel Topology...............................................6
4.4. Loop free VPLS................................................6 4.4. Loop free VPLS................................................6
5. Discovery.......................................................7 5. Discovery.......................................................7
6. Control Plane...................................................7 6. Control Plane...................................................7
6.1. LDP Based Signaling of Demultiplexers.........................7 6.1. LDP Based Signaling of Demultiplexers.........................7
6.1.1. Using the Generalized PWid FEC Element......................7 6.1.1. Using the Generalized PWid FEC Element......................8
6.2. MAC Address Withdrawal........................................8 6.2. MAC Address Withdrawal........................................8
6.2.1. MAC List TLV................................................9 6.2.1. MAC List TLV................................................9
6.2.2. Address Withdraw Message Containing MAC List TLV...........10 6.2.2. Address Withdraw Message Containing MAC List TLV...........10
7. Data Forwarding on an Ethernet PW..............................10 7. Data Forwarding on an Ethernet PW..............................10
7.1. VPLS Encapsulation actions...................................10 7.1. VPLS Encapsulation actions...................................10
7.2. VPLS Learning actions........................................11 7.2. VPLS Learning actions........................................11
8. Data Forwarding on an Ethernet VLAN PW.........................12 8. Data Forwarding on an Ethernet VLAN PW.........................12
8.1. VPLS Encapsulation actions...................................12 8.1. VPLS Encapsulation actions...................................12
9. Operation of a VPLS............................................13 9. Operation of a VPLS............................................13
9.1. MAC Address Aging............................................14 9.1. MAC Address Aging............................................14
10. A Hierarchical VPLS Model.....................................14 10. A Hierarchical VPLS Model.....................................14
10.1. Hierarchical connectivity...................................15 10.1. Hierarchical connectivity...................................15
10.1.1. Spoke connectivity for bridging-capable devices...........15 10.1.1. Spoke connectivity for bridging-capable devices...........15
10.1.2. Advantages of spoke connectivity..........................17 10.1.2. Advantages of spoke connectivity..........................17
10.1.3. Spoke connectivity for non-bridging devices...............17 10.1.3. Spoke connectivity for non-bridging devices...............17
10.2. Redundant Spoke Connections.................................19 10.2. Redundant Spoke Connections.................................19
10.2.1. Dual-homed MTU-s..........................................19 10.2.1. Dual-homed MTU-s..........................................19
10.2.2. Failure detection and recovery............................20 10.2.2. Failure detection and recovery............................20
10.3. Multi-domain VPLS service...................................20 10.3. Multi-domain VPLS service...................................21
11. Hierarchical VPLS model using Ethernet Access Network.........21 11. Hierarchical VPLS model using Ethernet Access Network.........21
11.1. Scalability.................................................22 11.1. Scalability.................................................22
11.2. Dual Homing and Failure Recovery............................22 11.2. Dual Homing and Failure Recovery............................22
12. Contributors..................................................22 12. Contributors..................................................22
13. Acknowledgments...............................................22 13. Acknowledgments...............................................23
14. Security Considerations.......................................23 14. Security Considerations.......................................23
15. IANA Considerations...........................................23 15. IANA Considerations...........................................24
16. References....................................................24 16. References....................................................24
16.1. Normative References........................................24 16.1. Normative References........................................24
16.2. Informative References......................................24 16.2. Informative References......................................25
17. Appendix: VPLS Signaling using the PWid FEC Element...........25 17. Appendix: VPLS Signaling using the PWid FEC Element...........25
18. Authors' Addresses............................................25 18. Authors' Addresses............................................26
3. Introduction 3. Introduction
Ethernet has become the predominant technology for Local Area Ethernet has become the predominant technology for Local Area
Network (LAN) connectivity and is gaining acceptance as an access Network (LAN) connectivity and is gaining acceptance as an access
technology, specifically in Metropolitan and Wide Area Networks technology, specifically in Metropolitan and Wide Area Networks
(MAN and WAN, respectively). The primary motivation behind Virtual (MAN and WAN, respectively). The primary motivation behind Virtual
Private LAN Services (VPLS) is to provide connectivity between Private LAN Services (VPLS) is to provide connectivity between
geographically dispersed customer sites across MANs and WANs, as if geographically dispersed customer sites across MANs and WANs, as if
they were connected using a LAN. The intended application for the they were connected using a LAN. The intended application for the
skipping to change at page 3, line 36 skipping to change at page 3, line 37
application application
Broadcast and multicast services are available over traditional Broadcast and multicast services are available over traditional
LANs. Sites that belong to the same broadcast domain and that are LANs. Sites that belong to the same broadcast domain and that are
connected via an MPLS network expect broadcast, multicast and connected via an MPLS network expect broadcast, multicast and
unicast traffic to be forwarded to the proper location(s). This unicast traffic to be forwarded to the proper location(s). This
requires MAC address learning/aging on a per pseudo-wire basis, requires MAC address learning/aging on a per pseudo-wire basis,
packet replication across pseudo-wires for multicast/broadcast packet replication across pseudo-wires for multicast/broadcast
traffic and for flooding of unknown unicast destination traffic. traffic and for flooding of unknown unicast destination traffic.
[PWE3-ETHERNET] defines how to carry Layer 2 (L2) frames over [RFC4448] defines how to carry Layer 2 (L2) frames over point-to-
point-to-point pseudo-wires (PW). This document describes point pseudo-wires (PW). This document describes extensions to
extensions to [PWE3-CTRL] for transporting Ethernet/802.3 and VLAN [RFC4447] for transporting Ethernet/802.3 and VLAN [802.1Q] traffic
[802.1Q] traffic across multiple sites that belong to the same L2 across multiple sites that belong to the same L2 broadcast domain
broadcast domain or VPLS. Note that the same model can be applied or VPLS. Note that the same model can be applied to other 802.1
to other 802.1 technologies. It describes a simple and scalable technologies. It describes a simple and scalable way to offer
way to offer Virtual LAN services, including the appropriate Virtual LAN services, including the appropriate flooding of
flooding of broadcast, multicast and unknown unicast destination broadcast, multicast and unknown unicast destination traffic over
traffic over MPLS, without the need for address resolution servers MPLS, without the need for address resolution servers or other
or other external servers, as discussed in [L2VPN-REQ]. external servers, as discussed in [L2VPN-REQ].
The following discussion applies to devices that are VPLS capable The following discussion applies to devices that are VPLS capable
and have a means of tunneling labeled packets amongst each other. and have a means of tunneling labeled packets amongst each other.
The resulting set of interconnected devices forms a private MPLS The resulting set of interconnected devices forms a private MPLS
VPN. VPN.
3.1. Terminology 3.1. Terminology
Q-in-Q 802.1ad Provider Bridge extensions also known Q-in-Q 802.1ad Provider Bridge extensions also known
as stackable VLANs or Q-in-Q. as stackable VLANs or Q-in-Q.
Qualified learning Learning mode in which each customer VLAN is Qualified learning Learning mode in which each customer VLAN is
mapped to its own VPLS instance. mapped to its own VPLS instance.
Service delimiter Information used to identify a specific customer Service delimitor Information used to identify a specific customer
service instance. This is typically encoded in service instance. This is typically encoded in
the encapsulation header of customer frames the encapsulation header of customer frames
(e.g. VLAN Id). (e.g. VLAN Id).
Tagged frame Frame with an 802.1Q VLAN identifier. Tagged frame Frame with an 802.1Q VLAN identifier.
Unqualified learning Learning mode where all the VLANs of a single Unqualified learning Learning mode where all the VLANs of a single
customer are mapped to a single VPLS. customer are mapped to a single VPLS.
Untagged frame Frame without an 802.1Q VLAN identifier Untagged frame Frame without an 802.1Q VLAN identifier
skipping to change at page 4, line 33 skipping to change at page 4, line 34
AC Attachment Circuit AC Attachment Circuit
BPDU Bridge Protocol Data Unit BPDU Bridge Protocol Data Unit
CE Customer Edge device CE Customer Edge device
FEC Forwarding Equivalence Class FEC Forwarding Equivalence Class
FIB Forwarding Information Base FIB Forwarding Information Base
GRE Generic Routing Encapsulation
IPsec IP secutity
L2TP Layer Two Tunneling Protocol
LAN Local Area Network LAN Local Area Network
LDP Label Distribution Protocol LDP Label Distribution Protocol
MTU-s Multi-Tenant Unit switch MTU-s Multi-Tenant Unit switch
PE Provider Edge device PE Provider Edge device
PW Pseudo-wire PW Pseudo-wire
skipping to change at page 5, line 29 skipping to change at page 5, line 37
+-----+ +-----+
| CE3 | | CE3 |
+-----+ +-----+
Site 3 Site 3
Figure 1: Topological Model of a VPLS for Customer X Figure 1: Topological Model of a VPLS for Customer X
With three sites With three sites
We note here again that while this document shows specific examples We note here again that while this document shows specific examples
using MPLS transport tunnels, other tunnels that can be used by PWs using MPLS transport tunnels, other tunnels that can be used by PWs
(as mentioned in [PWE-CTRL]), e.g., GRE, L2TP, IPSEC, etc., can (as mentioned in [RFC4447]), e.g., GRE, L2TP, IPsec, etc., can also
also be used, as long as the originating PE can be identified, be used, as long as the originating PE can be identified, since
since this is used in the MAC learning process. this is used in the MAC learning process.
The scope of the VPLS lies within the PEs in the service provider The scope of the VPLS lies within the PEs in the service provider
network, highlighting the fact that apart from customer service network, highlighting the fact that apart from customer service
delineation, the form of access to a customer site is not relevant delineation, the form of access to a customer site is not relevant
to the VPLS [L2VPN-REQ]. In other words, the attachment circuit to the VPLS [L2VPN-REQ]. In other words, the attachment circuit
(AC) connected to the customer could be a physical Ethernet port, a (AC) connected to the customer could be a physical Ethernet port, a
logical (tagged) Ethernet port, an ATM PVC carrying Ethernet logical (tagged) Ethernet port, an ATM PVC carrying Ethernet
frames, etc., or even an Ethernet PW. frames, etc., or even an Ethernet PW.
The PE is typically an edge router capable of running the LDP The PE is typically an edge router capable of running the LDP
skipping to change at page 5, line 47 skipping to change at page 6, line 4
(AC) connected to the customer could be a physical Ethernet port, a (AC) connected to the customer could be a physical Ethernet port, a
logical (tagged) Ethernet port, an ATM PVC carrying Ethernet logical (tagged) Ethernet port, an ATM PVC carrying Ethernet
frames, etc., or even an Ethernet PW. frames, etc., or even an Ethernet PW.
The PE is typically an edge router capable of running the LDP The PE is typically an edge router capable of running the LDP
signaling protocol and/or routing protocols to set up PWs. In signaling protocol and/or routing protocols to set up PWs. In
addition, it is capable of setting up transport tunnels to other addition, it is capable of setting up transport tunnels to other
PEs and delivering traffic over PWs. PEs and delivering traffic over PWs.
4.1. Flooding and Forwarding 4.1. Flooding and Forwarding
One of attributes of an Ethernet service is that frames sent to One of attributes of an Ethernet service is that frames sent to
broadcast addresses and to unknown destination MAC addresses are broadcast addresses and to unknown destination MAC addresses are
flooded to all ports. To achieve flooding within the service flooded to all ports. To achieve flooding within the service
provider network, all unknown unicast, broadcast and multicast provider network, all unknown unicast, broadcast and multicast
frames are flooded over the corresponding PWs to all PE nodes frames are flooded over the corresponding PWs to all PE nodes
participating in the VPLS, as well as to all ACs. participating in the VPLS, as well as to all ACs.
Note that multicast frames are a special case and do not Note that multicast frames are a special case and do not
necessarily have to be sent to all VPN members. For simplicity, necessarily have to be sent to all VPN members. For simplicity,
the default approach of broadcasting multicast frames can be used. the default approach of broadcasting multicast frames is used.
The use of IGMP snooping and PIM snooping techniques should be used
to improve multicast efficiency. A description of these techniques
is beyond the scope of this document.
To forward a frame, a PE MUST be able to associate a destination To forward a frame, a PE MUST be able to associate a destination
MAC address with a PW. It is unreasonable and perhaps impossible MAC address with a PW. It is unreasonable and perhaps impossible
to require PEs to statically configure an association of every to require PEs to statically configure an association of every
possible destination MAC address with a PW. Therefore, VPLS- possible destination MAC address with a PW. Therefore, VPLS-
capable PEs SHOULD have the capability to dynamically learn MAC capable PEs SHOULD have the capability to dynamically learn MAC
addresses on both ACs and PWs and to forward and replicate packets addresses on both ACs and PWs and to forward and replicate packets
across both ACs and PWs. across both ACs and PWs.
4.2. Address Learning 4.2. Address Learning
skipping to change at page 7, line 45 skipping to change at page 7, line 50
A full mesh of LDP sessions is used to establish the mesh of PWs. A full mesh of LDP sessions is used to establish the mesh of PWs.
The requirement for a full mesh of PWs may result in a large number The requirement for a full mesh of PWs may result in a large number
of targeted LDP sessions. Section 8 discusses the option of of targeted LDP sessions. Section 8 discusses the option of
setting up hierarchical topologies in order to minimize the size of setting up hierarchical topologies in order to minimize the size of
the VPLS full mesh. the VPLS full mesh.
Once an LDP session has been formed between two PEs, all PWs Once an LDP session has been formed between two PEs, all PWs
between these two PEs are signaled over this session. between these two PEs are signaled over this session.
In [PWE3-CTRL], two types of FECs are described, the PWid FEC In [RFC4447], two types of FECs are described, the PWid FEC Element
Element (FEC type 128) and the Generalized PWid FEC Element (FEC (FEC type 128) and the Generalized PWid FEC Element (FEC type 129).
type 129). The original FEC element used for VPLS was compatible The original FEC element used for VPLS was compatible with the PWid
with the PWid FEC Element. The text for signaling using PWid FEC FEC Element. The text for signaling using PWid FEC Element has
Element has been moved to Appendix 1. What we describe below been moved to Appendix 1. What we describe below replaces that
replaces that with a more generalized L2VPN descriptor, the with a more generalized L2VPN descriptor, the Generalized PWid FEC
Generalized PWid FEC Element. Element.
6.1.1. Using the Generalized PWid FEC Element 6.1.1. Using the Generalized PWid FEC Element
[PWE3-CTRL] describes a generalized FEC structure that is be used [RFC4447] describes a generalized FEC structure that is be used for
for VPLS signaling in the following manner. We describe the VPLS signaling in the following manner. We describe the assignment
assignment of the Generalized PWid FEC Element fields in the of the Generalized PWid FEC Element fields in the context of VPLS
context of VPLS signaling. signaling.
Control bit (C): This bit is used to signal the use of the control Control bit (C): This bit is used to signal the use of the control
word as specified in [PWE3-CTRL]. word as specified in [RFC4447].
PW type: The allowed PW types are Ethernet (0x0005) and Ethernet PW type: The allowed PW types are Ethernet (0x0005) and Ethernet
tagged mode (0x004) as specified in [IANA]. tagged mode (0x004) as specified in [IANA].
PW info length: As specified in [PWE3-CTRL]. PW info length: As specified in [RFC4447].
AGI, Length, Value: The unique name of this VPLS. The AGI Attachment Group Identifier (AGI), Length, Value: The unique name
identifies a type of name, Length denotes the length of Value, of this VPLS. The AGI identifies a type of name, Length denotes
which is the name of the VPLS. We use the term AGI interchangeably the length of Value, which is the name of the VPLS. We use the
with VPLS identifier. term AGI interchangeably with VPLS identifier.
TAII, SAII: These are null because the mesh of PWs in a VPLS Target Attachment Individual Identifier (TAII), Source Attachment
terminate on MAC learning tables, rather than on individual Individual Identifier (SAII): These are null because the mesh of
attachment circuits. The use of non-null TAII and SAII is reserved PWs in a VPLS terminate on MAC learning tables, rather than on
for future enhancements. individual attachment circuits. The use of non-null TAII and SAII
is reserved for future enhancements.
Interface Parameters: The relevant interface parameters are: Interface Parameters: The relevant interface parameters are:
- MTU: the MTU (Maximum Transmission Unit) of the VPLS MUST be - MTU: the MTU (Maximum Transmission Unit) of the VPLS MUST be
the same across all the PWs in the mesh. the same across all the PWs in the mesh.
- Optional Description String: same as [PWE3-CTRL]. - Optional Description String: same as [RFC4447].
- Requested VLAN ID: If the PW type is Ethernet tagged mode, - Requested VLAN ID: If the PW type is Ethernet tagged mode,
this parameter may be used to signal the insertion of the this parameter may be used to signal the insertion of the
appropriate VLAN ID, as defined in [PWE3-ETH]. appropriate VLAN ID, as defined in [RFC4448].
6.2. MAC Address Withdrawal 6.2. MAC Address Withdrawal
It MAY be desirable to remove or unlearn MAC addresses that have It MAY be desirable to remove or unlearn MAC addresses that have
been dynamically learned for faster convergence. This is been dynamically learned for faster convergence. This is
accomplished by sending an LDP Address Withdraw Message with the accomplished by sending an LDP Address Withdraw Message with the
list of MAC addresses to be removed to all other PEs over the list of MAC addresses to be removed to all other PEs over the
corresponding LDP sessions. corresponding LDP sessions.
We introduce an optional MAC List TLV in LDP to specify a list of We introduce an optional MAC List TLV in LDP to specify a list of
skipping to change at page 10, line 37 skipping to change at page 10, line 41
over which the message was received over which the message was received
The scope of a MAC List TLV is the VPLS specified in the FEC TLV in The scope of a MAC List TLV is the VPLS specified in the FEC TLV in
the MAC Address Withdraw Message. The number of MAC addresses can the MAC Address Withdraw Message. The number of MAC addresses can
be deduced from the length field in the TLV. be deduced from the length field in the TLV.
7. Data Forwarding on an Ethernet PW 7. Data Forwarding on an Ethernet PW
This section describes the data plane behavior on an Ethernet This section describes the data plane behavior on an Ethernet
PW used in a VPLS. While the encapsulation is similar to that PW used in a VPLS. While the encapsulation is similar to that
described in [PWE3-ETHERNET], the functions of stripping the described in [RFC4448], the functions of stripping the service-
service-delimiting tag and using a "normalized" Ethernet frame are delimiting tag and using a "normalized" Ethernet frame are
described. described.
7.1. VPLS Encapsulation actions 7.1. VPLS Encapsulation actions
In a VPLS, a customer Ethernet frame without preamble is In a VPLS, a customer Ethernet frame without preamble is
encapsulated with a header as defined in [PWE3-ETHERNET]. A encapsulated with a header as defined in [RFC4448]. A customer
customer Ethernet frame is defined as follows: Ethernet frame is defined as follows:
- If the frame, as it arrives at the PE, has an encapsulation - If the frame, as it arrives at the PE, has an encapsulation
that is used by the local PE as a service delimiter, i.e., to that is used by the local PE as a service delimiter, i.e., to
identify the customer and/or the particular service of that identify the customer and/or the particular service of that
customer, then that encapsulation may be stripped before the customer, then that encapsulation may be stripped before the
frame is sent into the VPLS. As the frame exits the VPLS, frame is sent into the VPLS. As the frame exits the VPLS,
the frame may have a service-delimiting encapsulation the frame may have a service-delimiting encapsulation
inserted. inserted.
- If the frame, as it arrives at the PE, has an encapsulation - If the frame, as it arrives at the PE, has an encapsulation
skipping to change at page 11, line 36 skipping to change at page 11, line 39
network, then the tag is not modified or stripped, as it belongs network, then the tag is not modified or stripped, as it belongs
with the rest of the customer frame. with the rest of the customer frame.
By following the above rules, the Ethernet frame that traverses a By following the above rules, the Ethernet frame that traverses a
VPLS is always a customer Ethernet frame. Note that the two VPLS is always a customer Ethernet frame. Note that the two
actions, at ingress and egress, of dealing with service delimiters actions, at ingress and egress, of dealing with service delimiters
are local actions that neither PE has to signal to the other. They are local actions that neither PE has to signal to the other. They
allow, for example, a mix-and-match of VLAN tagged and untagged allow, for example, a mix-and-match of VLAN tagged and untagged
services at either end, and do not carry across a VPLS a VLAN tag services at either end, and do not carry across a VPLS a VLAN tag
that has local significance only. The service delimiter may be an that has local significance only. The service delimiter may be an
MPLS label also, whereby an Ethernet PW given by [PWE3-ETHERNET] MPLS label also, whereby an Ethernet PW given by [RFC4448] can
can serve as the access side connection into a PE. An RFC1483 serve as the access side connection into a PE. An RFC1483 Bridged
Bridged PVC encapsulation could also serve as a service delimiter. PVC encapsulation could also serve as a service delimiter. By
By limiting the scope of locally significant encapsulations to the limiting the scope of locally significant encapsulations to the
edge, hierarchical VPLS models can be developed that provide the edge, hierarchical VPLS models can be developed that provide the
capability to network-engineer scalable VPLS deployments, as capability to network-engineer scalable VPLS deployments, as
described below. described below.
7.2. VPLS Learning actions 7.2. VPLS Learning actions
Learning is done based on the customer Ethernet frame as defined Learning is done based on the customer Ethernet frame as defined
above. The Forwarding Information Base (FIB) keeps track of the above. The Forwarding Information Base (FIB) keeps track of the
mapping of customer Ethernet frame addressing and the appropriate mapping of customer Ethernet frame addressing and the appropriate
PW to use. We define two modes of learning: qualified and PW to use. We define two modes of learning: qualified and
unqualified learning. unqualified learning. Qualified learning is the default mode and
MUST be supported. Support of unqualified learning is OPTIONAL.
In unqualified learning, all the VLANs of a single customer are In unqualified learning, all the VLANs of a single customer are
handled by a single VPLS, which means they all share a single handled by a single VPLS, which means they all share a single
broadcast domain and a single MAC address space. This means that broadcast domain and a single MAC address space. This means that
MAC addresses need to be unique and non-overlapping among customer MAC addresses need to be unique and non-overlapping among customer
VLANs or else they cannot be differentiated within the VPLS VLANs or else they cannot be differentiated within the VPLS
instance and this can result in loss of customer frames. An instance and this can result in loss of customer frames. An
application of unqualified learning is port-based VPLS service for application of unqualified learning is port-based VPLS service for
a given customer (e.g., customer with non-multiplexed AC where all a given customer (e.g., customer with non-multiplexed AC where all
the traffic on a physical port, which may include multiple customer the traffic on a physical port, which may include multiple customer
skipping to change at page 12, line 25 skipping to change at page 12, line 31
FIB, i.e., each customer VLAN has its own MAC address space. Since FIB, i.e., each customer VLAN has its own MAC address space. Since
VPLS broadcasts multicast frames by default, qualified learning VPLS broadcasts multicast frames by default, qualified learning
offers the advantage of limiting the broadcast scope to a given offers the advantage of limiting the broadcast scope to a given
customer VLAN. Qualified learning can result in large FIB table customer VLAN. Qualified learning can result in large FIB table
sizes, because the logical MAC address is now a VLAN tag + MAC sizes, because the logical MAC address is now a VLAN tag + MAC
address. address.
For STP to work in qualified learning mode, a VPLS PE must be able For STP to work in qualified learning mode, a VPLS PE must be able
to forward STP BPDUs over the proper VPLS instance. In a to forward STP BPDUs over the proper VPLS instance. In a
hierarchical VPLS case (see details in Section 10), service hierarchical VPLS case (see details in Section 10), service
delimiting tags (Q-in-Q or [PWE3-ETHERNET]) can be added such that delimiting tags (Q-in-Q or [RFC4448]) can be added such that PEs
PEs can unambiguously identify all customer traffic, including STP can unambiguously identify all customer traffic, including STP
BPDUs. In a basic VPLS case, upstream switches must insert such BPDUs. In a basic VPLS case, upstream switches must insert such
service delimiting tags. When an access port is shared among service delimiting tags. When an access port is shared among
multiple customers, a reserved VLAN per customer domain must be multiple customers, a reserved VLAN per customer domain must be
used to carry STP traffic. The STP frames are encapsulated with a used to carry STP traffic. The STP frames are encapsulated with a
unique provider tag per customer (as the regular customer traffic), unique provider tag per customer (as the regular customer traffic),
and a PEs looks up the provider tag to send such frames across the and a PEs looks up the provider tag to send such frames across the
proper VPLS instance. proper VPLS instance.
8. Data Forwarding on an Ethernet VLAN PW 8. Data Forwarding on an Ethernet VLAN PW
This section describes the data plane behavior on an Ethernet VLAN This section describes the data plane behavior on an Ethernet VLAN
PW in a VPLS. While the encapsulation is similar to that described PW in a VPLS. While the encapsulation is similar to that described
in [PWE3-ETHERNET], the functions of imposing tags and using a in [RFC4448], the functions of imposing tags and using a
"normalized" Ethernet frame are described. The learning behavior "normalized" Ethernet frame are described. The learning behavior
is the same as for Ethernet PWs. is the same as for Ethernet PWs.
8.1. VPLS Encapsulation actions 8.1. VPLS Encapsulation actions
In a VPLS, a customer Ethernet frame without preamble is In a VPLS, a customer Ethernet frame without preamble is
encapsulated with a header as defined in [PWE3-ETHERNET]. A encapsulated with a header as defined in [RFC4448]. A customer
customer Ethernet frame is defined as follows: Ethernet frame is defined as follows:
- If the frame, as it arrives at the PE, has an encapsulation - If the frame, as it arrives at the PE, has an encapsulation
that is part of the customer frame, and is also used by the that is part of the customer frame, and is also used by the
local PE as a service delimiter, i.e., to identify the local PE as a service delimiter, i.e., to identify the
customer and/or the particular service of that customer, then customer and/or the particular service of that customer, then
that encapsulation is preserved as the frame is sent into the that encapsulation is preserved as the frame is sent into the
VPLS, unless the Requested VLAN ID optional parameter was VPLS, unless the Requested VLAN ID optional parameter was
signaled. In that case, the VLAN tag is overwritten before signaled. In that case, the VLAN tag is overwritten before
the frame is sent out on the PW. the frame is sent out on the PW.
skipping to change at page 13, line 34 skipping to change at page 13, line 41
9. Operation of a VPLS 9. Operation of a VPLS
We show here, in Figure 2 below, an example of how a VPLS works. We show here, in Figure 2 below, an example of how a VPLS works.
The following discussion uses the figure below, where a VPLS has The following discussion uses the figure below, where a VPLS has
been set up between PE1, PE2 and PE3. The VPLS connects a customer been set up between PE1, PE2 and PE3. The VPLS connects a customer
with 4 sites labeled A1, A2, A3 and A4 through CE1, CE2, CE3 and with 4 sites labeled A1, A2, A3 and A4 through CE1, CE2, CE3 and
CE4, respectively. CE4, respectively.
Initially, the VPLS is set up so that PE1, PE2 and PE3 have a full Initially, the VPLS is set up so that PE1, PE2 and PE3 have a full
mesh of Ethernet PWs. The VPLS instance is assigned a identifier mesh of Ethernet PWs. The VPLS instance is assigned an identifier
(AGI). For the above example, say PE1 signals PW label 102 to PE2 (AGI). For the above example, say PE1 signals PW label 102 to PE2
and 103 to PE3, and PE2 signals PW label 201 to PE1 and 203 to PE3. and 103 to PE3, and PE2 signals PW label 201 to PE1 and 203 to PE3.
----- -----
/ A1 \ / A1 \
---- ----CE1 | ---- ----CE1 |
/ \ -------- ------- / | | / \ -------- ------- / | |
| A2 CE2- / \ / PE1 \ / | A2 CE2- / \ / PE1 \ /
\ / \ / \---/ \ ----- \ / \ / \---/ \ -----
---- ---PE2 | ---- ---PE2 |
skipping to change at page 14, line 46 skipping to change at page 15, line 11
In many cases, service providers place smaller edge devices in In many cases, service providers place smaller edge devices in
multi-tenant buildings and aggregate them into a PE in a large multi-tenant buildings and aggregate them into a PE in a large
Central Office (CO) facility. In some instances, standard IEEE Central Office (CO) facility. In some instances, standard IEEE
802.1q (Dot 1Q) tagging techniques may be used to facilitate 802.1q (Dot 1Q) tagging techniques may be used to facilitate
mapping CE interfaces to VPLS access circuits at a PE. mapping CE interfaces to VPLS access circuits at a PE.
It is often beneficial to extend the VPLS service tunneling It is often beneficial to extend the VPLS service tunneling
techniques into the access switch domain. This can be accomplished techniques into the access switch domain. This can be accomplished
by treating the access device as a PE and provisioning PWs between by treating the access device as a PE and provisioning PWs between
it and every other edge, as a basic VPLS. An alternative is to it and every other edge, as a basic VPLS. An alternative is to
utilize [PWE3-ETHERNET] PWs or Q-in-Q logical interfaces between utilize [RFC4448] PWs or Q-in-Q logical interfaces between the
the access device and selected VPLS enabled PE routers. Q-in-Q access device and selected VPLS enabled PE routers. Q-in-Q
encapsulation is another form of L2 tunneling technique, which can encapsulation is another form of L2 tunneling technique, which can
be used in conjunction with MPLS signaling as will be described be used in conjunction with MPLS signaling as will be described
later. The following two sections focus on this alternative later. The following two sections focus on this alternative
approach. The VPLS core PWs (hub) are augmented with access PWs approach. The VPLS core PWs (hub) are augmented with access PWs
(spoke) to form a two-tier hierarchical VPLS (H-VPLS). (spoke) to form a two-tier hierarchical VPLS (H-VPLS).
Spoke PWs may be implemented using any L2 tunneling mechanism, Spoke PWs may be implemented using any L2 tunneling mechanism,
expanding the scope of the first tier to include non-bridging VPLS expanding the scope of the first tier to include non-bridging VPLS
PE routers. The non-bridging PE router would extend a spoke PW PE routers. The non-bridging PE router would extend a spoke PW
from a Layer-2 switch that connects to it, through the service core from a Layer-2 switch that connects to it, through the service core
skipping to change at page 15, line 25 skipping to change at page 15, line 43
This section describes the hub and spoke connectivity model and This section describes the hub and spoke connectivity model and
describes the requirements of the bridging capable and non-bridging describes the requirements of the bridging capable and non-bridging
MTU-s devices for supporting the spoke connections. MTU-s devices for supporting the spoke connections.
10.1.1. Spoke connectivity for bridging-capable devices 10.1.1. Spoke connectivity for bridging-capable devices
In Figure 3 below, three customer sites are connected to an MTU-s In Figure 3 below, three customer sites are connected to an MTU-s
through CE-1, CE-2, and CE-3. The MTU-s has a single connection through CE-1, CE-2, and CE-3. The MTU-s has a single connection
(PW-1) to PE1-rs. The PE-rs devices are connected in a basic VPLS (PW-1) to PE1-rs. The PE-rs devices are connected in a basic VPLS
full mesh. For each VPLS service, a single spoke PW is set up full mesh. For each VPLS service, a single spoke PW is set up
between the MTU-s and the PE-rs based on [PWE3-CTRL]. Unlike between the MTU-s and the PE-rs based on [RFC4447]. Unlike
traditional PWs that terminate on a physical (or a VLAN-tagged traditional PWs that terminate on a physical (or a VLAN-tagged
logical) port, a spoke PW terminates on a virtual switch instance logical) port, a spoke PW terminates on a virtual switch instance
(VSI, see [L2FRAME]) on the MTU-s and the PE-rs devices. (VSI, see [L2FRAME]) on the MTU-s and the PE-rs devices.
PE2-rs PE2-rs
+--------+ +--------+
| | | |
| -- | | -- |
| / \ | | / \ |
CE-1 | \S / | CE-1 | \S / |
skipping to change at page 19, line 27 skipping to change at page 19, line 30
In this section we describe how the redundant connections can be In this section we describe how the redundant connections can be
provided to avoid total loss of connectivity from the MTU-s. The provided to avoid total loss of connectivity from the MTU-s. The
mechanism described is identical for both, MTU-s and PE-r devices. mechanism described is identical for both, MTU-s and PE-r devices.
10.2.1. Dual-homed MTU-s 10.2.1. Dual-homed MTU-s
To protect from connection failure of the PW or the failure of the To protect from connection failure of the PW or the failure of the
PE-rs, the MTU-s or the PE-r is dual-homed into two PE-rs devices. PE-rs, the MTU-s or the PE-r is dual-homed into two PE-rs devices.
The PE-rs devices must be part of the same VPLS service instance. The PE-rs devices must be part of the same VPLS service instance.
In Figure 5, two customer sites are connected through CE-1 and CE-2
to an MTU-s. The MTU-s sets up two PWs (one each to PE1-rs and PE3-
rs) for each VPLS instance. One of the two PWs is designated as
primary and is the one that is actively used under normal
conditions, while the second PW is designated as secondary and is
held in a standby state. The MTU-s negotiates the PW labels for
both the primary and secondary PWs, but does not use the secondary
PW unless the primary PW fails. How a spoke is designated primary
or secondary is outside of the scope of this document. For
example, a spanning tree instance running between only the MTU-s
and the two PE-rs nodes is one possible method. Another method
could be configuration.
PE2-rs PE2-rs
+--------+ +--------+
| | | |
| -- | | -- |
| / \ | | / \ |
CE-1 | \S / | CE-1 | \S / |
\ | -- | \ | -- |
\ +--------+ \ +--------+
\ MTU-s PE1-rs / | \ MTU-s PE1-rs / |
+--------+ +--------+ / | +--------+ +--------+ / |
skipping to change at page 19, line 54 skipping to change at page 20, line 32
/ \ +--------+ / \ +--------+
/ \ | | / \ | |
CE-2 \ | -- | CE-2 \ | -- |
\ Secondary PW | / \ | \ Secondary PW | / \ |
- - - - - - - - - - - - - - - - - | \S / | - - - - - - - - - - - - - - - - - | \S / |
| -- | | -- |
+--------+ +--------+
PE3-rs PE3-rs
Figure 5: An example of a dual-homed MTU-s Figure 5: An example of a dual-homed MTU-s
In Figure 5, two customer sites are connected through CE-1 and CE-2
to an MTU-s. The MTU-s sets up two PWs (one each to PE1-rs and PE3-
rs) for each VPLS instance. One of the two PWs is designated as
primary and is the one that is actively used under normal
conditions, while the second PW is designated as secondary and is
held in a standby state. The MTU-s negotiates the PW labels for
both the primary and secondary PWs, but does not use the secondary
PW unless the primary PW fails. How a spoke is designated primary
or secondary is outside of the scope of this document. For
example, a spanning tree instance running between only the MTU-s
and the two PE-rs nodes is one possible method. Another method
could be configuration.
10.2.2. Failure detection and recovery 10.2.2. Failure detection and recovery
The MTU-s should control the usage of the spokes to the PE-rs The MTU-s should control the usage of the spokes to the PE-rs
devices. If the spokes are PWs, then LDP signaling is used to devices. If the spokes are PWs, then LDP signaling is used to
negotiate the PW labels, and the hello messages used for the LDP negotiate the PW labels, and the hello messages used for the LDP
session could be used to detect failure of the primary PW. The use session could be used to detect failure of the primary PW. The use
of other mechanisms which could provide faster detection failures of other mechanisms which could provide faster detection failures
is outside the scope of this document. is outside the scope of this document.
Upon failure of the primary PW, MTU-s immediately switches to the Upon failure of the primary PW, MTU-s immediately switches to the
skipping to change at page 22, line 42 skipping to change at page 23, line 9
12. Contributors 12. Contributors
Loa Andersson, TLA Loa Andersson, TLA
Ron Haberman, Alcatel Ron Haberman, Alcatel
Juha Heinanen, Independent Juha Heinanen, Independent
Giles Heron, Tellabs Giles Heron, Tellabs
Sunil Khandekar, Alcatel Sunil Khandekar, Alcatel
Luca Martini, Cisco Luca Martini, Cisco
Pascal Menezes, Independent Pascal Menezes, Independent
Rob Nath, Riverstone Rob Nath, Lucent
Eric Puetz, SBC Eric Puetz, SBC
Vasile Radoaca, Nortel Vasile Radoaca, Independent
Ali Sajassi, Cisco Ali Sajassi, Cisco
Yetik Serbest, SBC Yetik Serbest, SBC
Nick Slabakov, Riverstone Nick Slabakov, Juniper
Andrew Smith, Consultant Andrew Smith, Consultant
Tom Soon, SBC Tom Soon, SBC
Nick Tingle, Alcatel Nick Tingle, Alcatel
13. Acknowledgments 13. Acknowledgments
We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel We wish to thank Joe Regan, Kireeti Kompella, Anoop Ghanwani, Joel
Halpern, Rick Wilder, Jim Guichard, Steve Phillips, Norm Finn, Matt Halpern, Bill Hong, Rick Wilder, Jim Guichard, Steve Phillips, Norm
Squire, Muneyoshi Suzuki, Waldemar Augustyn, Eric Rosen, Yakov Finn, Matt Squire, Muneyoshi Suzuki, Waldemar Augustyn, Eric Rosen,
Rekhter, Sasha Vainshtein, and Du Wenhua for their valuable Yakov Rekhter, Sasha Vainshtein, and Du Wenhua for their valuable
feedback. feedback.
We would also like to thank Rajiv Papneja (ISOCORE), Winston Liu We would also like to thank Rajiv Papneja (ISOCORE), Winston Liu
(Ixia), and Charlie Hundall for identifying issues with the draft (Ixia), and Charlie Hundall for identifying issues with the draft
in the course of the interoperability tests. in the course of the interoperability tests.
We would also like to thank Ina Minei, Bob Thomas, Eric Gray and We would also like to thank Ina Minei, Bob Thomas, Eric Gray and
Dimitri Papadimitriou for their thorough technical review of the Dimitri Papadimitriou for their thorough technical review of the
document. document.
skipping to change at page 23, line 39 skipping to change at page 24, line 9
- The customer traffic, which consists of Ethernet frames, - The customer traffic, which consists of Ethernet frames,
is carried unchanged over VPLS. If security is is carried unchanged over VPLS. If security is
required, the customer traffic SHOULD be encrypted required, the customer traffic SHOULD be encrypted
and/or authenticated before entering the service and/or authenticated before entering the service
provider network provider network
- Preventing broadcast storms can be achieved by using - Preventing broadcast storms can be achieved by using
routers as CPE devices or by rate policing the amount of routers as CPE devices or by rate policing the amount of
broadcast traffic that customers can send broadcast traffic that customers can send
- Control plane aspects - Control plane aspects
- LDP security (authentication) methods as described in - LDP security (authentication) methods as described in
[RFC-3036] SHOULD be applied. This would prevent [RFC3036] SHOULD be applied. This would prevent
unauthenticated messages from disrupting a PE in a VPLS unauthenticated messages from disrupting a PE in a VPLS
- Denial of service attacks - Denial of service attacks
- Some means to limit the number of MAC addresses (per site - Some means to limit the number of MAC addresses (per site
per VPLS) that a PE can learn SHOULD be implemented per VPLS) that a PE can learn SHOULD be implemented
15. IANA Considerations 15. IANA Considerations
The type field in the MAC List TLV is defined as 0x404 in section The type field in the MAC List TLV is defined as 0x404 in section
6.2.1 and is subject to IANA approval. 6.2.1 and is subject to IANA approval.
16. References 16. References
16.1. Normative References 16.1. Normative References
[PWE3-ETHERNET] "Encapsulation Methods for Transport of Ethernet [RFC4447] "Pseudowire Setup and Maintenance Using the Label
Frames Over IP/MPLS Networks", draft-ietf-pwe3-ethernet-encap- Distribution Protocol (LDP)", L. Martini, et al., April 2006.
10.txt, Work in progress, June 2005.
[PWE3-CTRL] "Transport of Layer 2 Frames over MPLS", draft-ietf- [RFC4448] "Encapsulation Methods for Transport of Ethernet over
pwe3-control-protocol-17.txt, Work in progress, June 2005. MPLS Networks", L. Martini, et al., RFC 4448, April 2006.
[802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std [802.1D-ORIG] Original 802.1D - ISO/IEC 10038, ANSI/IEEE Std
802.1D-1993 "MAC Bridges". 802.1D-1993 "MAC Bridges".
[802.1D-REV] 802.1D - "Information technology - Telecommunications [802.1D-REV] 802.1D - "Information technology - Telecommunications
and information exchange between systems - Local and metropolitan and information exchange between systems - Local and metropolitan
area networks - Common specifications - Part 3: Media Access area networks - Common specifications - Part 3: Media Access
Control (MAC) Bridges: Revision. This is a revision of ISO/IEC Control (MAC) Bridges: Revision. This is a revision of ISO/IEC
10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates 10038: 1993, 802.1j-1992 and 802.6k-1992. It incorporates
P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1998. P802.11c, P802.1p and P802.12e." ISO/IEC 15802-3: 1998.
skipping to change at page 24, line 37 skipping to change at page 24, line 51
Standards for Local and Metropolitan Area Networks: Virtual Bridged Standards for Local and Metropolitan Area Networks: Virtual Bridged
Local Area Networks", July 1998. Local Area Networks", July 1998.
[RFC3036] "LDP Specification", L. Andersson, et al., RFC 3036, [RFC3036] "LDP Specification", L. Andersson, et al., RFC 3036,
January 2001. January 2001.
[IANA] "IANA Allocations for pseudo Wire Edge to Edge Emulation [IANA] "IANA Allocations for pseudo Wire Edge to Edge Emulation
(PWE3)" Martini,Townsley, draft-ietf-pwe3-iana-allocation-08.txt, (PWE3)" Martini,Townsley, draft-ietf-pwe3-iana-allocation-08.txt,
Work in progress, February 2005. Work in progress, February 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
16.2. Informative References 16.2. Informative References
[BGP-VPN] "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis-03.txt, Work [BGP-VPN] "BGP/MPLS VPNs", draft-ietf-l3vpn-rfc2547bis-03.txt, Work
in Progress, October 2004. in Progress, October 2004.
[RADIUS-DISC] "Using Radius for PE-Based VPN Discovery", draft- [RADIUS-DISC] "Using Radius for PE-Based VPN Discovery", draft-
ietf-l2vpn-radius-pe-discovery-01.txt, Work in Progress, February ietf-l2vpn-radius-pe-discovery-01.txt, Work in Progress, February
2005. 2005.
[BGP-DISC] "Using BGP as an Auto-Discovery Mechanism for Network- [BGP-DISC] "Using BGP as an Auto-Discovery Mechanism for Network-
skipping to change at page 25, line 22 skipping to change at page 25, line 43
17. Appendix: VPLS Signaling using the PWid FEC Element 17. Appendix: VPLS Signaling using the PWid FEC Element
This section is being retained because live deployments use this This section is being retained because live deployments use this
version of the signaling for VPLS. version of the signaling for VPLS.
The VPLS signaling information is carried in a Label Mapping The VPLS signaling information is carried in a Label Mapping
message sent in downstream unsolicited mode, which contains the message sent in downstream unsolicited mode, which contains the
following PWid FEC TLV. following PWid FEC TLV.
PW, C, PW Info Length, Group ID, Interface parameters are as PW, C, PW Info Length, Group ID, Interface parameters are as
defined in [PWE3-CTRL]. defined in [RFC4447].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW TLV |C| PW Type |PW info Length | | PW TLV |C| PW Type |PW info Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Group ID | | Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWID | | PWID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface parameters | | Interface parameters |
~ ~ ~ ~
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
We use the Ethernet PW type to identify PWs that carry Ethernet We use the Ethernet PW type to identify PWs that carry Ethernet
traffic for multipoint connectivity. traffic for multipoint connectivity.
In a VPLS, we use a VCID (which, when using the PWid FEC, has been In a VPLS, we use a VCID (which, when using the PWid FEC, has been
substituted with a more general identifier (AGI), to address substituted with a more general identifier (AGI), to address
extending the scope of a VPLS) to identify an emulated LAN segment. extending the scope of a VPLS) to identify an emulated LAN segment.
Note that the VCID as specified in [PWE3-CTRL] is a service Note that the VCID as specified in [RFC4447] is a service
identifier, identifying a service emulating a point-to-point identifier, identifying a service emulating a point-to-point
virtual circuit. In a VPLS, the VCID is a single service virtual circuit. In a VPLS, the VCID is a single service
identifier, so it has global significance across all PEs involved identifier, so it has global significance across all PEs involved
in the VPLS instance. in the VPLS instance.
18. Authors' Addresses 18. Authors' Addresses
Marc Lasserre Marc Lasserre
Riverstone Networks Lucent Technologies
Email: marc@riverstonenet.com Email: mlasserre@lucent.com
Vach Kompella Vach Kompella
Alcatel Alcatel
Email: vach.kompella@alcatel.com Email: vach.kompella@alcatel.com
IPR Disclosure Acknowledgement IPR Disclosure Acknowledgement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology described to pertain to the implementation or use of the technology described
skipping to change at page 26, line 31 skipping to change at page 26, line 52
at 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.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). This document is Copyright (C) The Internet Society (2006). This document is
subject to the rights, licenses and restrictions contained in BCP subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their 78, and except as set forth therein, the authors retain all their
rights. rights.
Disclaimer Disclaimer
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
 End of changes. 50 change blocks. 
106 lines changed or deleted 110 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/