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

[Robert Raszuk <[e-mail]>]

Hi Sue,

Yes this was my first thought as well after reading John's note.

However, as John observed already we need to be sure that we can not use
the next hop itself. Either explicitly from MP-REACH or if ever needed to
cross domains - implicitly via Multi-Next-Hop new attribute.

Thx,
R.

On Wed, Feb 28, 2024 at 11:04 PM Susan Hares <[e-mail]> wrote:

> John and Linda:
>
>
>
> Client routes use of the TEA just Tunnel Egress Endpoint.
>
> The tunnel endpoint identifies a tunnel of type  SD-WAN-Hybrid.
>
>
>
> The details of this internal tunnel are passed in the SD-WAN NLRI + TEA.
>
>
>
> If this usage is clearly specified for the Tunnel type =15,
>
> It does not seem to break the text of RFC9012.
>
>
>
> The draft-ietf-idr-sdwan-edge-discovery procedures need to differentiate
> the
>
> Processing for NLRI SAFI (1/128 or 2/128)  versus  SD-WAN SAFI.
>
> (IMO – the draft-ietf-idr-sdwan-edge-discovery needs to be adjust to make
> this clear. )
>
>
>
> Sue
>
>
>
>
>
> *From:* John Scudder <[e-mail]>
> *Sent:* Tuesday, February 27, 2024 6:51 PM
> *To:* Linda Dunbar <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: Error in draft-ietf-idr-sdwan-edge-discovery use of
> Encapsulation Extended Community
>
>
>
>
>
> Hi Linda,
>
>
>
> That’s not how the Encapsulation Extended Community is defined. Please see
> RFC 9012 Section 4.1. As I wrote in my first note in this thread, it looks
> like what you should be specifying for client routes, is that they do NOT
> include an Encapsulation Extended Community, and that they DO recurse (via
> their next hop) to another route that carries the tunnel information (you
> call this “UPDATE 2”).
>
>
>
> If, after reading RFC 9012 Section 4.1 you still think Encapsulation
> Extended Community can be used in the way you’ve written, I’d be interested
> in knowing exactly why, because we tried to be clear in 9012 that an
> Encapsulation Extended Community is exactly and only an alias for a
> “barebones Tunnel TLV”, i.e. I Tunnel TLV that has no sub-TLVs other than
> Tunnel Egress Endpoint.
>
>
>
> —John
>
>
>
> > On Feb 27, 2024, at 6:35 PM, Linda Dunbar <[e-mail]>
> wrote:
>
> >
>
> >
>
> > John,  See the answers below:  -----Original Message-----
>
> > From: John Scudder <[e-mail]>
>
> > Sent: Tuesday, February 27, 2024 5:10 PM
>
> > To: Linda Dunbar <[e-mail]>
>
> > Cc: [e-mail]; [e-mail]
>
> > Subject: Re: Error in draft-ietf-idr-sdwan-edge-discovery use of
> Encapsulation Extended Community
>
> >  Hi Linda,
>
> >  What are the semantics of a Tunnel Encapsulation path attribute, with
> tunnel type = SD-WAN-Hybrid, and no sub-TLVs other than egress endpoint?
>
> >  [Linda] There ARE sub-TLVs under the Tunnel Encapsulation Path
> Attribute, which specifies the detailed attributes associated with the
> IPsec tunnel for the SD-WAN Edge’s WAN Ports. I am trying to say that there
> are NO sub-TLVs under the client routes UPDATE (which has Encapsulation
> Extended Community)
>
> >  draft-ietf-bess-bgp-sdwan-usage-20 describe how to use BGP,  stating
> There are two UPDATE2:
>
> > 1) UPDATE 1 is for Client Route UPDATE (which follows the traditional
> BGP-based client routes)
>
> > 2) UPDATE 2 for the Edges to advertise the WAN port information. In the
> UPDATE2, the Route prefix is the WAN port address.
>
> >  draft-ietf-idr-sdwan-edge-discovery-12 specifies the detailed BGP
> extension for UPDDATE2. The UPDATE 2 has Tunnel Encapsulation Path
> Attribute with a new NLRI for Underlay Tunnel Update and the sub-TLVs
> specified in the document.  Linda  —John
>
> >  > On Feb 27, 2024, at 6:03 PM, Linda Dunbar <[e-mail]>
> wrote:
>
> > > > > [External Email. Be cautious of content]
>
> > > > > John  The  Encapsulation Extended Community is only in the client
> routes BGP UPDATE, which is the BGP-based VPN/EVPN client routes UPDATE
> message. There are no sub-TLVs added. Section 6's first paragraph states
> the Client Route UPDATE follows the BGP-based VPN/EVPN client route UPDATE
> message..  The sub-TLVs discussed in the draft are under the Tunnel
> Encapsulation Path attribute in a separate UPDATE (U2 in the document)
> which DOES NOT have Encapsulation Extended Community for SD-WAN edges to
> advertise the information about their WAN ports. Please see below for the
> details.
>
> > >  p.s. Are you referring to version-20?   Linda
>
> > > -----Original Message-----
>
> > > From: John Scudder <[e-mail]>
>
> > > Sent: Tuesday, February 27, 2024 2:42 PM
>
> > > To: [e-mail]
>
> > > Cc: [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.
>
> > >  [Linda] That is just an example for needing a different Tunnel Type >
> in the Encapsulation Extended Community
>
> > >  - 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).
>
> > > [Linda] That is our understanding as well. This document doesn’t
> specify additional sub-TLVs to be added to the BGP UPDATE with the
> Encapsulation Extended Community.
>
> > >  - 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.
>
> > > [Linda] All those sub-TLVs are NOT used with Encapsulation Extended
> Community. Those Sub-TLVs are under the Tunnel Encapsulation Path attribute
> in a separate UPDATE (U2 in the document) for SD-WAN edges to advertise the
> information about their WAN ports. There is no Encapsulation Extended
> Community included when an edge node advertises its WAN port information.
> Please see Section 5 for BGP Walk Through details.
>
> > >  - 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):
>
> > >  [Linda] The Client Route UPDATE can use the Extended Community to
> indicate that their associated tunnel information is advertised by separate
> UDPATE. The purpose is to reduce the size of the Clint Route UPDATE message
> size because the tunnel associated with IPsec has a lot of information to
> be exchanged. They don’t change at the same frequency as the Client Routes.
>
> > > ```
>
> > > 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).
>
> > > [Linda] The Client Route Update message is NOT using RFC9012. Here is
> to indicate that another type might be needed. As this is a BGP usage
> draft, with the intent to explain how to use BGP, with the justification to
> BGP extension later.  - But RFC 9012 §4.1 told us we can’t use a tunnel
> type with sub-TLVs as an Encapsulation Extended Community!
>
> > > [Linda] The Client Route Update message is NOT using RFC9012.
>
> > >  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.
>
> > > [Linda] You are correct. The Tunnel Encapsulation Attribute is used to
> carry the SD-WAN-Hybrid for SD-WAN edge nodes to advertise the WAN ports
> (i.e. the under route).
>
> > >    Thanks,
>
> > >  —John
>
>
>
>
>