Hi Jeffrey,
Thanks for your comments, Please see responses inline.
Hi,
As the document shepherd, I have the following questions/comments. Some of
which are just editorial nits.
This document describes how EVPN can be used to support virtual
private wire service (VPWS) in MPLS/IP networks.
Please capitalize "virtual private wire service". There are two other cases of
this.
... eliminates the
need for single-segment and multi-segment PW signaling,
This is not discussed in the draft later. It should either be discussed, or
removed from the abstract & introduction.
[Sami]
We do have a section 5 on comparison between PW signaling and EVPN, Actually,
the draft is proposing a mechanism that eliminates PW signaling for P2P service
using EVPN, so not sure how can we remove this?
[Sami]
... and provides
fast protection using data-plane prefix independent convergence upon
node or link failure.
This is not discussed in the draft either. Can you elaborate? Is it really
enabled by EVPN or actually independent of EVPN?
[Sami]
Please have a look at section 5.
[Sami]
It seems that the Ethernet Segment is not used consistently. From RFC 7432:
Ethernet Segment (ES): When a customer site (device or network) is
connected to one or more PEs via a set of Ethernet links, then
that set of links is referred to as an 'Ethernet segment'.
My understanding is that ES is at link/port level and it refers to a set of
links, while AC could be at vlan level. In the below paragraph,
[EVPN] has the ability to forward customer traffic to/from a given
customer Attachment Circuit (AC), aka Ethernet Segment in EVPN
terminology, without any MAC lookup.
Here we're referring AC as ES - it does not seem to be stringent.
It's better to remove "aka Ethernet Segment in EVPN terminology" to avoid
inconsistency.
[Sami]
There is no inconsistency, the text you refer to in [7432] is part of the
explanation of the ESI or ethernet segment identifier.
in [7432] Page 31, it mentions exactly what we are referring to above. "On the
other hand, a unique label per <ESI, Ethernet tag> allows an egress PE to
forward a packet that it receives from another PE, to the connected CE, after
looking up only the MPLS labels without having to perform a MAC lookup.”
[Sami]
... [MEF] defines Ethernet
Virtual Private Line (EVPL) service as p2p service between a pair of
ACs (designated by VLANs) and Ethernet Private Line (EPL) service, in
which all traffic flows are between a single pair of ESes.
Perhaps change "ESes" to "links or ESes"? The definition of ES in RFC7432 is
"set of links". See below about generalization.
[Sami]
From one PE point of view an ES is a single link.[7432] is not denying this.
[Sami]
... EVPL can
be considered as a VPWS with only two ACs.
Both EVPL and EPL can be considered as VPWS with only two ACs (I assume an AC
is not necessarily at vlan level).
... In a VPWS service, the traffic from an
originating Ethernet Segment can be forwarded only to a single
destination Ethernet Segment; hence, no MAC lookup is needed and the
MPLS label associated with the per-EVI Ethernet AD route can be used
in forwarding user traffic to the destination AC.
I can understand that ES here is generalized, but it's better to point out at
the beginning.
For a multi-homed CE, in an advertised Ethernet A-D per EVI route the
ESI field is set to the CE's ESI and the Ethernet Tag field is set to
the VPWS service instance identifier, which MUST have the same value
on all PEs attached to that ES.
What if you receive a set of per EVI routes with the same Ethernet Tag field
but different ESIs? The spec should define the behavior.
[Sami]
Those will be different routes as per [7432]. We are not defining any new
behavior.
[Sami]
In all cases traffic follows the transport paths, which
may be asymmetric.
"follows the transport paths" is hard to understand. Perhaps this sentence
could be deleted.
[Sami]
Transport paths carry the service traffic over the MPLS transport network, we
are simply mentioning this, those paths can for sure be asymetric as the per
the nature of MPLS LSPs. I am not really sure if we should delete this.
[Sami]
The Ethernet Segment identifier encoded in the Ethernet A-D per EVI
route is not used to identify the service, however it can be used for
flow-based load-balancing and mass withdraw functions.
The first clause is a little strange in its reference to "identify the
service". It seems to be just irrelevant? Also, it's not the ESI itself that is
used for load-balancing? Perhaps the paragraph can be reworded as the following:
The Ethernet A-D per ES route and corresponding Ethernet A-D per
EVI routes can be correlated by the Ethernet Segment Identifier.
This allows flow-based load-balancing and mass withdraw functions.
[Sami]
Ok, will change this.
[Sami]
In the following paragraph:
For EVPL
service, the Ethernet frames transported over an MPLS/IP network MUST
remain tagged with the originating VID and any VID translation is
performed at the disposition PE. For EPL service, the Ethernet frames
are transported as is and the tags are not altered.
"remain tagged" is a little unclear to me and RFC 7432 does not talk about it
either. Is it that incoming tagging is not changed at all (e.g. double tagged)
or is it single tagged with normalized VIDs? Is it that for both services, the
frames are transported as is across the core, and the tag alteration is only
happening at the disposition PE in case of EVPL?
[Sami]
We will change the MUST to a SHOULD to be consistent with [7432] Vlan based
services section 6.1.
[Sami]
5. Also, multiple EVPL service VLANs on the same trunk could belong
to the same EVPN instance (EVI), or they could belong to different
EVIs. This should be purely an administrative choice of the network
operator.
6. A given access trunk could have hundreds of EVPL services, and a
given PE could have thousands of EVPLs configured. It must be
possible to configure multiple EVPL services within the same EVI.
Aren't the above two the same?
[Sami]
They are not the same, [5] talks about multiple EVPL on the same trunk
interface belonging to different EVI(s), and [6] talks about EVPL on a multiple
access interfaces belonging to the same EVI.
[Sami]
8. EPL-LAN and EVP-LAN are possible on the same system and also ESIs
can be shared between EVPL and EVP-LANs.
I guessed what EPL-LAN and EVP-LAN are. They should be listed in the
terminology section.
[Sami]
Sure will do.
[Sami]
... For this service interface, each VLAN is
presented by a single VID which means no VLAN translation is allowed.
Perhaps change to "all VLANs are represented by ..."?
[Sami]
Not sure I get that, you mean all VLANs are presented by different VIDs?
[Sami]
This service interface is a special case of the VLAN bundle service
interface, where all of the VLANs on the port are mapped to the same
VPWS service instance identifier. The procedures are identical to
those described in Section 6.2.
s/6.2/2.2/
[Sami]
This is section 6.2 in [7432], will fix that.
[Sami]
Contrary to EVPN, in EVPN-VPWS this service interface maps to VLAN-
based service interface (defined in section 6.1) and thus this
service interface is not used in EVPN-VPWS. In other words, if one
tries to define data-plane and control plane behavior for this
service interface, he would realize that it is the same as that of
VLAN-based service.
s/6.1/2.1/
[Sami]
Same as above.
[Sami]
This document proposes the use of the Ethernet A-D per EVI route to
signal VPWS services. The Ethernet Segment Identifier field is set to
the customer ES and the Ethernet Tag ID 32-bit field is set to the
24-bit VPWS service instance identifier.
Is there any reason to restrict it to 24-bit? Why not make use of all 32 bits?
[Sami]
To be consistent with [7432] and current implementations.
[Sami]
... Finally,
EVPN may employ data plane local repair mechanisms not available in
VPWS.
Can you elaboration on the above? What is different from non-EVPN VPWS wrt
local repair?
[Sami]
In EVPN, on failure we can direct traffic to the backup PE using a backup label
signaled, PW redundancy doesn’t have that.
[Sami]
P If set to 1 in multihoming single active scenarios, it
indicates that the advertising PE is the Primary PE.
SHOULD be set to 1 for multihoming all active scenarios.
B If set to 1 in multihoming single active scenarios, it
indicates that the advertising PE is the Backup PE.
It seems that only a P bit is needed here for both single-active and
all-active? In either case, local PE can load-balance to those advertising P=1,
or setup backup PW towards one of those advertising P=0. The ESI label EC in
the per-ES A-D route is not needed at all as the behavior could be purely
determined by the P bit alone?
[Sami]
There is not PW getting setup here.
[Sami]
I understand that there is no need to change it at this time, but for my own
educational benefit I'd like to confirm my understanding. At least, the
following details should be added:
- What's the defined behavior when receiving B=1 for all-active or B=0 for
single-active
- What's label value to be put into the ESI label EC (I assume no ESI label is
needed)
If my understanding is correct, it may be easier to simply go with a single P
bit. Of course, I'm just trying to understand it better, not to push for this
change.
[Sami]
The draft already explicitly mention that in single active, traffic will not
start flowing until the remote PE, receives from at least one of the PE(s) in
the single active redundancy an Ethernet-AD route with the P bit set.
Identifying the backup PE will help to failover quicker at the remote PE. We
have spent weeks as co-authors on this section before, and to be quite honest,
I am not sure if any new text on this will clarify!
[Sami]
The ESI Bandwidth will be encoded using the Link Bandwidth Extended
community defined in [draft-ietf-idr-link-bandwidth] and associated
with the Ethernet AD route used to realize the EVPL services.
Per EVI or per ES route? I assume it's per EVI - better make it clear.
[Sami]
Will do.
[Sami]
Looks like that a PE includes the community for the other end to request the BW
enforcement/accounting from the PSN. Should/could both ends include the
community? Does it make sense for the two to signal different BW? I suppose so?
[Sami]
This BW will be symmetric, we can make that explicit in the doc.
[Sami]
In the case where PSN resources are not available, the PE receiving
this attribute MUST re-send its local Ethernet AD routes for this
EVPL service with the ESI Bandwidth = All FFs to declare that the
"PSN Resources Unavailable".
Shouldn't we use a different indication that the requested BW is not granted
(see comments above)?
[Sami]
Not sure, I get this, if it can’t be granted BW in one direction, are you
saying may be the other direction will get it?
[Sami]
The scope of the ESI Bandwidth is limited to only one Autonomous
System.
The BW request might be used in two ways:
- request the PSN to "guarantee" the requested BW
- request the other PE to shape/limit the traffic that it sends towards this PE
For the first case, the BW may not be guaranteed across ASes and I assume
that's the reason for the limitation in the above quoted text (better to
explain it). For the second case, it would be valid even if it's across ASes.
In fact, draft-boutros-bess-evpn-vpws-service-edge-gateway has the following:
- Auto-provision features such as QOS access lists (ACL), tunnel
preference, bandwidth, L3VPN on a per head-end interface basis
I assumed that the "auto-provision ... bandwidth" in that draft is more about
traffic shaping/limiting by the PE than about bandwidth guarantee by the PSN.
If that's the case, then it should be valid even if it's across ASes.
It would help a lot if the draft can elaborate on the use case of the bandwidth
community.
[Sami]
We are not proposing any Shaping, or filters for traffic entering the EVPN-VPWS
service, it is a simple BW negotiation, that can be provisioned single sided.
[Sami]
7.1 Single-Homed CEs
Unlike [EVPN], EVPN-VPWS uses Ethernet AD route advertisements for
single-homed Ethernet Segments. Therefore, upon a link/port failure
of this single-homed Ethernet Segment, the PE MUST withdraw the
associated Ethernet A-D routes.
Better make it clearer by saying "Ethernet AD per EVI route".
[Sami]
Sure will do.
[Sami]
7.2 Multi-Homed CEs
For a faster convergence in multi-homed scenarios with either Single-
Active Redundancy or All-active redundancy, mass withdraw technique
as per [EVPN] baseline is used. A PE previously advertising an
Ethernet A-D per ES route, can withdraw this route signaling to the
remote PEs to switch all the VPWS service instances associated with
this multi-homed ES to the backup PE
Does the PE also withdraw the individual per-EVI AD routes? I assume not;
better make it clear.
[Sami]
It will withdraw as per [7432], we are not defining any new behavior.
[Sami]
If that's case, is it desirable to assign non-zero ESIs even for single-home
case and advertise per ES AD routes so that mass withdraw can be done?
[Sami]
Correct, an operator may chose that. We are not precluding this.
[Sami]
That way when the link comes back up, there is no need to re-advertise those
per-EVI routes.
8. VPWS with multiple sites
Might as well move this non-goal to the "requirements" section.
[Sami]
Will remove this section, and finally, thanks for all your comments.
Sami
_______________________________________________
BESS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bess
