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

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

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?

   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?

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

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.

   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