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

["Rabadan, Jorge (Nokia - US)" <[e-mail]>]

Hi Jeffrey,

More in-line.
Thanks.

On 5/12/16, 3:43 PM, "EXT Jeffrey (Zhaohui) Zhang" <[e-mail]> wrote:

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

[JORGE] Well, EPL maps the entire port to a VPWS whereas EVPL maps a <port,vlan> (or <port,outer-vlan,inner-vlan>) to a VPWS. EPL can be implemented with port-based service interface and EVPL with VLAN-based. Hence the other difference is the ability to translate or not at the disposition PE. I guess we can discuss with the rest of the co-authors and how to clarify it. 

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

[JORGE] In theory yes, however for the practical reasons I said above, I would not change it in the current text.

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

[JORGE] ok, yes, we should clarify it.

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

[JORGE] Let’s assume you have 3 PEs in ES-1 (PE1/2/3) that is a single-active ES. PE4 is a remote PE doing backup function. 
- PE1 is the primary - the winner of the DF election. PE1 sends P=1
- PE2 is the backup - the winner of the DF election (without PE1). PE2 sends B=1.
- PE3 then sends P=B=0. This indicates that PE3 is neither primary nor backup, but the AC is active (if it was oper-down, it would withdraw the route).
- In case of a failure on PE1, PE2 will activate its AC on ES-1 since he wins the new DF election. At the same time, PE4 can immediately send traffic to PE2 as soon as PE1 withdraws the AD routes. PE4 does not even need to wait for the confirmation that PE2 is the new DF. This backup mechanism speeds up convergence big time.
- The mechanism above does not work if PE2 and PE3 send both the same P=B=0, since it case of PE1 failure, PE4 could not send any traffic (it does not know who is the active one in the ES) and would need to wait for PE2 to send P=1.

Hope the above helps a bit?

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

[JORGE] There is no need to involve the per-ES route for determining SA/AA at the remote PE, but it is still good to check on the rest of the PEs in the ES. But, OK, I agree it could be clarified. Thanks for the feedback Jeffrey.

>
>Thanks.
>Jeffrey