Hi Jeffrey,
>>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. > >It's still not clear why the other RT is needs to be included in that route. >It does not seem to be necessary for the edge nodes to import that route? The >edge nodes only need to be configured what RT needs to be used for what >service, and one edge node's route does not need to be imported by other edge >nodes - only the service nodes need to import it. This is correct, but the service node need still to import the access edge nodes routes to be able to respond to them, and for that it still need an RT or at least an import extended community, we can have for that an EVPN Layer 2 import extended community provisioned/derived at service node, however I think when service node respond to the access node, it still need to attach an RT not an import EC, in order not to change the operation access nodes. > >> 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. > >Understand. However, if the service is EVPN, even when you terminate the VPWS >with logical interfaces that are part of of the service EVI on the service >node, that service node will do local switching between those logical >interface; if we extend the EVPN to the edge node using virtual hub and spoke, >the traffic between the edge nodes will still go through the service nodes >anyway due to the nature of hub and spoke, so no different from the VPWS >approach as far as local switching is concerned? The way I look at this as yet another option that will be outside the spoke of this draft, since this is vanilla EVPN hub and spoke that can be used too. I.e. This draft define another mean of achieving a similar thing, in scenarios where access node will only be capable of supporting dynamic EVPN-VPWS or even static EVPN-VPWS with no signaling. Thanks, Sami > >Thanks. > >Jeffrey > >> -----Original Message----- >> From: Ali Sajassi (sajassi) [mailto:saja...@cisco.com] >> Sent: Wednesday, November 16, 2016 9:07 AM >> To: Jeffrey (Zhaohui) Zhang; Sami Boutros; bess@ietf.org >> Subject: Re: [bess] Questions & comments on draft-boutros-bess-evpn-vpws- >> service-edge-gateway-02 >> >> >> Hi Jeffrey, >> >> >> On 11/14/16, 10:13 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" >> <bess-boun...@ietf.org on behalf of zzh...@juniper.net> 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:sbout...@vmware.com] >> >> Sent: Tuesday, March 29, 2016 1:32 AM >> >> To: Jeffrey (Zhaohui) Zhang; bess@ietf.org >> >> 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 >> >BESS@ietf.org >> >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=CwIFAw&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=me053Be9qKrCJjUISJBP2sGFEDp-39GNmgAhZLwv8aY&m=DuwaaeMDzjr3yaEmRRUPWcDKI5aYhYwH5x40RcQ6cqQ&s=9_3AMDvEElGuc-kA-YqtceieDACWRg6AJC1ICq_k8e4&e= >> > > _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
