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

[Susan Hares <[e-mail]>]

Linda and John:

Thank you for digging into these points.!!  The first insertion of the Tunnel-Encapsulation Attribute was painful and took lots of work.  These new tunnel types require considerable thought.

Let’s pick up the attached email thread.  Please look at my discussion after I sent my second summary message.  I am looking at the email thread before I send my third message.

The client shown in section 3.3 have

  *   AFI/SAFI =  (1/128),
  *   Color = 4 octet value (site-identifier) [Extended Community]
  *   Prefixes 10,1.1/24, 20.1.1/24, Next-Hop - 2.2.2.2

If you used the Tunnel Encaps attribute, it would contain:

  *   Tunnel type = SD-Wan-Hybrid
  *   Egress-EndPoint TLV = 2.2.2.2

The Client routes simply look like a logical tunnel (from 1.1.1.1 to 2.2.2.2).

Note: Please note the TEA would have 1 TLVs – the Egress Endpoint.
The SDWAN procedures need to clearly state what happens if Color is specified in TEA (subTLV Color) + Extended Community [Color-EC}.
This issue requires a revision to the draft-ietf-sdwan-edge-discovery text.

The question is whether it is valid to use TEA with 1/128 (VPN Labeled Unicast)

[RFC9012] states”
6.  Semantics and Usage of the Tunnel Encapsulation Attribute

   The BGP Tunnel Encapsulation attribute MAY be carried in any BGP
   UPDATE message whose AFI/SAFI is 1/1 (IPv4 Unicast), 2/1 (IPv6
   Unicast), 1/4 (IPv4 Labeled Unicast), 2/4 (IPv6 Labeled Unicast),
   1/128 (VPN-IPv4 Labeled Unicast), 2/128 (VPN-IPv6 Labeled Unicast),
   or 25/70 (Ethernet VPN, usually known as EVPN).  Use of the Tunnel
   Encapsulation attribute in BGP UPDATE messages of other AFI/SAFIs is
   outside the scope of this document.

Note: This is John’s concern. There are two questions to ask:


1.  Is the usage (NLRI + TEA (Type = SDWAN-Hybrid, TLV=Egress Endpoint) valid according to RFC9012.

If you do not specify encapsulation in the customer route (NLRI (1/128) + TEA(tunnel = SDWAN-Hybrid, Egress Endpoint), then no procedures are directly broken.

At least section 6, 8

RFC 9012 (section 6)

   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.



   Sending a packet through a tunnel always requires that the packet be

   encapsulated, with an encapsulation header that is appropriate for

   the tunnel type.  The contents of the tunnel encapsulation header may

   be influenced by the Encapsulation sub-TLV.  If there is no

   Encapsulation sub-TLV present, the router transmitting the packet

   through the tunnel must have a priori knowledge (for example, by

   provisioning) of how to fill in the various fields in the

   encapsulation header.



2.  How is the client usage different BGP SID-Prefix [RFC8669]?

RFC8669:

   The BGP Prefix-SID attribute defined in this document can be attached

   to prefixes from Multiprotocol BGP IPv4/IPv6 Labeled Unicast

   ([RFC4760] [RFC8277]).  Usage of the BGP Prefix-SID attribute for

   other Address Family Identifier (AFI) / Subsequent Address Family

   Identifier (SAFI) combinations is not defined herein but may be

   specified in future specifications.

The BGP SID-Prefix identified a logical tunnel (SR Policy) for AFI/SAFI Labeled Unicast [RFC4760] or [RFC8277].

draft-ietf-idr-sr-policy-safi – will pass the underlay information for this logical tunnel (SR Policy)

Why is the use of BGP Prefix-SID RFC8669 valid,  and the SD-WAN-Hybrid Tunnel invalid?

This is not a light question. Consider based on the information contained - why one is valid and the other is invalid.

  *   Is it because the BGP prefix-SID is in another attribute outside the TEA?
  *   Is that really different?  The SR Policy tunnel type of the TEA passes the SID

It would be good to hear why John thinks the use case is invalid.

Sue

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

John, See the answers below:  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌  ‌
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzM4MWNjNDBlYTU2ZDUxYmFkNzhiZWQ2ZDA5NjI0NGY2LzE3MDkwNzY5MjAuMjQ=#key=6180d353fbc8c3f9aee37c35f9153722>  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,

See the answers below:

-----Original Message-----
From: John Scudder <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 27, 2024 5:10 PM
To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Cc: [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,

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]<mailto:[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]<mailto:[e-mail]>>
> Sent: Tuesday, February 27, 2024 2: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.
>  [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