Yes, OK, let's forward it.
Aijun From: Linda Dunbar <[email protected]> Sent: Wednesday, March 11, 2026 7:39 AM To: Aijun Wang <[email protected]>; 'Jeff Tantsura' <[email protected]>; 'RTGWG' <[email protected]> Cc: 'rtgwg-chairs' <[email protected]>; [email protected] Subject: RE: [rtgwg] WGLC for draft-ietf-rtgwg-multisegment-sdwan Ai Jun, Thank you very much for the valuable comments. Please see below of the resolutions. Please let us know if they can address your concern. Linda From: Aijun Wang <[email protected] <mailto:[email protected]> > Sent: Monday, March 9, 2026 2:09 AM To: 'Jeff Tantsura' <[email protected] <mailto:[email protected]> >; 'RTGWG' <[email protected] <mailto:[email protected]> > Cc: 'rtgwg-chairs' <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> Subject: RE: [rtgwg] WGLC for draft-ietf-rtgwg-multisegment-sdwan Hi, Jeff: Support its forwarding. Regarding to the document, I would like to the authors make some clarification on the following issues: 1) It is possible for the Cloud GW know the source and destination of the IPsec tunnel between the CPEs, then why define again the "SD-WAN Tunnel Endpoint Sub-TLV" and "SD-WAN Tunnel Originator Sub-TLV"? [Linda] The intent is not that the Cloud GW cannot derive the information by parsing deeper into the encapsulated payload. Rather, the SD-WAN Tunnel Endpoint Sub-TLV and SD-WAN Tunnel Originator Sub-TLV provide that information explicitly in the GENEVE metadata carried to the ingress Cloud GW. Since the outer destination of the GENEVE packet is the Cloud GW itself, carrying the SD-WAN tunnel endpoint/originator in Sub-TLVs allows the Cloud GW to process forwarding and policy metadata directly from the GENEVE header without inspecting deeper into the encapsulated payload. This simplifies processing and keeps the metadata aligned with the Cloud Backbone forwarding function. These Sub-TLVs are optional because some implementations may derive the same information by other means. 2) How can the CPE know in advance the information of explicit Egress GW? Especially when the cloud and cpe belong to different adminatration? [Linda] The draft already states that the explicit egress GW address "can be either preconfigured or dynamically discovered through a control plane protocol exchange with the destination CPE," and that "the details of the control plane protocol used for GW discovery are beyond the scope of this document." Aijun From: [email protected] <mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jeff Tantsura Sent: Tuesday, February 24, 2026 7:32 AM To: RTGWG <[email protected] <mailto:[email protected]> > Cc: rtgwg-chairs <[email protected] <mailto:[email protected]> >; [email protected] <mailto:[email protected]> Subject: [rtgwg] WGLC for draft-ietf-rtgwg-multisegment-sdwan Hi, This starts the Working Group Last Call for draft-ietf-rtgwg-multisegment-sdwan - Multi-segment SD-WAN via Cloud DCs https://datatracker.ietf.org/doc/draft-ietf-rtgwg-multisegment-sdwan/ Please send your support or objection before March 10, 2026. If you have any comments on this draft, whether positive or negative, please send them to the list. Thanks, Yingzhen & Jeff
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
