Re: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

["Jeffrey (Zhaohui) Zhang" <[e-mail]>]

Hi Jorge,

> -----Original Message-----
> From: Rabadan, Jorge (Nokia - US) [mailto:[e-mail]]
> Sent: Thursday, May 12, 2016 7:44 AM
> To: Jeffrey (Zhaohui) Zhang <[e-mail]>; BESS <[e-mail]>
> Subject: Re: [bess] FW: WG Last Call (including implem status & shepherd)
> for draft-ietf-bess-evpn-vpws-03
> 
> 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

I assume other non-editorial questions/comments will be followed up separately :-)

I trimmed text below.

> >   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.

I understand that the text is consistent with RFC7432, but I need some help understanding it. For example, if the ACs are double-tagged, will the traffic be double-tagged as is across the core? If so, there is really no difference between EVPL and EPL wrt traffic across the core (and the only difference is the process on the disposition PE). The way it is written, it is kind of confusing to me.

> >   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…

I understand the consistency and the reason for not changing it; but since the tag field is actually no longer VID for EVPN-VPWS, in theory all 32-bit could be used? Just want to confirm my understanding for my own educational benefit.

> >
> >     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

That's also one of my points, but then the following paragraph gets in the way:

   The usage of the Per ES Ethernet AD route is unchanged from its usage
   in [RFC7432], i.e. the "Single-Active" bit in the flags of the ESI
   Label extended community will indicate if single active or all active
   redundancy is used for this ES.

> - 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.

If a PE sends a route w/o setting P-bit, wouldn't that indicate it is a backup? Why would it bother sending the route if it does not want to be the backup?

> 
> 
> >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.

The text should make it clear; and I think we're agreeing that there is no need to involve the per-ES route for the purpose of determining single-active vs. all-active. If that is made clear, then my original question/comment becomes moot.

Thanks.
Jeffrey