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

[Susan Hares <[e-mail]>]

Linda:

If the each client route, needs a specific encapsulation from the SDWAN-Hybrid tunnel then:


  1.  You cannot use Encapsulation extended communities –  You only have the egress endpoint.
  2.  You can use TEA (SD-WAN-Hybrid Tunnel) type – with Egress Endpoint + an identifier for which sub-tunnel (MPLS, IP-SEC (GRE), IP-SEC (VXLAN))
If each client route, only needs to signal the node to pick sub-tunnels based on something you pass in the underlay,  you can specify
         Client route + TEA (SD-WAN-Hybrid Tunnel) with Egress Endpoint.

The rules on Encapsulation Extended community are very tight in RFC9012.  Errors in deployment caused these reasons to be very tight.

Bottom line – it is good John caught this before going to the IESG.  We have time to adjust the text and talk to Arista.

Sue

From: Linda Dunbar <[e-mail]>
Sent: Tuesday, February 27, 2024 9:31 PM
To: John Scudder <[e-mail]>
Cc: Robert Raszuk <[e-mail]>; [e-mail]; [e-mail]
Subject: RE: Error in draft-ietf-idr-sdwan-edge-discovery use of Encapsulation Extended Community

John, Here is the SD-WAN scenario why simple Nexthop cannot do the job: Suppose one SD-WAN edge has 3 client routes (#1, #2, #3) and multiple underlay paths (public unsecure paths & private secure pat
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tL2Y3YzJlZDIzYjU3ZDEyNjU4OGQyMDdlODFjMWEzMzczLzE3MDkwODc1MDMuNDU=#key=e6af876a0a75f2c1d2b4ab878f933050>  FAQ<https://www.godaddy.com/help/report-email-with-advanced-email-security-40813>  GoDaddy Advanced Email Security, Powered by INKY<https://www.inky.com/protection-by-inky>

John,
Here is the SD-WAN scenario why simple Nexthop cannot do the job:

Suppose one SD-WAN edge has 3 client routes (#1, #2, #3)  and multiple underlay paths (public unsecure paths & private secure paths) to other peer nodes:
1) The client route #1 needs to be forwarded by a private path (such as network service provider's MPLS path),
2) The  client route #2 (at the same nextHop) can be forwarded by IPsec SA or MPLS (i.e., the Hybrid tunnel described in the document)
3) The client route #3 can be forwarded by unsecure path (such as web browsing traffic)

When this SD-WAN edge advertises Client Route #1, it needs to indicate the necessary encapsulation type to be MPLS.
When this SD-WAN edge advertises the Client Route #2, it needs to indicate the encapsulation type to be SD-WAN-Hybrid.
When the SD-WAN edge advertises the Client Route #3, it only needs to indicate the NextHop.

Linda

-----Original Message-----
From: John Scudder <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 27, 2024 6:37 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: Robert Raszuk <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: Re: Error in draft-ietf-idr-sdwan-edge-discovery use of Encapsulation Extended Community

Hi Linda,

> On Feb 27, 2024, at 7:12 PM, Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:
>
> Our intent of using Encapsulation Extended Community is to indicate
> that Client routes need to be forwarded by a tunnel, but there is too much information about the  Tunnel attributes to be included in the Client route advertisement and those attributes are associated with the WAN ports (instead with Client Routes).
>
> We need to interpret the "barebones" as a hook to inform the peer nodes to use information carried in  the second UPDATE to establish the tunnel for the Client routes.

I don’t see why you need any indication beyond the next hop. It’s both necessary (so that the recipient can find the route that has the tunnel information) and sufficient (because once it finds that route, it will see it includes tunnel information). This is exactly what Section 8 explains.

> I don't understand why RFC9012 doesn't allow this. What harm does it cause?

If RFC 9012 was still in draft, and you had suggested the idea above as a change to the spec, we could have had this discussion. But it’s moot now — RFC 9012 is what it is, and what it is, very specifically and precisely does *not* allow a tunnel type that has mandatory sub-TLVs to be used as an Encapsulation Extended Community, and does *not* require any additional information beyond the next hop to “glue” a client route to an underlay route that has a tunnel attribute.

If you want to use RFC 9012, it is what it is. If you think (for some reason I don’t yet understand) that you need to have an extra “hook” beyond the next hop, you can specify some new thing to do that.

—John