[Idr] Re: Follow-up: remaining resolutions for the comments (RE: RtgDir Early review: draft-ietf-idr-sdwan-edge-discovery-22

[Alvaro Retana <[e-mail]>]

 On May 27, 2025 at 4:03:42 PM, Linda Dunbar wrote:


Hi!

...
> > [] The Introduction said that this section presents a "brief definition
of
> > these two use cases", but it seems to me that "SD-WAN Secure Links" is
not
> > a different use case... I may of course be confused already.
>
> [Linda] meant to say the following:
>
> "This section provides an overview of (1) L3VPN services supported by
SD-WAN
> overlays and (2) SD-WAN Secure Links as an alternative tunneling
mechanism
> for simpler deployments."

Ok, but one thing that is not clear (and doesn't belong in this document)
is the conditions when one or the other are used.  IOW, what represents a
"simpler deployment"?



...
> > 225 Authorized BGP peer: Authorized BGP peer are Peers which a
> > 226 particular BGP Peer has been configured by local policy to connect
> > 227 to.
> >
> > [] IOW, what every other document would call a "BGP Peer". Note that
this
> > term is only used one more time in this document (§2.3) coupled with
> > discovery, which, to me, is different that "configured".
>
> [Linda] Revised definition:
>
> “Authorized BGP Peer: A BGP peer that a given BGP speaker is permitted to
> exchange SD-WAN-related information with, based on local configuration or
> policy. This term is used in the context of SD-WAN edge discovery to
indicate
> that not all discovered peers are automatically eligible for overlay
> connectivity.”

I don't think the revision helped because, by default, BGP expects a
configuration, so we're left with the same thing: a configured BGP peer.




> > 229 Cloud DC: Off-Premises Data Centers that usually host applications
> > 230 and workload owned by different organizations or tenants.
> >
> > [major] Some of the definitions are different from the ones in related
> > drafts. For example, "Cloud DC" has a slightly different definition in
> > draft-ietf-rtgwg-net2cloud-problem-statement. I recommend that you only
> > define the terms once and then reference them.
>
> [Linda] Here is the revised definition of the Cloud DC:
>
> “Cloud DC: Off-premises data centers that host applications and workloads,
> typically across multiple tenants or organizations, as defined in
> [Net2Cloud].”

The point of "only define the terms once and then reference them" is to not
include a definition in this document.  Instead, mention that the
terminology in Net2Cloud is expected to be understood.

However, we go back to the specific application (SD-WAN) vs the general use
of the BGP extensions.   And the fact that, in this case, "Cloud DC" is
only used once more...as an example.  Discussing its definition, or even
including it, is not worth it...



...
> [Linda] revised to the following:
>
> “Controller: Refers to the SD-WAN Controller as defined in
> [SD-WAN-BGP-USAGE]. It is responsible for managing SD-WAN control-plane
> operations, including overlay path setup, teardown, policy enforcement,
and
> route advertisement via BGP.”

Same comment as above.



...
> [Linda] Yes, change to the following and changed CPE to C-PE across the
> entire document:
>
> “C-PE: Customer Premises Equipment that participates in the SD-WAN overlay
> network. As defined in [SD-WAN-BGP-USAGE], the term is used in this
document
> to emphasize the role of a Provider Edge (PE) device functioning as the
> SD-WAN edge node, responsible for forming secure overlays across diverse
> underlay networks within the provider’s infrastructure.”

Same comment as above.


...
> [Linda] Changed to the following:
>
> “MP_REACH_NLRI: A BGP Path Attribute used to advertise reachability
> information for multiple address families, as defined in [RFC4760]. This
> document uses MP_REACH_NLRI for carrying SD-WAN-specific NLRIs.”

Same as above.  MP_REACH_NLRI is already defined in rfc4760...



...
> > 300 TEA: Tunnel Encapsulation Path Attribute [RFC9012]
> >
> > [major] Please don't make up unnecessary terms. Using the name used in
> > rfc9012 keeps terminology in sync through out all the RFCs.
>
> [Linda] "Tunnel Encapsulation Path Attribute " is used over 20 times in
the
> document. The full name makes the figure exceeding the Line limit. How
about
> this definition?
>
> “TEA: Abbreviation for Tunnel Encapsulation Attribute as defined in
> [RFC9012]. Used in this document for brevity.”

This is how we start splintering the terminology...



...
> > 319 Tunnel Encapsulation may be attached to the prefixes from the
Unicast
> > 320 v4 and v6 ((AFI/SAFI 1/1 and 2/1), and L3VPNs for v4 and v6
(AFI/SAFI
> > 321 1/128 and 2/128) (per [RFC4364], [RFC4659]).
...
> > [major] The statement is about the use of the Tunnel Encapsulation
> > Attribute is false, in general. It may be what this specification
expects
> > (when used with a specific tunnel type or NLRI) -- if so, please be
> > explicit.
>
> [Linda] How about changing the sentence to the following?
>
> “The Tunnel Encapsulation Attribute [RFC9012] may be attached to prefixes
> carried in BGP UPDATEs for IPv4 and IPv6 unicast routes (AFI/SAFI 1/1 and
> 2/1), as well as for IPv4 and IPv6 L3VPNs (AFI/SAFI 1/128 and 2/128), as
> specified in [RFC4364] and [RFC4659]. In the context of this
specification,
> these NLRIs are used to signal SD-WAN tunnel information and endpoint
> properties associated with specific prefixes.”

No.  The first sentence still makes a general statement about the Tunnel
Encapsulation Attribute (in general), and not just when the extensions
defined in this document are used...which is what I assume you're after.  ??

Also, the text in -23 uses "MAY" in the first sentence.  It is out of place
because the sentence is pointing at a fact, not an option.



...
> > 350 This section summarizes the BGP requirements from the following
three
> > 351 scenarios from [SD-WAN-BGP-USAGE] can be handled by a BGP control
> > 352 plane using BGP Tunnel-Encapsulation attribute [RFC9012]:
...
> > [] Also, these seem to be data plane requirements, not "BGP
requirements".
> >
> > IOW, I understand how BGP can be used to carry the information to
achieve
> > the final goal...but the requirements don't seem specific to the use of
BGP
>
> [Linda] We've clarified that the listed items are deployment scenarios,
not
> “BGP requirements,” and rephrased the paragraph to distinguish them from
the
> five control-plane requirements described in Section 1.1. We've also
applied
> the suggested wording fix for clarity and accuracy. Here are the revised
> text:
>
> “This section summarizes how a BGP-based control plane, using the BGP
Tunnel
> Encapsulation Attribute [RFC9012], can support three deployment scenarios
> described in [SD-WAN-BGP-USAGE]. These scenarios focus on different ways
> encrypted tunnels are used in SD-WAN service delivery. While Section 1.1
> lists five BGP-specific control-plane requirements, the following list
> highlights service-level SD-WAN deployment models that BGP can support
> through tunnel advertisement and associated metadata.”

This is part of the redundant information between the draft that doesn't
belong here.


Alvaro.