Joel, Thank you. As for the second resolution, the document assumes that the iBGP sessions among enterprise CPEs use the enterprise's own management or control connectivity, rather than the cloud network described here. The intent was simply to distinguish the logical control plane among CPEs from the separate eBGP control plane between a CPE and its attached Cloud GW. How about the following wording change to make it clearer?
Old: The iBGP sessions among CPEs described in this section are a logical control plane relationship among enterprise managed nodes. New: The iBGP sessions among CPEs described in this section are a logical control plane relationship among enterprise managed nodes, using the enterprise's own management/control connectivity. Linda From: Joel Halpern <[email protected]> Sent: Tuesday, March 10, 2026 4:26 PM To: Linda Dunbar <[email protected]>; RTGWG <[email protected]> Cc: [email protected] Subject: Re: [rtgwg] WGLC for draft-ietf-rtgwg-multisegment-sdwan Thank you. That first resolution is exactly what I had missed, and the proposed text does a good job of explaining it. I can live with the second resolution. I am not sure whether the independence you describe is based on assuming an intra-domain path among the CPE that is separate from the SD-WAN. If so, a mention of that assumption would be helpful. Yours, Joel On 3/10/2026 7:21 PM, Linda Dunbar wrote: Joel, Thank you very much for the valuable comments. Please see below for the resolutions and let us know if the wording changes can address your concern. Linda From: Joel Halpern <[email protected]><mailto:[email protected]> Sent: Monday, March 9, 2026 4:04 PM 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 I have reviewed this draft. Overall, it is clear and provides a useful description. I support advancing this document. I do have some minor comments which I would appreciate being considered. Section 4.3 on the SD-WAN Tunnel Originator Sub-TLV indicates that this may be used to influence policy routing or security policy. This seems to introduce its own threat vector not considered by the Threat analysis in section 9.1. It may be that the intention is to use this to allow the custoemr to specify what treatment the want, albeit indirectly? Or it may be that the assumption is that if the customer lies in this field, they will only hurt themselves? Or that such lies will be detected and penalized by other systems? Whatever the assumption is, it should be spelled out. [Linda] The intent is not that a customer can use the SD-WAN Tunnel Originator Sub-TLV to arbitrarily obtain preferred forwarding or security treatment. Any such policy is applied only after the ingress Cloud GW authenticates the sender and validates the Originator value against authorized/provider-configured state. How about changing the text to the following: Old: This Sub-TLV allows Cloud GWs and transit nodes to identify the packet's source, allowing them to apply source specific policies for forwarding. These policies may include traffic engineering rules specific to the originating CPE, security enforcement tailored to the source, or path selection constraints based on the origin New: This Sub-TLV allows Cloud GWs and transit nodes to identify the packet's source, allowing them to apply source-specific policies for forwarding. Such policies may include traffic engineering rules specific to the originating CPE, security enforcement tailored to the source, or path selection constraints based on the origin. Any such policy, however, MUST be applied only after the ingress Cloud GW authenticates the sender and validates the Originator value against authorized policy state. A false, unauthorized, or unverifiable Originator value MUST NOT be used to obtain preferred treatment and such packets MUST be discarded. I see a disconnect between sections 7.1 and 7.2. I suspect that the disconnect is due to a descriptive gap, not a technical flaw. Section 7.1 talks about using iBGP to coordinate information among the various CPE. Section 7.2 then talks about using eBGP to coordinate between the CPE and the Cloud gateway. That seems to mean that the iBGP sessions are running over scope subject to eBGP. I am guessing that the assumption is that iBGP is expected to be tunneled over the paths controlled by eBGP. But the text doesn't say that. [Linda] Section 7.1 describes the logical control-plane relationship among CPEs, while Section 7.2 describes the separate control-plane relationship between a CPE and its attached Cloud GW. The iBGP sessions among CPEs are not required to run over or depend on the eBGP sessions to the Cloud GW. How about the following changes at the end of Section 7.1? Old: Further details on the control plane between CPEs and Cloud Gateways (CGs) are described in Section 7.2. New: The iBGP sessions among CPEs described in this section are a logical control plane relationship among enterprise managed nodes. They are independent of the eBGP sessions between a CPE and its attached Cloud GW described in Section 7.2. For Section 7.2, adding the following sentence at the beginning? "This section describes the control plane relationship between a CPE and its attached Cloud GW, which is distinct from the iBGP based control plane among CPEs described in Section 7.1." Yours, Joel On 2/23/2026 6:32 PM, Jeff Tantsura wrote: 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]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
