draft-ietf-bess-evpn-etree-07.txt   draft-ietf-bess-evpn-etree-08.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Intended Status: Standards Track Cisco Intended Status: Standards Track Cisco
Updates: RFC7385 J. Drake Updates: RFC7385 J. Drake
Juniper Juniper
J. Uttaro J. Uttaro
ATT ATT
S. Boutros S. Boutros
VMware VMware
J. Rabadan J. Rabadan
Nokia Nokia
Expires: March 1, 2017 September 1, 2016 Expires: June 12, 2017 January 12, 2017
E-TREE Support in EVPN & PBB-EVPN E-TREE Support in EVPN & PBB-EVPN
draft-ietf-bess-evpn-etree-07 draft-ietf-bess-evpn-etree-08
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). A solution Ethernet service known as Ethernet Tree (E-Tree). A solution
framework for supporting this service in MPLS networks is proposed in framework for supporting this service in MPLS networks is proposed in
and RFC called "A Framework for E-Tree Service over MPLS Network". and RFC called "A Framework for E-Tree Service over MPLS Network".
This document discusses how those functional requirements can be This document discusses how those functional requirements can be
easily met with (PBB-)EVPN and how (PBB-)EVPN offers a more efficient easily met with (PBB-)EVPN and how (PBB-)EVPN offers a more efficient
implementation of these functions. This document makes use of the implementation of these functions. This document makes use of the
skipping to change at page 2, line 31 skipping to change at page 2, line 31
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
2 E-Tree Scenarios and EVPN / PBB-EVPN Support . . . . . . . . . 4 2 E-Tree Scenarios and EVPN / PBB-EVPN Support . . . . . . . . . 4
2.1 Scenario 1: Leaf OR Root site(s) per PE . . . . . . . . . . 4 2.1 Scenario 1: Leaf OR Root site(s) per PE . . . . . . . . . . 4
2.2 Scenario 2: Leaf OR Root site(s) per AC . . . . . . . . . . 5 2.2 Scenario 2: Leaf OR Root site(s) per AC . . . . . . . . . . 5
2.3 Scenario 3: Leaf OR Root site(s) per MAC . . . . . . . . . . 6 2.3 Scenario 3: Leaf OR Root site(s) per MAC . . . . . . . . . . 7
3 Operation for EVPN . . . . . . . . . . . . . . . . . . . . . . . 7 3 Operation for EVPN . . . . . . . . . . . . . . . . . . . . . . . 7
3.1 Known Unicast Traffic . . . . . . . . . . . . . . . . . . . 7 3.1 Known Unicast Traffic . . . . . . . . . . . . . . . . . . . 8
3.2 BUM Traffic . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 BUM Traffic . . . . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 E-TREE Traffic Flows for EVPN . . . . . . . . . . . . . . . 10 3.3 E-TREE Traffic Flows for EVPN . . . . . . . . . . . . . . . 11
3.3.1 E-Tree with MAC Learning . . . . . . . . . . . . . . . . 10 3.3.1 E-Tree with MAC Learning . . . . . . . . . . . . . . . . 11
3.3.2 E-Tree without MAC Learning . . . . . . . . . . . . . . 11 3.3.2 E-Tree without MAC Learning . . . . . . . . . . . . . . 12
4 Operation for PBB-EVPN . . . . . . . . . . . . . . . . . . . . . 11 4 Operation for PBB-EVPN . . . . . . . . . . . . . . . . . . . . . 12
4.1 Known Unicast Traffic . . . . . . . . . . . . . . . . . . . 12 4.1 Known Unicast Traffic . . . . . . . . . . . . . . . . . . . 13
4.2 BUM Traffic . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2 BUM Traffic . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3 E-Tree without MAC Learning . . . . . . . . . . . . . . . . 13 4.3 E-Tree without MAC Learning . . . . . . . . . . . . . . . . 14
5 BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5 BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1 E-TREE Extended Community . . . . . . . . . . . . . . . . . 13 5.1 E-TREE Extended Community . . . . . . . . . . . . . . . . . 14
5.2 PMSI Tunnel Attribute . . . . . . . . . . . . . . . . . . . 14 5.2 PMSI Tunnel Attribute . . . . . . . . . . . . . . . . . . . 15
6 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 15 6 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 16
7 Security Considerations . . . . . . . . . . . . . . . . . . . . 15 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 16
8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 15 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 16
8.1 Considerations for PMSI Tunnel Types . . . . . . . . . . . . 15 8.1 Considerations for PMSI Tunnel Types . . . . . . . . . . . . 16
9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1 Normative References . . . . . . . . . . . . . . . . . . . 16 9.1 Normative References . . . . . . . . . . . . . . . . . . . 17
9.2 Informative References . . . . . . . . . . . . . . . . . . 16 9.2 Informative References . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
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.
[RFC7387] proposes the solution framework for supporting E-Tree [RFC7387] proposes the solution framework for supporting E-Tree
skipping to change at page 5, line 21 skipping to change at page 5, line 21
|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, topology constraint, provided by BGP Route Target In such scenario, using tailored BGP Route Target (RT) import/export
(RT) import/export policies among the PEs belonging to the same EVI, policies among the PEs belonging to the same EVI, can be used to
can be used to restrict the communications among Leaf PEs. The restrict the communications among Leaf PEs. To restrict the
purpose of this topology constraint is to avoid having PEs with only communications among Leaf sites connected to the same PE and
Leaf sites importing and processing BGP MAC routes from each other. belonging to the same EVI, split-horizon filtering is used to block
To support such topology constrain in EVPN, two BGP Route-Targets traffic from one Leaf interface to another Leaf interface of a given
(RTs) are used for every EVPN Instance (EVI): one RT is associated E-TREE EVI. The purpose of this topology constraint is to avoid
with the Root sites and the other is associated with the Leaf sites. having PEs with only Leaf sites importing and processing BGP MAC
On a per EVI basis, every PE exports the single RT associated with routes from each other. To support such topology constrain in EVPN,
its type of site(s). Furthermore, a PE with Root site(s) imports both two BGP Route-Targets (RTs) are used for every EVPN Instance (EVI):
Root and Leaf RTs, whereas a PE with Leaf site(s) only imports the one RT is associated with the Root sites and the other is associated
Root RT. with the 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
site(s) imports both Root and Leaf RTs, whereas a PE with Leaf
site(s) only imports the Root RT.
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 receives traffic from either Root OR Leaf In this scenario, a PE receives traffic from either Root OR Leaf
sites (but not both) on a given Attachment Circuit (AC) of an EVI. In sites (but not both) on a given Attachment Circuit (AC) of an EVI. In
other words, an AC (ES or ES/VLAN) is either associated with Root(s) other words, an AC (ES or ES/VLAN) is either a Root AC or a Leaf AC
or Leaf(s) (but not both). (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, just like the previous scenario (in section 2.1),
EVI, then the RT constrain procedures described in section 2.1 can two Route Targets (one for Root and another for Leaf) can be used.
also be used here. However, when a Root site is added to a Leaf PE, However, the difference is that on a PE with both Root and Leaf ACs,
then that PE needs to process MAC routes from all other Leaf PEs and all remote MAC routes are imported and thus there needs to be a way
add them to its forwarding table. For this scenario, if for a given to differentiate remote MAC routes associated with Leaf ACs versus
EVI, the vast majority of PEs will eventually have both Leaf and Root the ones associated with Root ACs in order to apply the proper
sites attached, even though they may start as Root-only or Leaf-only ingress filtering.
PEs, then it is recommended to use a single RT per EVI and avoid
additional configuration and operational overhead. In order to support such ingress filtering on the ingress PE with
both Leaf and Root ACs, one the following two approaches can be used:
A) To use two MAC-VRFs (two bridge tables per VLANs if a given VLAN
exists on the PE for both Leaf and Root ACs of an EVI) - one for Root
ACs and another for Leaf ACs.
B) To color MAC addresses with Leaf or Root color before distributing
them in BGP to other PEs depending on whether they are learned on a
Leaf AC or a Root AC.
Maintaining two MAC-VRFs (two bridge tables) per VLAN (when both Leaf
and Root ACs exists for that VLAN) would either require two lookups
be performed per MAC address in each direction in case of a miss, or
duplicating many MAC addresses between the two bridge tables
belonging to the same VLAN (same E-TREE instance). Unless two lookups
are made, duplication of MAC addresses would be needed for both
locally learned and remotely learned MAC addresses. Locally learned
MAC addresses from Leaf ACs need to be duplicated onto Root bridge
table and locally learned MAC addresses from Root ACs need to be
duplicated onto Leaf bridge table. Remotely learned MAC addresses
from Root ACs need to be copied onto both Root and Leaf bridge
tables. Because of potential inefficiencies associated with data-
plane implementation of additional MAC lookup or duplication of MAC
entries, option (A) is not believed to be implementable without
dataplane performance inefficiencies in some platforms and thus this
draft introduces the coloring option (B) as detailed in section 3.1.
In order to avoid two MAC-VRFs, this draft introduces the coloring
option (B) as detailed in section 3.1.
For this scenario, if for a given EVI, the vast majority of PEs will
have both Leaf and Root sites attached, even though they may start as
Root-only or Leaf-only PEs, then a single RT per EVI MAY be used in
order to alleviate the configuration overhead associated with using
two RTs per EVI at the expense of having unwanted MAC addresses on
the Leaf-only PEs.
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 single Attachment Circuit (AC) of an EVI. Since an sites on a single Attachment Circuit (AC) of an EVI. Since an
Attachment Circuit (ES or ES/VLAN) carries traffic from both Root and Attachment Circuit (ES or ES/VLAN) carries traffic from both Root and
Leaf sites, the granularity at which Root or Leaf sites are Leaf sites, the granularity at which Root or Leaf sites are
identified is on a per MAC address. This scenario is considered in identified 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 because
BUM traffic is not supported in this scenario and it is dropped . the DF filtering per [RFC7432] would not be compatible with the
required egress filtering - i.e., BUM traffic is not supported in
this scenario and it is dropped by the ingress PE.
+---------+ +---------+ +---------+ +---------+
| 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 | |
| | I | | | | | | I | | +---+ | | I | | | | | | I | | +---+
| | | | | | | | +--+---ES2/AC2--+CE3| | | | | | | | | +--+---ES2/AC2--+CE3|
| +---+ | +------+ | +---+ | (Leaf) +---+ | +---+ | +------+ | +---+ | (Leaf) +---+
skipping to change at page 9, line 14 skipping to change at page 9, line 51
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 as well as known-unicast traffic. traffic as well as known-unicast traffic.
There are four scenarios to consider as follows. In all these There are four scenarios to consider as follows. In all these
scenarios, the ingress PE imposes the right MPLS label associated scenarios, the ingress PE imposes the right MPLS label associated
with the originated Ethernet Segment (ES) depending on whether the with the originated Ethernet Segment (ES) depending on whether the
Ethernet frame originated from a Root or a Leaf site on that Ethernet Ethernet frame originated from a Root or a Leaf site on that Ethernet
Segment (ESI or Leaf label). The mechanism by which the PE identifies Segment (ESI label or Leaf label). The mechanism by which the PE
whether a given frame originated from a Root or a Leaf site on the identifies whether a given frame originated from a Root or a Leaf
segment is based on the AC identifier for that segment (e.g., site on the segment is based on the AC identifier for that segment
Ethernet Tag of the frame for 802.1Q frames). Other mechanisms for (e.g., Ethernet Tag of the frame for 802.1Q frames). Other mechanisms
identifying root or leaf (e.g., on a per MAC address basis) is beyond for identifying root or leaf (e.g., on a per MAC address basis) is
the scope of this document. 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 MPLS label indicating In this scenario, the ingress PE adds a special MPLS label indicating
a Leaf site. This special Leaf MPLS label, used for single-homing a Leaf site. This special Leaf MPLS label, used for single-homing
scenarios, is not on a per ES basis but rather on a per PE basis - scenarios, is not on a per ES basis but rather on a per PE basis -
i.e., a single Leaf MPLS label is used for all single-homed ES's on i.e., a single Leaf MPLS label is used for all single-homed ES's on
that PE. This Leaf label is advertised to other PE devices, using a that PE. This Leaf label is advertised to other PE devices, using a
new EVPN Extended Community called E-TREE Extended Community (section new EVPN Extended Community called E-TREE Extended Community (section
5.1) along with an Ethernet A-D per ES route with ESI of zero and a 5.1) along with an Ethernet A-D per ES route with ESI of zero and a
skipping to change at page 9, line 43 skipping to change at page 10, line 32
sent exceed the limit on a single route per [RFC7432]. The ESI for sent exceed the limit on a single route per [RFC7432]. The ESI for
the Ethernet A-D per ES route is set to zero to indicate single-homed the Ethernet A-D per ES route is set to zero to indicate single-homed
sites. sites.
When a PE receives this special Leaf label in the data path, it When a PE receives this special Leaf 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 or Leaf label In this scenario, the ingress PE does not add any ESI label or Leaf
and 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, it is assumed that while different ACs (VLANs) on In this scenario, it is assumed that while different ACs (VLANs) on
the same ES could have different root/leaf designation (some being the same ES could have different root/leaf designation (some being
roots and some being leafs), the same AC (e.g., VLAN) does have the roots and some being leafs), the same AC (e.g., VLAN) does have the
same root/leaf designation on all PEs on the same ES. Furthermore, it same root/leaf designation on all PEs on the same ES. Furthermore, it
is assumed that there is no forwarding among subnets - ie, the is assumed that there is no forwarding among subnets - ie, the
service is EVPN L2 and not EVPN IRB. IRB use case is outside the service is EVPN L2 and not EVPN IRB. IRB use case is outside the
scope of this document. scope of this document.
skipping to change at page 13, line 4 skipping to change at page 13, line 39
For known unicast traffic, the PEs perform ingress filtering: On the For known unicast traffic, the PEs perform ingress filtering: On the
ingress PE, the C-MAC destination address lookup yields, in addition ingress PE, the C-MAC destination address lookup yields, in addition
to the target B-MAC address and forwarding adjacency, a flag which to the target B-MAC address and forwarding adjacency, a flag which
indicates whether the target B-MAC is associated with a Root or a indicates whether the target B-MAC is associated with a Root or a
Leaf site. The ingress PE cross-checks this flag with the status of Leaf site. The ingress PE cross-checks this flag with the status of
the originating site, and if both are a Leaf, then the packet is not the originating site, and if both are a Leaf, then the packet is not
forwarded. forwarded.
4.2 BUM Traffic 4.2 BUM Traffic
For BUM traffic, the PEs must perform egress filtering. When a PE For BUM traffic, the PEs must perform egress filtering. When a PE
receives a MAC advertisement route (which will be used as a source B- receives a MAC advertisement route (which will be used as a source B-
MAC for BUM traffic), it updates its egress filtering (based on the MAC for BUM traffic), it updates its egress filtering (based on the
source B-MAC address), as follows: source B-MAC address), as follows:
- If the MAC Advertisement route indicates that the advertised B-MAC - If the MAC Advertisement route indicates that the advertised B-MAC
is a Leaf, and the local Ethernet Segment is a Leaf as well, then the is a Leaf, and the local Ethernet Segment is a Leaf as well, then the
source B-MAC address is added to its B-MAC list used for egress source B-MAC address is added to its B-MAC list used for egress
filtering. filtering - i.e., to block traffic from that B-MAC address.
- Otherwise, the B-MAC filtering list is not updated. - Otherwise, the B-MAC filtering list is not updated.
When the egress PE receives the packet, it examines the B-MAC source When the egress PE receives the packet, it examines the B-MAC source
address to check whether it should filter or forward the frame. Note address to check whether it should filter or forward the frame. Note
that this uses the same filtering logic as baseline [RFC7623] and that this uses the same filtering logic as baseline [RFC7623] and
does not require any additional flags in the data-plane. does not require any additional flags in the data-plane.
Just as in section 3.2, the PE places all Leaf Ethernet Segments of a Just as in section 3.2, the PE places all Leaf Ethernet Segments of a
given bridge domain in a single split-horizon group in order to given bridge domain in a single split-horizon group in order to
skipping to change at page 15, line 27 skipping to change at page 16, line 24
traffic, the PE will use the the label in the Tunnel Identifier field traffic, the PE will use the the label in the Tunnel Identifier field
when sending its BUM traffic. when sending its BUM traffic.
Using the Composite flag for Tunnel Types 0x00 'no tunnel information Using the Composite flag for Tunnel Types 0x00 'no tunnel information
present' and 0x06 'Ingress Replication' is invalid, and should be present' and 0x06 'Ingress Replication' is invalid, and should be
treated as an invalid tunnel type on reception. treated as an invalid tunnel type on reception.
6 Acknowledgement 6 Acknowledgement
We would like to thank Dennis Cai, Antoni Przygienda, and Jeffrey We would like to thank Dennis Cai, Antoni Przygienda, and Jeffrey
Zhang for their valuable comments. Zhang for their valuable comments. The authors would also like to
thank Thomas Morin for shepherding this document and providing
valuable comments.
7 Security Considerations 7 Security Considerations
Since this draft uses the EVPN constructs of [RFC7432] and [RFC7623], Since this draft uses the EVPN constructs of [RFC7432] and [RFC7623],
the same security considerations in these drafts are also applicable the same security considerations in these drafts are also applicable
here. Furthermore, this draft provides additional security check by here. Furthermore, this draft provides additional security check by
allowing sites (or ACs) of an EVPN instance to be designated as allowing sites (or ACs) of an EVPN instance to be designated as
"Root" or "Leaf" and preventing any traffic exchange among "Leaf" "Root" or "Leaf" and preventing any traffic exchange among "Leaf"
sites of that VPN through ingress filtering for known unicast traffic sites of that VPN through ingress filtering for known unicast traffic
and egress filtering for BUM traffic. and egress filtering for BUM traffic.
skipping to change at page 16, line 12 skipping to change at page 17, line 12
8.1 Considerations for PMSI Tunnel Types 8.1 Considerations for PMSI Tunnel Types
The "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types" The "P-Multicast Service Interface Tunnel (PMSI Tunnel) Tunnel Types"
registry in the "Border Gateway Protocol (BGP) Parameters" registry registry in the "Border Gateway Protocol (BGP) Parameters" registry
needs to be updated to reflect the use of the most significant bit to needs to be updated to reflect the use of the most significant bit to
advertise the use of "composite tunnels" (section 5.2). advertise the use of "composite tunnels" (section 5.2).
For this purpose, this document updates RFC7385. For this purpose, this document updates RFC7385.
The registry is to be updated, by removing the entries for 0xFB-0xFE The registry is to be updated, by removing the entries for 0xFB-0xFE
and 0x0F, and replacing them by: - 0x7B-0x7E Reserved for and 0x0F, and replacing them by:
Experimental Use [this document]- 0x7F Reserved [this document]-
0x80-0xFF Not Allocatable, corresponds to Composite tunnel types - 0x7B-0x7E Reserved for Experimental Use [this document]
[this document] - 0x7F Reserved [this document]
- 0x80-0xFF Not Allocatable, corresponds to Composite tunnel types
[this document]
The allocation policy for values 0x00 to 0x7A is IETF Review The allocation policy for values 0x00 to 0x7A is IETF Review
[RFC5226]. The range for experimental use is now 0x7B-0x7E, and value [RFC5226]. The range for experimental use is now 0x7B-0x7E, and value
in this range are not to be assigned. The status of 0x7F may only be in this range are not to be assigned. The status of 0x7F may only be
changed through Standards Action [RFC5226]. changed through Standards Action [RFC5226].
9 References 9 References
9.1 Normative References 9.1 Normative References
 End of changes. 18 change blocks. 
66 lines changed or deleted 112 lines changed or added

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