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

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

Hi Sami,

Some text snipped … Please see zzh2> below.


Zzh> When it comes to PIC, the closed thing I can find in section 5 is the following:

   Upon link or node failure, EVPN can trigger failover with the
   withdrawal of a single BGP route per EVPL service or multiple EVPL
   services, whereas with VPWS PW redundancy, the failover sequence
   requires exchange of two control plane messages: one message to
   deactivate the group of primary PWs and a second message to activate
   the group of backup PWs associated with the access link. Finally,
   EVPN may employ data plane local repair mechanisms not available in
   VPWS.

The first part (before “Finally”) talks about the two control plane message – so that’s not “data-plane” (the text I had question about talks about “data-plane prefix independent convergence). The second part talks about “data plane local repair” but has no details that I was looking for.

Sami:
The local repair here will be done by the primary PE o(on local AC down) using the label advertised in per EVI EAD route advertised by the backup PE will direct the traffic to backup PE, I will add this text to clarify this, is this ok?

Zzh2> So you’re talking about “egress link protection” – in flight traffic from the other end arriving on the primary PE will be redirected to the backup PE if the AC is down on the primary PE. This definitely needs some clarifying text, and it’s better to say egress link protection instead of data plane local repair?

Sami: Will add to the terminology section that an ES on a PE refer to the link attached to it, this link can be part of a set of links attached to different Pes in multi home cases, or could be a single link in single home cases. How does that sound?

Zzh2> Yes that’s good.


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.

Zzh> It’s not the MUST that I am having trouble with. It’s the “remain tagged” that is not clear to me (7432 is not clear to me either). As I mentioned in the other exchange with Jorge on this – is it that in both cases the Ethernet frames are transported in the core as is?

If both cases are “transported as is” (in the core – I understand that in EVPL case translation may be done on the egress PE), then it is confusing to me to say “remain tagged” for EVPL but “as is” for EPL. Better use consistent wording.

If “remain tagged” means that traffic in the core is using “normalized VID” (e.g., double tagged incoming packets become single tagged), then the word “remain” is not clear enough.

Sami: Shall we say, for EVPL, at least one VID should be present on the packet, and the VID manipulation is a local matter.

Zzh2> Because RFC7432 is not clear about “remain tagged” (for example, see my above questions), it would be good to spell out the details, not just “at least one VID should be present”?

[Sami]

Zzh> Basically, my points about BW are:

- It seems that it does not have to be limited to BW reservation in the network; it could be simply traffic shaping/limiting on the PE into the network. Therefore it does not have to be limited to only one AS. For example, the nework could be using LDP and there is no way to reserve BW but shaping is still desired on the PEs.

Sami: The issue here is that we are using the BW idr draft, and there is no shaping defined there, and we don’t plan to define a new attribute for this, perhaps we can add that to a new draft?

Zzh2> Good point that BW is not equal to shaping parameters; however, existing PW specifications do not seem to have BW related stuff and one actual customer use case I am aware of with EVPN VPWS actually does involve shaping; so maybe it’s better to take care of this in the base spec? It’s just a new attribute anyway.

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

Zzh> Now that you mention it, I did a search in RFC 7432 and the only place I can found about withdrawing per-EVI route is the following:


   When an Ethernet tag is decommissioned on an Ethernet segment, then

   the PE MUST withdraw the Ethernet A-D per EVI route(s) announced for

   the <ESI, Ethernet tags> that are impacted by the decommissioning.

All other mentioning of withdrawing are about mac/ip and per-ES AD route. I think it’s better to explicitly point out in this section that per-EVI routes are not withdrawn (so that when the link comes back only a single per-ES route is advertised) when the link goes down.

Sami: Actually per EVI EAD routes must be withdrawn too

Zzh2> RFC7432 only says it’s withdrawn when a tag is “decommissioned”; if the intention is to withdraw when the AC goes down, it should be explicitly spelled out (it’s not in RFC 7432 but should be added to this draft if that’s the right behavior). However, isn’t it better to keep those routes around so that they don’t need to be re-advertised when the link comes back up?

Thanks!
Jeffrey