Reviewer: Susan Hares
Review result: Almost Ready
GEN-ART review
Status: Almost ready
Summary Comment:
==========
Multicast distribution can aid the network, so it is important to have a solid
standard.
Wow! This is an amazing amount of work to combine EVPN and MVPN.
I went between RFC6513, RFC6514, RFC7432, and RFC8542. You caught many of the
issues between the EVPN-MVPN.
I'm hopeful this will help catch a few additional issues.
Sue
============================
Status Early Review: On the right track,
6 technical issues, editorial issues
===============
Summary of Technical issues:
1. Technical issue #1: Section 5.3 - refers to section 8 and 9
How you do you restriction of importing the same type-5 Route to IPVPN VRF from
multiple PEs (Section 8.1)?
The issue is the same Route-5 from different PEs (MVPN PE or EVPN PE) into the
IPVPN cloud with the same VRF. If type-5 Route is sent from different PEs with
different VRFs, there is not a problem. If type-5 Route is sent once from
different PE with same VRF, then route selection policy should handle the
resolution. If type-5 Route is sent multiple times from different PEs with Same
VRF, it can encounter the count to infinity problem.
Level: IDR chairs indicate this ia well-known issue, and can be noted in
manageability. Issue: No manageability section.
2. VXLAN tunnels under the MVPN network (Section 8.2.2)
Question: How does the network limit the reach of these tunnels to keep the
EVPN and MVPN?
level: Security/managemeability issue
3. Section 8.2.3 - It is unclear what tunnel types that this RFC draft supports.
Does it support VXLAN plus NVGRE (type = 9) , GRE (type = 2), GENEVE or GPE (?).
Are you supporting any other tunnel types for encapsulation?
Level: Clarity of what is supported in draft
4. Section 9 – MVPN VPN overlay tunnel over DC network is terminated on
IP-VRF (rather than MAC-VRF/BTs).
Problem 1 – Does the split horizon for EVPN (RFC7432, section 8.3] require MPLS
forwarding in the EVPN-MVPN network? 4a) Does this functioning require MPLS
forwarding of traffic in EVPN--MVPN network? 4b) How is this BUM (Broadcast,
Unknown Unicast, and Multicast traffic) handled in the MVPN/EVPN gateway
(section 6.3) for three types of tunnels?
5. TTL decrement - the IDR chairs do not think this is a problem.
6. The Security section does not seem to cover all the security and
mangeability issue for the EVPN-MVPN?
==================================================
Full Description of 6 Technical issues
============================
Level: Split-horizon + effective split horizon (RFC8584)
===============
Explanation of technical comments:
General overview:
The procedures in this draft are an extension of RFC6513 and RFC6514.
Figure 1-2 shows two ways to EVPN and MVPN in seamless operation.
Figure 1:
EVPN glued to MVPN via IP VRFs
EVPN PE1
+------------+
Src1 +----|(MAC-VRF1) | MVPN PE3
Rcvr1 +----| \ | +---------+ +--------+
| (IP-VRF)|----| |---|(IP-VRF)|--- Rcvr5
| / | | | +--------+
Rcvr2 +---|(MAC-VRF2) | | |
+------------+ | |
| MPLS/ |
EVPN PE2 | IP |
+------------+ | |
Rcvr3 +---|(MAC-VRF1) | | | MVPN PE4
| \ | | | +--------+
| (IP-VRF)|----| |---|(IP-VRF)|--- Rcvr6
| / | +---------+ +--------+
Rcvr4 +---|(MAC-VRF3) |
+------------+
Figure 1: MVPN PEs Seamless Interop
Figure 2:
EVPN as MVPN PEs
EVPN PE1
+------------+
Src1 +----|(MAC-VRF1) |
| \ |
Rcvr1 +----| +--------+| +---------+ +--------+
| |MVPN PE1||----| |---|MVPN PE3|--- Rcvr5
| +--------+| | | +--------+
| / | | |
Rcvr2 +---|(MAC-VRF2) | | |
+------------+ | |
| MPLS/ |
EVPN PE2 | IP |
+------------+ | |
Rcvr3 +---|(MAC-VRF1) | | |
| \ | | |
| +--------+| | | +--------+
| |MVPN PE2||----| |---|MVPN PE4|--- Rcvr6
| +--------+| | | +--------+
| / | +---------+
Rcvr4 +---|(MAC-VRF3) |
+------------+
Figure 2: EVPN PEs as MVPN PEs
MVPN passes NLRI with sub-route types 1-7 (RFC6514, setion 4).
AFI=1, SAFI=5 (MVPN), AFI=1, SAFI=129 - VPN for MVPN
+ 0 - Reserved
+ 1 - Intra-AS I-PMSI A-D route;
+ 2 - Inter-AS I-PMSI A-D route;
+ 3 - S-PMSI A-D route;
+ 4 - Leaf A-D route;
+ 5 - Source Active A-D route.
+ 6 - Shared Tree Join route;
+ 7 - Source Tree Join route;
PMSI Tunnel attribute with the following tunnel types
+ 0 - No tunnel information present
+ 1 - RSVP-TE P2MP LSP
+ 2 - mLDP P2MP LSP
+ 3 - PIM-SSM Tree
+ 4 - PIM-SM Tree
+ 5 - BIDIR-PIM Tree
+ 6 - Ingress Replication
+ 7 - mLDP MP2MP LSP
PE Distinguisher Labels attribute.
RFC9012 (TEA) - prefers PMSI tunnels if both TEA and PMSI.
Extended Communities: Source AS and VRF-RT Import
EVPN document defines the following Route Types for AFI (RFC7432)
AFI = 25, SAFI: 70
+ 0 - Reserved
+ 1 - Ethernet Auto-Discovery (A-D) route
+ 2 - MAC/IP Advertisement route
+ 3 - Inclusive Multicast Ethernet Tag route
+ 4 - Ethernet Segment route
Extended Communities:
1) ESI Label Extended Community [0x01]
2) ES-Import Targe Extended Community [0x02]
3) MAC Mobility [0x00]
4) Default Gateway Extended Community [Opague]
====================================================================
Technical issue scope:
Sections 5.3, 5.4, and 5.5 are the key issues in EVPN/MVPN interoperation.
Technical issue #1: Section 5.3 - refers to section 8 and 9
Problem:
1. Restriction of importing the same type-5 Route to IPVPN VRF from
multiple PEs (Section 8.1)
The issue is the same Route-5 from different PEs (MVPN PE or EVPN PE) into the
IPVPN cloud with the same VRF. If type-5 Route is sent from different PEs with
different VRFs, there is not a problem. If type-5 Route is sent once from
different PE with same VRF, then route selection policy should handle the
resolution. If type-5 Route is sent multiple times from different PEs with Same
VRF, it can encounter the count to infinity problem.
Text + explanation behind the problem.
---------------------------------------
1. Section 5.3 paragraph 1
Text:
/ When an IP multicast source is attached to an EVPN PE, the unicast
route for that IP multicast source needs to be advertised.
[Case 1]
When the source is attached to a Single-Active multi-homed Ethernet
Segment (ES), then the EVPN DF PE is the PE that advertises a unicast
route corresponding to the source IP address with VRF Route Import
extended community which in turn is used as the Route Target for Join
(S,G) messages sent toward the source PE by the remote PEs. The EVPN
PE advertises this unicast route using EVPN route type 2 and IPVPN
unicast route along with VRF Route Import extended community. EVPN
route type 2 is advertised with the Route Targets corresponding to
both IP-VRF and MAC-VRF/BT; whereas, the IPVPN unicast route is
advertised with RT corresponding to the IP-VRF. When unicast routes
are advertised by MVPN PEs, they are advertised using IPVPN unicast
route along with VRF Route Import extended community per [RFC6514].
/
Example: Figure-1, src-1, EVPN DF = EVPN-PE1, PE1 announces
src1 with VRF Route Import Ext-Com in two announcements
EVPN (RFC7542, AFI=L2 (25), SAFI = 70), Route-type=2, Rt-Targets IP-VRF +
MAC-VRF MVPN - IP-VPN (RFC6514/6513, AFI=1, SAFI=5) RT-target = IP VRF
If single access, EVPN routes are added to
figure 1 + 2 : PE1 + PE2 MAC VRF + IP-VPN, PE3 + PE - IPVRN
More text on Case 2a/
When the source is attached to an All-Active multi-homed ES, then the
PE that learns the source advertises the unicast route for that
source using EVPN route type 2 and IPVPN unicast route along with VRF
Route Import extended community. EVPN route type 2 is advertised
with the Route Targets corresponding to both IP-VRF and MAC-VRF/BT;
whereas, the IPVPN unicast route is advertised with RT corresponding
to the IP-VRF./
Note: This is the same announcement as above.
Case 2b (already have) / When the other multi-homing EVPN PEs for that ES
receive this unicast EVPN route, they import the route and check to
see if they have learned the route locally for that ES, if they have,
then they do nothing.
/
Case 2c (don't have)
/But if they have not, then they add the IP and
MAC addresses to their IP-VRF and MAC-VRF/BT tables respectively with
the local interface corresponding to that ES as the corresponding
route adjacency. Furthermore, these PEs advertise an IPVPN unicast
route along with VRF Route Import extended community and Route Target
corresponding to IP-VRF to other remote PEs for that MVPN.
Therefore, the remote PEs learn the unicast route corresponding to
the source from all multi-homing PEs associated with that All-Active
ES even though one of the multi-homing PEs may only have directly
learned the IP address of the source./
Result:
Same as above.
-----------------
Section 8
Section 8 extends seamless interop procedures to EVPN only fabrics as
an IRB solution for multicast. L3VPN provisioning is not needed
among EVPN PEs. EVPN PEs only need to advertise unicast routes using
EVPN route-type 2 or route-type 5 with VRF Route Import extended
community and don't need to advertise IPVPN routes within EVPN only
fabric.
----------------
Technical issues for section 8 implementing 5.3
#1. Restriction of importing the same type-5 Route to IPVPN VRF from
multiple PEs (Section 8.1)
Problem: The same Route-5 from different PEs (MVPN PE or EVPN PE) into the
IPVPN cloud with the same VRF.
If type-5 Route is sent from different PEs with different VRFs, there is not a
problem. If type-5 Route is sent once from different PE with same VRF, then
route selection policy should handle the resolution. If type-5 Route is sent
multiple times from different PEs with Same VRF, it can encounter the count to
infinity problem.
Keyur Comment: This problem is well-known issue, and can be noted in
manageability.
===========================================================================
#2. VXLAN tunnels under the MVPN network (Section 8.2.2)
technology:
a) VXLAN tunnels (tunnel type = 8)
1. set up tunnels
2. Announce MVPN routes I-PMSI (Type 1 or 2) or S-PMSI (Type 3) +
PMSI Tunnel Attribute + RFC9012 Ext-Com (Encapsulation) with tunnel type 8
(barebones)
+ VRF Route Import Extended Community + SRC Extended Community
3. Require Gateway EVPN and MVPN with complete termination of L2 and L3
Question: How does the network limit the reach of these tunnels
to keep the EVPN and MVPN?
The initial assumption for a walled garden with EVPN and MVPN
is that the "configuration that limits the reach of EVPN and MVPN."
However, the text indicates there is little EVPN configuration.
Reference text: /
8.2.2. VxLAN Encapsulation
In order to signal VXLAN, the corresponding BGP encapsulation
extended community [RFC9012] SHOULD be appended to the MVPN I-PMSI
and S-PMSI A-D routes. The MPLS label in the PMSI Tunnel Attribute
MUST be the Virtual Network Identifier (VNI) associated with the
customer MVPN. The supported PMSI tunnel types with VXLAN
encapsulation are: PIM-SSM Tree, PIM-SM Tree, BIDIR-PIM Tree, Ingress
Replication [RFC6514]. Further details are in [RFC8365].
In this case, a gateway is needed for inter-operation between the
EVPN MVPN-capable PEs and non-EVPN MVPN PEs. The gateway should re-
originate the control plane signaling with the relevant tunnel
encapsulation on either side. In the data plane, the gateway
terminates the tunnels formed on either side and performs the
relevant stitching/re- encapsulation on data packets.
/
====================================================
# 3. What tunnel types does this EVPN-MVPN draft support besides VXLAN?
Problem: It is unclear what is the exact list of tunnel types that this RFC
draft supports. VXLAN, NVGRE (type = 9) , GRE (type = 2), or GENEVE (? see
IANA). Are you supporting any other tunnel types for encapsulation? Would you
include SR-Policy with TEA attribute?
Text:/
8.2.3. Other Encapsulation
In order to signal a different tunneling encapsulation such as NVGRE,
GPE, or GENEVE the corresponding BGP encapsulation extended community
[RFC9012] SHOULD be appended to the MVPN I-PMSI and S-PMSI A-D
routes. If the Tunnel Type field in the encapsulation extended-
community is set to a type that requires Virtual Network Identifier
(VNI), e.g., VXLAN-GPE or NVGRE [RFC9012], then the MPLS label in the
PMSI Tunnel Attribute MUST be the VNI associated with the customer
MVPN. Same as in the VXLAN case, a gateway is needed for inter-
operation between the EVPN MVPN-capable PEs and non-EVPN MVPN PEs.
/
================================================
#4. Section 9 – MVPN VPN overlay tunnel over DC network is terminated on IP-VRF
(rather than MAC-VRF/BTs).
Problem 1 – Does the split horizon for EVPN (RFC7432, section 8.3] require MPLS
forwarding in the entire EVPN-MVPN network and the gateway between EVPN-MVPN?
If so,
a) Where are you limiting the EVPN-MVPN network to multicast forwarding via
MPLS? b) What are all the gateway EVPN/MVPN interactions need to be handled?
draft section 5.4/
Since the network of interest for seamless interoperability between
EVPN and MVPN PEs is MPLS, the EVPN handling of BUM traffic for MPLS
network needs to be considered. EVPN [RFC7432] uses ESI MPLS label
for split-horizon filtering of Broadcast/Unknown unicast/multicast
(BUM) traffic from an All-Active multi-homing Ethernet Segment to
ensure that BUM traffic doesn't get looped back to the same Ethernet
Segment that it came from. This split-horizon filtering mechanism
applies as-is for multicast IRB scenarios because of using the intra-
ES tunnel among multi-homing PEs. Since the multicast traffic
received from a TS source on an All-Active ES by a multi-homing PE is
bridged to all other multi-homing PEs in that group, the standard
EVPN split-horizon filtering described in [RFC7432] applies as-is.
/
Problem 2 - How is BUM traffic handled in the MVPN-EVPN gateway?
There are three types of tunnels listed in section 6
1) intra-ES tunnel - for multihoming of ES traffic -
L2 forwarded among PEs on the same subnet.
2) intra-subnet BUM tunnel - for BUM traffic on a
given subnet (section 6.2) set-up by IMET per RFC7432
(IMET defined in section 7.3, procedures in 11, 12, and 16).
3) Inter-Subnet for IP multicast tunnel - L3 traffic using
a) I-PMSI A-D Route (RFC6514, sections 4.1 + 9.2) for default underlay tunnel
route, b) S-PMSI A-D Route (RFC6514, sections 4.2 + 9.1) for customer flow
specific underlay tunnels,
All-Active multi-homing PE uses two tunnels:
1) intra-ES tunnel among multi-homing PEs (L2 + L3)
2) IMET tunnel for the Link-local multicast BUM part of the intra-ES network,
and
Section 6.3, does not seem to discuss how the L3 Multicast
It would be good to discuss scaling in a manageability section
about inclusive overlay trees versus tenant IP-VRF.
Section of text referenced in RFC7432
========================
RFC7432 section 8.3 Text: /
8.3. Split Horizon
Consider a CE that is multihomed to two or more PEs on an Ethernet
segment ES1 operating in All-Active redundancy mode. If the CE sends
a broadcast, unknown unicast, or multicast (BUM) packet to one of the
non-Designated Forwarder (non-DF) PEs, say PE1, then PE1 will forward
that packet to all or a subset of the other PEs in that EVPN
instance, including the DF PE for that Ethernet segment. In this
case, the DF PE to which the CE is multihomed MUST drop the packet
and not forward back to the CE. This filtering is referred to as
"split-horizon filtering" in this document.
When a set of PEs are operating in Single-Active redundancy mode, the
use of this split-horizon filtering mechanism is highly recommended
because it prevents transient loops at the time of failure or
recovery that would impact the Ethernet segment -- e.g., when two PEs
think that both are DFs for that segment before the DF election
procedure settles down.
In order to achieve this split-horizon function, every BUM packet
originating from a non-DF PE is encapsulated with an MPLS label that
identifies the Ethernet segment of origin (i.e., the segment from
which the frame entered the EVPN network). This label is referred to
as the ESI label and MUST be distributed by all PEs when operating in
All-Active redundancy mode using a set of Ethernet A-D per ES routes,
per Section 8.2.1 above. The ESI label SHOULD be distributed by all
PEs when operating in Single-Active redundancy mode using a set of
Ethernet A-D per ES routes. These routes are imported by the PEs
connected to the Ethernet segment and also by the PEs that have at
least one EVPN instance in common with the Ethernet segment in the
route. As described in Section 8.1.1, the route MUST carry an ESI
Label extended community with a valid ESI label. The disposition PE
relies on the value of the ESI label to determine whether or not a
BUM frame is allowed to egress a specific Ethernet segment.
/
=============================
5. The points out that inter-subnet will be L2-Switched not routed, so TTL
is decremented (see appendix A)
The IDR Chairs thought the TTL decrement was a positive thing rather than a
problem.
========================================
6. Technical - lack of in-depth manageability or security section on
combination.
6-a) How the walled garden for the EVPN/MVPN cloud is delineated?
What attacks can occur within the combined walled garden?
6-b) How does the text discuss the security issues regarding
DOS attacks due to overload with multicast technology?
Old text in draft /
14. Security Considerations
All the security considerations in [RFC7432], [RFC6513] and [RFC6514]
apply directly to this document because this document leverages these
RFCs control planes and their associated procedures.
/
Why I am concerned about these issues
==========================================
#6-a) How the walled garden for the EVPN/MVPN cloud is delineated?
What attacks can occur within the combined walled garden?
Texts from RFC6513, RFC6514, RFC7432 that cause me to wonder:
Text from RFC6513:/
An ASBR may receive, from one SP's domain, an mLDP, PIM, or RSVP-TE
control message that attempts to extend a P-tunnel from one SP's
domain into another SP's domain. This is perfectly valid if there is
an agreement between the SPs to jointly provide an MVPN service. In
the absence of such an agreement, however, this could be an
illegitimate attempt to intercept data packets. By default, an ASBR
MUST NOT allow P-tunnels to extend beyond AS boundaries. However, it
MUST be possible to configure an ASBR to allow this on a specified
set of interfaces. /
Review comment: Is this Extension abnormal for the EVPN-MVPN cloud?
How are tunnels restricted with RFC 9012 TEA?
Text from RFC6514:/
17. Security Considerations
The mechanisms described in this document could reuse the existing
BGP security mechanisms [RFC4271] [RFC4272]. The security model and
threats specific to Provider Provisioned VPNs, including L3VPNs, are
discussed in [RFC4111]. [MVPN] discusses additional threats specific
to the use of multicast in L3VPNs. There is currently work in
progress to improve the security of TCP authentication. When the
document is finalized as an RFC, the method defined in [RFC5925]
SHOULD be used where authentication of BGP control packets is needed.
A PE router MUST NOT accept, from CEs routes, with MCAST-VPN SAFI.
If BGP is used as a CE-PE routing protocol, then when a PE receives a
route from a CE, if this route carries the VRF Route Import Extended
Community, the PE MUST remove this Community from the route before
turning it into a VPN-IP route. Routes that a PE advertises to a CE
MUST NOT carry the VRF Route Import Extended Community.
/
Text from RFC7432 , Section 19 /
Note that [RFC5925] will not help in keeping MPLS labels private --
knowing the labels, one can eavesdrop on EVPN traffic. Such
eavesdropping additionally requires access to the data path within an
SP network. Users of VPN services are expected to take appropriate
precautions (such as encryption) to protect the data exchanged over
a VPN.
One of the requirements for protecting the data plane is that the
MPLS labels be accepted only from valid interfaces. For a PE, valid
interfaces comprise links from other routers in the PE's own AS. For
an ASBR, valid interfaces comprise links from other routers in the
ASBR's own AS, and links from other ASBRs in ASes that have instances
of a given EVPN. It is especially important in the case of multi-AS
EVPN instances that one accept EVPN packets only from valid
interfaces.
/
#6-b) How does the text discuss the security issues regarding
DOS attacks due to overload with multicast technology?
Text from RFC6513, Sction 13 /
Many of the procedures in this document cause the SP network to
create and maintain an amount of state that is proportional to
customer multicast activity. If the amount of customer multicast
activity exceeds expectations, this can potentially cause P and PE
routers to maintain an unexpectedly large amount of state, which may
cause control and/or data plane overload. To protect against this
situation, an implementation should provide ways for the SP to bound
the amount of state it devotes to the handling of customer multicast
activity.
In particular, an implementation SHOULD provide mechanisms that allow
an SP to place limitations on the following:
- total number of (C-*,C-G) and/or (C-S,C-G) states per VRF
- total number of P-tunnels per VRF used for S-PMSIs
- total number of P-tunnels traversing a given P router
A PE implementation MAY also provide mechanisms that allow an SP to
limit the rate of change of various MVPN-related states on PEs, as
well as the rate at which MVPN-related control messages may be
received by a PE from the CEs and/or sent from the PE to other PEs.
An implementation that provides the procedures specified in Sections
10.1 or 10.2 MUST provide the capability to impose an upper bound on
the number of Source Active A-D routes generated and on how
frequently they may be originated. This MUST be provided on a per-
PE, per-MVPN granularity.
/
Text from RFC6514, section 17 /
It is important to protect the control plane resources within the PE
to prevent any one VPN from hogging excessive resources. This is the
subject of the remainder of the Security Considerations section.
When C-multicast routing information is exchanged among PEs using
BGP, an implementation SHOULD provide the ability to rate limit BGP
messages used for this exchange. This SHOULD be provided on a per-
PE, per-MVPN granularity.
An implementation SHOULD provide capabilities to impose an upper
bound on the number of S-PMSI A-D routes, as well as on how
frequently they may be originated. This SHOULD be provided on a per-
PE, per-MVPN granularity.
In conjunction with the procedures specified in Section 14, an
implementation SHOULD provide capabilities to impose an upper bound
on the number of Source Active A-D routes, as well as on how
frequently they may be originated. This SHOULD be provided on a per-
PE, per-MVPN granularity.
In conjunction with the procedures specified in Section 13 limiting
the amount of (C-S,C-G) state would limit the amount of Source Active
A-D route, as in the context of this section, Source Active A-D
routes are created in response to Source Tree Join C-multicast
routes, and Source Tree Join C-multicast routes are created as a
result of creation of (C-S,C-G) state on PEs. However, to provide an
extra level of robustness in the context of these procedures, an
implementation MAY provide capabilities to impose an upper bound on
the number of Source Active A-D routes, as well as on how frequently
they may be originated. This MAY be provided on a per-PE, per-MVPN
granularity.
Section 16.1.1 describes optional procedures for dampening
withdrawals of C-multicast routes. It is RECOMMENDED that an
implementation support such procedures.
Section 16.1.1 describes optional procedures for dampening
withdrawals of Leaf A-D routes. It is RECOMMENDED that an
implementation support such procedures.
/
Text from RFC7542 Section 19, /
As mentioned in [RFC4761], there are two aspects to achieving data
privacy and protecting against denial-of-service attacks in a VPN:
securing the control plane and protecting the forwarding path.
Compromise of the control plane could result in a PE sending customer
data belonging to some EVPN to another EVPN, or black-holing EVPN
customer data, or even sending it to an eavesdropper, none of which
are acceptable from a data privacy point of view. In addition,
compromise of the control plane could provide opportunities for
unauthorized EVPN data usage (e.g., exploiting traffic replication
within a multicast tree to amplify a denial-of-service attack based
on sending large amounts of traffic).
[snip]
It is also important to help limit malicious traffic into a network
for an impostor MAC address. The mechanism described in Section 15.1
shows how duplicate MAC addresses can be detected and continuous
false MAC mobility can be prevented. The mechanism described in
Section 15.2 shows how MAC addresses can be pinned to a given
Ethernet segment, such that if they appear behind any other Ethernet
segments, the traffic for those MAC addresses can be prevented from
entering the EVPN network from the other Ethernet segments.
/
==============================================
End of Technical Comments
Editorial comments
=========================
1. Introduction, paragraph 2
Problem: Sentence Grammar - Capitalization of first word in sentence.
Old Text/
- Lower Cost: gateway devices need to have very high scalability to
handle VPN services for their DCs and as such need to handle large
number of VPN instances (in tens or hundreds of thousands) and very
large number of routes (e.g., in tens of millions).
/
New Text/
- Lower Cost: Gateway devices need to have very high scalability to
handle VPN services for their DCs and as such need to handle large
number of VPN instances (in tens or hundreds of thousands) and very
large number of routes (e.g., in tens of millions).
/
Old text:/
- Optimum Forwarding: in a given Central Office(CO), both EVPN PEs
and MVPN PEs can be connected to the same fabric/network (e.g., same
IGP domain).
/
New text: /
- Optimum Forwarding: In a given Central Office(CO), both EVPN PEs
and MVPN PEs can be connected to the same fabric/network (e.g., same
IGP domain).
/
2. Introduction paragraph 2, section starting with "Optimm Forwarding"
Issue: The use of terms "tromboned" or "tromboning" is term of art, but
the lack of a definition in the Terminology section makes it difficult for
starting to read.
Suggestion:
1) Add a definition on tromboned or Tromboning in the Terminology section.
3. Section 3, Terminology
3a) Please alphabetize the terms in this section.
3b) Use a consistent methodology for periods in this section.
I think you are consistent except for the following:
Old text/
E: Provider Edge device.
/
New text:/
PE: Provider Edge device.
/
3c) Please consider adding the following terms used in the document:
1) Aggregate Selective P-tunnels
2) Aggregate tunnel (Section 5, paragraph 4)
3) CO (section 4.1)
4) IMET (section 6.2)
5) ingress replication tunnels (section 4.1)
6) Intra subnet (section 4.2)
7) Inter subnet (section 4.
8) P2MP Tunnels (setion 4.10
9) Selective P-tunels
4) Section 5.1.1
Old text:/
In order to enable seamless integration of EVPN and MVPN PEs, this
document extends the concept of an emulated VLAN service for
multicast IRB applications such that the intra-subnet IP multicast
traffic can get treated the same as inter-subnet IP multicast traffic
which means intra-subnet IP multicast traffic destined to remote PEs
gets routed instead of being L2-switched - i.e., TTL value gets
decremented and the Ethernet header of the L2 frame is de-capsulated
and encapsulated at both ingress and egress PEs.
/
English problem- This text uses "which means" and "- i.e."
The abbreviation “i.e.” stands for id est, which is Latin for “that is".
A main clause followed by two clauses "which means" ... "that is"
makes the sentence confusing.
It would be good to rewrite the sentece which takes up the whole paragraph.
5) Section 5.2, Figure 2
Old Text:/ Figure 1: & MVPN PEs Seamless Interop/
New Text:/ Figure 1: MVPN PE Seamless Interop /
The content makes me wonder if the figure should be title something different. ;
6) Section 5.3
context: Sections 5.3, 5.4 and 5.5 contain key technology.
Problem: Section 5.3 is has many run-on sentences.
This level of run-on sentences may be due to multiple edits.
It would be good to suggest the authors try a fresh write of the
section.
One nit if they are rewriting:
Old text: /
When the source is attached to an All-Active multi-homed ES, then the
PE that learns the source advertises the unicast route for that
source using EVPN route type 2 and IPVPN unicast route along with VRF
Route Import extended community.
/
new text:/
When the multicast source is attached to an All-Active multi-homed ES, then
the PE that learns the multicast source advertises the unicast route for
that source using EVPN route type 2 and IPVPN unicast route along with VRF
Route Import extended community.
/
7) Section 6.1 - paragraph indenting is not consistent.
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
