Hi Jeffrey,
On 11/14/16, 10:13 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" <[email protected] on behalf of [email protected]> wrote: >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? One RT is used for the service edge GWs to discover themselves so that they can do DF election using HRW. The other RT is used among edge nodes and service edge nodes for setting up P2P service tunnels. > >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. That¹s fine. >- 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. There are scenarios in which access node need to ONLY backhaul traffic (and not do any local switching!). In those scenarios, you will need to terminate the service tunnels at the service edge nodes regardless of IRB or not. Cheers, Ali > >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 _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
