Internet DRAFT - draft-cao-l2vpn-bgp-vpls-etree
draft-cao-l2vpn-bgp-vpls-etree
Network Working Group Yuqun Cao
Internet Draft Ruijie Networks
Intended status: Standard Track April 15, 2011
Expires: October 2011
Extension to BGP-VPLS for E-Tree
draft-cao-l2vpn-bgp-vpls-etree-01.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, except to publish it
as an RFC and to translate it into languages other than English.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
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."
Cao Expires October 15, 2011 [Page 1]
Internet-Draft Extension to BGP-VPLS for E-Tree April 2011
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 October 15, 2011.
Copyright Notice
Copyright (c) 2011 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.
Abstract
This document proposes an approach to support Metro Ethernet Forum
(MEF) Ethernet Tree (E-Tree) in Virtual Private LAN Service using
BGP for auto-discovery and signaling [RFC4761]. The proposed solution
is characterized by breaking pseudowire between Leafs to fulfill the
specific E-Tree requirement: Leaf cannot communicate with Leaf.
Backward compatibility is also considered.
Table of Contents
1. Introduction................................................3
2. Conventions used in this document............................4
3. Terminology.................................................4
4. Reference Model.............................................4
5. Extension to VPLS for E-Tree.................................6
5.1. Assumptions............................................6
5.2. AC type................................................7
5.3. PW setup Matrix.........................................7
5.4. VPLS BGP NLRI..........................................8
5.5. PW setup and teardown...................................9
5.5.1. Root endpoint......................................9
5.5.2. Leaf endpoint......................................9
5.6. Signaling PE Capabilities..............................10
5.7. Signaling PE Capabilities..............................10
5.8. Backward Compatibility.................................10
Cao Expires October 15, 2011 [Page 2]
Internet-Draft Extension to BGP-VPLS for E-Tree April 2011
6. Extension to Data Plane for E-Tree..........................10
7. Compliance with Requirements................................10
8. Security Considerations.....................................11
9. References.................................................11
9.1. Normative References...................................11
9.2. Informative References.................................11
10. Acknowledgments...........................................11
1. Introduction
A specific Rooted-multipoint service, Ethernet Tree(E-Tree), has been
defined by Metro Ethernet Forum [MEF6.1]. Compared with MEF Ethernet
LAN (E-LAN) service where there is no communication restriction
between its attachment circuits, each attachment circuit of E-tree is
designated as either a Root or a Leaf. A Root-AC can communicate with
all other attachment circuit in an E-Tree, however a Leaf-AC can only
communicate with Root-ACs but not Leafs.
[Draft VPLS ETree Req] provides the functional requirements for MEF
E-Tree support in VPLS.
This document presents a minimal extension to the current VPLS
standard [RFC4761] to break the "communication channel" between Leaf
attachment circuits.
Figure 1 below describes scenario for Leaf-to-Leaf communication
restriction.
|<----------E-Tree-------->|
| |
V V
+-------+ +---------+
| PE1 | | PE2 |
+---+ | +---+ | | +---+ | +---+
|CE1+----AC1---+-+ | | | | +--+---AC3----+CE3|
+---+ (Root AC)| | V | |Ethernet| | V | |(Root AC) +---+
| | S +-+---PW---+--+ S | |
+---+ | | I | | | | I | | +---+
|CE2+----AC2---+-+ | | | | +--+---AC4----+CE4|
+---+ (Leaf AC)| +---+ | | +---+ | (Leaf AC)+---+
+-------+ +---------+
Figure 1 Scenario for Leaf-to-Leaf Communication Restriction
If PE2 receives one frame from PE1 over Ethernet PW, PE2 does NOT
know the frame comes from Root AC or from Leaf AC, so it can not
decide to forward the frame to AC4 (Leaf AC) or not with the current
VPLS standards [RFC4761] [RFC4762].
Cao Expires October 15, 2011 [Page 3]
Internet-Draft Extension to BGP-VPLS for E-Tree April 2011
2. 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 RFC-2119 [RFC2119].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
3. Terminology
There are two solutions to restrict Leaf-to-Leaf communication,
1. Each frame carries additional information to indicate that it is
originated from a Leaf endpoint or Root endpoint on the ingress PE,
then egress PE can know forward behavior of the frame, if it comes
from Leaf, it will NOT be forwarded to the local Leaf ACs.
[Draft Ext VPLS for ETree] proposes this solution.
2. If a frame from local Leaf-AC, one PE in a VPLS will NOT forward
it to its other local Leaf-ACs; if there is no PW between local
Leaf-ACs and remote Leaf-ACs which are connected to remote PE, a
frame from local Leafs also cannot be forwarded to remote Leafs.
In this way, we also can restrict the communication between Leafs.
The purposed solution in this document prefers to the second and two
terms are introduced,
o Root-endpoint. One endpoint which connects only Root-ACs, one or
more Root-ACs.
o Leaf-endpoint. One endpoint which connects only Leaf-ACs, one or
more Leaf-ACs.
There is no endpoint which connects both Root-ACs and Leaf-ACs in the
second solution.
4. Reference Model
Figure 2 below describes a typical reference model where Root ACs
{AC1, AC5, AC6} can communicate with all other Ethernet ACs in the
VSI, but Leaf ACs {AC2, AC3, AC4} only can communicate with Root ACs
{AC1, AC5, AC6}, and can not communicate with each other.
Cao Expires October 15, 2011 [Page 4]
Internet-Draft Extension to BGP-VPLS for E-Tree April 2011
|<----------E-Tree------------>|
| |
V V
+---------+ +---------+
| PE1 | | PE2 | /Leaf endpoint
+---+ | +---+ | | +---+ | /\ +---+
|CE1+-------AC1-+--+ V | | | | V +--+-|--- --AC3----+CE3|
+---+ (Root AC)| | S +--+---PW12---+--+ S | | | |(Leaf AC) +---+
+---+ | | I | | | | I | | | | +---+
|CE2+----AC2----+--+ | | | | +--+-|------AC4----+CE4|
+---+ (Leaf AC)| +-+-+ | | +-+-+ | \/ (Leaf AC) +---+
+---+-+---+ +----+----+
^ | | |
| | |PW13-2 |PW23
| | | |
PW13-1| | +----+----+ /Root endpoint
| | | | +-+-+ | /\ +---+
| | | | | v +--+-|--------AC5-+CE5|
| | +--------------+--+ s | | | |(Root AC)+---+
| | | | I | | | | +---+
| +----------------+ | +--+-|------AC6---+CE6|
| | +---+ | \/ (Root AC)+---+
| | PE3 |
| +---------+
| ^
| <-----------E-Tree---------->|
Figure 2 E-Tree typical Reference Model
In most use cases, an E-Tree architecture has only a few Root ACs but
many Leaf-ACs. On any PE in E-Tree, there are 3 cases,
o Root-only ACs. All ACs connected to VSI are Root ACs, say AC5 and
AC6 of PE 3 in Figure 2 and at least one VE ID which stands for
one Root endpoint is assigned.
o Leaf-only ACs. All ACs connected to VSI are Leaf ACs, say AC3 and
AC4 of PE 2 in Figure 2 and at least one VE ID which stands for
one Leaf endpoint is assigned.
o Root-Leaf-Mixed ACs. Some connected to VSI are Root ACs and some
are Leaf ACs, say AC1 and AC2 of PE 1 in Figure 2. Here network
administrator should at least assign two VE IDs, one is called as
Root-endpoint for Root ACs, and one is called as Leaf-endpoint for
Leaf ACs.
Within an E-Tree,
Cao Expires October 15, 2011 [Page 5]
Internet-Draft Extension to BGP-VPLS for E-Tree April 2011
o All Root-ACs of a Root endpoint can receive frame from and
transmit frame to any other endpoints in an E-Tree.
o A Root-AC of a Root endpoint can receive frame from and transmit
frame to its other Root-ACs;
o A Leaf endpoint can receive frame from and transmit frame to any
Root endpoints in an E-Tree.
o A Leaf endpoint cannot receive frame from and transmit frame to
any other Leaf endpoints in the E-Tree.
o A Leaf-AC of a Leaf endpoint cannot receive frame from and
transmit frame to its other Leaf-ACs;
For one VSI, PE 1 has both Root and Leaf ACs, so on PE 1, PE 1
establish one PW (PW12) for AC 1 (Root AC, also belongs to a Root
endpoint) with PE 2 where remote ACs are Leaf-only, two PWs with PE 3
where PE 1 receives frames from or transmits frames to remote Root
ACs for local Root AC(s) over PW13-1 and receives frames from or
transmits frames to remote Root ACs for local Leaf ACs over PW13-2;
PE 2 has Leaf-only ACs, so PE 2 establish one PW (PW12) with remote
Root ACs on PE 1 and one PW (PW23) with remote Root ACs on PE3; PW3
which has Root-only ACs can establish PW with remote Leaf ACs and
Root ACs, so PE 3 establish two PWs with PE 1 and one PW with PE2.
However the ACs on PE 2 are Leaf, so any Ethernet frame which is
received from AC 3 cannot be transmitted to other local Leaf ACs, say
AC4, for example. PE 2 also can not transmit Ethernet frame to remote
Leaf ACs since there is no PW for it.
This applies to all traffic, including Unicast Known, Unicast Unknown,
Broadcast or Multicast.
5. Extension to VPLS for E-Tree
5.1. Assumptions
The PEs are assumed to be (logically) fully meshed with tunnels over
which packets that belong to a service (such as VPLS or E-Tree) are
encapsulated and forwarded.
Any E-Tree endpoint comprises only one AC type. If a PE in a VPLS has
both Root ACs and Leaf ACs, it SHOULD be configured with at least two
endpoints, one is composed of Root ACs, and another is composed of
Leaf ACs. It is illegal for any endpoint to have both at same time.
Cao Expires October 15, 2011 [Page 6]
Internet-Draft Extension to BGP-VPLS for E-Tree April 2011
5.2. AC type
Each AC connected to an E-Tree on PE MUST have an AC attribute, Root
AC or Leaf AC. For backward compatibility, the default AC type MUST
be Root for current VPLS standard [RFC4761] [RFC4762].
o Root AC. It can communicate with all ACs in a VPLS or E-Tree and
SHOULD belong to a Root endpoint.
o Leaf AC. It only can communicate with all Root ACs in a VPLS or E-
Tree, and SHOULD belong to a Leaf endpoint.
5.3. PW setup Matrix
Just as mentioned in Section 3, there is no PW between Leaf-endpoints
and Table 1 describes PW setup matrix,
+---------------+-------+------+
| Endpoint type + Root + Leaf +
+---------------+-------+------+
| Root + Setup + Setup+
+---------------+-------+------+
| Leaf + Setup + n/a +
+---------------+-------+------+
Table 1 PW setup Matrix
In the following cases PW may be established,
o Local Root-Remote Root
o Local Root-Remote Leaf or Local Leaf-Remote Root
Foex example, between PE 1 and PE 2 in Figure 1, we have to setup 3
PWs,
o PW 1: Communication between Root ACs, i.e., AC 1 and AC 3 in
Figure 1.
o PW 2: Communication between Root AC and Leaf AC, i.e., AC 1 and AC
4 in Figure 1.
o PW 3: Communication between Root AC and Leaf AC, i.e., AC 2 and AC
3 in Figure 1.
Cao Expires October 15, 2011 [Page 7]
Internet-Draft Extension to BGP-VPLS for E-Tree April 2011
5.4. VPLS BGP NLRI
Section 3.2.2 in [RFC 4761] defines VPLS BGP NLRI with a new AFI and
SAFI to exchange VPLS membership and demultiplexors.
+------------------------------------+
| Length (2 octets) |
+------------------------------------+
| Route Distinguisher (8 octets) |
+------------------------------------+
| VE ID (2 octets) |
+------------------------------------+
| VE Block Offset (2 octets) |
+------------------------------------+
| VE Block Size (2 octets) |
+------------------------------------+
| Label Base (3 octets) |
+------------------------------------+
Figure 3 BGP NLRI for VPLS Information
A PE participating in a E-Tree must have at least one VE ID, but for
a VSI on a PE which has both Root-ACs and Leaf-ACs, it must have at
least two VE IDs, one is called as Root endpoint and one is called as
Leaf endpoint.
Here whole VE ID set is divided into two parts, one is Root VE ID set,
and one is Leaf VE id set.
L = {VBO, VBO+1, ......, VBO+LVBS-1},
R = { VBO+LVBS, VBO+LVBS +1,......, VBO+VBS-1},
Here VE ID, Leaf VE block Size (LVBS) and VE Block Size (VBO) are
typically assigned by the network administrator. All Root VE IDs are
in R set, and all Leaf VE IDs are in L set. If there are Root-only
ACs on a PE, LVBS SHOULD be set as zero and L is NULL; if there are
Leaf-only ACs, LVBS SHOULD be equal to VBS.
The endpoint which is identified by VE ID in L set only can establish
PW with the endpoint identified by VE ID in R set, but the endpoint
identified by the VE ID in R set can establish PW with all VPLS
endpoint identified by VE ID in RUL.
Cao Expires October 15, 2011 [Page 8]
Internet-Draft Extension to BGP-VPLS for E-Tree April 2011
5.5. PW setup and teardown
Suppose PE-a is part of E-Tree foo and has both Root-ACs and Leaf-ACs.
For Leaf ACs, it is assigned with VE ID l which is in Leaf VE ID set,
VE block offset VBO+LVBS, VE Block Size LVBS, and label base lLB, For
Root ACs, it is assigned with VE ID r which is in Root VE ID set, VE
Block Offset VBO, VE Block Size VBS-LVBS, and label base rLB. If PE-b
is also part of E-Tree foo with VE ID w (Root or Leaf) and gets NLRI
advertisement from PE-a, it will do the following,
5.5.1. Root endpoint
1. Checks if w is part of PE-a's 'remote VE set': if VBO <= w < VBO+
VBS, then w is part of PE-a's remote VE set. If not, PE-b ignores
this message, and skips the rest of this procedure.
2. Sets up a PW to PE-a: the demultiplexor label to send traffic from
PE-b to PE-a is computed as (rLB + W - VBO).
3. Checks if r is part of any 'remote VE set' that PE-b announced,
i.e., PE-b checks if r belongs to some remote VE set that PE-b
announced, say with VE Block Offset VBO', VE Block Size VBS', and
label base LB'. If not, PE-b MUST make a new announcement as
described.
4. Sets up a PW from PE-a: the demultiplexor label over which PE-b
should expect traffic from PE-a is computed as: (LB' + r - VBO').
If PE-a withdraws an NLRI for r that PE-b was using, then PE-b MUST
tear down its ends of the pseudowire between PE-a and PE-b.
5.5.2. Leaf endpoint
1. Checks if w is part of PE-a's 'remote VE set': if VBO+LVBS <= w <
VBO+ VBS, then w is part of PE-a's remote Root VE set. If not,
PE-b ignores this message, and skips the rest of this procedure.
2. Sets up a PW to PE-a: the demultiplexor label to send traffic from
PE-b to PE-a is computed as (LB + w - VBO).
3. Checks if l is part of any 'remote VE set' that PE-b announced,
i.e., PE-b checks if l belongs to some remote VE set that PE-b
announced, say with VE Block Offset VBO', VE Block Size VBS', and
label base LB'. If not, PE-b MUST make a new announcement as
described.
Cao Expires October 15, 2011 [Page 9]
Internet-Draft Extension to BGP-VPLS for E-Tree April 2011
4. Sets up a PW from PE-a: the demultiplexor label over which PE-b
should expect traffic from PE-a is computed as: (LB' + l - VBO').
If PE-a withdraws an NLRI for l that PE-b was using, then PE-b MUST
tear down its ends of the pseudowire between PE-a and PE-b.
5.6. Signaling PE Capabilities
5.7. Signaling PE Capabilities
The extended attribute in Section [RFC4761] 3.2.4, the "Layer2 Info
Extended Community", is used to signal control information about the
pseudowires to be setup for a VPLS. It also can carry endpoint
information. It will be extended in later version.
5.8. Backward Compatibility
Root-ACs and Leaf-ACs are used only in cases where PEs support E-Tree
and have no impact on VPLS PEs already in operation.
In a case where a common VPLS is composed of both PEs supporting the
solution and PEs not supporting it, ACs attached to PEs which don't
support E-tree are taken as Root-ACs. The Leaf-to-Leaf communication
restriction will be implemented within the scope of the compliant PEs.
6. Extension to Data Plane for E-Tree
This will be added in later version.
7. Compliance with Requirements
The proposed solution in this document meets the requirements
mentioned in [Draft VPLS ETree Req] Section 5.
The solution prohibits communication between any two Leaf ACs in a
VPLS.
The solution allows multiple Root ACs in a VPLS instance.
The solution allows Root AC and Leaf AC of a VPLS instance co-exist
on any PE.
The solution is applicable to BGP-VPLS [RFC4761].
The solution is applicable to Case 1: Single technology "VPLS-only".
Cao Expires October 15, 2011 [Page 10]
Internet-Draft Extension to BGP-VPLS for E-Tree April 2011
8. Security Considerations
This will be added in later version.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[MEF6.1] Metro Ethernet Forum, Ethernet Services Definitions - Phase
2, April 2008
[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
9.2. Informative References
[Draft VPLS ETree Req] Key, et al., Requirements for MEF E-Tree
Support in VPLS, draft-key-l2vpn-vpls-etree-reqt-
02.txt,October 2010
[Draft Ext VPLS for ETree] Key, et al., Extension to VPLS for E-Tree,
draft-key-l2vpn-vpls-etree-04.txt,October 2010
10. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Authors' Addresses
Yuqun Cao
Ruijie Networks
618 Jinshan Road, Fuzhou 350002, China
Email: yuqun.cao@gmail.com
Cao Expires October 15, 2011 [Page 11]
