Sami, Let me use this old thread to continue the discussion during/after your presentation on Monday.
The service node would advertise EVPN-VPWS per EVI Ethernet A-D routes with the Ethernet Segment Identifier field set to 0 and the Ethernet tag ID set to (0xFFFFFFFF wildcard), all those routes will be associated with the EVPN-VPWS service edge RT that will be imported by other service edge PEs, each route will have a unique RD and will be associated with another RT corresponding to the L2, L3 or Ethernet VPN overlay service that can be transported over the EVPN- VPWS transport service. As we agreed after the session, the second RT above is only used to indicate the type of services that a service node support but not for the purpose of route import/export control. For that, we don't need to use RTs. ECs are just fine. An afterthought is that, we can probably define some bits in "EVPN Layer 2 attributes extended community" to signal the types of services? When a service node advertises a per EVI Ethernet A-D rout in response to the one received from an access node, it could target the route to that particular access node. This could be done by including a VRF Route Import EC (RFC 7153) in the route sent by the access node - the service node will include that in its route and only the targeted access node will import it. We did not get to cover the following two points: - during draft-ietf-bess-evpn-vpws LC, it was agreed to move the BW section to this document. - as the email below suggested, if the service is evpn or ipvpn, unless per-AC QoS needs to be enforced at the service node (vs. at the access node), instead of using VPWS between the access node and service node, perhaps EVPN Hub and Spoke can be used all the way to the access node (the service nodes will use IRB to provide IPVPN service)? That way, the service nodes do not need to use logical interfaces to terminate the VPWS and then connect into the EVPN/IPVPN. Jeffrey > -----Original Message----- > From: Sami Boutros [mailto:[email protected]] > Sent: Tuesday, March 29, 2016 1:32 AM > To: Jeffrey (Zhaohui) Zhang; [email protected] > Subject: Re: Questions & comments on draft-boutros-bess-evpn-vpws-service- > edge-gateway-02 > ... > > > >"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 [email protected] https://www.ietf.org/mailman/listinfo/bess
