Subject: [bess] Questions & comments on draft-boutros-bess-evpn-vpws-service-edge-gateway-02

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 25 Mar 2016 01:20:22 +0000

Sami and co-authors,

I have some comments & questions on this draft.

I noticed that the following terms are used in a mixed way and that adds confusion. Perhaps it could be straightened out?

  Service node, service edge node, service edge gateway, access node

Also in Figure 1, "AN" and "SE" are not marked in the figure.

There are a couple of places referring to "underlay EVI". Given that underlay typically refer to the underlying provider network, perhaps "transport EVI" or "VPWS EVI" would be better?

   This document describes how a service node can act as a gateway
   terminating dynamically EVPN virtual private wire service (VPWS) from
   access nodes and offering Layer 2, EVPN and Layer 3 VPN overlay
   services to Customer edge devices connected to the access nodes.

I take it that the gateway is offering "layer 2, EVPN and layer 3 VPN" services but instead of via local attachment circuits, it's via VPWS implemented via EVPN.

"4.2 Applicability to IP-VPN TBD" is empty, so I'll use EVPN for my understanding: the VPWS brings the customer connection (on the AN) to the EVPN on the gateway. There could be many VPWS from multiple ANs terminating into the same EVPN instance on the gateway. With that, I wonder if EVPN virtual hub and spoke could be used to implement the same? The ANs would be the spokes and the gateway would be the hub? Other EVPN PEs (not drawn in Figure 1) on the core side can be either spokes or hubs in the same EVPN instance?

If the above makes sense, then could the same be extended to IP-VPN service? You just need an IRB interface for the EVPN instance on the gateway?

Thanks.
Jeffrey

---

From: Sami Boutros <[email-masked]>
Date: Mon, 28 Mar 2016 16:31:56 +0000

Hi Jeffrey,

Thanks for your comments and Please see comments inline..

>  Service node, service edge node, service edge gateway, access node

Sami: Agreed will update the text in next rev.
>Also in Figure 1, "AN" and "SE" are not marked in the figure.

Sami: will do.
>There are a couple of places referring to "underlay EVI". Given that underlay typically refer to the underlying provider network, perhaps "transport EVI" or "VPWS EVI" would be better?

Sami: We will update this text too.
>I take it that the gateway is offering "layer 2, EVPN and layer 3 VPN" services but instead of via local attachment circuits, it's via VPWS implemented via EVPN.

Sami: Correct.
>If the above makes sense, then could the same be extended to IP-VPN service? You just need an IRB interface for the EVPN instance on the gateway?

Sami: The current document doesn’t preclude the IRB option and terminating multiple EVPN VPWS to the same L2 overlay bridge that has an IRB interface attached to an IP-VPN service. The empty sections are there for describing use cases that we will plan to add to the document in the future.

Thanks,

Sami