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] > <mailto:[email protected]>> wrote: >> Aseem, >> >> >> >> Thanks for reviewing the draft. Answers to your questions are inserted below: >> >> >> >> Linda >> >> >> >> From: Aseem Choudhary <[email protected] >> <mailto:[email protected]>> >> Sent: Tuesday, July 11, 2023 1:13 AM >> To: [email protected] >> <mailto:[email protected]> >> Subject: Re: draft-dmk-rtgwg-multisegment-sdwan-00 >> >> >> >> Fixed a typo. >> >> >> >> From: Aseem Choudhary <[email protected] >> <mailto:[email protected]>> >> Date: Sunday, July 9, 2023 at 9:33 PM >> To: [email protected] >> <mailto:[email protected]> >> <[email protected] >> <mailto:[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: >> >> >> >> 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. >> >> >> >> 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. >> >> >> >> 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] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/rtgwg > -- > <http://www.verizon.com/> > Gyan Mishra > Network Solutions Architect > Email [email protected] <mailto:[email protected]> > M 301 502-1347 > > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
