[Idr] Re: RtgDir Early review: draft-ietf-idr-sdwan-edge-discovery-22 (Resolutions for Line 1537 -2027 )

[Linda Dunbar <[e-mail]>]

Alvaro,

Below are the line-by-line replies to your comments from Line 1537 -2027 . This is the second of multiple emails for the resolutions to avoid large email being truncated.


These have also been documented in GitHub under Issue #62 through Issue #88:
Issues · ietf-wg-idr/draft-ietf-idr-sdwan-edge-discovery<https://github.com/ietf-wg-idr/draft-ietf-idr-sdwan-edge-discovery/issues>
[cid:image001.png@01DBEC0E.3981D970]<https://github.com/ietf-wg-idr/draft-ietf-idr-sdwan-edge-discovery/issues>
Issues · ietf-wg-idr/draft-ietf-idr-sdwan-edge-discovery - GitHub<https://github.com/ietf-wg-idr/draft-ietf-idr-sdwan-edge-discovery/issues>
Find and fix vulnerabilities Codespaces. Instant dev environments
github.com



If there are any resolutions you disagree with or would like to discuss further, could we set up a quick call to go over them?
Thank you very much for your detailed comments.

Linda


From: Alvaro Retana <[e-mail]<mailto:[e-mail]>>
Sent: Monday, June 2, 2025 5:00 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: RE: RtgDir Early review: draft-ietf-idr-sdwan-edge-discovery-22

On May 23, 2025 at 7:28:33 PM, Linda Dunbar wrote:


Hello

I have been selected to do a routing directorate “early” review of this
draft.
https://datatracker.ietf.org/doc/draft-ietf-idr-sdwan-edge-discovery/

The routing directorate will, on request from the working group chair,
perform an “early” review of a draft before it is submitted for publication
to the IESG. The early review can be performed at any time during the
draft’s lifetime as a working group document. The purpose of the early
review depends on the stage that the document has reached.

As this document is in working group last call, my focus for the review was
to determine whether the document is ready to be published. Please consider
my comments along with the other working group last call comments.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Thanks!

Alvaro.

1537 3.3.6.  Extended Port Attribute Sub-TLV
...
1544   SubTLV Description:  The Extended Port Attribute Sub-TLV advertises
1545      the properties associated with a public Internet-facing WAN port
1546      that might be behind NAT.  A SD-WAN edge node can query a STUN
1547      Server (Session Traversal of UDP through Network address
1548      translation [RFC8489]) to get the NAT properties, including the
1549      public IP address and the Public Port number, to pass to its
1550      peers.

[nit] s/behind NAT/behind a NAT device
[Linda] fixed.


1552         The location of a NAT device can be:

1554         *  Only the initiator is behind a NAT device.  Multiple
1555            initiators can be behind separate NAT devices.  Initiators
1556            can also connect to the responder through multiple NAT
1557            devices.

1559         *  Only the responder is behind a NAT device.

1561         *  Both the initiator and the responder are behind a NAT
1562            device.

1564         The initiator's address and/or responder's address can be
1565         dynamically assigned by an ISP or when their connection crosses
1566         a dynamic NAT device that allocates addresses from a dynamic
1567         address pool.

[?] Only this text in the whole document talks about initiator/responder.
I'm guessing that the terminology is related to STUN, or ??   It seems out
of place...

[Linda] changed to “request” and “respond”

1569         As one SD-WAN edge can connect to multiple peers, the pair-wise
1570         NAT exchange as IPsec's IKE[RFC7296] is not efficient.  In the
1571         BGP Controlled SD-WAN, NAT properties for a WAN port are
1572         encoded in the Extended Port Attribute sub-TLV.

[major] "is not efficient"

Even if it may be part of the justification for this work, please don't
compare this solution to others...


[Linda] The Extended Port Sub-TLV is used to convey NAT traversal parameters associated with each SD-WAN edge node, allowing peers to correctly establish tunnels even when one or both are behind NAT devices. change the terminology to peer to peer instead of the initiator and responder.
Revise the description to the following:
The Extended Port Attribute Sub-TLV advertises NAT-related properties associated with a public Internet-facing WAN port on an SD-WAN edge node. This information enables peer SD-WAN nodes to establish secure tunnels even when one or both peers are behind NAT devices.
An SD-WAN edge node may query a STUN server (Session Traversal Utilities for NAT [RFC8489]) to determine its NAT properties, including its public IP address and public port number. These properties are then advertised to peer nodes using the Extended Port Attribute Sub-TLV.
Revise the NAT Type description to the following:
NAT Type (8 bits): an unsigned integer indicating the NAT behavior observed for this WAN port. The values are derived from the legacy NAT classification model described in RFC 3489 Section 5.

Revise the error handling section to the following:
If the Extended Port Attribute Sub-TLV is malformed (e.g., incorrect length, invalid address format, or unrecognized NAT type), it MUST be ignored per the procedures described in [RFC9012]. Other Sub-TLVs in the same Tunnel Encapsulation Attribute, if valid, MUST still be processed.


1574   SubTLV Encoding:  The encoding is shown in the figure below:

1576        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
1577       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1578       |Type=65(extPort| ExtPort Length| Reserved      |I|O|R|R|R|R|R|R|
1579       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1580       | NAT Type      |  Encap-Type   |Trans networkID|     RD ID     |
1581       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1582       |                  Local  IP Address                            |
1583       |        32-bits for IPv4, 128-bits for Ipv6                    |
1584       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1585       |                  Local  Port                                  |
1586       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1587       |                Public IP                                      |
1588       |        32-bits for IPv4, 128-bits for Ipv6                    |
1589       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1590       |                Public Port                                    |
1591       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1592       |               Extended SubSub-TLV                             |
1593       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

[minor] The first field seems truncated: "Type=65(extPort".

s/Type=65(extPort/Type=65

[Linda] fixed.

...
1602   *  ExtPort Length: the length of the subTLV in octets (variable).
1603      If IPv4, the length is 32 (8 header, 32 address, 8 for 1
1604      subSubTLV).  If IPv6, the length is 64 (8 header, 48 addresses,
1605      8 for 1 subSubTLV).

[minor] s/ExtPort Length/Length

To be consistent with the rest...

[Linda] fixed

[major] If I remember correctly, most of the other Length fields don't
include the Type and Length, but this one does. :-(   Is there a reason for
the inconsistency?


[minor] The components of this TLV (header, address...) are not called out
anywhere else.  It is not intuitive that the "address" contains 2 IP
addresses and 2 port numbers...  Recommendation: remove that part of the
text, which, BTW is wrong.

s/32 address...48 addresses/16 address...40 addresses

s/If IPv6, the length is 64/If IPv6, the length is 56

[Linda] fixed


[major] What action should be taken if the Length is any other value?


[major] The sub-Sub-TLV are not required!   §3.3.6.1 defines only one
sub-sub-TLV, which happens to have a length of 8, but I assume that others
could be defined later, right?  The lengths listed would not be accurate
then.  A better idea would be to list the lengths as relative...



1607   *  Flags:

1609      -  I bit (CPE port address or Inner address scheme):

1611         o  If set to 0, indicate the inner (private) address is
1612            IPv4.

1614         o  If set to 1, indicates the inner address is IPv6.

1616      -  O bit (Outer address scheme):

1618         o  If set to 0, indicate the inner (private) address is
1619            IPv4.

1621         o  If set to 1, indicates the inner address is IPv6.

[major] The definition of "inner" was copied to "outer".


[major] Assuming that the inner and outer can have different values (?)
then the lengths above wouldn't be as indicated.  If they can't have
different values, why use 2 bits?



1623      -  R bits: reserved for future use.  Must be set to 0, and
1624         ignored upon reception.

[] s/must/MUST

[Linda] fixed.

1626   *  NAT Type: the NAT type can be one of the following values:

1628      -  1: without NAT ;

1630      -  2: 1-to-1 static NAT;

1632      -  3: Full Cone;

1634      -  4: Restricted Cone;

1636      -  5: Port Restricted Cone;

1638      -  6: Symmetric; or

1640      -  7: Unknown (i.e. no response from the STUN server).

1642      NAT type values outside of 1-7 are invalid for this SubTLV.

[major] Is the "NAT Type" field a bit field (8 bits total) or a integer
(255 values).


[major] Where are these type defined?  How would the sender know what to
set them to?  How would the receiver validate them?  Or does it have to?



1644   *  Encap-Type: the supported encapsulation types for the port.

1646      -  Encap-Type=1: GRE;

1648      -  Encap-Type=2: VxLAN;

[major] I'm assuming this field is an integer...  Please don't make the
reader guess/assume.


[Linda] Encap-Type (8 bits):
An unsigned integer indicating the encapsulation type supported for this WAN port.
Added a subsection in IANA Considerations.


1650      Notes:

1652      -  The Encap-Type inside the Extended Port Attribute Sub-TLV is
1653         different from the RFC9012's BGP-Tunnel-Encapsulation type.
1654         The port can indicate the specific encapsulations, such as:

[major] By "BGP-Tunnel-Encapsulation type", do you mean "the Tunnel Type in
the Tunnel Encapsulation TLV"?  Consistency!!



1656         o  If the IPsec-SA-ID subTLV or the IPsec SA detailed
1657            subTLVs (Nonce/publicKey/Proposal) are included in the
1658            SD-WAN-Hybrid tunnel, the Encap-Type indicates the
1659            encapsulation type within the IPsec payload.

[major] Please be consistent about the names in this document too!!  Use
the complete names!

Note that this is the only mention of "detailed subTLVs".



...
1665      -  Encapsulation types outside of GRE and VxLAN are outside of
1666         the scope of this specification.

[major] In this case, this note is not needed.  Is there anything specific
about an indication of other encapsulations?  I'm asking because this
document just specifies the signaling, and not any specific action.


[major] Please set up a registry for other values.



1668      -  The Extended Port attribute SubTLV cannot support 6to4NAT
1669         encoding.

[major] I guess this text partially answers my question above about setting
the inner and outer bits to different values...

[Linda] see the above resolution

1671   *  Transport Network ID: Central Controller assigns a global
1672      unique ID to each transport network.  Any value in this octet
1673      is valid

[minor] The field in the figure is called "Trans networkID".

[Linda] Trans NetworkID (Transport Network ID): An identifier assigned by the SD-WAN Controller to indicate the transport network that this WAN port belongs to. All values from 0 to 255 are valid.

[nit] s/valid/valid.

[Linda] fixed.

[major] Again, I assume this field contains an integer...



1675   *  RD ID: Routing Domain ID, need to be globally unique.  Any
1676      value in this octet is valid.

[nit] s/need/needs


[major] How is this field validated?



1678      -  Some SD-WAN deployment might have multiple levels, zones, or
1679         regions that are represented as logical domains.  Policies
1680         can govern if tunnels can be established across domains.
1681         For example, a hub node can establish tunnels with different
1682         logical domains but the spoke nodes cannot establish tunnels
1683         with nodes in different domains.

[major] The definition and enforcement of these policies should be
explicitly out of the scope of this document.


[Linda] Revised the test for SD-WAN deployments to the following:
Some SD-WAN deployments may define multiple levels, zones, or regions that are represented as logical domains. Operational policies may govern whether tunnels are allowed between nodes in different logical domains. For example, a hub node may be permitted to establish tunnels across domains, while spoke nodes may be restricted to communicating only within their own domain.
The definition, distribution, and enforcement of such policies are outside the scope of this document.


...
1690   *  Public IP: The IP address after the NAT.  If NAT is not used,
1691      this field is set to all-zeros

1693   *  Public Port: The Port after the NAT.  If NAT is not used, this
1694      field is set to all-zeros.

[major] What happens if only one of these values is set to 0?


[Linda] If NAT is not used for the WAN port, both the Public IP and Public Port fields MUST be set to zero. If one field is set to zero and the other is non-zero, the Sub-TLV is considered malformed.

...
1699   SubTLV Error Handling:  A IPsec SA Proposal Sub-TLV is a MALFORMED
1700      Sub-TLV if the fields do not fit the limits specified above.  Per
1701      [RFC9012] a MALFORMED Sub-TLV is ignored.  The procedures for
1702      content checks for the IPsec SA Proposal SubTLV is specified in
1703      section 3.4 for client routes, and section 3.5 for underlay
1704      routes.

[major] Bad copy and paste; this section is about the Extended Port
Attribute Sub-TLV.

[Linda] fixed.

...
1709 3.3.6.1.  Extended SubSub-TLV

1711   One Extended SubSub-TLVs is specified in this document: Underlay
1712   Network Transport SubSub-TLV.

[nit] There's no reason to dig deeper in the TOC if only one Sub-Sub-TLV is
defined here.



1714 3.3.6.1.1.  Underlay Network Transport SubSub-TLV
...
1740   Underlay Network Properties:  sub Type=66

[] The name in the field and the description don't match...  Consistency!

[Linda] fixed.

...
1747   Connection Type:  are listed below as:

1749      *  1 = Wired

1751      *  2 = WIFI

1753      *  3 = LTE

1755      *  4 = 5G

1757      *  Any value outside of 1-4 is outside the scope of this
1758         specification.

[major] Is this field a bit field or an integer?


[major] Please set up a registry.

[Linda] added in the IANA section

1760   Port Type:  Port type define as follows:

1762      *  1 = Ethernet

1764      *  2 = Fiber Cable
1765      *  3 = Coax Cable

1767      *  4 = Cellular

1769      *  Any value outside of values 1-4 are outside the scope of
1770         this specification.

[major] Is this field a bit field or an integer?


[major] Please set up a registry.

[Linda] added in the IANA section

1772   Port Speed:  The port seed is defined as 2 octet value.  The
1773      values are defined in megabit speed.  For example, a value of
1774      1000 would mean 1 gigabit (1000 Mbps).  For example, a value of
1775      1000 would mean 1 gigabit (1000 Mbps).  The port speed of "0"
1776      is not valid.

[nit] s/as 2 octet value/as a 2 octet value
[Linda] fixed.

1778   The connection types of equipment and port types will continue to
1779   grow with technology change.  Future specifications may specify
1780   additional connection types or port types.

[minor] This paragraph is not needed.  Setting up a registry is.

[Linda] removed the sentence about two forms a Tunnel Encapsulation Attribute (TEA) can take.

[?] Just curious...  What is the value/use of carrying this type of
information?  Will the behavior or maybe preference of the connection be
affected?
[Linda] Azure co-author wanted this information, stating it is useful for them.

1794 3.4.  Procedure for Client Routes with Hybrid SD-WAN Tunnel

1796   The Tunnel Encapsulation Attribute for the SD-WAN Hybrid Tunnel Type
1797   may be associated with BGP UPDATE messages with NLRI with AFI/SAFI
1798   IPv4 Unicast (1/1), IPv6 (2/1), L3VPN v4 Unicast (1/128), and IPv6
1799   L3VPN (2/128).

[minor] s/associated with BGP UPDATE messages/advertised in BGP UPDATEs
[Linda] fixed.


1801   The SD-WAN Secure Links topology is supported by the Unicast IPv4/
1802   IPv6 prefixes.  The L3VPN topologies support forming the SD-WAN
1803   Secure L3VPN described in [SD-WAN-BGP-USAGE] and MEF ([MEF
1804   70.1][MEF70.2]).

[] Repetitive...

[Linda] fixed.

1806   Based on [RFC9012], there are two forms a Tunnel Encapsulation
1807   Attribute (TEA) can take: "Barebones" using the Encapsulation
1808   Extended Community (Encap-EC) and a normal Tunnel Encapsulation form.

[major] Well, the "barebones" version may not use the Tunnel Encapsulation
Attribute...  In any case, this paragraph is not needed...
[Linda] waiting to discuss with Sue.


1810 3.4.1.  SD-WAN Tunnel in Encapsulation Extended Community (Encap-EC)

1812   The SD-WAN Client routes are sent with a the Encapsulation Extended
1813   Community (Encap-EC) BGP attribute that identifies the Hybrid SD-
1814   WAN tunnel type.  Per [RFC9012], the Encapsulation Extended Community
1815   uses the NextHop Field in the BGP UPDATE as the Tunnel Egress
1816   EndPoint.  The validation for the Tunnel Egress Endpoint uses the
1817   validation in sections 6, 8, and 13 applied to the NextHop.

[] Repetitive...
[Linda] waiting to discuss with Sue.

1819   A Color Extended Community (Color-EC) or local policy applied to the
1820   client route directs the traffic for the client route to across
1821   appropriate interface within the Hybrid SD-WAN Tunnel to the Tunnel
1822   Egress Endpoint.

[] "directs the traffic for the client route to across appropriate
interface within the Hybrid SD-WAN Tunnel to the Tunnel Egress Endpoint."

Couldn't parse. :-(

[Linda] Meant to say the following:
The Color Extended Community (Color-EC) is used to correlate client routes with eligible underlay tunnels. The Color value carried with the client route identifies the set of underlay tunnels (previously advertised with the same Color value) that may be used to transport the client route's traffic. This allows SD-WAN controllers or ingress nodes to select appropriate underlay paths based on pre-established tunnel characteristics such as performance, policy, or service requirements


1824 3.4.2.  SD-WAN Tunnel in Tunnel Encapsulation Path Attribute (TEA)

1826   The procedures for validating a client route with a TEA does the
1827   following:

1829   1.  Check for Well-formed SD-WAN Hybrid Tunnel TLV:  A well-formed
Hybrid SD-WAN Tunnel TLV MUST have a Tunnel
1830         Engress Endpoint SubTLV.  The validation for the Tunnel Egress
1831         Endpoint uses the [RFC9012] validation in section 6, 8, and 13.
1832         An invalid Tunnel Egress Endpoint, cause the Hybrid SD-WAN
1833         Tunnel TLV to be invalid, and the TLV is ignored.

[nit] s/Engress/Egress
[Linda] fixed.

[major] §3.2.2 says that what matters is the SD-WAN-Node-ID, not the Tunnel
Egress Endpoint sub-TLV.  Why is the Tunnel Egress Endpoint sub-TLV
required?  It seems to be a potential cause of invalidity with no benefits.

[Linda] Tunnel Egress Endpoint sub-TLV carries the WAN port address.

1835         It MAY also have any of the following SubTLVs:

[major] s/MAY/may

The optional nature of the sub-TLVs should be specified where they are
defined.  At this point, "may" is only indicating a fact.

[Linda] Fixed.

...
1841         *  IPsec SA Nonce,

[major] s/IPsec SA Nonce/IPsec SA ReKey Counter

Consistency!!
[Linda] fixed nits: /IPsec SA Nonce/IPsec SA ReKey Counter and s/SA)/SA

...
1847         *  Simplified IPsec SA)

[nit] s/SA)/SA
[Linda] fixed.

1849         A MALFORMED SubTLV is ignored in the Tunnel TLV is ignored.

[?] Not sure I'm parsing this correctly, but it sounds as something that is
already specified in rfc9012.
[Linda] waiting for Sue’s response.


1851         SubTLV with an unknown type is ignored.

[] Already specified in rfc9012.



1853   2.  Check for multiple instances of SubTLVs:  Multiple instances of
the Tunnel Endpoint SubTLV causes the
1854         first one to be used, and the subsequent instances to be
1855         ignored.

[] Already specified in rfc9012...



1857         Multiple instances of the IPsec Public Key, IPsec SA Proposal,
1858         and Simplified IPsec SA cause the first instance to be used,
1859         and subsequent instances to be ignored.

[major] For each of these sub-TLVs, this behavior should be specified where
they were defined.

[Linda] It is easier to have one sentence describing the behavior for multiple Sub-TLVs in one place instead separately : IPsec Public Key, IPsec SA Proposal, and Simplified IPsec SA.

1861         A Hybrid SD-WAN tunnel TLV may have multiple instances of the
1862         IPsec-SA-ID if the IPsec SA Identifiers are unique.  If all the
1863         IPsec SA Identifies are not unique, the second SubTLV is
1864         ignored and not propagated.

[major] This behavior should be specified where the sub-TLV was defined.
[Linda] see the reply above.


1866   3.  Validate Tunnel Egress Endpoint:  The Tunnel Egress Endpoint MUST
1867      link to the remote end of one of the underlay links to be used.
1868      This validation adheres to the [RFC9012] Tunnel Egress Endpoint
1869      validation.  The tunnel link may be active or inactive.

[] If already in rfc9012, there's no need to repeat it here.



1871   4.  Validate each NLRI:  Local policy is run to validate routes.

[major] "Local policy" or rfc4271?

[Linda] Local policy

1873   5.  Validate Hext Hop:  The next hop must be be reachable via the
1874      tunnel."

[major] This text is at odds with §3.2.2 -- or I don't understand the
relationship between the Next Hop, the SD-WAN-Node-ID, and the Tunnel
Egress Endpoint.


[Linda] It has been cleared in the revision that:
When Client routes are advertised using Extended Encapsulation Community, the NextHop carries the SD-WAN node's loopback address.
The Tunnel Endpoint Sub-TLV in the TEA carries the WAN port address where the tunnel terminates.


1876   If a tunnel encapsulation attribute is malformed, it MUST be ignored
1877   per [RFC9012].  However, in SD-WAN environments where secure tunnels
1878   are required, traffic forwarding MUST be contingent on tunnel
1879   liveness.  If a required secure tunnel is unavailable, the associated
1880   route MUST NOT be installed in the forwarding table or used to
1881   forward traffic.  The route MAY still exist in the BGP control plane
1882   but MUST be marked as unusable for forwarding until a valid secure
1883   tunnel is established.

[] The first sentence is not needed because it repeats the rfc9012 behavior.


[minor] s/However, in/In

[Linda] fixed.

I don't see the applicability of "however" in this case.  ??


[major] "traffic forwarding MUST be contingent on tunnel liveness. If a
required secure tunnel is unavailable, the associated route MUST NOT be
installed in the forwarding table or used to forward traffic."

Yes, these are obvious (and repetitive) statements: if the tunnel is not up
then the traffic cannot be forwarded.  But, how does it relate to the BGP
operation?

I don't see the purpose of using Normative language here.


[major] "The route MAY still exist in the BGP control plane"

s/control plane/RIB [§3.2/rfc4271]

Why do you consider optional having the route in the BGP RIB?  Or are you
explicitly thinking about the Adj-RIB-In, or ???


[major] "MUST be marked as unusable for forwarding until a valid secure
tunnel is established"

According to §9.1.2/rfc4271, if the next hop is not reachable then the
route won't be selected for installation in the Routing Table (and used for
forwarding).  Are you trying to specify something more?

It sounds as if you're concerned about the tunnel not being setup properly,
while the next hop is reachable.  Note that §6/rfc9012 says:

   The full set of procedures for sending a packet through a particular
   tunnel type to a particular tunnel egress endpoint depends upon the
   tunnel type and is outside the scope of this document. Note that some
   tunnel types may require the execution of an explicit tunnel setup
   protocol before they can be used for carrying data. Other tunnel
   types may not require any tunnel setup protocol.

If this document wants to specify the criteria for a feasible tunnel, or
require local policy, for the SD-WAN-Hybrid tunnel type, then you need to
be specific about it.


[Linda] I think this paragraph can be deleted from this section of "SD-WAN Hybrid Tunnel in TEA" because the TEA is included in the client route update.
If a Tunnel Encapsulation Attribute is malformed, it MUST be ignored per [RFC9012]. However, in SD-WAN environments where secure tunnels are required, traffic forwarding MUST be contingent on tunnel liveness. If a required secure tunnel is unavailable, the associated route MUST NOT be installed in the forwarding table or used to forward traffic. The route MAY still exist in the BGP control plane but MUST be marked as unusable for forwarding until a valid secure tunnel is established.

in responding to RFC9012's
Note that some tunnel types may require the execution of an explicit tunnel setup protocol before they can be used for carrying data.

The following statement should be added to Section 3.4.1 (SD-WAN Hybrid Tunnel in Encap-EC):
When client routes are advertised using the Encapsulation Extended Community (Encap-EC) with the SD-WAN Hybrid Tunnel Type, the routes MUST NOT be installed in the forwarding table until the underlay secure tunnel is established.
The following paragraph is added to Section 3.4.1:
In this approach, if a required underlay tunnel is unavailable, the associated route MUST NOT be installed in the forwarding table or used to forward traffic. The route MAY still exist in the BGP control plane but MUST be marked as unusable for forwarding until a valid secure tunnel is established.


1885 3.4.3.  Multiple tunnels attached to One Client Route

1887   A single SD-WAN client route may be attached to multiple SD-WAN
1888   Hybrid tunnels.  An Update with an SD-WAN client route may express
1889   these tunnels as an Encap-EC or a TEA.  Each of these tunnel
1890   descriptions is treated as a unique Hybrid SD-WAN tunnel with a
1891   unique Egress Endpoint.  Local Policy on the BGP Peer determines
1892   which tunnel the client data traffic will use.

[] Already specified in rfc9012.



1894 3.4.4.  SD-WAN VPN ID in the Client Route Update

1896   An SD-WAN VPN ID is the same as a client VPN ID in a BGP controlled
1897   SD-WAN network.  The Route Target Extended Community should be
1898   included in a Client Route UPDATE message to differentiate the client
1899   routes from routes belonging to other VPNs.  Route Target value is
1900   taken as the VPN ID (for 1/1 and 2/1).  For 1/128 and 2/128, the RD
1901   from the NLRI identifies the VPN ID.  For EVPN, picking up the VPN-ID
1902   from EVPN SAFI.

[minor] Please add a reference for "Route Target Extended Community".

[Linda] added.

[major] "Route Target Extended Community should be included..."

Does this statement need to be Normative?

When is it ok to not include the Route Target Extended Community?

[Linda] fixed

[minor] "(for 1/1 and 2/1).  For 1/128 and 2/128"

I know you're referring to AFI/SAFIs, but please be explicit and precise in
the specification!

[Linda] fixed

[minor] "the RD from the NLRI"

Add a reference and expand RD.

[Linda] fixed

[major] "For EVPN, picking up the VPN-ID from EVPN SAFI."

This is the only place where EVPN is mentioned...or where it is even hinted
that this specification also applies to the EVPN SAFI.  !!
[Linda] removed the EVPN reference.


1904 3.4.5.  SD-WAN VPN ID in Data Plane

1906   SD-WAN edge node can be reached by either an MPLS path or an IPsec
1907   path within the hybrid SD-WAN tunnel.  If client packets are sent via
1908   a secure MPLS network within the Hybrid SD-WAN tunnel, then the data
1909   packets will have MPLS headers with the MPLS Labels based on the
1910   scheme specified by [RFC8277].  It is assumed the secure MPLS network
1911   assures the security outer MPLS Label header.

[nit] s/SD-WAN edge node/An SD-WAN edge node
[Linda] fixed.

[?] What is a "secure MPLS network"?
[Linda] meant to say MPLS network being secure as compared with public internet.

[] "MPLS Labels based on the scheme specified by [RFC8277]"

This is a specification of the data plane...not BGP-related...
[Linda] fixed.

[minor] "It is assumed the secure MPLS network assures the security outer
MPLS Label header."

I'm not sure I'm parsing this sentence correctly.  Did you mean "assures
the security of the outer"??
[Linda] meant to say MPLS network being secure as compared with public internet.


1913   If the packets are sent via a link with IPsec outer encryption across
1914   a public network, the payload is still encrypted with GRE or VXLAN
1915   encryption.  For GRE Encapsulation within an IPsec tunnel, the GRE
1916   key field can be used to carry the SD-WAN VPN ID.  For network
1917   virtual overlay (VxLAN, GENEVE, etc.) encapsulation within the IPsec
1918   tunnel, the Virtual Network Identifier (VNI) field is used to carry
1919   the SD-WAN VPN ID.

[minor] "network virtual overlay (VxLAN, GENEVE, etc.)"

[Linda] fixed.

§3.3.6 says that only GRE and VxLAN are in scope.

[Linda] fixed.


1921 3.5.  Procedure for Underlay Routes with Hybrid SD-WAN Tunnel TLV

1923 3.5.1.  Hybrid SD-WAN NLRI with a Encapsulation Extended Community

1925   The Hybrid SD-WAN NLRI MUST be accompanied with the TEA, and MUST NOT
1926   be accompanied by an Encapsulation Extended Community.

[major] This sentence is in conflict with rfc9012 which specifies that
"where a tunnel could be encoded using a barebones TLV, it MUST be encoded
using the corresponding Encapsulation Extended Community".


[Linda] The BGP Peer receiving the NLRI MUST have pre-configured inbound filters to set the preference for the SD-WAN NLRI tuple.
Revised the text to the following:
As specified in Section 3.2.1, a Route Type 1 NLRI includes the tuple (Port-Local-ID, SD-WAN-Color, SD-WAN-Node-ID). The Port-Local-ID field MAY be set to zero to indicate that the NLRI applies to all WAN ports on the identified SD-WAN node, effectively representing tunnel attributes at the node level rather than a specific port.
When Port-Local-ID = 0, the receiving BGP speaker SHOULD apply local policy to determine how to associate client routes with underlay tunnels. This local policy may prefer tunnels from specific SD-WAN nodes, or choose among SD-WAN Colors based on administrative preference, link type, path performance, or service-level objectives. The exact selection logic is implementation-specific.
It is valid for multiple such node-level NLRIs to be received, each advertising different SD-WAN Colors for the same node. For example, the following three NLRIs may be received (within one or more UPDATE messages):
·         (Port-Local-ID = 0, SD-WAN-Color = 10, SD-WAN-Node-ID = 2.2.2.2)
·
·         (Port-Local-ID = 0, SD-WAN-Color = 20, SD-WAN-Node-ID = 2.2.2.2)
·
·         (Port-Local-ID = 0, SD-WAN-Color = 30, SD-WAN-Node-ID = 2.2.2.2)
These indicate that node 2.2.2.2 supports multiple tunnel groups, each classified by a different SD-WAN Color. For example, these Colors may correspond to service tiers such as gold, silver, and bronze. The SD-WAN-Color field is used to correlate underlay tunnels with client routes that carry a matching Color Extended Community. If no match is found, the client route may not be forwarded over any SD-WAN tunnel.



1928 3.5.2.  Underlay Route with a TEA

1930   An underlay routes contains Hybrid SD-WAN NLRIs with TEA attached.
1931   The procedures for processing underlay routes follows the following
1932   steps:

[nit] s/An underlay routes/An underlay route

[Linda] fixed.


1934   1.  Check for Well-Formed SD-WAN Hybrid Tunnel TLV:  An Hybrid SD-WAN
1935      Tunnel TLV is well-formed using only SubTLVs valid for association
1936      with the underlay Route.

1938         A well-formed SD-WAN Hybrid Tunnel TLV MUST contain a valid
1939         Tunnel Egress Endpoint subTLV to be a valid SD-WAN Hybrid TLV.
1940         [RFC9012] provides validation guidelines for the Tunnel Egress
1941         Endpoint in sections 13.

[major] "MUST contain a valid Tunnel Egress Endpoint subTLV"

§3.2.2 says that what matters is the SD-WAN-Node-ID, not the Tunnel Egress
Endpoint sub-TLV.  Why is the Tunnel Egress Endpoint sub-TLV required?  It
seems to be a potential cause of invalidity with no benefits.

[Linda] see the revised text above.


1943         The SD-WAN Hybrid Tunnel TLV MAY contain the following subTLVs:
1944         Tunnel Egress, IPsec-SA-ID, Extended Port SubTLV, IPsec Nonce,
1945         IPsec Public Key, IPsec SA Proposal, and Simplified IPsec SA.

[major] s/MAY/may
[Linda] fixed.

The optional nature of the sub-TLVs should be specified where they are
defined.  At this point, "may" is only indicating a fact.



1947         Following [RFC9012] intent, a MALFORMED SubTLV is ignored, and
1948         a SubTLV with an unknown type is ignored.

[] Specified in rfc9012.



1950   2.  Multiple instances of SubTLVs within a SD-WAN Tunnel TLV
1951      Multiple instances of the Tunnel Endpoint, IPsec Public Key, IPsec
1952      SA Proposal, and Simplified IPsec SA cause only the first one to
1953      be used.  Subsequent subTLVs are ignored and not propagated.  The
1954      IPsec-SA-ID subTLVs may have multiple instances of the subTLV if
1955      the IPsec SA Identifiers are unique, but if the IPsec SA
1956      Identifiers are not unique the second subTLV is ignored and not
1957      propagated.  If multiple Extended Port SubTLVs exist, the TLVs
1958      must be validated in step 4.

[] See related comments in §3.4.2.

[Linda] see the revised text above.


1960   3.  Validate Tunnel Egress Endpoint  The Tunnel Egress Endpoint MUST
1961      link to remote end point of one of the underlay links from the
1962      router receiving the link.

[] See related comments in §3.4.2.



1964   4.  Validate Extended Port SubTLV(s)  If a single Extended Port
1965      SubTLV exist, then validate that the port information provides
1966      needed information to establish a connection to the remote port.
1967      A SD-WAN edge node MAY utilize local policy, local configuration,
1968      and the information from the SubTLV.  The exact mechanism of local
1969      port validation is outside the scope of this document.  If the
1970      Extended Port SubTLV is invalid, the SD-WAN tunnel TLV must be
1971      considered to be invalid.

[major] "If a single Extended Port SubTLV exist..."

What if multiple exist?  Please specify this where the sub-TLV is defined.


[major] "node MAY utilize local policy, local configuration, and the
information from the SubTLV"

What's left?  If it's optional to use "local policy, local configuration,
and the...SubTLV", what would the node use?   s/MAY/may    s/and/or


[major] "The exact mechanism of local port validation is outside the scope
of this document."

Only the local port information?  Where is the mechanism to validate the
rest?


[major] "If the Extended Port SubTLV is invalid, the SD-WAN tunnel TLV must
be considered to be invalid."

Should this statement be Normative?

[Linda] see the revised text above.


1973   5.  Validate each NLRI  The typed NLRI in the SD-WAN Underlay MUST be
1974      Well-Formed having the format specified in section 3.2.1.  A
1975      MALFORMED NLRI must cause the NLRI to be discarded.  An
1976      implementation MAY log an error for a MALFORMED NLRI.  The local
1977      policy configuration in the BGP peer receiving this NLRI MUST
1978      determine the validity of the route based on policy.

[major] "MUST be Well-Formed having the format specified in section 3.2.1."

Does well-formed imply only the format?  What about the contents?  See
related comments in §3.2.1.

[Linda] see the revised text above.


1980   6.  Validate Next Hop  The IP address specified in the Next Hop field
1981      must be reachable by the Tunnels.

[major] This text is at odds with §3.2.2 -- or I don't understand the
relationship between the Next Hop, the SD-WAN-Node-ID, and the Tunnel
Egress Endpoint.

[Linda] see the revised text above.


1983 3.5.3.  Underlay Routes with Port-Local-ID of zero

1985   Section 3.2.1 specifies that Route Type 1 has a tuple of (Port-Local-
1986   ID, SD-WAN-Color, SD-WAN-Node-ID).  Port-Local-ID may be zero if the
1987   NLRI applies to multiple ports.  The BGP Peer receiving the NLRI must
1988   have pre-configured inbound filters to set the preference for the SD-
1989   WAN NLRI tuple.

[major] "must have pre-configured inbound filters to set the preference for
the SD-WAN NLRI tuple"

Should this be a Normative statement?

Please provide more details about the filters and the preference.  What
does "preference" mean in this context?



1991   Since a Port-Local-ID value of zero indicates the NLRI applies to
1992   multiple ports, it is possible to have the following NLRI within a
1993   packet (or received in multiple packets):

[minor] s/packet/update...

[Linda] fixed.

1995      Port-Local-ID (0), SD-WAN-Color (10), SD-WAN-Node-ID (2.2.2.2),
1996      Port-Local-ID (0), SD-WAN-Color (20), SD-WAN-Node-ID (2.2.2.2),
1997      and

1999      Port-Local-ID (0), SD-WAN-Color (30), SD-WAN-Node-ID (2.2.2.2).

2001   These NLRI may simply indicate that there are three groups of tunnels
2002   for SD-WAN-Node-ID (2.2.2.2) assigned three colors.  For example,
2003   these tunnels could represent three types of gold, silver and bronze
2004   network service.

[] This explanation wasn't too convincing.  "may simply indicate", or what?

[Linda] see the revised text above.


2006 3.5.4.  Multiple Tunnels attached to One Underlay Route

2008   An underlay route (SD-WAN NLRI) may only attach to one Hybrid SD-WAN
2009   Tunnel.  If there are more than one Hybrid SD-WAN Tunnel TLV within a
2010   single TEA, the first is processed and the subsequent Hybrid SD-WAN
2011   Tunnel TLVs are ignored.

[major] This should be specified where the TLV is defined!

[Linda] wait for Sue’s response

2013 3.6.  Error handling

2015   The Error handling for SD-WAN VPN support has two components: error
2016   handling for Tunnel Encapsulation signaling (Encap-EC and TEA) and
2017   the SD-WAN NLRI.  An SD-WAN NLRI, a Tunnel Encapsulation attribute
2018   MUST always accompany the SD-WAN NLRI.

[] See the related comment in §3.5.1.



2020   The previous sections (3.4 and 3.5) provide the normal procedures for
2021   handling client routes and undelay routes.

[] "normal procedures"

Are there other procedures?



2023 3.6.1.  Error handling for the Tunnel Encapsulation Signaling

2025   The error handling for the tunnel encapsulation signaling (Encap-EC
2026   and TEA) adheres to the error handling and validation specified by
2027   [RFC9012].

[] Just include any exceptions here...no need to repeat what rfc9012
already says.

[Linda] Question to Sue: can we delete this section? The content is repeat.