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

[Susan Hares <[e-mail]>]

Sorry for the SPAM, but I realized this response did not have the correct header.  This header lets the IESG catch it in their email filters.

Sue

From: Susan Hares
Sent: Wednesday, February 28, 2024 3:44 PM
To: [e-mail]
Cc: John Scudder <[e-mail]>; [e-mail]; Andrew Alston <[e-mail]>
Subject: FW: Error in draft-ietf-idr-sdwan-edge-discovery use of Encapsulation Extended Community

Per John’s request -  I am returning this message to the main IDR list.

The point of this message is that SDWAN Underlay mechanisms [NLRI + TEA] are similar to the SR Policy Underlay [NLRI + TEA]

SD-WAN-Hybrid tunnel – abides by the [RFC9012] TEA restrictions for having the Tunnel Egress Endpoint + validation of route.
SR Policy tunnel – does not abide by the [RFC9012] TEA restrictions for having the

[RFC9012] states:

   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.

The SDWAN underlay SAFIs and the SR Policy tunnel are outside [RFC9012] usage.

John’s concerns break down into two categories of use of TEA:

  *   Category 1: TEA with the following NLRIs [1/1, 2/1,1/4, 2/4, 1/128, 2/128, 2/70
  *   Category 2: TEA with other NLRIs.
     *   SR Policy [1/73, 2/73] [draft-ietf-idr-sr-policy-safi]
     *   SD-WAN [1/74, 2/74] [draft-ietf-idr-sdwan-edge-discovery]

SDWAN – examples show category 1 (client routes + TEA) and category 2 (SD-WAN Underlay routes)
SR Policy (draft-ietf-idr-sr-policy-safi) – has only category 2

This message provides the details behind the comparison.  I am grateful for having to do the comparison since it helped me find weak areas in both drafts (draft-idr-sr-policy-safi, and draft-ietf-idr-sdwan-edge-discovery).

The next message will consider whether based on [RFC9012]  text the SDWAN can

  1.  Use the TEA to Identify SDWAN-Hybrid Logical tunnels  (Egress EndPoint address)
  2.  Create the details in an underlay associated with the Egress EndPoint address.

The question for people to consider is

  *   RFC8669 – allowed logical tunnels (identified by Prefix-SID) to be attached to MP-BGP IPv4/Ipv6 Labeled Unicast [RFC4760][RFC8277]
     *   (  The BGP Prefix-SID attribute defined in this document can be attached to prefixes from Multiprotocol BGP IPv4/IPv6 Labeled Unicast  ([RFC4760] [RFC8277])).
  *   SR Policy (draft-ietf-idr-sr-policy-safi) – is created the underlay.

How is this different than the SD-WAN use?

Sue

PS  - It takes me time to write the detailed message.



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

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.


From: Susan Hares
Sent: Wednesday, February 28, 2024 3:01 PM
To: 'Linda Dunbar' <[e-mail]<mailto:[e-mail]>>; John Scudder <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; Keyur Patel <[e-mail]<mailto:[e-mail]>>; Gyan Mishra <[e-mail]<mailto:[e-mail]>>
Subject: RE: Error in draft-ietf-idr-sdwan-edge-discovery use of Encapsulation Extended Community - Offline discussion message #1

Linda, John, and Co-authors:

I am moving this offline due to IDR WG LC this week.  As indicated in my long message, I am structuring this discussion in the following steps:


  1.  Client Routes  Tunnel Encaps Attribute with SD-WAN Hybrid – is just another tunnel [Last message]



The SubTLV on IP-Sec  Sub-TLVs gives information security encapsulation over the logical tunnel.

The Extended Port Sub-TLV gives information about the links bound into the logical tunnel.


  1.  SDWAN Underlay routes mechanism are similar to the SR Policy underlay [This message]



SD-WAN NLRI (Port-id, Color, N) + TEA  (SD-WAN-Hybrid)  is similar to SR Policy Mechanisms (draft-ietf-idr-sr-policy-safi) [this email message]

SR Policy usage of SR Policy NLRI + SR Policy TEA (tunnel type = SR Policy)  ~= SD-WAN NLRI + SD-WAN-Hybrid tunnel.


  1.  What Should go Client routes versus Infrastructure routes?  [next email message]
Option 1: Full TEA
Option 2: TEA with just Hybrid Tunnel identifier

Please let me know if I am helping clarify the issues.

Sue

=================
Recap from last message:

SD-WAN NLRI – giving the (Port-ID, Color, N) + TEA attribute

  *   NLRI – identifies the Hybrid tunnel + Port  (Port-ID, Color, N) –
Port-Id – uniquely identifies sub-tunnel within the logical tunnel (zero – means all sub-tunnels)
Logical tunnel-ID -  (C = Color, N = Tunnel End Pont)

  *   TEA – provides updates per port.  A special case (address = 0/0) allows for the updates to apply to all ports.

SR Policy Tunnel is similar in format:

Use-1:  SR Policy tunnel (draft-ietf-idr-sr-policy-safi) (tunnel-type 15)
SR-Policy logical tunnels are identified by SR Policy NLRI.  The sub-tunnels are identified by Tunnel Encaps Tunnel type.

BGP Definition from  [draft-ietf-idr-sr-policy-safi-00] (was te-policy)

  *   SR Policy NLRI (Distinguisher, Policy-Color, Endpoint) [AFI/SAFI = 1/73, 2/72]
     *   Distinguisher – 4 octet uniquely identifying the Policy
     *   Color – 4 octet color
     *   Endpoint -  Address (IPv4, IPv6) or zero (all per color)

SR-Policy Identifier:  [Headend, Color, EndPoint] – Uniquely identifying the Policy
SR Candidate Path Route identifier:  [Protocol, Originator, Discriminator] – for BGP = [BGP, Node-Originating, discriminator]  (section 2.6 of RFC9256]



  *   SR Policy Tunnel-Encaps Attribute (23)

 Tunnel Type: SR Policy (15)

  TLVS:

     *   Binding SID – (optional, only 1)  SID that uniquely identifiers active candidate path [processed by SRPM]
     *   SRv6 Binding SID – (optional, multiple) - SRv6 Binding SID identifies SR Candidate Path.
     *   Preference (optional, only 1) – preference for a particular SR Candidate Path
     *   Priority (optional, only 1) – order in which the SR Policy [not the SR Candidate Path Priority)
     *   Policy Name (optional, only 1) – symbolic name for SR Policy
     *   Policy Candidate Path Name (optional, 1) – symbolic name for SR Candidate Path
     *   Explicit NULL Label Policy (optional, 1) – [Encapsulation policy) Null Label stack handling for unlabeled IPv4 traffic and unlabeled IPv6 traffic when steering over SR-MPLS
     *   Segment List – (optional, multiple) – Each segment-list may have many segments + a weight for the segment-list. Currently only segment types A (SR-MPLS) + B (SRv6 SID)
        *   Sub-TLVS – segment list + Weight

Common concepts between draft-ietf-idr-sr-policy-safi  + draft-ietf-idr-sdwan-edge-discovery


  *   NLRI identifies the logical end of the hybrid logical tunnel.
     *   SR Policy NLRI  (D, C, E)  identifies the headend of the tunnel – from which the segment list traverse to the egress point.  No validation via TEA [RFC9012] procedures. Only the SRPM validates the tunnel’s existence.
     *   SD-WAN identifies (Port-id, C, E) – identifies egress point of the tunnel which decapsulates the tunnel information.  TEA procedures validate end-point of tunnel.
  *   TEA provides additional details on the logical tunnel
     *   SR Policy tunnel type
        *   For SR-MPLS (logical tunnel) - SR Candidate Route is identified by a SRv6 Binding Sid.   Requires Segment list + Explicit Null level for appropriate functioning.
        *    For SR-v6 (logical tunnel) – SR Candidate Route is identified by SR Binding SID.     Logical tunnel is augmented by SRv6 behaviors.  Requires Segment list + Logical behaviors.
        *   For all – parameters for calculation in the SRPM.
     *   SD-WAN tunnel type
        *   For MPLS – identifies link,
        *   For IP – Identifies the port

Shepherd’s comment on Problems in the draft-ietf-idr-sr-policy-safi issues:

  *   NLRI’s
     *   NLRI Distinguisher – defined as “4 octet uniquely identifying the Policy” [draft-ietf-idr-sr-policy-safi] instead of the “The headend is the node where the policy is instantiated/implemented.” [section 2.1, RFC9252]
     *   SR Policy priority – Why is SR Policy priority on the Candidate Paths rather than the SR Policy? Is there some operational issue?
  *   TEA definitions:
     *   Each SR Policy Candidate paths – may have multiple segment list TLVs
     *   Multiple SR Policy Candidate Paths with only 1 active Candidate path.
        *   SRv6 Binding SID – indicates that multiple SRv6 Binding SIDs are possible with the rest of the parameters common.
        *   Based on this data, the SRPM may create many logical sub-tunnels within 1 SR Candidate Path.
     *   Debugging of the SR Candidate Paths (NLRI + TEA) does not have direct links between BGP packets --- and Active candidate paths.
        *   How does debugging work?
        *   What happens if information from BGP --> SRPM is not correctly copied?  What link?

Author’s comments on the draft-ietf-idr-sdwan-edge-discovery

  *   The usage of  SD-WAN NLRI + TEA are similar to SR Policy Candidate Routes.
     *   SDWAN Tunnel - uses validation of path to Egress Node of tunnel.
     *   SR Policy requires – SRPM must be used to validate SR Candidate Paths
  *   Question: Are the sub-tunnels identified clearly in the Extended Port Attribute? Do we need sub-tunnel identifiers

==========================
Definitions from RFC9256:

SR Policy [RFC9256] – logical tunnel (section 2)
“The general concept of SR Policy provides a framework that enables the instantiation of an ordered list of segments on a node for implementing a source routing policy for the steering of traffic for a specific purpose (e.g., for a specific Service Level Agreement (SLA)) from that node.”

Identification of SR Policy:  [RFC9256] – [Headend, Color, EndPoint] (section 2.1)
An SR Policy MUST be identified through the tuple <Headend, Color, Endpoint>. In the context of a specific headend, an SR Policy MUST be identified by the <Color, Endpoint> tuple. The headend is the node where the policy is instantiated/implemented. The headend is specified as an IPv4 or IPv6 address and MUST resolve to a unique node in the SR domain [RFC8402].

SR Policy  a logical tunnel that combines multiple sub-tunnels. [RFC9256]
An SR Policy is associated with one or more candidate paths. A candidate path is the unit for signaling of an SR Policy to a headend via protocol extensions like the Path Computation Element Communication Protocol (PCEP) [RFC8664<https://www.rfc-editor.org/rfc/rfc9256.html#RFC8664>] [PCEP-SR-POLICY-CP<https://www.rfc-editor.org/rfc/rfc9256.html#I-D.ietf-pce-segment-routing-policy-cp>] or BGP SR Policy [BGP-SR-POLICY<https://www.rfc-editor.org/rfc/rfc9256.html#I-D.ietf-idr-segment-routing-te-policy>].

Identification of a Candidate Path [RFC9256] -  A candidate path is identified in the context of a single SR Policy. The tuple <Protocol-Origin, Originator, Discriminator> uniquely identifies a candidate path.
[note: BGP, Node-Originating, discriminator]

BSID - Each candidate path MAY be defined with a BSID.  The BSID of an SR Policy is the BSID of its active candidate path.

  *   Candidate paths of the same SR Policy SHOULD have the same BSID.
  *   Candidate paths of different SR Policies MUST NOT have the same BSID.

Priority of an SR Policy (section 2.12, RFC9256)
“Upon topological change, many policies could be re-computed or revalidated. An implementation MAY provide a per-policy priority configuration. The operator may set this field to indicate the order in which the policies should be re-computed. Such a priority is represented by an integer in the range (0, 255) where the lowest value is the highest priority. The default value of priority is 128.

[Section 2.2] An SR Policy may comprise multiple candidate paths received from the same or different sources. A candidate path MAY be signaled with a priority value. When an SR Policy has multiple candidate paths with distinct signaled non-default priority values and the SR Policy itself does not have a priority value configured, the SR Policy as a whole takes the lowest value (i.e., the highest priority) amongst these signaled priority values.

[Section 4.4] Use of Explicit Null Label Policy:
When steering unlabeled IPv6 BGP destination traffic using an SR Policy composed of segment list(s) based on IPv4 SIDs, the Explicit Null Label Policy is processed as specified in [BGP-SR-POLICY<https://www.rfc-editor.org/rfc/rfc9256.html#I-D.ietf-idr-segment-routing-te-policy>] (now draft-ietf-idr-sr-policy-safi-00)
When an "IPv6 Explicit NULL label" is not present as the bottom label, the headend SHOULD automatically impose one. Refer to Section 8<https://www.rfc-editor.org/rfc/rfc9256.html#Steering> [RFC9256] for more details.

Definitions from [draft-ietf-idr-sr-policy-safi-00

  *   SR Policy SAFI - Distinguisher: 4-octet value uniquely identifying the policy in the context of <color, endpoint> tuple. The distinguisher has no semantic value and is solely used by the SR Policy originator to make unique (from an NLRI perspective) both for multiple candidate paths of the same SR Policy as well as candidate paths of different SR Policies (i.e. with different segment lists) with the same Color and Endpoint but meant for different headends.
  *   “The SRv6 Binding SID sub-TLV is used to signal the SRv6 Binding SID related information of an SR Policy candidate path. It enables the specification of the SRv6 Endpoint Behavior [RFC8986] to be instantiated on the headend node. The contents of this sub-TLV are used by the SRPM as described in section 6 in [RFC9256].  The SRv6 Binding SID sub-TLV is optional. More than one SRv6 Binding SID sub-TLVs MAY be signaled in the same SR Policy encoding to indicate one or more SRv6 SIDs, each with potentially different SRv6 Endpoint Behaviors to be instantiated.”
  *   Policy Priority SubTLV -  An operator MAY set the Policy Priority sub-TLV to indicate the order in which the SR policies are re-computed upon topological change. The contents of this sub-TLV are used by the SRPM as described in section 2.12 of [RFC9256<https://www.ietf.org/archive/id/draft-ietf-idr-sr-policy-safi-00.html#RFC9256>].



From: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, February 27, 2024 6:04 PM
To: John Scudder <[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

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 paragrap
External ([e-mail]<mailto:[e-mail]>)
  Report This Email<https://protection.inkyphishfence.com/report?id=bmV0b3JnMTA1ODY5MTIvc2hhcmVzQG5kemguY29tLzdhMzQyYmVkMzM4MDhlODk2NWM2ZjAzN2I4ZGUzZDJjLzE3MDkwNzUwMjQuOTY=#key=8af5eb05b3d0f7cdb95fe5e54f3da7cb>  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

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