Thanks Jeff! That is an excellent feature of GENEVE.
Makes sense. Gyan On Sun, Jul 16, 2023 at 7:29 PM Jeff Tantsura <[email protected]> wrote: > Hi Gyan, > > Couple of comments: > 1. Geneve is not L2 centric (it can natively encapsulate L3 and doesn’t > require MAC to be present), and the encapsulation of choice (IETF) if/when > meta-data need to be included in the data-plane.Transit nodes don’t > have/need to lookup the transit Geneve packets below IP/UDP. > 2. Any assumptions about trust relationship between cloud backbone and CPE > domain don’t hold, all the traffic, when it changes the domains will be > re-evaluated and potentially remapped to align with the schema used in its > domain. Also, end2end IPv6 is not a given (hence foo in UDP is a more > realistic approach). > 3. I’d advise to take a look at latest EHoInternet measurements done by > Geoff Huston. > > Cheers, > Jeff > > On Jul 16, 2023, at 12:32 PM, Gyan Mishra <[email protected]> wrote: > > > Hi Linda > > I reviewed the draft and had some questions and ideas for expansion of the > draft to expand on use free using SRv6 uSID. We can discuss in separate > email. > > The connection from CPE to any cloud GW being on Prem part of enterprise > or off Prem to CSP would always be an eBGP peering to the gateway for both > single segment and multi segment. > > Section 5.1 and 5.2 single and multi segment transit GW as iBGP. Would > that not always be eBGP to the GW for both on Prem or off Prem GW. > > GENEVE is a DC specific overlay over IP underlay L2 centric > extensibility. Since we are providing IP over SD WAN transitivity it seems > having the complexity of the NVO GENEVE encapsulation seems quite a lot of > overhead with outer MAC / IP / UDP / GENEVE / inner Ethernet / Payload. > > I believe Next SID SRv6 uSID as it uses native IP DA uSID carrier for > steering up to 5 GW hops and SRv6 as it uses IPv6 data plane and IPv6 has > native IPSEC with extension header you can do secure SRv6 uSID steering > multi hop multi segment through CSP waypoints for end to end optimized SD > WAN steering capabilities and all done natively with uSID which utilizes > simplified IP DA address as uSID carrier for 6 hops of steering using uN > shift and forward function within the DA IP uSID carrier as opposed to > Replace SID which copies from SRH to DA requiring SRH to be present on the > CSP GW multi hop endpoints. > > Another idea is maybe to use RFC 9012 BGP tunnel encapsulation attribute > leverage to build the single and multi hop IP tunnels between the CSP > gateways. > > Thanks > > Gyan > > On Tue, Jul 11, 2023 at 10:53 AM Linda Dunbar <[email protected]> > wrote: > >> Aseem, >> >> >> >> Thanks for reviewing the draft. Answers to your questions are inserted >> below: >> >> >> >> Linda >> >> >> >> *From:* Aseem Choudhary <[email protected]> >> *Sent:* Tuesday, July 11, 2023 1:13 AM >> *To:* [email protected] >> *Subject:* Re: draft-dmk-rtgwg-multisegment-sdwan-00 >> >> >> >> Fixed a typo. >> >> >> >> *From: *Aseem Choudhary <[email protected]> >> *Date: *Sunday, July 9, 2023 at 9:33 PM >> *To: *[email protected] < >> [email protected]> >> *Subject: *draft-dmk-rtgwg-multisegment-sdwan-00 >> >> >> >> Hello Authors, >> >> >> >> Thanks for the document, Great work! >> >> >> >> Having gone through the document, I have some questions/clarifications: >> >> >> >> 1. Section 3.3, it is mentioned SRv6/mpls-te not the best way. If >> there are multiple Cloud GW’s and traffic need to be steered through for >> serviceability and performance, why SRv6 *not* an option? >> >> [Linda] The draft proposes to use GENEVE header simply because wide >> adoption of GENEVE by cloud operators. >> >> In addition, when the traffic from on-prem CPEs to Cloud GWs via the >> public Internet, TE and SRv6 is not supported by the Internet. Internet can >> only forward traffic based on the packets’ destination addresses. >> >> >> >> 1. Section 4.5: Can there be multiple Egress GW Sub-TLV (or Next GW >> Sub-TLV) to steer traffic. >> >> >> >> [Linda] The Egress GW Sub-TLV carries the information of the SD-WAN end >> point which is used by the egress GW to forward the traffic to. >> >> >> >> 1. Section 4.6/4.7: What is the best way to encode AZ/Regions? Is it >> possible to include/exclude specific Transit GW’s? >> >> [Linda] Probably will be “name” for the AZ/Regions, as most cloud >> operators do today, as the actual GW address of different AZ/Regions might >> be hidden from the end users. >> >> >> >> I may have further comments. >> >> >> >> -thanks, >> >> Aseem >> >> >> _______________________________________________ >> rtgwg mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/rtgwg >> > -- > > <http://www.verizon.com/> > *Gyan Mishra* > *Network Solutions A**rchitect * > *Email [email protected] <[email protected]>* > > > *M 301 502-1347* > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
