Network Working Group Raymond Key
Internet Draft Simon Delord
Category: Informational Frederic Jounay, France Telecom
Expires: September 2010 Lucy Yong, Huawei
Lizhong Jin, ZTE
Yuji Kamite, NTT Communications
Wim Henderickx, Alcatel-Lucent
March 8, 2010
A Framework for E-Tree Service over MPLS Network
draft-key-l2vpn-etree-frwk-02.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 8, 2010.
Abstract
This document proposes a solution framework for supporting Metro
Ethernet Forum (MEF) Ethernet Tree (E-Tree) services over a
Multiprotocol Label Switching (MPLS) network. The objective is to
provide a simple and effective approach to emulate E-Tree services
in addition to Ethernet LAN (E-LAN) services on an existing MPLS
network.
Key, et al. Expires September 2010 [Page 1]
Internet Draft Framework E-Tree over MPLS March 2010
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents
1. Introduction....................................................3
1.1. Objective and Scope...........................................3
1.2. Traditional Ethernet Network..................................3
1.3. MEF Multipoint Ethernet Services..............................3
1.3.1. Similarity between E-LAN and E-Tree.........................4
1.3.2. Difference between E-LAN and E-Tree.........................4
1.4. IETF Multipoint L2VPN Services................................5
1.4.1. Virtual Private LAN Service (VPLS)..........................5
1.4.2. Virtual Private Multicast Service (VPMS)....................6
1.5. Terminology...................................................6
2. Reference Model.................................................8
3. Use Cases......................................................10
4. Challenges.....................................................12
4.1. Generic E-Tree Service Definition............................12
4.1.1. Mandatory Leaf-to-Leaf Communication Restriction...........12
4.2. Use Case Desirable Requirements..............................12
4.2.1. Ethernet Broadcast/Multicast Optimisation..................12
4.2.2. IP Multicast Optimisation..................................13
4.2.3. MAC-based Forwarding Unnecessary...........................13
4.2.4. MAC-based Forwarding Security Concern......................14
5. A Solution Framework for MAC-based Forwarding E-Tree...........15
5.1. MAC-based Forwarding Any-to-Any Ethernet VPN.................15
5.2. Leaf-to-Leaf Communication Restriction.......................15
5.2.1. Per-payload Signaling on PW - From Leaf or Root............15
5.2.2. Extension to VPLS..........................................17
5.3. Optional Enhancement - Point-to-Multipoint PW................17
5.4. Optional Enhancement - IP Multicast in VPLS.......... .......18
6. Non-MAC-based Forwarding E-Tree................................19
6.1. Single Root, Broadcast Only - VPMS...........................19
6.2. Multiple Roots, Broadcast and Unicast........................19
7. Security Consideration.........................................20
8. IANA Considerations............................................20
9. Acknowledgements...............................................20
10. References....................................................20
10.1. Normative References........................................20
10.2. Informative References......................................21
Appendix A. Other Possible Ways for Leaf-to-Leaf Communication
Restriction...........................................22
Authors' Addresses................................................32
Intellectual Property and Copyright Statements....................32
Key, et al. Expires September 2010 [Page 2]
Internet Draft Framework E-Tree over MPLS March 2010
1. Introduction
1.1. Objective and Scope
This document proposes a solution framework for supporting Metro
Ethernet Forum (MEF) Ethernet Tree (E-Tree) services over a MPLS
network. The objective is to provide a simple and effective approach
to emulate E-Tree services in addition to Ethernet LAN (E-LAN)
services on an existing MPLS network.
This solution framework makes use of existing IETF specified
mechanisms unless there are technical reasons why the existing
mechanisms are insufficient or unnecessary.
This document does not intend to provide a full specification of the
solution, but rather to identify the functional components of the
overall solution, and for each component, whether it is REQUIRED or
OPTIONAL, whether existing mechanism is sufficient, or whether
relevant mechanism is already under development.
In this document, "current standard" refers to [RFC4385], [RFC4447],
[RFC4448], [RFC4761] and [RFC4762].
1.2. Traditional Ethernet Network
In this document, traditional Ethernet network refers to the Ethernet
bridge/switch network, not the Ethernet repeater/hub network.
Data frame is Ethernet frame.
Data forwarding is MAC-based forwarding, which includes MAC address
learning and aging.
It is important to note that in traditional Ethernet network unicast
unknown, multicast and broadcast frames are forwarded in exactly the
same way to every port except the ingress port.
An Ethernet host receiving a frame checks the destination address in
the frame to decide whether it is the intended destination.
1.3. MEF Multipoint Ethernet Services
MEF defines two multipoint Ethernet Service types:
- E-LAN (Ethernet LAN), multipoint-to-multipoint service
- E-Tree (Ethernet Tree), rooted-multipoint service
Key, et al. Expires September 2010 [Page 3]
Internet Draft Framework E-Tree over MPLS March 2010
According to MEF's technical specification, a generic E-LAN/E-Tree
service is always bidirectional in the sense that ingress frames can
originate at any endpoint in the service. However, some application
scenarios of E-Tree may have unidirectional traffic only. Section 3
will discuss about different use cases.
For full specification, please refer to MEF's "Ethernet Services
Definitions - Phase 2" [MEF6.1] and "Ethernet Services Attributes
Phase 2" [MEF10.2].
1.3.1. Similarity between E-LAN and E-Tree
Data frame MUST be Ethernet frame.
Data forwarding can be MAC-based forwarding or something else, to be
specified by service provider in the particular service definition.
Extract from [MEF6.1] Table 7 and Table 9:
+---------------+---------------------------------------------------+
| EVC Service | E-LAN/E-Tree Service Type Requirement |
| Attribute | |
+---------------+---------------------------------------------------+
| Unicast | Deliver Unconditionally or Deliver Conditionally. |
| Service Frame | If Delivered Conditionally, MUST specify the |
| Delivery | delivery criteria. |
+---------------+---------------------------------------------------+
| Multicast | Deliver Unconditionally or Deliver Conditionally. |
| Service Frame | If Delivered Conditionally, MUST specify the |
| Delivery | delivery criteria. |
+---------------+---------------------------------------------------+
| Broadcast | Deliver Unconditionally or Deliver Conditionally. |
| Service Frame | If Delivered Conditionally, MUST specify the |
| Delivery | delivery criteria. |
+---------------+---------------------------------------------------+
It is important to note that it is not a must for a MEF multipoint
Ethernet service (E-LAN or E-Tree) to use MAC-based forwarding. This
document presents a solution framework for MAC-based forwarding
E-Tree in section 5, and also discusses non-MAC-based forwarding
E-Tree in section 6.
1.3.2. Difference between E-LAN and E-Tree
Within the context of a multipoint Ethernet service, each endpoint is
designated as either a Root or a Leaf. A Root can communicate with
all other endpoints in the same multipoint Ethernet service, however
a Leaf can only communicate with Roots but not Leafs.
Key, et al. Expires September 2010 [Page 4]
Internet Draft Framework E-Tree over MPLS March 2010
The only difference between E-LAN and E-Tree is:
- E-LAN has Root endpoints only, which implies there is no
communication restriction between endpoints
- E-Tree has both Root and Leaf endpoints, which implies there is a
need to enforce communication restriction between Leaf endpoints
Extract from [MEF10.2] Section 6.3:
The UNI Type MUST have the value either "Root" or "Leaf." If the type
of EVC is Point-to-Point or Multipoint-to-Multipoint, then the UNI
Type MUST equal "Root."
Extract from [MEF10.2] Section 6.1.2.2:
An ingress Service Frame mapped to the EVC at a Leaf UNI MUST NOT
result in an egress Service Frame at another Leaf UNI but MAY result
in an egress Service Frame at some or all of the Root UNIs.
It is important to note that one E-Tree service may have single or
multiple Root UNIs.
Extract from [MEF6.1] Section 6.3:
In its simplest form, an E-Tree Service type can provide a single
Root for multiple Leaf UNIs. Each Leaf UNI can exchange data with
only the Root UNI. ... In more sophisticated forms, an E-Tree Service
type may support two or more Root UNIs. In this scenario, each Leaf
UNI can exchange data only with the Root UNIs. As well, the Roots can
communicate with each other. In such a service, redundant access to
the Root can also be provided, effectively allowing for enhanced
service reliability and flexibility.
1.4. IETF Multipoint L2VPN Services
1.4.1. Virtual Private LAN Service (VPLS)
VPLS is a L2VPN service that provides multipoint-to-multipoint
connectivity for Ethernet across an IP or MPLS-enabled IP Packet
Switched Network. VPLS emulates the Ethernet VLAN functionality of
traditional Ethernet network.
VPLS is a current IETF standard, please refer to [RFC4761] [RFC4762].
Data frame is Ethernet frame.
Data forwarding is MAC-based forwarding, which includes MAC address
learning and aging.
Key, et al. Expires September 2010 [Page 5]
Internet Draft Framework E-Tree over MPLS March 2010
It is important to note that the current standard VPLS treats
Ethernet multicast frame in exactly the same way as Ethernet
broadcast frame and does not restrict transmission of Ethernet
multicast frame to a smaller set of receivers. An Ethernet host
receiving a frame checks the destination address in the frame to
determine whether it is the intended destination.
VPLS can be used to emulate E-LAN service over MPLS network provided
that the E-LAN service uses MAC-based forwarding as service frame
delivery attribute. Considerable number of service providers have
adopted this approach to provide E-LAN services to customers.
1.4.2. Virtual Private Multicast Service (VPMS)
VPMS is a L2VPN service that provides point-to-multipoint
connectivity across a variety of link layers, including Frame Relay,
ATM, Ethernet, PPP, etc., across an IP or MPLS-enabled IP Packet
Switched Network.
In the Ethernet use case, VPMS provides single coverage of receiver
membership, i.e. there is no distinct differentiation for multiple
multicast groups. Destination address in Ethernet frame is not used
in data forwarding.
VPMS MUST support unidirectional point-to-multipoint traffic from a
sender to multiple receivers and MAY support reverse traffic in a
point-to-point manner.
VPMS is currently under development. Please refer to [Draft VPMS
Frmwk].
1.5. Terminology
E-Tree
An Ethernet VPN in which each Root AC can communicate with every
other AC, whereas Leaf ACs can only communicate with Root ACs. Each
AC on an E-Tree construct is designated as either a Root AC or a Leaf
AC. There can be multiple Root ACs and Leaf ACs per E-Tree construct.
Root AC
An ingress frame at a Root AC can be delivered to one or more of
any of the other ACs in the E-Tree. Please note that this AC is
bidirectional.
Key, et al. Expires September 2010 [Page 6]
Internet Draft Framework E-Tree over MPLS March 2010
Leaf AC
Ingress frame at a Leaf AC can only be delivered to one or more Root
ACs in the E-Tree. Ingress frame at a Leaf AC MUST NOT be delivered
to any Leaf ACs in the E-Tree. Please note that this AC is
bidirectional.
Key, et al. Expires September 2010 [Page 7]
Internet Draft Framework E-Tree over MPLS March 2010
2. Reference Model
Figure 1 below describes a generic reference model where PE1, PE2 and
PE3 need to establish an E-Tree construct between different Ethernet
endpoints. Each PE has 2 Root ACs and 2 Leaf ACs connected to a VSI.
These VSIs are then linked together via Ethernet PWs.
In most use cases, an E-Tree construct has only a few Root ACs but
many Leaf ACs. There may be only Root ACs or only Leaf ACs on a PE.
<------------E-Tree------------>
+---------+ +---------+
| PE1 | | PE2 |
+----+ | +---+ | | +---+ | +----+
|CE01+----AC1----+--+ | | | | +--+----AC5----+CE05|
+----+ (Root AC) | | V | | | | V | | (Root AC) +----+
+----+ | | | | | | | | +----+
|CE02+----AC2----+--+ | | Ethernet | | +--+----AC6----+CE06|
+----+ (Root AC) | | S +--+-----PW-----+--+ S | | (Root AC) +----+
+----+ | | | | | | | | +----+
|CE03+----AC3----+--+ | | | | +--+----AC7----+CE07|
+----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+
+----+ | | | | | | | | +----+
|CE04+----AC4----+--+ | | | | +--+----AC8----+CE08|
+----+ (Leaf AC) | +-+-+ | | +-+-+ | (Leaf AC) +----+
| | | | | |
+----+----+ +----+----+
| |
|Ethernet |Ethernet
|PW |PW
| |
| +----+----+
| | | |
| | +-+-+ | +----+
| | | +--+----AC9----+CE09|
| | | V | | (Root AC) +----+
| | | | | +----+
| | | +--+----AC10---+CE10|
+-----------------+--+ S | | (Root AC) +----+
| | | | +----+
| | +--+----AC11---+CE11|
| | I | | (Leaf AC) +----+
| | | | +----+
| | +--+----AC12---+CE12|
| +---+ | (Leaf AC) +----+
| PE3 |
+---------+
<------------E-Tree------------>
Figure 1: E-Tree Reference Model
Key, et al. Expires September 2010 [Page 8]
Internet Draft Framework E-Tree over MPLS March 2010
With an E-Tree construct:
- A Root AC can receive from and transmit to any other ACs.
- A Leaf AC can receive from and transmit to any Root ACs.
- A Leaf AC cannot receive from and transmit to any other Leaf ACs.
This applies to all traffic, including Unicast Known, Unicast
Unknown, Broadcast and Multicast.
When an Ethernet Frame is received on PE1 via AC1, the frame can be
transmitted to any other local ACs on PE1 and via Ethernet PWs to any
remote ACs on PE2 and PE3.
However when an Ethernet frame is received on PE1 via AC3, the frame
can be transmitted to any other local Root ACs on PE1 and via
Ethernet PWs to any remote Root ACs on PE2 and PE3, but the frame
cannot be transmitted to any local Leaf ACs on PE1 nor any remote
Leaf ACs on PE2 and PE3.
Key, et al. Expires September 2010 [Page 9]
Internet Draft Framework E-Tree over MPLS March 2010
3. Use Cases
Table 1 below presents some major use cases.
+---------------------------+--------------+------------+
| Use Case | Root | Leaf |
+---+---------------------------+--------------+------------+
| 1 | Broadcast Video | Video Source | Subscriber |
| | (unidirectional only) | | |
+---+---------------------------+--------------+------------+
| 2 | Broadcast/Multicast Video | Video Source | Subscriber |
| | plus Control Channel | | |
+---+---------------------------+--------------+------------+
| 3 | Internet Access | BNG Router | Subscriber |
+---+---------------------------+--------------+------------+
| 4 | IEEE 1588 PTPv2 | PTP Server | PTP Client |
| | Clock Synchronisation | | |
+---+---------------------------+--------------+------------+
| 5 | Mobile Backhaul | RAN NC | RAN BS |
+---+---------------------------+--------------+------------+
| 6 | Hub & Spoke VPN | Hub Site | Spoke Site |
+---+---------------------------+--------------+------------+
| 7 | Wholesale Access | Customer's | Customer's |
| | | Interconnect | Subscriber |
+---+---------------------------+--------------+------------+
| 8 | Device Management | Management | Managed |
| | | System | Device |
+---+---------------------------+--------------+------------+
Table 1: E-Tree Use cases
Common to all use cases, direct Leaf-to-Leaf communication is not
required. For Mobile backhaul, this may not be valid for LTE X2
interfaces in the future.
If direct Leaf-to-Leaf communication is not allowed due to security
concern, then E-Tree should be used to prohibit communication between
Leaf endpoints, otherwise E-LAN is also a feasible option.
Also common to the use cases mentioned above, there may be single or
multiple Root endpoints in one E-Tree service. The need for multiple
Root endpoints is usually driven by redundancy requirement. Whether
a particular E-Tree service needs to support single or multiple Root
endpoints depends on the target application.
Key, et al. Expires September 2010 [Page 10]
Internet Draft Framework E-Tree over MPLS March 2010
A generic E-Tree service supports the following traffic flows:
- Unicast bidirectional Root to/from Root
- Unicast bidirectional Root to/from Leaf
- Broadcast/Multicast unidirectional Root to all Roots and Leafs
- Broadcast/Multicast unidirectional Leaf to all Roots
A particular E-Tree service may need to support all the above or only
a subset depending on the target application.
Among the use cases mentioned above, broadcast video draws most
attention. Actually, broadcast video is a representing example for
content delivery in general, such as news feed, financial data
feed, etc.
Key, et al. Expires September 2010 [Page 11]
Internet Draft Framework E-Tree over MPLS March 2010
4. Challenges
4.1. Generic E-Tree Service Definition
This section highlights why the current standard VPLS is insufficient
for emulating E-Tree service over MPLS network.
4.1.1. Mandatory Leaf-to-Leaf Communication Restriction
Current standard VPLS treats all ACs equal (i.e. not classified into
Root or Leaf) and provides any-to-any connectivity among all ACs. The
current standard VPLS does not include any mechanism of communication
restriction between specific ACs, therefore is insufficient for
emulating generic E-Tree service over MPLS network.
In order to fulfil the generic E-Tree service definition, extensions
to the current VPLS standard and related PWE3 standard are required.
Such extensions should have minimal impact on the emulated E-LAN
services already in operation.
4.2. Use Case Desirable Requirements
There are quite a variety of use cases for E-Tree. For some use
cases, the generic MEF E-Tree service definition is good enough. For
some other use cases, there are desirable requirements beyond that.
The challenges discussed in this section are not related to the
generic MEF E-Tree service definition but the desirable requirements
of specific use cases. They may be critical to the success in some
E-Tree services while totally irrelevant in some others.
4.2.1. Ethernet Broadcast/Multicast Optimisation
According to MAC-based forwarding, an Ethernet broadcast/multicast/
unicast unknown frame is forwarded to all ACs other than the ingress
AC, which implies point-to-multipoint traffic from the ingress PE to
all other PEs in the VPLS instance.
The current standard VPLS uses only point-to-point PW between PEs.
When the Ethernet destination address is broadcast, multicast or
unicast unknown, the ingress PE replicates the frame on every PW
towards remote PE belonging to the same VPLS instance. Depending on
the mapping between the logical topology of the E-Tree service and
the physical topology of the network, multiple PWs may transverse
same physical link, result in multiple copies of the same payload
Ethernet frame on the physical link. Such approach is inefficient in
terms of bandwidth usage.
Key, et al. Expires September 2010 [Page 12]
Internet Draft Framework E-Tree over MPLS March 2010
For some use cases, for example broadcast/multicast video, due to
nature of the application, there is significant volume of point-to-
multipoint traffic. Bandwidth optimisation for such traffic within
the network becomes a concern from the service provider perspective.
[RFC5501] provides an in-depth discussion on broadcast/multicast
related requirements for VPLS, see issue B (Replication of PWs on
shared physical path) in section 3.2.
4.2.2. IP Multicast Optimisation
The current standard VPLS is a L2VPN service agnostic to customer's
Layer 3 traffic, hence does not maintain any information about IP
multicast group membership. Although a Layer 3 IP multicast packet is
encapsulated in a Layer 2 Ethernet multicast frame, the current
standard VPLS treats Ethernet multicast frame in exactly the same way
as Ethernet broadcast frame. Therefore, such payload IP multicast
packet will be forwarded to every other AC of the same VPLS instance.
A payload IP multicast packet will be forwarded to all ACs, including
those with no member of the specific IP multicast group attached.
Unnecessary traffic consumes bandwidth on access link and may become
a concern from the customer perspective. In some cases, it may also
be a security concern as the multicast frame may be forwarded to an
endpoint other than the intended destinations.
A payload IP multicast packet will be forwarded to a remote PE with
no member of the specific IP multicast group attached. Unnecessary
traffic consumes bandwidth in the network and may become a concern
from the service provider perspective.
For some use cases, for example multicast video, due to nature of the
application, there is significant volume of IP multicast traffic and
different IP multicast groups are required in one E-Tree service. The
above may become a real concern from both the customer and service
provider perspectives.
[RFC5501] provides an in-depth discussion on broadcast/multicast
related requirements for VPLS, see both issue A (Replication to non-
member site) and issue B (Replication of PWs on shared physical path)
in section 3.2.
4.2.3. MAC-based Forwarding Unnecessary
For some use cases, for example broadcast video, due to nature of the
application, there is only broadcast unidirectional traffic from Root
to all other endpoints. It is unnecessary to use destination address
for data forwarding. Deliver unconditionally for ingress frame at
Root endpoint may be a simpler approach than MAC-based forwarding.
Key, et al. Expires September 2010 [Page 13]
Internet Draft Framework E-Tree over MPLS March 2010
4.2.4. MAC-based Forwarding Security Concern
MAC-based forwarding will make an unicast frame from a Root destined
for a specific Leaf being forwarded to other endpoints in addition to
the intended destination when the frame is classified as unicast
unknown, may be due to MAC address aged out or MAC address table
overflow.
MAC address spoofing may cause an unicast frame from a Root destined
for a specific Leaf being forwarded to an endpoint different from the
intended destination.
If such unicast frame carries sensitive information strictly for the
intended destination only, then the MAC-based forwarding may cause a
security concern from the customer perspective.
For some use cases where mutually un-trusted subscribers are
connected to leaf endpoints in the same E-Tree service, such as
Internet access and wholesale access, this is a valid concern.
There are some possible mitigations:
- For every Leaf endpoint of the particular E-Tree service, deploy
a service provider controlled router between the Leaf endpoint
and the customer network
- Customer to deploy encryption for sensitive information, for
example IPsec, SSL, SSH, HTTPS
Whether the MAC-based forwarding really becomes a security concern
depends on the particular application and the deployment scenario.
This is unlikely to be a critical concern in most cases.
Key, et al. Expires September 2010 [Page 14]
Internet Draft Framework E-Tree over MPLS March 2010
5. A Solution Framework for MAC-based Forwarding E-Tree
As mentioned in section 1.3.1. E-Tree can use MAC-based forwarding or
something else for data forwarding. This section presents a solution
framework for MAC-based forwarding E-Tree. Section 6 will discuss
other variants.
This is a VPLS-based solution. Functional components of the solution
are identified and discussed in the subsections.
5.1. MAC-based Forwarding Any-to-Any Ethernet VPN
This is a REQUIRED component.
This component is the current standard VPLS and PWE3 as specified in
[RFC4385] [RFC4447] [RFC4448] [RFC4761] [RFC4762], which provides
any-to-any connectivity among all ACs in one VPLS instance.
This is the base component. All other REQUIRED/OPTIONAL components
are to be added on top of this component.
5.2. Leaf-to-Leaf Communication Restriction
This is a REQUIRED component.
This component is a minimal extension to the current VPLS and PWE3
standards, with the objective to provide a simple and effective way
to support E-Tree services in addition to E-LAN services using VPLS
on a MPLS network.
5.2.1. Per-payload Signaling on PW - From Leaf or Root
Let's look at the scenario illustrated in Figure 2 below. VPLS is
used to emulate an E-Tree service over a MPLS network.
Key, et al. Expires September 2010 [Page 15]
Internet Draft Framework E-Tree over MPLS March 2010
<------------E-Tree------------>
+---------+ +---------+
| PE1 | | PE2 |
+----+ | +---+ | | +---+ | +----+
|CE01+----AC1----+--+ | | | | +--+----AC5----+CE05|
+----+ (Root AC) | | V | | | | V | | (Root AC) +----+
+----+ | | | | | | | | +----+
|CE02+----AC2----+--+ | | Ethernet | | +--+----AC6----+CE06|
+----+ (Root AC) | | S +--+-----PW-----+--+ S | | (Root AC) +----+
+----+ | | | | | | | | +----+
|CE03+----AC3----+--+ | | | | +--+----AC7----+CE07|
+----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+
+----+ | | | | | | | | +----+
|CE04+----AC4----+--+ | | | | +--+----AC8----+CE08|
+----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+
| | | |
+---------+ +---------+
Figure 2: Reference Model for Leaf-to-Leaf Communication Restriction
When PE2 receives a frame from PE1 via the PW,
- PE2 does not know which AC on PE1 is the ingress AC
- PE2 does not know whether the ingress AC is a Leaf AC or not
- PE2 does not have sufficient information to enforce the
Leaf-to-Leaf communication restriction
A simple fix is to carry additional one bit of information (0 or 1)
for each payload Ethernet frame on the Ethernet PW
- Indicate whether the frame is from a Leaf AC on ingress PE or not
- Based on this one bit of information, egress PE can decide
whether the frame can be forwarded to a local Leaf AC or not
Extension to current PWE3 standard [RFC4448] is proposed. The work in
progress [Draft CW L-bit] provides a precise specification on how to
use a specific bit within the Control Word, refer as "CW L-bit" to
indicate whether the payload Ethernet frame comes from a Root AC or a
Leaf AC.
There are other possible ways to get around this problem. Some do not
require any extension to current PWE3 standard. Unfortunately they
all come with significant design complexity and/or deployment
constraints and hence not recommended as solution for the generic
E-Tree service definition. Appendix A highlights the major ones and
the related concerns.
Key, et al. Expires September 2010 [Page 16]
Internet Draft Framework E-Tree over MPLS March 2010
5.2.2. Extension to VPLS
Extension to current VPLS standard [RFC4761] [RFC4762] is proposed.
The work in progress [Draft VPLS ETree] provides a precise
specification on how to enforce the Leaf-to-Leaf communication
restriction locally on a PE.
The [Draft VPLS ETree] introduces the following:
- AC Type, either Root or Leaf
- Use of Control Word to carry the "CW L-bit"
- Additional "Set CW L-bit" action and "Forward or Drop" decision
in data forwarding
It is important to note that the "Set CW L-bit" action and "Forward
or Drop" decision specified in [Draft VPLS ETree] are in addition to
and performed after the following
- MAC-based forwarding decision as per current standard
- Loop free VPLS "split horizon" rule (MUST NOT forward traffic
from one PW to another PW in the same VPLS mesh) as per current
standard
5.3. Optional Enhancement - Point-to-Multipoint PW
This is in response to the challenge in section 4.2.1. Ethernet
Broadcast/Multicast Optimisation.
This is an OPTIONAL component, applicable only when there is
significant volume of Ethernet broadcast/multicast traffic.
Point-to-Multipoint pseudowire (P2MP PW) is a PW attached to a source
used to distribute Layer 1 or Layer 2 format traffic to a set of
receivers. P2MP PW is unidirectional but optionally bidirectional.
By using P2MP PW, the ingress PE is not responsible for replicating
the payload frame on each P2P PW towards egress PE, instead the
network elements along the physical path participate in replication.
The replication is done by the underlying point-to-multipoint label
switched path (P2MP LSP).
Extension to current VPLS standard will be required to specify how
P2MP PW and P2P PW should be used and how MAC learning works on P2MP
PW.
P2MP PW is currently under development. Please refer to [Draft P2MP
PW Req] [Draft P2MP PW Sig].
Key, et al. Expires September 2010 [Page 17]
Internet Draft Framework E-Tree over MPLS March 2010
It is important to note that this component will align with the
recommendation in [RFC4665],
"With the exception of IPLS, an L2VPN service SHOULD be agnostic to
customer's Layer 3 traffic (e.g., IP, IPX, Appletalk) encapsulated
within Layer 2 frames."
5.4. Optional Enhancement - IP Multicast in VPLS
This is in response to the challenge in section 4.2.2. IP Multicast
Optimisation.
This is an OPTIONAL component, applicable only when there is
significant volume of IP multicast traffic and different IP multicast
groups are required in one E-Tree service.
Multicast in VPLS is currently under development, with the objective
to provide efficient ways to support IP multicast services over VPLS.
It covers IP multicast group membership control and also bandwidth
optimisation. Please refer to [Draft Mcast VPLS].
It is important to note that this component will make use of Layer 3
IP multicast information in payload frames to improve transport
efficiency, hence will not align with the recommendation in [RFC4665]
that an L2VPN service SHOULD be agnostic to customer's Layer 3
traffic.
Key, et al. Expires September 2010 [Page 18]
Internet Draft Framework E-Tree over MPLS March 2010
6. Non MAC-based Forwarding E-Tree
This section presents some variants of E-Tree services which do not
use MAC-based forwarding as the service frame delivery attribute.
6.1. Single Root, Broadcast Only - VPMS
This is in response to the challenge in section 4.2.3. MAC-based
Forwarding Unnecessary.
VPMS provides single coverage of receiver membership. Destination
address in Ethernet frame is not used in data forwarding.
For E-Tree service of single Root and only unidirectional broadcast
traffic from the Root, for example certain broadcast video or similar
content delivery applications, VPMS will be a much more simple and
effective solution than VPLS.
VPMS is currently under development. Please refer to [Draft VPMS
Frmwk].
6.2. Multiple Roots, Broadcast and Unicast
This is in response to the challenge in section 4.2.4. MAC-based
Forwarding Security Concern.
This will be added in next version of this document.
Key, et al. Expires September 2010 [Page 19]
Internet Draft Framework E-Tree over MPLS March 2010
7. Security Considerations
This will be added in next version of this document.
8. IANA Considerations
This will be added in next version of this document.
9. Acknowledgements
This will be added in next version of this document.
10. References
10.1. Normative References
[MEF6.1] Metro Ethernet Forum, Ethernet Services Definitions -
Phase 2, April 2008
[MEF10.2] Metro Ethernet Forum, Ethernet Services Attributes
Phase 2, October 2009
[RFC2119] Bradner, S., Key words for use in RFCs to Indicate
Requirement Levels, BCP 14, RFC 2119, March 1997
[RFC4385] Bryant,S., Swallow, G., and Al, Pseudowire Emulation
Edge-to-Edge (PWE3) Control Word for Use over an MPLS
PSN, February 2006.
[RFC4447] Martini, L., and al, Pseudowire Setup and Maintenance
Using the Label Distribution Protocol (LDP), April 2006
[RFC4448] Martini, L., and al, Encapsulation Methods for
Transport of Ethernet over MPLS Networks, April 2006
[RFC4665] Augustyn & Serbest, Service Requirements for Layer 2
Provider-Provisioned Virtual Private Networks,
September 2006
[RFC4761] Kompella & Rekhter, Virtual Private LAN Service (VPLS)
Using BGP for Auto-Discovery and Signaling, January 2007
[RFC4762] Lasserre & Kompella, Virtual Private LAN Service (VPLS)
Using Label Distribution Protocol (LDP) Signaling,
January 2007
[RFC5501] Kamite, et al., Requirements for Multicast Support in
Virtual Private LAN Services, March 2009
Key, et al. Expires September 2010 [Page 20]
Internet Draft Framework E-Tree over MPLS March 2010
[Draft CW L-bit]
Delord, et al., Control Word Reserved bit for use in
E-Tree, draft-delord-pwe3-cw-bit-etree-02.txt,
January 2010
[Draft VPLS ETree]
Key, et al., Extension to VPLS for E-Tree,
draft-key-l2vpn-vpls-etree-02.txt, January 2010
[Draft P2MP PW Req]
Jounay, et al., Requirements for Point-to-Multipoint
Pseudowire, draft-ietf-pwe3-p2mp-pw-requirements-02.txt,
January, 2010
[Draft P2MP PW Sig]
Martini, et al., Signaling Root-Initiated Point-to-
Multipoint Pseudowires using LDP,
draft-martini-pwe3-p2mp-pw-01.txt, October 2009
[Draft Mcast VPLS]
Raggarwa, Kamite & Fang, Multicast in VPLS,
draft-ietf-l2vpn-vpls-mcast-05.txt, July 2009
[Draft VPMS Frmwk]
Kamite, et al., Framework and Requirements for Virtual
Virtual Private Multicast Service (VPMS),
draft-ietf-l2vpn-vpms-frmwk-requirements-02.txt,
October 2009
10.2. Informative References
Key, et al. Expires September 2010 [Page 21]
Internet Draft Framework E-Tree over MPLS March 2010
Appendix A. Other Possible Ways for Leaf-to-Leaf Communication
Restriction
This appendix briefly describes the following approaches:
- Single Root Only (A.1)
- Only one PE has Roots (A.2)
- Only one PE with both Root & Leaf
- Backhaul Root (A.3)
- Backhaul Leaf (A.4)
- H-VPLS Root (A.5)
- H-VPLS Leaf (A.6)
- Separate PEs for Root and Leaf (A.7)
- Separate VSI for Root and Leaf
- Internal Connection (A.8)
- External Connection (A.9)
- Separate PWs for "From Root" traffic and "From Leaf" traffic (A.10)
- "From Root" or "From Leaf" derived from source MAC address (A.11)
- Static MAC address configuration for Root AC (A.12)
Reference Model for Leaf-to-Leaf Communication Restriction
(Figure 2 in section 5.2.1.)
<------------E-Tree------------>
+---------+ +---------+
| PE1 | | PE2 |
+----+ | +---+ | | +---+ | +----+
|CE01+----AC1----+--+ | | | | +--+----AC5----+CE05|
+----+ (Root AC) | | V | | | | V | | (Root AC) +----+
+----+ | | | | | | | | +----+
|CE02+----AC2----+--+ | | Ethernet | | +--+----AC6----+CE06|
+----+ (Root AC) | | S +--+-----PW-----+--+ S | | (Root AC) +----+
+----+ | | | | | | | | +----+
|CE03+----AC3----+--+ | | | | +--+----AC7----+CE07|
+----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+
+----+ | | | | | | | | +----+
|CE04+----AC4----+--+ | | | | +--+----AC8----+CE08|
+----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+
| | | |
+---------+ +---------+
For the diagrams in this appendix, "L" indicates the particular AC or
PW belonging to the PE local split horizon group specifically for
Leaf-to-Leaf Communication Restriction. No communication is allowed
between any two members of a split horizon group.
Key, et al. Expires September 2010 [Page 22]
Internet Draft Framework E-Tree over MPLS March 2010
A.1. Single Root Only
<------------E-Tree------------>
+---------+ +---------+
| PE1 | | PE2 |
+----+ | +---+ | | +---+ |
|CE01+----AC1----+--+ | | | | | |
+----+ (Root AC) | | V | | | | V | |
| | | | | | | |
| | | | Ethernet | | | |
| | S +L-+-----PW-----+--+ S | |
+----+ | | | | | | | | +----+
|CE03+----AC3----+-L+ | | | | +L-+----AC7----+CE07|
+----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+
+----+ | | | | | | | | +----+
|CE04+----AC4----+-L+ | | | | +L-+----AC8----+CE08|
+----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+
| | | |
+---------+ +---------+
Concerns:
- Not fulfil multi-Root requirement of generic MEF E-Tree service
definition
A.2. Only one PE has Roots
<------------E-Tree------------>
+---------+ +---------+
| PE1 | | PE2 |
+----+ | +---+ | | +---+ |
|CE01+----AC1----+--+ | | | | | |
+----+ (Root AC) | | V | | | | V | |
+----+ | | | | | | | |
|CE02+----AC2----+--+ | | Ethernet | | | |
+----+ (Root AC) | | S +L-+-----PW-----+--+ S | |
+----+ | | | | | | | | +----+
|CE03+----AC3----+-L+ | | | | +L-+----AC7----+CE07|
+----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+
+----+ | | | | | | | | +----+
|CE04+----AC4----+-L+ | | | | +L-+----AC8----+CE08|
+----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+
| | | |
+---------+ +---------+
Concerns:
- Deployment constraint
Key, et al. Expires September 2010 [Page 23]
Internet Draft Framework E-Tree over MPLS March 2010
A.3. Only one PE with both Root & Leaf - Backhaul Root
+---AC5(Root AC)---------------------------+
| |
| +-AC6(Root AC)----------------------+ |
| | | |
| | | |
| | | |
+---+-+---+ +---------+ | |
| | | | | | | |
+----+ | ++-++ | | +---+ | | +-+--+
|CE01+----AC1----+--+ | | | | | | | |CE05|
+----+ (Root AC) | | V | | | | V | | | +----+
+----+ | | | | | | | | | +----+
|CE02+----AC2----+--+ | | Ethernet | | | | +--+CE06|
+----+ (Root AC) | | S +L-+-----PW-----+--+ S | | +----+
+----+ | | | | | | | | +----+
|CE03+----AC3----+-L+ | | | | +L-+----AC7----+CE07|
+----+ (Leaf AC) | | I | | | | I | | (Leaf AC) +----+
+----+ | | | | | | | | +----+
|CE04+----AC4----+-L+ | | | | +L-+----AC8----+CE08|
+----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+
| PE1 | | PE2 |
+---------+ +---------+
<------------E-Tree------------>
Concerns:
- Deployment constraint
- Long fibre path
Key, et al. Expires September 2010 [Page 24]
Internet Draft Framework E-Tree over MPLS March 2010
A.4. Only one PE with both Root & Leaf - Backhaul Leaf
<------------E-Tree------------>
+---------+ +---------+
| PE1 | | PE2 |
+----+ | +---+ | | +---+ | +----+
|CE01+----AC1----+--+ | | | | +--+----AC5----+CE05|
+----+ (Root AC) | | V | | | | V | | (Root AC) +----+
+----+ | | | | | | | | +----+
|CE02+----AC2----+--+ | | Ethernet | | +--+----AC6----+CE06|
+----+ (Root AC) | | S +--+-----PW-----+--+ S | | (Root AC) +----+
+----+ | | | | | | | | +----+
|CE03+----AC3----+-L+ | | | | | | +--+CE07|
+----+ (Leaf AC) | | I | | | | I | | | +----+
+----+ | | | | | | | | | +----+
|CE04+----AC4----+-L+ | | | | | | | |CE08|
+----+ (Leaf AC) | ++-++ | | +---+ | | +-+--+
| L L | | | | |
+---+-+---+ +---------+ | |
| | | |
| | | |
| | | |
| +-AC7(Leaf AC)----------------------+ |
| |
+---AC8(Leaf AC)---------------------------+
Concerns:
- Deployment constraint
- Long fibre path
Key, et al. Expires September 2010 [Page 25]
Internet Draft Framework E-Tree over MPLS March 2010
A.5. Only one PE with both Root & Leaf - H-VPLS Root
<------------E-Tree------------>
+---------+ +---------+
| PE1 | | PE2 |
+----+ | +---+ | Ethernet | | +----+
|CE01+----AC1----+--+ +--+-----PW-----+---------+----AC5----+CE05|
+----+ (Root AC) | | V | | | | (Root AC) +----+
+----+ | | | | Ethernet | | +----+
|CE02+----AC2----+--+ +--+-----PW-----+---------+----AC6----+CE06|
+----+ (Root AC) | | S | | | +---+ | (Root AC) +----+
+----+ | | | | | | | | +----+
|CE03+----AC3----+-L+ | | Ethernet | | V +L-+----AC7----+CE07|
+----+ (Leaf AC) | | I +L-+-----PW-----+--+ S | | (Leaf AC) +----+
+----+ | | | | | | I | | +----+
|CE04+----AC4----+-L+ | | | | +L-+----AC8----+CE08|
+----+ (Leaf AC) | +---+ | | +---+ | (Leaf AC) +----+
| | | |
+---------+ +---------+
Concerns:
- Design complexity
- More PW
- Hair pinning (e.g. CE05 to CE06/07/08) impact bandwidth and delay
A.6. Only one PE with both Root & Leaf - H-VPLS Leaf
<------------E-Tree------------>
+---------+ +---------+
| PE1 | | PE2 |
+----+ | +---+ | | +---+ | +----+
|CE01+----AC1----+--+ | | | | +--+----AC5----+CE05|
+----+ (Root AC) | | V | | Ethernet | | V | | (Root AC) +----+
+----+ | | +--+-----PW-----+--+ S | | +----+
|CE02+----AC2----+--+ | | | | I +--+----AC6----+CE06|
+----+ (Root AC) | | S | | | | | | (Root AC) +----+
+----+ | | | | Ethernet | +---+ | +----+
|CE03+----AC3----+-L+ +L-+-----PW-----+---------+----AC7----+CE07|
+----+ (Leaf AC) | | I | | | | (Leaf AC) +----+
+----+ | | | | Ethernet | | +----+
|CE04+----AC4----+-L+ +L-+-----PW-----+---------+----AC8----+CE08|
+----+ (Leaf AC) | +---+ | | | (Leaf AC) +----+
| | | |
+---------+ +---------+
Concerns:
- Design complexity
- More PW
- Hair pinning (e.g. CE08 to CE05/06) impact bandwidth and delay
Key, et al. Expires September 2010 [Page 26]
Internet Draft Framework E-Tree over MPLS March 2010
A.7. Separate PEs for Root and Leaf
(PE2 split to PE2R & PE2L)
<------------E-Tree------------>
+---------+ +---------+
| PE1 | | PE2R |
+----+ | +---+ | | +---+ | +----+
|CE01+----AC1----+--+ | | Ethernet | | V +--+----AC5----+CE05|
+----+ (Root AC) | | V +--+-----PW-----+--+ S | | (Root AC) +----+
+----+ | | | | | | I | | +----+
|CE02+----AC2----+--+ | | | | +--+----AC6----+CE06|
+----+ (Root AC) | | S | | | +-+-+ | (Root AC) +----+
+----+ | | | | | L |
|CE03+----AC3----+-L+ | | +----+----+
+----+ (Leaf AC) | | I | | |
+----+ | | | | |Ethernet
|CE04+----AC4----+-L+ | | |PW
+----+ (Leaf AC) | +-+-+ | |
| L | +----+----+
+----+----+ | | |
| | +-+-+ | +----+
| Ethernet | | V +L-+----AC7----+CE07|
+----------PW-----+--+ S | | (Leaf AC) +----+
| | I | | +----+
| | +L-+----AC8----+CE08|
| +---+ | (Leaf AC) +----+
| PE2L |
+---------+
<------------E-Tree------------>
Concerns:
- Require two PEs in one POP
- More PW
Key, et al. Expires September 2010 [Page 27]
Internet Draft Framework E-Tree over MPLS March 2010
A.8. Separate VSI for Root and Leaf - Internal Connection
(VSI on PE2 split to VSIR & VSIL)
<------------E-Tree------------>
+---------+ +---------+
| PE1 | | PE2 |
+----+ | +---+ | | +---+ | +----+
|CE01+----AC1----+--+ | | Ethernet | | V +--+----AC5----+CE05|
+----+ (Root AC) | | V +--+-----PW-----+--+ S | | (Root AC) +----+
+----+ | | | | | | I | | +----+
|CE02+----AC2----+--+ | | | | R +--+----AC6----+CE06|
+----+ (Root AC) | | S | | | +-+-+ | (Root AC) +----+
+----+ | | | | | L |
|CE03+----AC3----+-L+ | | | | |
+----+ (Leaf AC) | | I | | | | |
+----+ | | | | | |Internal
|CE04+----AC4----+-L+ | | | |Connection
+----+ (Leaf AC) | +-+-+ | | | |
| L | | | |
+----+----+ | | |
| | +-+-+ | +----+
| Ethernet | | V +L-+----AC7----+CE07|
+----------PW-----+--+ S | | (Leaf AC) +----+
| | I | | +----+
| | L +L-+----AC8----+CE08|
| +---+ | (Leaf AC) +----+
| |
+---------+
Concerns:
- Design complexity
- More VSI
- More PW
- Some vendor implementation may require additional hardware module
to support internal connection between two VSIs
- Some vendor implementation may have bandwidth limitation on
internal connection between two VSIs
- Some vendor implementation of service-aware management system may
assume only one VSI per VPLS on one PE
Key, et al. Expires September 2010 [Page 28]
Internet Draft Framework E-Tree over MPLS March 2010
A.9. Separate VSI for Root and Leaf - External Connection
(VSI on PE2 split to VSIR & VSIL)
<------------E-Tree------------>
+---------+ +---------+
| PE1 | | PE2 |
+----+ | +---+ | | +---+ | +----+
|CE01+----AC1----+--+ | | Ethernet | | +--+----AC5----+CE05|
+----+ (Root AC) | | V +--+-----PW-----+--+ V | | (Root AC) +----+
+----+ | | | | | | S | | +----+
|CE02+----AC2----+--+ | | | | I +--+----AC6----+CE06|
+----+ (Root AC) | | S | | | | R | | (Root AC) +----+
+----+ | | | | | | | |
|CE03+----AC3----+-L+ | | | | +L-+----AC-X------+
+----+ (Leaf AC) | | I | | | +---+ | (Leaf AC) |
+----+ | | | | | | External|
|CE04+----AC4----+-L+ | | | | Connection|
+----+ (Leaf AC) | +-+-+ | | +---+ | |
| L | | | +--+----AC-Y------+
+----+----+ | | | | (Root AC)
| | | V | | +----+
| Ethernet | | S +L-+----AC7----+CE07|
+----------PW-----+--+ I | | (Leaf AC) +----+
| | L | | +----+
| | +L-+----AC8----+CE08|
| +---+ | (Leaf AC) +----+
| |
+---------+
Concerns:
- Design complexity
- More VSI
- More PW
- More AC (for external connection between two VSIs)
- Require additional two high speed physical ports on PE to support
such external connections
- Some vendor implementation of service-aware management system may
assume only one VSI per VPLS on one PE
Key, et al. Expires September 2010 [Page 29]
Internet Draft Framework E-Tree over MPLS March 2010
A.10. Separate PWs for "From Root" traffic and "From Leaf" traffic
<------------E-Tree------------>
+---------+ +---------+
| PE1 | | PE2 |
+----+ | +---+ | | +---+ | +----+
|CE01+----AC1----+--+ | | Ethernet | | +--+----AC5----+CE05|
+----+ (Root AC) | | V +--+---PW for---+--+ V | | (Root AC) +----+
+----+ | | | |"From Root" | | | | +----+
|CE02+----AC2----+--+ | | Traffic | | +--+----AC6----+CE06|
+----+ (Root AC) | | S | | | | S | | (Root AC) +----+
+----+ | | | | | | | | +----+
|CE03+----AC3----+--+ | | | | +--+----AC7----+CE07|
+----+ (Leaf AC) | | I | | Ethernet | | I | | (Leaf AC) +----+
+----+ | | +--+---PW for---+--+ | | +----+
|CE04+----AC4----+--+ | |"From Leaf" | | +--+----AC8----+CE08|
+----+ (Leaf AC) | +---+ | Traffic | +---+ | (Leaf AC) +----+
| | | |
+---------+ +---------+
Concerns:
- More PW
- Most, if not all, vendor implementation support only one PW
between two VSIs on different PEs
- Most, if not all, vendor implementation of service-aware management
system assume only one PW between two VSIs on different PEs
- Asymmetric path for bidirectional traffic between Root and Leaf on
different PEs (e.g. CE01-->CE07 use the "From Root" PW, CE07-->CE01
use the "From Leaf" PW)
- Require extension to current standard VPLS
- support two PWs between two VSIs on different PEs (both active
but no loop)
- share MAC learning between the "From Root" PW and "From Leaf" PW
(bidirectional traffic may be on asymmetric path)
- in addition to standard MAC-based forwarding, select which PW to
use based on whether ingress AC is Root or Leaf
- filter Leaf-to-Leaf traffic (split horizon group at PW/AC level
is not good enough because of asymmetric path)
Key, et al. Expires September 2010 [Page 30]
Internet Draft Framework E-Tree over MPLS March 2010
A.11. "From Root" or "From Leaf" derived from source MAC address
Based on the current standard VPLS, a PE has no information about ACs
on another PE.
This approach will need additional information exchange between
ingress PE and egress PE, via OSS or peer to peer.
Concerns:
- Require system development or additional signaling between PEs
- Not an ideal solution from security perspective because of the
dynamic nature of MAC address to AC mapping
A.12. Static MAC address configuration for Root AC
This approach requires additional configuration on PEs
- Disable MAC address learning for Root ACs
- Static configuration of MAC addresses per Root AC
- Add filtering for each Root AC
- Drop ingress frame if source MAC address not equal to any of the
static MAC addresses configured for the particular Root AC
- Add filtering for each Leaf AC
- Drop ingress frame if source MAC address equal to any of the
static MAC addresses configured for any Root ACs of the VPLS
instance
- Drop egress frame if source MAC address not equal to any of the
static MAC addresses configured for any Root ACs of the VPLS
instance
Concerns:
- No MAC address learning capability for Root ACs
- Need resources for maintaining the static MAC address configuration
per Root AC
Key, et al. Expires September 2010 [Page 31]
Internet Draft Framework E-Tree over MPLS March 2010
Authors' Addresses
Raymond Key
Australia
Email: raymond.key@ieee.org
Simon Delord
Australia
Email: simon.delord@gmail.com
Frederic Jounay
France Telecom
2, avenue Pierre-Marzin
22307 Lannion Cedex, France
Email: frederic.jounay@orange-ftgroup.com
Lucy Yong
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075, USA
Email: lucyyong@huawei.com
Lizhong Jin
ZTE Corporation
889, Bibo Road
Shanghai, 201203, China
Email: lizhong.jin@zte.com.cn
Yuji Kamite
NTT Communications Corporation
Granpark Tower
3-4-1 Shibaura, Minato-ku
Tokyo 108-8118, Japan
Email: y.kamite@ntt.com
Wim Henderickx
Alcatel-Lucent
Copernicuslaan 50
2018 Antwerp, Belgium
Email: wim.henderickx@alcatel-lucent.com
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (http://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Key, et al. Expires September 2010 [Page 32]