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

Hi John

Yes that is what I was thinking to mark tunnel affinity.  Yep that would be
difficult since it’s separate from the tunnel endpoint TEA.  How to
correlate back to the tunnel endpoint would be tricky.

RFC 9012 deprecates RFC 5512 extended community but kept section 4.1 for
backwards compatibility to RFC 5512 and thus was encoded as a bare bones
TLV and not allowing sub TLVs.  In cases such as SD WAN draft and maybe
future use cases it would have been nice to allow for sub TLVs and not have
that restriction.

It seems the sub TLV restriction maybe was made for backwards compatibility
to RFC 5512?  What do you think?  Or maybe not.

Just wondering if would be worth an errata to lift the restriction since it
makes it difficult for the extended community to be useful.

I guess as you mentioned RFC 9012 could be updated adding a new TEA
extended community path attribute for future use cases such as this one.

Kind Regards

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*

On Wed, Feb 28, 2024 at 10:58 AM John Scudder <jgs@juniper.net> wrote:

> Hi Gyan,
>
> You mean, to mark tunnel-type affinity? I'm sure you could do that, but I
> don't see an advantage, especially since the tunnel endpoint information
> isn't going to be contained in ELC so the scope constraint feature doesn't
> end up covering the whole solution anyway. Also, as a practical matter, ELC
> hasn't reached RFC yet, so it would potentially be a downref, whereas
> extended communities are long-established.
>
> —John
>
> On Feb 28, 2024, at 10:51 AM, Gyan Mishra <hayabusagsm@gmail.com> wrote:
>
>
>
> Hi Linda and John
>
> What if you use RCA in place of encapsulation extended community. This
> draft was the original ELC update to fix route leak issue and then was made
> generic next hop draft with ELC being the first use case.
>
> https://datatracker.ietf.org/doc/html/draft-ietf-idr-entropy-label-13
> <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-idr-entropy-label-13__;!!NEt6yMaO-gk!AbISHJTE2qZCfyfd3XGJSpgm968HdsNchYUKdZDzEQfGFNBWHOEJFCHL4WCdzPDY7fkeM1rLNwzs3puW_g$>
>
> John
>
> You are pretty familiar with this draft.  What do you think?
>
> Kind Regards
>
>
>
> <https://urldefense.com/v3/__http://www.verizon.com/__;!!NEt6yMaO-gk!AbISHJTE2qZCfyfd3XGJSpgm968HdsNchYUKdZDzEQfGFNBWHOEJFCHL4WCdzPDY7fkeM1rLNwyrvCsh7Q$>
> *Gyan Mishra*
> *Network Solutions A**rchitect *
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
>
> *M 301 502-1347 *
>
>
>
> On Tue, Feb 27, 2024 at 11:12 PM John Scudder <jgs=
> 40juniper.net@dmarc.ietf.org> wrote:
>
>> Well, you could use light red and dark red. Or you could use different
>> next hop addresses. Or you could invent a new kind of extended community to
>> indicate tunnel affinity. But Encapsulation Extended Community simply isn’t
>> defined to do what you want.
>>
>> —John
>>
>> On Feb 27, 2024, at 11:01 PM, Linda Dunbar <linda.dunbar@futurewei.com>
>> wrote:
>>
>> 
>>
>> [External Email. Be cautious of content]
>>
>>
>> John,
>>
>>
>>
>> The Color Extended Community alone is not enough.
>>
>> For example, one SD-WAN edge has 5 routes (Route #1 ~#5) with 3 types of
>> underlay paths (IPsec over Internet, SRv6 , and unsecure internet).
>>
>>
>>
>> Route #1 &  #2 have to be forwarded by SRv6, but Route #1 needs to use
>> the SRv6 Red Color paths, Route #2 needs to use the SRv6 Blue Color paths.
>>
>>
>>
>> In conclusion: SD-WAN routes (or customer traffic) need to have both
>> Encapsulation Extended Community and the Color Extended Community.
>>
>>
>>
>> Linda
>>
>>
>>
>> *From:* John Scudder <jgs@juniper.net>
>> *Sent:* Tuesday, February 27, 2024 9:14 PM
>> *To:* Linda Dunbar <linda.dunbar@futurewei.com>
>> *Cc:* Robert Raszuk <robert@raszuk.net>; idr@ietf.org;
>> draft-ietf-idr-sdwan-edge-discovery@ietf.org
>> *Subject:* Re: Error in draft-ietf-idr-sdwan-edge-discovery use of
>> Encapsulation Extended Community
>>
>>
>>
>> You could accomplish that using the Color Extended Community. See
>> second-last paragraph of Section 8.
>>
>>
>>
>> —John
>>
>>
>>
>> On Feb 27, 2024, at 9:31 PM, Linda Dunbar <linda.dunbar@futurewei.com>
>> wrote:
>>
>> 
>>
>> *[External Email. Be cautious of content]*
>>
>>
>>
>> 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 <jgs@juniper.net>
>> Sent: Tuesday, February 27, 2024 6:37 PM
>> To: Linda Dunbar <linda.dunbar@futurewei.com>
>> Cc: Robert Raszuk <robert@raszuk.net>; idr@ietf.org;
>> draft-ietf-idr-sdwan-edge-discovery@ietf.org
>> 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 <linda.dunbar@futurewei.com>
>> 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
>>
>>
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/idr__;!!NEt6yMaO-gk!AbISHJTE2qZCfyfd3XGJSpgm968HdsNchYUKdZDzEQfGFNBWHOEJFCHL4WCdzPDY7fkeM1rLNwxGOhWNWg$>
>>
>
>