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

[Sami Boutros <[e-mail]>]

Hi Jeffrey,

Thanks for your comments, Please see responses inline.

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.

[Sami]
We do have a section 5 on comparison between PW signaling and EVPN, Actually, the draft is proposing a mechanism that eliminates PW signaling for P2P service using EVPN, so not sure how can we remove this?

[Sami]

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

[Sami]
Please have a look at section 5.
[Sami]


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.

[Sami]

There is no inconsistency, the text you refer to in [7432] is part of the explanation of the ESI or ethernet segment identifier.
in [7432] Page 31, it mentions exactly what we are referring to above. "On the other hand, a unique label per <ESI, Ethernet tag> allows an egress PE to forward a packet that it receives from another PE, to the connected CE, after looking up only the MPLS labels without having to perform a MAC lookup.”

[Sami]

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

[Sami]

From one PE point of view an ES is a single link.[7432] is not denying this.

[Sami]

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

[Sami]
Those will be different routes as per [7432]. We are not defining any new behavior.

[Sami]

   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.

[Sami]
Transport paths carry the service traffic over the MPLS transport network, we are simply mentioning this, those paths can for sure be asymetric as the per the nature of MPLS LSPs. I am not really sure if we should delete this.
[Sami]


   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.

[Sami]
Ok, will change this.
[Sami]


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.

[Sami]

   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?
[Sami]
They are not the same, [5] talks about multiple EVPL on the same trunk interface belonging to different EVI(s), and [6] talks about EVPL on a multiple access interfaces belonging to the same EVI.
[Sami]


   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.
[Sami]
Sure will do.
[Sami]


   ... 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 ..."?
[Sami]

Not sure I get that, you mean all VLANs are presented by different VIDs?

[Sami]

   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/

[Sami]
This is section 6.2 in [7432], will fix that.
[Sami]

   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/

[Sami]
Same as above.
[Sami]


   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?

[Sami]
To be consistent with [7432] and current implementations.
[Sami]


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

[Sami]
In EVPN, on failure we can direct traffic to the backup PE using a backup label signaled, PW redundancy doesn’t have that.
[Sami]


     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?

[Sami]
There is not PW getting setup here.
[Sami]


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.

[Sami]
The draft already explicitly mention that in single active, traffic will not start flowing until the remote PE, receives from at least one of the PE(s) in the single active redundancy an Ethernet-AD route with the P bit set. Identifying the backup PE will help to failover quicker at the remote PE. We have spent weeks as co-authors on this section before, and to be quite honest, I am not sure if any new text on this will clarify!
[Sami]


   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.
[Sami]
Will do.
[Sami]

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?

[Sami]
This BW will be symmetric, we can make that explicit in the doc.
[Sami]


   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)?
[Sami]
Not sure, I get this, if it can’t be granted BW in one direction, are you saying may be the other direction will get it?
[Sami]


   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.

[Sami]
We are not proposing any Shaping, or filters for traffic entering the EVPN-VPWS service, it is a simple BW negotiation, that can be provisioned single sided.
[Sami]


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".
[Sami]
Sure will do.
[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.
[Sami]

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?

[Sami]
Correct, an operator may chose that. We are not precluding this.
[Sami]

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.

[Sami]
Will remove this section, and finally, thanks for all your comments.

Sami