draft-ietf-bess-evpn-etree-02.txt   draft-ietf-bess-evpn-etree-03.txt 
L2VPN Workgroup Ali Sajassi L2VPN Workgroup Ali Sajassi
INTERNET-DRAFT Samer Salam INTERNET-DRAFT Samer Salam
Intended Status: Standards Track Sami Boutros Intended Status: Standards Track Sami Boutros
Cisco Cisco
Wim Henderickx Wim Henderickx
Jorge Rabadan Jim Uttaro Jorge Rabadan Jim Uttaro
Alcatel-Lucent AT&T Alcatel-Lucent AT&T
John Drake Aldrin Isaac John Drake Aldrin Isaac
Wen Lin Bloomberg Wen Lin Juniper
Juniper Juniper
Expires: January 6, 2015 July 6, 2015 Expires: April 10, 2016 October 10, 2015
E-TREE Support in EVPN & PBB-EVPN E-TREE Support in EVPN & PBB-EVPN
draft-ietf-bess-evpn-etree-02 draft-ietf-bess-evpn-etree-03
Abstract Abstract
The Metro Ethernet Forum (MEF) has defined a rooted-multipoint The Metro Ethernet Forum (MEF) has defined a rooted-multipoint
Ethernet service known as Ethernet Tree (E-Tree). [ETREE-FMWK] Ethernet service known as Ethernet Tree (E-Tree). [ETREE-FMWK]
proposes a solution framework for supporting this service in MPLS proposes a solution framework for supporting this service in MPLS
networks. This document discusses how those functional requirements networks. This document discusses how those functional requirements
can be easily met with (PBB-)EVPN and how (PBB-)EVPN offers a more can be easily met with (PBB-)EVPN and how (PBB-)EVPN offers a more
efficient implementation of these functions. efficient implementation of these functions.
skipping to change at page 2, line 39 skipping to change at page 2, line 39
3 Operation for EVPN . . . . . . . . . . . . . . . . . . . . . . . 7 3 Operation for EVPN . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Known Unicast Traffic . . . . . . . . . . . . . . . . . . . 7 3.1 Known Unicast Traffic . . . . . . . . . . . . . . . . . . . 7
3.2 BUM Traffic . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 BUM Traffic . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1 BUM traffic originated from a single-homed site on a 3.2.1 BUM traffic originated from a single-homed site on a
leaf AC . . . . . . . . . . . . . . . . . . . . . . . . 9 leaf AC . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2 BUM traffic originated from a single-homed site on a 3.2.2 BUM traffic originated from a single-homed site on a
root AC . . . . . . . . . . . . . . . . . . . . . . . . 9 root AC . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3 BUM traffic originated from a multi-homed site on a 3.2.3 BUM traffic originated from a multi-homed site on a
leaf AC . . . . . . . . . . . . . . . . . . . . . . . . 9 leaf AC . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.4 BUM traffic originated from a multi-homed site on a 3.2.4 BUM traffic originated from a multi-homed site on a
root AC . . . . . . . . . . . . . . . . . . . . . . . . 10 root AC . . . . . . . . . . . . . . . . . . . . . . . . 9
3.3 E-TREE Traffic Flows for EVPN . . . . . . . . . . . . . . . 10 3.3 E-TREE Traffic Flows for EVPN . . . . . . . . . . . . . . . 10
3.3.1 E-Tree with MAC Learning . . . . . . . . . . . . . . . . 10 3.3.1 E-Tree with MAC Learning . . . . . . . . . . . . . . . . 10
3.3.2 E-Tree without MAC Learning . . . . . . . . . . . . . . 11 3.3.2 E-Tree without MAC Learning . . . . . . . . . . . . . . 11
4 Operation for PBB-EVPN . . . . . . . . . . . . . . . . . . . . . 11 4 Operation for PBB-EVPN . . . . . . . . . . . . . . . . . . . . . 11
4.1 Known Unicast Traffic . . . . . . . . . . . . . . . . . . . 12 4.1 Known Unicast Traffic . . . . . . . . . . . . . . . . . . . 12
4.2 BUM Traffic . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 BUM Traffic . . . . . . . . . . . . . . . . . . . . . . . . 12
5 BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5 BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 Leaf ESI Label Extended Community . . . . . . . . . . . . . 13 5.1 E-TREE Extended Community . . . . . . . . . . . . . . . . . 13
5.2 E-TREE Extended Community . . . . . . . . . . . . . . . . . 13 5.2 PMSI Tunnel Attribute . . . . . . . . . . . . . . . . . . . 14
6 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 14 6 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 14
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 14 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 14
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 14
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1 Normative References . . . . . . . . . . . . . . . . . . . 14 9.1 Normative References . . . . . . . . . . . . . . . . . . . 15
9.2 Informative References . . . . . . . . . . . . . . . . . . 14 9.2 Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1 Introduction 1 Introduction
The Metro Ethernet Forum (MEF) has defined a rooted-multipoint The Metro Ethernet Forum (MEF) has defined a rooted-multipoint
Ethernet service known as Ethernet Tree (E-Tree). In an E-Tree Ethernet service known as Ethernet Tree (E-Tree). In an E-Tree
service, endpoints are labeled as either Root or Leaf sites. Root service, endpoints are labeled as either Root or Leaf sites. Root
sites can communicate with all other sites. Leaf sites can sites can communicate with all other sites. Leaf sites can
communicate with Root sites but not with other Leaf sites. communicate with Root sites but not with other Leaf sites.
skipping to change at page 4, line 43 skipping to change at page 4, line 43
document are to be interpreted as described in RFC 2119 [KEYWORDS]. document are to be interpreted as described in RFC 2119 [KEYWORDS].
2 E-Tree Scenarios and EVPN / PBB-EVPN Support 2 E-Tree Scenarios and EVPN / PBB-EVPN Support
In this section, we will categorize support for E-Tree into three In this section, we will categorize support for E-Tree into three
different scenarios, depending on the nature of the site association different scenarios, depending on the nature of the site association
(Root/Leaf) per PE or per Ethernet Segment: (Root/Leaf) per PE or per Ethernet Segment:
- Leaf OR Root site(s) per PE - Leaf OR Root site(s) per PE
- Leaf AND Root site(s) per PE - Leaf OR Root site(s) per AC
- Leaf AND Root site(s) per Ethernet Segment - Leaf OR Root site(s) per MAC
2.1 Scenario 1: Leaf OR Root site(s) per PE 2.1 Scenario 1: Leaf OR Root site(s) per PE
In this scenario, a PE may receive traffic from either Root sites OR In this scenario, a PE may receive traffic from either Root sites OR
Leaf sites for a given MAC-VRF/bridge table, but not both Leaf sites for a given MAC-VRF/bridge table, but not both
concurrently. In other words, a given MAC-VRF/bridge table on a PE is concurrently. In other words, a given EVI on a PE is either
either associated with a root or leaf. The PE may have both Root and associated with a root or leaf. The PE may have both Root and Leaf
Leaf sites albeit for different MAC-VRFs/bridge tables. sites albeit for different EVIs.
+---------+ +---------+ +---------+ +---------+
| PE1 | | PE2 | | PE1 | | PE2 |
+---+ | +---+ | +------+ | +---+ | +---+ +---+ | +---+ | +------+ | +---+ | +---+
|CE1+---ES1----+--+ | | | MPLS | | | +--+----ES2-----+CE2| |CE1+---ES1----+--+ | | | MPLS | | | +--+----ES2-----+CE2|
+---+ (Root) | |MAC| | | /IP | | |MAC| | (Leaf) +---+ +---+ (Root) | |MAC| | | /IP | | |MAC| | (Leaf) +---+
| |VRF| | | | | |VRF| | | |VRF| | | | | |VRF| |
| | | | | | | | | | +---+ | | | | | | | | | | +---+
| | | | | | | | +--+----ES3-----+CE3| | | | | | | | | +--+----ES3-----+CE3|
| +---+ | +------+ | +---+ | (Leaf) +---+ | +---+ | +------+ | +---+ | (Leaf) +---+
+---------+ +---------+ +---------+ +---------+
Figure 1: Scenario 1 Figure 1: Scenario 1
In such scenario, an EVPN PE implementation MAY provide topology In such scenario, an EVPN PE implementation MAY provide E-TREE
constraint among the PEs belonging to the same EVI associated with an service using topology constraint among the PEs belonging to the same
E-TREE service. The purpose of this topology constraint is to avoid EVI. The purpose of this topology constraint is to avoid having PEs
having PEs with only Leaf sites importing and processing BGP MAC with only Leaf sites importing and processing BGP MAC routes from
routes from each other, thereby unnecessarily exhausting their RIB each other. To support such topology constrain in EVPN, two BGP
tables. To support such topology constrain in EVPN, two BGP Route- Route-Targets (RTs) are used for every EVPN Instance (EVI): one RT is
Targets (RTs) are used for every EVPN Instance (EVI): one RT is
associated with the Root sites and the other is associated with the associated with the Root sites and the other is associated with the
Leaf sites. On a per EVI basis, every PE exports the single RT Leaf sites. On a per EVI basis, every PE exports the single RT
associated with its type of site(s). Furthermore, a PE with Root associated with its type of site(s). Furthermore, a PE with Root
site(s) imports both Root and Leaf RTs, whereas a PE with Leaf site(s) imports both Root and Leaf RTs, whereas a PE with Leaf
site(s) only imports the Root RT. If the number of EVIs is very large site(s) only imports the Root RT. If the number of EVIs is very large
(e.g., more than 32K or 64K), then RT type 0 as defined in [RFC4360] (e.g., more than 32K or 64K), then RT type 0 as defined in [RFC4360]
SHOULD be used; otherwise, RT type 2 is sufficient. SHOULD be used; otherwise, RT type 2 is sufficient.
2.2 Scenario 2: Leaf OR Root site(s) per AC 2.2 Scenario 2: Leaf OR Root site(s) per AC
In this scenario, a PE may receive traffic from either Root OR Leaf In this scenario, a PE receives traffic from either Root OR Leaf
sites on a given Attachment Circuit (AC) of a MAC-VRF/bridge table. sites (but not both) on a given Attachment Circuit (AC) of an EVI. In
In other words, an AC (ES or ES/VLAN) is either associated with a other words, an AC (ES or ES/VLAN) is either associated with a Root
Root or Leaf (but not both). or Leaf (but not both).
+---------+ +---------+ +---------+ +---------+
| PE1 | | PE2 | | PE1 | | PE2 |
+---+ | +---+ | +------+ | +---+ | +---+ +---+ | +---+ | +------+ | +---+ | +---+
|CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2|
+---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+ +---+ (Leaf) | |MAC| | | MPLS | | |MAC| | (Leaf) +---+
| |VRF| | | /IP | | |VRF| | | |VRF| | | /IP | | |VRF| |
| | | | | | | | | | +---+ | | | | | | | | | | +---+
| | | | | | | | +--+---ES2/AC2--+CE3| | | | | | | | | +--+---ES2/AC2--+CE3|
| +---+ | +------+ | +---+ | (Root) +---+ | +---+ | +------+ | +---+ | (Root) +---+
+---------+ +---------+ +---------+ +---------+
Figure 2: Scenario 2 Figure 2: Scenario 2
In this scenario, if there are PEs with only root (or leaf) sites per In this scenario, if there are PEs with only root (or leaf) sites per
EVI, then the RT constrain procedures described in section 2.1 can EVI, then the RT constrain procedures described in section 2.1 can
also be used here. However, when a Root site is added to a Leaf PE also be used here. However, when a Root site is added to a Leaf PE,
(or vise versa), then that PE needs to process MAC routes from all then that PE needs to process MAC routes from all other Leaf PEs and
other Leaf PEs and add them to its forwarding table. If for a given add them to its forwarding table. For this scenario, if for a given
EVI, the PEs can eventually have both Leaf and Root sites attached, EVI, the majority of PEs will eventually have both Leaf and Root
even though they may start as Root-only or Leaf-only PEs, then it is sites attached, even though they may start as Root-only or Leaf-only
recommended to use a single RT per EVI and avoid additional PEs, then it is recommended to use a single RT per EVI and avoid
configuration and operational overhead. additional configuration and operational overhead.
2.3 Scenario 3: Leaf OR Root site(s) per MAC 2.3 Scenario 3: Leaf OR Root site(s) per MAC
In this scenario, a PE may receive traffic from both Root AND Leaf In this scenario, a PE may receive traffic from both Root AND Leaf
sites on a given Attachment Circuit (AC) of a MAC-VRF/bridge table. sites on a given Attachment Circuit (AC) of an EVI. Since an
Since an Attachment Circuit (ES or ES/VLAN) carries traffic from both Attachment Circuit (ES or ES/VLAN) carries traffic from both Root and
Root and Leaf sites, the granularity at which Root or Leaf sites are Leaf sites, the granularity at which Root or Leaf sites are
identifies is on a per MAC address. This scenario is considered in identifies is on a per MAC address. This scenario is considered in
this draft for EVPN service with only known unicast traffic - i.e., this draft for EVPN service with only known unicast traffic - i.e.,
there is no BUM traffic. there is no BUM traffic.
+---------+ +---------+ +---------+ +---------+
| PE1 | | PE2 | | PE1 | | PE2 |
+---+ | +---+ | +------+ | +---+ | +---+ +---+ | +---+ | +------+ | +---+ | +---+
|CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2| |CE1+-----ES1----+--+ | | | | | | +--+---ES2/AC1--+CE2|
+---+ (Root) | | E | | | MPLS | | | E | | (Leaf/Root)+---+ +---+ (Root) | | E | | | MPLS | | | E | | (Leaf/Root)+---+
| | V | | | /IP | | | V | | | | V | | | /IP | | | V | |
skipping to change at page 7, line 11 skipping to change at page 7, line 11
+---------+ +---------+ +---------+ +---------+
Figure 3: Scenario 3 Figure 3: Scenario 3
3 Operation for EVPN 3 Operation for EVPN
[EVPN] defines the notion of ESI MPLS label used for split-horizon [EVPN] defines the notion of ESI MPLS label used for split-horizon
filtering of BUM traffic at the egress PE. Such egress filtering filtering of BUM traffic at the egress PE. Such egress filtering
capabilities can be leveraged in provision of E-TREE services as seen capabilities can be leveraged in provision of E-TREE services as seen
shortly. In other words, [EVPN] has inherent capability to support E- shortly. In other words, [EVPN] has inherent capability to support E-
TREE services without defining any new BGP routes but just defining a TREE services without defining any new BGP routes but by just
new BGP Extended Community for leaf indication as shown later in this defining a new BGP Extended Community for leaf indication as shown
document. later in this document.
3.1 Known Unicast Traffic 3.1 Known Unicast Traffic
Since in EVPN, MAC learning is performed in control plane via Since in EVPN, MAC learning is performed in control plane via
advertisement of BGP routes, the filtering needed by E-TREE service advertisement of BGP routes, the filtering needed by E-TREE service
for known unicast traffic can be performed at the ingress PE, thus for known unicast traffic can be performed at the ingress PE, thus
providing very efficient filtering and avoiding sending known unicast providing very efficient filtering and avoiding sending known unicast
traffic over MPLS/IP core to be filtered at the egress PE as done in traffic over MPLS/IP core to be filtered at the egress PE as done in
traditional E-TREE solutions (e.g., E-TREE for VPLS). traditional E-TREE solutions (e.g., E-TREE for VPLS).
To provide such ingress filtering for known unicast traffic, a PE To provide such ingress filtering for known unicast traffic, a PE
MUST indicate to other PEs what kind of sites (root or leaf) its MAC MUST indicate to other PEs what kind of sites (root or leaf) its MAC
addresses are associated with. This indication is achieved by using addresses are associated with by advertising a leaf indication flag
one of the following mechanisms: (via an Extended Community) along with each of its MAC/IP
Advertisement route. The lack of such flag indicates that the MAC
1) For single-homing scenarios of sections 2.2 and 2.3, the PE address is associated with a root site. This scheme applies to all
advertises the MAC addresses received from a Leaf site, with an scenarios described in section 2.
Extended community indicating a leaf flag. The lack of such flag
indicates that the MAC address is associated with a root site.
2) For multi-homing scenario of section 2.2, where an AC is either
root or leaf (but not both), the PE advertises leaf indication along
with the Ethernet A-D per EVI route. Since these routes are always
advertised ahead of MAC advertisements route, there is no need to
append leaf-indication flag with the MAC advertisement routes. The
leaf indication flag on Ethernet A-D per EVI route tells the
receiving PEs that all MAC addresses associated with this <ESI, EVI>
or <ESI, EVI/VLAN> are from a leaf site. The lack of such leaf-
indication flag tells the receiving PEs that the MAC addresses are
associated with a root site.
If a leaf site is multi-homed to PE1 an PE2, and PE1 advertises the
Ethernet A-D per EVI corresponding to this leaf site with the leaf-
indication flag but PE2 does not, then the receiving PE MUST notify
the operator of such discrepancy and ignore the leaf-indication flag
on PE1. In other words, in case of discrepancy, the multi-homing for
that pair of PEs is assumed to be in default "root" mode for that
<ESI, EVI> or <ESI, EVI/VLAN>.
3) For multi-homing scenario of section 2.3, where an AC is both root Furthermore, for multi-homing scenario of section 2.2, where an AC is
or leaf (i.e., root or leaf indication is at the granularity of MAC either root or leaf (but not both), the PE MAY advertise leaf
address), the PE advertises leaf indication along with each MAC indication along with the Ethernet A-D per EVI route. This
advertisement route just as in (1). No leaf-indication flag SHALL be advertisement is used for sanity checking in control-plane to ensure
sent along with the Ethernet A-D per EVI route for this scenario. that there is no discrepancy in configuration among different PEs of
the same redundancy group. For example, if a leaf site is multi-homed
to PE1 an PE2, and PE1 advertises the Ethernet A-D per EVI
corresponding to this leaf site with the leaf-indication flag but PE2
does not, then the receiving PE notifies the operator of such
discrepancy and ignore the leaf-indication flag on PE1. In other
words, in case of discrepancy, the multi-homing for that pair of PEs
is assumed to be in default "root" mode for that <ESI, EVI> or <ESI,
EVI/VLAN>. The leaf indication flag on Ethernet A-D per EVI route
tells the receiving PEs that all MAC addresses associated with this
<ESI, EVI> or <ESI, EVI/VLAN> are from a leaf site. Therefore, if a
PE receives a leaf indication for an AC via the Ethernet A-D per EVI
route but doesn't receive a leaf indication in the corresponding MAC
route, then it notify the operator and ignore the leaf indication on
the Ethernet A-D per EVI route.
Tagging MAC addresses with a leaf indication (either directly via MAC Tagging MAC addresses with a leaf indication enables remote PEs to
advertisement route or indirectly via Ethernet A-D per EVI route) perform ingress filtering for known unicast traffic - i.e., on the
enables remote PEs to perform ingress filtering for known unicast ingress PE, the MAC destination address lookup yields, in addition to
traffic - i.e., on the ingress PE, the MAC destination address lookup the forwarding adjacency, a flag which indicates whether the target
yields, in addition to the forwarding adjacency, a flag which MAC is associated with a Leaf site or not. The ingress PE cross-
indicates whether the target MAC is associated with a Leaf site or checks this flag with the status of the originating AC, and if both
not. The ingress PE cross-checks this flag with the status of the are Leafs, then the packet is not forwarded.
originating AC, and if both are Leafs, then the packet is not
forwarded.
To support the above ingress filtering functionality, a new E-TREE To support the above ingress filtering functionality, a new E-TREE
Extended Community with a Leaf indication flag is introduced [section Extended Community with a Leaf indication flag is introduced [section
5.2]. This new Extended Community is advertised with either Ethernet 5.2]. This new Extended Community MUST be advertised with MAC/IP
A-D per EVI route or MAC/IP Advertisement route as described above. Advertisement route and MAY be advertised with an Ethernet A-D per
EVI route as described above.
3.2 BUM Traffic 3.2 BUM Traffic
For BUM traffic, it is not possible to perform filtering on the For BUM traffic, it is not possible to perform filtering on the
ingress PE, as is the case with known unicast, because of the multi- ingress PE, as is the case with known unicast, because of the multi-
destination nature of the traffic. As such, the solution relies on destination nature of the traffic. As such, the solution relies on
egress filtering. In order to apply the proper egress filtering, egress filtering. In order to apply the proper egress filtering,
which varies based on whether a packet is sent from a Leaf AC or a which varies based on whether a packet is sent from a Leaf AC or a
root AC, the MPLS-encapsulated frames MUST be tagged with an root AC, the MPLS-encapsulated frames MUST be tagged with an
indication of whether they originated from a Leaf AC or not. In other indication of whether they originated from a Leaf AC or not. In other
skipping to change at page 9, line 5 skipping to change at page 8, line 46
carry an upstream assigned or downstream assigned MPLS label carry an upstream assigned or downstream assigned MPLS label
(respectively) for the purpose of egress filtering to indicate to the (respectively) for the purpose of egress filtering to indicate to the
egress PEs whether this packet is originated from a root AC or a leaf egress PEs whether this packet is originated from a root AC or a leaf
AC. AC.
The main difference between downstream and upstream assigned ESI MPLS The main difference between downstream and upstream assigned ESI MPLS
label is that in case of downstream assigned not all egress PE label is that in case of downstream assigned not all egress PE
devices need to receive the ESI label just like ingress replication devices need to receive the ESI label just like ingress replication
procedures defined in [RFC7432]. procedures defined in [RFC7432].
There are four scenarios to consider: There are four scenarios to consider as follow. In all these
scenarios, the imposition PE imposes the right ESI MPLS label
depending on whether the Ethernet frame originated from a Root or a
Leaf site on that Ethernet Segment. The mechanism by which the PE
identifies whether a given frame originated from a Root or a Leaf
site on the segment is based on the Ethernet Tag associated with the
frame (e.g., whether the frame received on a leaf or a root AC).
Other mechanisms for identifying whether an egress AC is a root or
leaf is beyond the scope of this document.
3.2.1 BUM traffic originated from a single-homed site on a leaf AC 3.2.1 BUM traffic originated from a single-homed site on a leaf AC
In this scenario, the ingress PE adds a special ESI MPLS label to the In this scenario, the ingress PE adds a special MPLS label indicating
frame indicating a Leaf site. This special ESI MPLS label used for a Leaf site. This special Leaf MPLS label, used for single-homing
single-homing scenarios is not on a per ES basis but rather on a per scenarios, is not on a per ES basis but rather on a per PE basis -
PE basis - i.e., a single ESI MPLS label is used for all single-homed i.e., a single Leaf MPLS label is used for all single-homed ES's on
ES's on that PE. This special ESI MPLS label is advertised to other that PE. This Leaf MPLS label is advertised to other PE devices,
PE devices, using a new EVPN Extended Community called Leaf ESI MPLS using a new EVPN Extended Community called E-TREE Extended Community
label Extended Community (section 5.1) along with a set of Ethernet (section 5.1) along with an Ethernet A-D per ES route with ESI of
A-D per ES routes. The set of Ethernet A-D per ES routes may be zero and a set of Route Targets (RTs) corresponding to all the leaf
needed if the number of Route Targets (RTs) that need to be sent ACs on the PE. The set of Ethernet A-D per ES routes may be needed if
exceed the limit on a single route per [RFC 7432]. The RT(s) the number of Route Targets (RTs) that need to be sent exceed the
represent EVIs with at least a leaf site in them. The ESI for the limit on a single route per [RFC 7432]. The RT(s) represent EVIs with
Ethernet A-D per ES route is set to zero indicating single-homed at least a leaf site in them. The ESI for the Ethernet A-D per ES
sites. route is set to zero to indicate single-homed sites.
When a PE receives this special ESI MPLS label in the data path, it When a PE receives this special ESI MPLS label in the data path, it
blocks the packet if the destination AC is of type Leaf; otherwise, blocks the packet if the destination AC is of type Leaf; otherwise,
it forwards the packet. it forwards the packet.
3.2.2 BUM traffic originated from a single-homed site on a root AC 3.2.2 BUM traffic originated from a single-homed site on a root AC
In this scenario, the ingress PE does not add any ESI MPLS label and In this scenario, the ingress PE does not add any ESI or Leaf MPLS
it operates per [RFC7432] procedures. label and it operates per [RFC7432] procedures.
3.2.3 BUM traffic originated from a multi-homed site on a leaf AC 3.2.3 BUM traffic originated from a multi-homed site on a leaf AC
In this scenario, the ingress PE adds an ESI MPLS label to the frame In this scenario, it is assumed that a multi-homed Ethernet Segment
indicating both the Ethernet Segment of origin and its Leaf type. The (ES) can have a mixed of both leaf and root ACs with each AC
reason Ethernet Segment of origin needs to be identified in addition designating a subnet (e.g., a VLAN). Furthermore, it is assumed that
to Leaf type, is to accommodate multi-homing scenarios for Integrated there is no forwarding among subnets - ie, the service is EVPN L2 and
Routing and Bridging (IRB) where a source (Leaf) can be on one VLAN not EVPN IRB. IRB use case is for further study.
and the receivers (roots) can be on some other VLANs for the same
Ethernet Segment.
This ESI MPLS label is advertised to other PE devices, using a new In such scenarios, If a multicast packet is originated from a leaf
EVPN Extended Community called Leaf ESI Label Extended Community AC, then it only needs to carry Leaf MPLS label described in section
(section 5.1) along with a set of Ethernet A-D per ES routes 3.2.1. This label is sufficient in providing the necessary egress
corresponding to the ES of the origin. If the egress ES is the same filtering of BUM traffic from getting sent to leaf ACs including the
as the originated ES, then the receiving PE uses the same procedure leaf AC on the same Ethernet Segment.
for filtering BUM traffic as the one specified in [RFC 7432]. If the
egress ES is different from the originated ES, then the receiving PE
uses the ESI label to identify that the BUM traffic is associated
with a leaf site and thus blocking the BUM traffic if the destination
AC is also of type Leaf similar to section 3.2.1.
3.2.4 BUM traffic originated from a multi-homed site on a root AC 3.2.4 BUM traffic originated from a multi-homed site on a root AC
In this scenario, both the ingress and egress PE devices follows the In this scenario, both the ingress and egress PE devices follows the
procedure defined in [RFC 7432] for adding and/or processing an ESI procedure defined in [RFC 7432] for adding and/or processing an ESI
MPLS label. MPLS label.
The ingress PE imposes the right ESI MPLS label depending on whether
the Ethernet frame originated from the Root or Leaf site on that
Ethernet Segment. The mechanism by which the PE identifies whether a
given frame originated from a Root or Leaf site on the segment is
based on the Ethernet Tag associated with the frame (e.g., whether
the frame come from a leaf or a root AC). Other mechanisms for
identifying whether an egress AC is a root or leaf is beyond the
scope of this document.
3.3 E-TREE Traffic Flows for EVPN 3.3 E-TREE Traffic Flows for EVPN
Per [ETREE-FMWK], a generic E-Tree service supports all of the Per [ETREE-FMWK], a generic E-Tree service supports all of the
following traffic flows: following traffic flows:
- Ethernet Unicast from Root to Roots & Leaf - Ethernet Unicast from Root to Roots & Leaf
- Ethernet Unicast from Leaf to Root - Ethernet Unicast from Leaf to Root
- Ethernet Broadcast/Multicast from Root to Roots & Leafs - Ethernet Broadcast/Multicast from Root to Roots & Leafs
- Ethernet Broadcast/Multicast from Leaf to Roots - Ethernet Broadcast/Multicast from Leaf to Roots
skipping to change at page 10, line 41 skipping to change at page 10, line 26
types of flows or only a select subset, depending on the target types of flows or only a select subset, depending on the target
application. In the case where unicast flows need not be supported, application. In the case where unicast flows need not be supported,
the L2VPN PEs can avoid performing any MAC learning function. the L2VPN PEs can avoid performing any MAC learning function.
In the subsections that follow, we will describe the operation of In the subsections that follow, we will describe the operation of
EVPN to support E-Tree service with and without MAC learning. EVPN to support E-Tree service with and without MAC learning.
3.3.1 E-Tree with MAC Learning 3.3.1 E-Tree with MAC Learning
The PEs implementing an E-Tree service must perform MAC learning when The PEs implementing an E-Tree service must perform MAC learning when
unicast traffic flows must be supported from Root to Leaf or from unicast traffic flows must be supported among Root and Leaf sites. In
Leaf to Root sites. In this case, the PE with Root sites performs MAC this case, the PE with Root sites performs MAC learning in the data-
learning in the data-path over the Ethernet Segments, and advertises path over the Ethernet Segments, and advertises reachability in EVPN
reachability in EVPN MAC Advertisement routes. These routes will be MAC Advertisement routes. These routes will be imported by PEs that
imported by PEs that have Leaf sites as well as by PEs that have Root have Leaf sites as well as by PEs that have Root sites, in a given
sites, in a given EVI. Similarly, the PEs with Leaf sites perform MAC EVI. Similarly, the PEs with Leaf sites perform MAC learning in the
learning in the data-path over their Ethernet Segments, and advertise data-path over their Ethernet Segments, and advertise reachability in
reachability in EVPN MAC Advertisement routes which are imported only EVPN MAC Advertisement routes which are imported only by PEs with at
by PEs with at least one Root site in the EVI. A PE with only Leaf least one Root site in the EVI. A PE with only Leaf sites will not
sites will not import these routes. PEs with Root and/or Leaf sites import these routes. PEs with Root and/or Leaf sites may use the
may use the Ethernet A-D routes for aliasing (in the case of multi- Ethernet A-D routes for aliasing (in the case of multi-homed
homed segments) and for mass MAC withdrawal per [RFC 7432]. segments) and for mass MAC withdrawal per [RFC 7432].
To support multicast/broadcast from Root to Leaf sites, either a P2MP To support multicast/broadcast from Root to Leaf sites, either a P2MP
tree rooted at the PE(s) with the Root site(s) or ingress replication tree rooted at the PE(s) with the Root site(s) or ingress replication
can be used. The multicast tunnels are set up through the exchange of can be used. The multicast tunnels are set up through the exchange of
the EVPN Inclusive Multicast route, as defined in [RFC7432]. the EVPN Inclusive Multicast route, as defined in [RFC7432].
To support multicast/broadcast from Leaf to Root sites, ingress To support multicast/broadcast from Leaf to Root sites, ingress
replication should be sufficient for most scenarios where there is a replication should be sufficient for most scenarios where there are
single Root or few Roots. If the number of Roots is large, a P2MP only a few Roots (typically two). Therefore, in a typical scenario, a
tree rooted at the PEs with Leaf sites may be used. root PE needs to support both a P2MP tunnel in transmit direction
from itself to leaf PEs and at the same time it needs to support
ingress-replication tunnels in receive direction from leaf PEs to
itself. In order to signal this efficiently from the root PE, a new
composite tunnel type is defined per section 5.3. This new composite
tunnel type is advertised by the root PE to simultaneously indicate a
P2MP tunnel in transmit direction and an ingress-replication tunnel
in the receive direction for the BUM traffic.
If the number of Roots is large, P2MP tunnels originated at the PEs
with Leaf sites may be used and thus there will be no need to use the
modified PMSI tunnel attribute in section 5.2 for composite tunnel
type.
3.3.2 E-Tree without MAC Learning 3.3.2 E-Tree without MAC Learning
The PEs implementing an E-Tree service need not perform MAC learning The PEs implementing an E-Tree service need not perform MAC learning
when the traffic flows between Root and Leaf sites are multicast or when the traffic flows between Root and Leaf sites are multicast or
broadcast. In this case, the PEs do not exchange EVPN MAC broadcast. In this case, the PEs do not exchange EVPN MAC
Advertisement routes. Instead, the Ethernet A-D routes are used to Advertisement routes. Instead, the Inclusive Multicast Ethernet Tag
exchange the EVPN labels. (IMET) routes are used to support BUM traffic.
The fields of the Ethernet A-D route are populated per the procedures The fields of the IMET route are populated per the procedures defined
defined in [RFC7432], and the route import rules are as described in in [RFC7432], and the route import rules are as described in previous
previous sections. sections.
Just as in the previous section, if the number of PEs with root sites
are only a few and thus ingress replication is desired from leaf PEs
to these root PEs, then the modified PMSI attribute as defined in
section 5.3 should be used.
4 Operation for PBB-EVPN 4 Operation for PBB-EVPN
In PBB-EVPN, the PE must advertise a Root/Leaf indication along with In PBB-EVPN, the PE must advertise a Root/Leaf indication along with
each B-MAC Advertisement route, to indicate whether the associated B- each B-MAC Advertisement route, to indicate whether the associated B-
MAC address corresponds to a Root or a Leaf site. Similar to the EVPN MAC address corresponds to a Root or a Leaf site. Similar to the EVPN
case, this flag will be added to the new E-TREE Extended Community case, this flag will be added to the new E-TREE Extended Community
defined in section [5.2], and advertised with each MAC Advertisement defined in section [5.2], and advertised with each MAC Advertisement
route. route.
skipping to change at page 13, line 9 skipping to change at page 13, line 9
The PE places all Leaf Ethernet Segments of a given bridge domain in The PE places all Leaf Ethernet Segments of a given bridge domain in
a single split-horizon group in order to prevent intra-PE forwarding a single split-horizon group in order to prevent intra-PE forwarding
among Leaf segments. This split-horizon function applies to BUM among Leaf segments. This split-horizon function applies to BUM
traffic. traffic.
5 BGP Encoding 5 BGP Encoding
This document defines two new BGP Extended Community for EVPN. This document defines two new BGP Extended Community for EVPN.
5.1 Leaf ESI Label Extended Community 5.1 E-TREE Extended Community
This Extended Community is a new transitive Extended Community having This Extended Community is a new transitive Extended Community having
a Type field value of 0x06 (EVPN) and the Sub-Type 0x04. In purpose, a Type field value of 0x06 (EVPN) and the Sub-Type 0x05. It is used
it is similar to ESI Label EC defined in [RFC 7432] with the only for leaf indication of known unicast and BUM traffic. For BUM
difference that it is used to indicate a leaf site in addition to the traffic, the Leaf Label field is set to a valid MPLS label and this
Ethernet segment of origin. EC is advertised along with Ethernet A-D per ES route with an ESI of
zero to enable egress filtering on disposition PEs per section 3.2.1
It may be advertised along with Ethernet Auto-discovery routes, and and 3.2.3. For known unicast traffic, the Leaf flag bit is set to one
it enables split-horizon procedures for multihomed sites as described and this EC is advertised along with MAC/IP Advertisement route per
in Section 3.2.1.3. The Leaf ESI Label field represents an ES with a section 3.1.
leaf site by the advertising PE, and it is used in split-horizon
filtering by other PEs that are connected to the same multihomed
Ethernet segment and egress filtering by other PEs that are connected
to Leaf ACs.
The E-TREE Extended Community is encoded as an 8-octet value as The E-TREE Extended Community is encoded as an 8-octet value as
follows: follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=0x04 | Reserved=0 | | Type=0x06 | Sub-Type=0x04 | Flags(1 Octet)| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved=0 | Leaf ESI Label | | Reserved=0 | Leaf Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2 E-TREE Extended Community The low-order bit of the Flags octet is defined as the "Leaf-
Indication" bit. A value of one indicates a Leaf AC/Site.
A new EVPN BGP Extended Community called E-TREE is introduced here. When this EC is advertised along with MAC/IP Advertisement route, the
This new extended community is a transitive extended community with Leaf-Indication flag MUST be set to one and Leaf Label is set to
the Type field of 0x06 (EVPN) and the Sub-Type of 0x05. This extended zero. The received PE should ignore Leaf Label and only processes
community is used to for leaf indication and it is advertised with an Leaf-Indication flag. A value of zero for Leaf-Indication flag is
EVPN MAC/IP route or an Ethernet A-D per EVI route. invalid when sent along with MAC/IP advertisement route and an error
should be logged.
The E-TREE Extended Community is encoded as an 8-octet value as When this EC is advertised along with Ethernet A-D per ES route (with
follows: ESI of zero), the Leaf Label MUST be set to a valid MPLS label and
the Leaf-Indication flag should be set to zero. The received PE
should ignore the Leaf-Indication flag. A non-valid MPLS label when
sent along with the Ethernet A-D per ES route, should be logged as an
error.
0 1 2 3 5.2 PMSI Tunnel Attribute
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=0x05 | Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rserved=0 | Reserved=0 |L|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Leaf flag (L): A value of 1 indicates a leaf [RFC 6514] defines PMSI Tunnel attribute which is an optional
transitive attribute with the following format:
+---------------------------------+
| Flags (1 octet) |
+---------------------------------+
| Tunnel Type (1 octets) |
+---------------------------------+
| MPLS Label (3 octets) |
+---------------------------------+
| Tunnel Identifier (variable) |
+---------------------------------+
This draft uses all the fields per existing definition except for the
following modifications to the Tunnel Type and Tunnel Identifier:
When receiver ingress-replication label is needed, the high-order bit
of the tunnel type field (C bit - Composite tunnel bit) is set while
the remaining low-order seven bits indicate the tunnel type as
before. When this C bit is set, the "tunnel identifier" field would
begin with a three-octet label, followed by the actual tunnel
identifier for the transmit tunnel. PEs that don't understand the
new meaning of the high-order bit would treat the tunnel type as an
invalid tunnel type. For the PEs that do understand the new meaning
of the high-order, if ingress replication is desired when sending BUM
traffic, the PE will use the the label in the Tunnel Identifier field
when sending its BUM traffic.
6 Acknowledgement 6 Acknowledgement
We would like to thank Dennis Cai and Antoni Przygienda for their We would like to thank Dennis Cai, Antoni Przygienda, and Jeffrey
comments. Zhang for their valueable comments.
7 Security Considerations 7 Security Considerations
Same security considerations as [RFC7432]. Same security considerations as [RFC7432].
8 IANA Considerations 8 IANA Considerations
Allocation of Extended Community Type and Sub-Type for EVPN. Allocation of Extended Community Type and Sub-Type for EVPN.
9 References 9 References
 End of changes. 38 change blocks. 
174 lines changed or deleted 197 lines changed or added

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