Jeffrey, I’m sure we will fix the editorial changes… Just wanted to comment on a few questions you had on the VIDs, eth-tags, P/B bits and ES label. Please see in-line with [JORGE]. Thank you! Jorge
On 5/11/16, 8:13 PM, "BESS on behalf of EXT Jeffrey (Zhaohui) Zhang" <bess-boun...@ietf.org on behalf of zzh...@juniper.net> wrote: >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? [JORGE] I think the above text is consistent with RFC7432 for VLAN-based service interfaces (section 6.1). The VLAN that is used for the 1:1 mapping to the service (MAC-VRF in RFC7432 or VPWS service instance here) has to be kept on the imposition PE and ‘possibly’ translated at the disposition PE. The only inconsistency that I see is a MUST here as opposed to a SHOULD in RFC7432. Other than that the text should be good. > > 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? [JORGE] 24-bit is consistent with RFC7432 in which the eth-tag can be either a 12 or 24-bit identifier. Also I wouldn’t change it as this point given that we have a few implementations already using 24-bit ethernet tags… > > ... 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? > [JORGE] the main point here is that with the P/B bits the implementation at the remote PE doing aliasing or backup functions is greatly simplified: - The remote PE does not even need to check the single-active bit in the AD per-ES route anymore and forwarding can be purely based on the P/B bits - If multiple routes for eth-tag 1 are received with P=1, the PE will load-balance - B bit is absolutely necessary for the backup function. Since there may be more than 2 PEs in the ES, a remote PE needs to know who the primary is and in case of failure on the primary who the backup is, since it will send the traffic right away to it. If there was no B=1, the remote PE wouldn’t know where to send the traffic in case of a failure. >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) [JORGE] no ESI label is needed for EVPN VPWS, but remember that the ES may be shared with MAC-VRFs that NEED the ESI label. The ESI label should be as per RFC7432. > >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 _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
