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]>
*Sent:* Monday, March 9, 2026 4:04 PM
*To:* Jeff Tantsura <[email protected]>; RTGWG <[email protected]>
*Cc:* rtgwg-chairs <[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]
