Re: [Idr] Error in draft-ietf-idr-sdwan-edge-discovery use of Encapsulation Extended Community

[John Scudder <[e-mail]>]

Hi Sue,

Thanks for your reply. I hope you don't mind, I'm keeping the IDR list in the CC, I think it's best for transparency, especially since this discussion intersects with my DISCUSS position on draft-ietf-bess-bgp-sdwan-usage-20. I don't have any objection to the co-authors taking their discussion off-line, if that's how you'd prefer to work, of course.

Regarding "Please confirm that agree up  to this point by sending me email”, yes, I agree. On the other “do you agree”/“please send comment” parts, that's going to take a little more time than I have right now I'm afraid, sorry. I'll try to get to it soon, so if you do make progress offline please update me so that I'm not reviewing text that's been overtaken by events!

Thanks a lot for your work on this.

--John

On Feb 28, 2024, at 10:12 AM, Susan Hares <[e-mail]> wrote:



John and Linda:

Thank you for your patience while I completed a set of reviews for the CAR document.   After further investigation,  as an author, I still think we will need to adjust this document before asking for IESG Publication.

This discussion in this email has 3 parts as a way of explanation of the basic concepts of the technology:

  *   SD-WAN-Hybrid – just Client Routes +  Tunnel encapsulation attribute (this email)
  *   SD-WAN-Hybrid with SD-WAN Underlay NRLI  - All Ports example
  *   SD-WAN-Hybrid with SD-WAN Underlay NLRI  - One Port update


[Chair hat on]
Due to the other WGLC traffic (CAR, CT, sr-safi-policy)  on the IDR list, it would be helpful if the discussion would go “offlist” as we work to fix these issues.
 [chair hat off]

Again, thanks for catching this error before we went to the IESG.  We’ll work to refine the draft, update the implementation report, and go through a 2nd WG LC on the update.

Sue Hares

=============

Part 1 – Restrict the work to Client Route + new Tunnel Encapsulation Attribute

See section 3.3 of the text.

Current text:/
As described in [SD-WAN-BGP-USAGE], two separate BGP UPDATE messages are used for SD-WAN Edge Discovery:
Client routes BGP UPDATE:
This UPDATE is precisely the same as the BGP VPN client route UPDATE. It uses the Encapsulation Extended Community and the Color Extended Community to link with the SD-WAN Tunnels UPDATE Message as specified in section 8 of [RFC9012].
A new Tunnel Type (SD-WAN-Hybrid) is added and used by the Encapsulation Extended Community or the Tunnel-Encap Path Attribute [RFC9012] to indicate mixed underlay networks.
SD-WAN UPDATE:
This UPDATE is for an edge node to advertise the properties of directly attached underlay networks, including the NAT information, pre-configured IPsec SA identifiers, and/or the underlay network-specific information. This UPDATE can also include the detailed IPsec SA attributes, such as keys, nonce, encryption algorithms, etc.
/

Restriction from RFC-9012
Section: 4.1

Current text:/
This extended community may be attached to a route of any AFI/SAFI to which the Tunnel Encapsulation attribute may be attached. Each such extended community identifies a particular tunnel type; its semantics are the same as semantics of a Tunnel TLV in a Tunnel Encapsulation attribute, for which the following three conditions all hold:

It identifies the same tunnel type.
It has a Tunnel Egress Endpoint sub-TLV for which one of the following two conditions holds:

Its Address Family subfield contains zero, or
Its Address subfield contains the address of the Next Hop field of the route to which the Tunnel Encapsulation attribute is attached.
It has no other sub-TLVs.
Such a Tunnel TLV is called a "barebones" Tunnel TLV.
/

Note:  If you change Section 3.3 above to the text below, you do not have a problem with the Tunnel Encap Attribute.

New text:/
Client routes BGP UPDATE:
This UPDATE is precisely the same as the BGP VPN client route UPDATE. It uses the Tunnel Encapsulation Attribute and the Color Extended Community to link with the SD-WAN Tunnels UPDATE Message as specified in section 8 of [RFC9012].
A new Tunnel Type (SD-WAN-Hybrid) is added and used by the Encapsulation Extended Community or the Tunnel-Encap Path Attribute [RFC9012] to indicate mixed underlay networks.
/
Please confirm that agree up  to this point by sending me email.
Client Routes:
Section 3.3 indicates:
Old text:/
C-PE2 advertises the attached client routes as below:
•         Client Route UPDATE:
o    Extended community: RT for SD-WAN VPN 1
o    NLRI: AFI=IPv4/IPv6 and SAFI = VPN
o    Prefix: 10.1.1.x; 20.1.1.x
o    NextHop: 2.2.2.2 (C-PE2)
o    Encapsulation Extended Community: tunnel-type=SD-WAN-Hybrid tunnel endpoint
o    Color Extended Community: Site-identifier

•         SD-WAN UPDATE:
o    C-PE2 can use the following Update messages to advertise the properties of Internet facing ports 192.0.0.1 and 170.0.0.1, and their associated IPsec SA related parameters.
o    Update #1 for the properties associated with the WAN port 192.0.0.1, such as the NAT properties, the underlay network properties, etc. (Details in Section 9.1).
o    Update #2 for the properties associated with the WAN port 170.0.0.1 associated properties. (Details in Section 9.1).
o    Update #3 for IPsec parameters associated with IPsec tunnel terminated at the Node level (2.2.2.2), such as the supported encryption methods, public keys, etc. (Details in Section 9.2).
/
If you use the Tunnel Encaps Attribute (TEA) [RFC9012] to describe the SD-Wan Hybrid tunnel, then
Client Route UPDATE
o    Extended community: RT for SD-WAN VPN 1  [Route Target Constraints [RFC4684]
o    NLRI: AFI=IPv4 (1)/IPv6 (2) and SAFI = VPN (128)
o    Color Extended Community: Site-identifier assigned as color for NLRI
o    Prefix: 10.1.1.x; 20.1.1.x
o    NextHop: 2.2.2.2 (C-PE2) (sets next-hop self) – Loopback address
o    Tunnel Attribute: tunnel-type=SD-WAN-Hybrid (type = 25)

           *   Tunnel endpoint 2.2.2.2
           *   Extended Port Sub-TLV for – B1-A1 - MPLS Link  - identified locally as 1001
           *   Extended Port Sub-TLV for – B2-A2 – IP-SEC - identified locally as 192.0.0.1
           *   Extended Port Sub-TLV for – B3-A3 – IP-Sec – identified locally as 170.0.0.1
           *   IP-SEC SA with security keys available for the IP-SEC links.
           *   Color TLV: Site-identifier


Key points:

  *   The inner ports are uniquely identified by logical tunnel endpoint (2.2.2.2), trans network ID,  RD, and local address, and local port (4 octets)
  *   Please notice that the Tunnel encapsulation can handle all the SDWAN functionality – just as other tunnels do.
     *   The tunnel end is 2.2.2.2.  It is set-up between 1.1.1.1 to 2.2.2.2.
     *   If the tunnel address Endpoint = 0, the tunnel’s address is the next hop.
  *   Every time the tunnel attributes change, this causes a change in the Update.
  *   Similar to SR Policy (draft-ietf-idr-sr-policy-safi) with multiple candidate routes (segments)
     *   Unlike SR Policy, it does require the use of the TEA End Point for validation.
Diagram for reference:
                                 +---+
                   +--------------|RR |----------+
                  /  Untrusted    +-+-+           \
                 /                                 \
                /                                   \
        +---------+  MPLS Path                      +-------+
11.1.1.x| C-PE1   A1-------------------------------B1 C-PE2 |10.1.1.x
        |         |                                 |       |
21.1.1.x|         A2(192.10.0.10)------( 192.0.0.1)B2       |20.1.1.x
        |         |                                 |       |
        | Addr    A3(160.0.0.1) --------(170.0.0.1)B3 Addr  |
        | 1.1.1.1 |                                 |2.2.2.2|

Do you agree with me? Please send me email.
Part 2: SD-WAN-Hybrid Tunnel + SDWAN Underlay Tunnel ID
The concept is the SDWAN Underlay NLRI to SD-WAN Hybrid tunnels identified by the tunnel Egress Endpoint.
   Node-1.1.1.1 -----------------Node-2.2.2.2
                   Hybrid SD-Wan-Tunnel
The virtual tunnel end-point is 2.2.2.2.
The SD-WAN NLRI is simply providing details on SD-WAN tunnels ending at Node-2.2.2.2.
SDWAN NLRI (IPv4)  - (P-ID, C, N)
  Port-Local-ID = 0 (for all ports) or specific port ID
  SD-WAN-Color = [4 octets]
  SD-WAN-Node-ID = 2.2.2.2 (See 2.2.2.2 as Tunnel Egress Endpoint)
+ TEA – Tunnel Attribute (1) – same encodings as above

  *   Tunnel endpoint 2.2.2.2
  *   Extended Port Sub-TLV for B1-A1 – ID: 1000,  Encapsulation: MPLS encapsulation
  *   Extended Port Sub-TLV for B2-A2 – ID: 192.0.0.1, Encapsulation:  IP-SEC
  *   Extended Port Sub-TLV for B3-A3 – ID: 170.0.0.1, Encapsulation: IP-SEC
  *   IP-SEC SA with security keys available for the IP-SEC links.
  *   Color TLV: Site-identifier

Key points:

  *   If Port-Local-Id = 0, then this passes the same information as example 1 for the tunnel endpoint.  (Explaining why ID, C, N instead of C, N, ID is missing in the text).
  *   SDWAN Hybrid tunnel – matches the Tunnel Endpoint (2.2.2.2), Port-ID and updates interface and IP-SEC information.
  *   This is similar to TEA with SR Policy with multiple Candidate Routes.
Response Request – please send comments on part
3. Application to single port
Revised Example from 9.1
Update #1
SD-WAN NLRI – AFI/SAFI (1/SD-Wan) SD-WAN  (ID, C, N)

  *   Local Port ID – 4 octets – 190.0.0.1
  *   Color  - 4 octet
  *   Node-ID – 2.2.2.2 (C-PE2)
  *   Next Hop - 2.2.2.2


Tunnel Encaps Attribute

  *   TEA Endpoint = 2.2.2.2
  *   Extended Port Sub-TLV for B2-A2 – ID: 192.0.0.1
  *   IP-SEC Sub-TLV – new Security associations

Update #2 – Just New Security
SD-WAN NLRI – AFI/SAFI (1/SD-Wan) SD-WAN  (ID, C, N)

  *   Local Port ID – 4 octets – 170.0.0.1
  *   Color  - 4 octet
  *   Node-ID – 2.2.2.2 (C-PE2)
  *   Next Hop - 2.2.2.2


Tunnel Encaps Attribute

  *   TEA Endpoint = 2.2.2.2
  *   Extended Port Sub-TLV for B2-A2 – ID: 170.0.0.1
  *   IP-SEC Sub-TLV – new Security associations

Key points:

  *   This usage comes from 9.1



From: John Scudder <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 27, 2024 3:42 PM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Error in draft-ietf-idr-sdwan-edge-discovery use of Encapsulation Extended Community


Hi Authors, WG,

I just noticed draft-ietf-idr-sdwan-edge-discovery-12 and was looking at its use of RFC 9012. There seems to be a fundamental misunderstanding of how the Encapsulation Extended Community can be used, and I thought you should be aware of it. TL;DR, you’re specifying the use of SD-WAN-Hybrid tunnel type in an Encapsulation Extended Community, but this isn’t allowed. Details follow.

- RFC 9012, Section 4.1 tells us that the only permissible use of the Encapsulation Extended Community is when there are *no sub-TLVs*, other than the Address Family sub-TLV (item 3 in the list of conditions).

- In draft-ietf-idr-sdwan-edge-discovery-12 Section 6.3 we see the definition of the IPsec-SA-ID Sub-TLV of the SD-WAN-Hybrid tunnel type. This seems pretty central to the purpose of the spec. So, the SD-WAN-Hybrid tunnel type does have sub-TLVs in addition to the Address Family, and therefore MUST NOT be used in an Encapsulation Extended Community.

- Also, in draft-ietf-idr-sdwan-edge-discovery-12 Section 5.1 we see that the client route update uses the Encapsulation Extended Community (emphasis added):

```
5.  Client Route UPDATE

   The SD-WAN network's Client Route UPDATE message is the same as the
   L3 VPN or EVPN client route UDPATE message.  The SD-WAN Client Route
   UPDATE message uses the **Encapsulation Extended Community** and the
   Color Extended Community to link with the SD-WAN Underlay UPDATE
   Message.
```

- It’s clear from other parts of the spec that the tunnel type is SD-WAN-Hybrid, for example, this is both stated in Section 3.3, and then used in the example (same section).

- But RFC 9012 §4.1 told us we can’t use a tunnel type with sub-TLVs as an Encapsulation Extended Community!

I think what you really must be trying to do is use the Tunnel Encapsulation attribute (only!) to carry the SD-WAN-Hybrid in the SD-WAN Underlay route, and then have the client routes making use of that tunnel recurse into the underlay route (including tunnel) as per RFC 9012 Section 8. Note that Section 8 does NOT require that the client route carry the Encapsulation Extended Community — the next hop address is both necessary and sufficient to effectuate the linkage to the underlay route.

Thanks,

—John