Hi Jeffrey, Thanks for your comments and Please see comments inline..
On 3/24/16, 6:20 PM, "Jeffrey (Zhaohui) Zhang" <zzh...@juniper.net> wrote: >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 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. > > 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. Sami: Correct. > >"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? 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 > >Thanks. >Jeffrey > _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
