Thank you Linda. Yes, that change makes it clear and understandable.
Yours,
Joel
On 3/10/2026 8:59 PM, Linda Dunbar wrote:
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]
*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]
To unsubscribe send an email [email protected]
_______________________________________________
rtgwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
