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. ... 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? 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. ... [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. ... 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. 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. 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. 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? 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? 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. ... 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 ..."? 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/ 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/ 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? ... 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? 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? 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. 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. 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? 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)? 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. 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". 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. 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? 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. Jeffrey _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess