[bess] Re: John Scudder's Discuss on draft-ietf-bess-bgp-sdwan-usage-20: (with DISCUSS and COMMENT)

[Linda Dunbar <[e-mail]>]

John,

We are revising draft-ietf-bess-bgp-sdwan-usage-24 in response to the Directorate review of draft-ietf-idr-sdwan-edge-discovery, which recommended maintaining a separate draft to document SD-WAN use cases and requirements rather than merging its content into draft-ietf-idr-sdwan-edge-discovery. https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/

Given the limited work on SD-WAN within the IETF, having a dedicated document to describe SD-WAN use cases and requirements can establish a baseline to guide not only discussions on BGP protocol extensions in the IDR but also related efforts, such as draft-ietf-rtgwg-multi-segment-sdwan in the RTGWG and draft-sheng-idr-gw-exchange-in-sd-wan.

While BGP and IPsec are well-established technologies, their application in SD-WAN environments presents unique challenges, including scalability, traffic segmentation, and multi-homing. This document aims to establish a common foundation to support and guide the  SD-WAN-related efforts in IETF.

Here are the resolutions to your comments. Please let us know if they are satisfactory.

Linda
-----Original Message-----
From: John Scudder <[e-mail]>
Sent: Wednesday, April 10, 2024 2:14 PM
To: Linda Dunbar <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: John Scudder's Discuss on draft-ietf-bess-bgp-sdwan-usage-20: (with DISCUSS and COMMENT)

Hi Linda,

Looking at the diff between versions 20 and 22 I continue to have concerns.

I don’t think I’ve gotten much in the way of responses to my first and second points, but to a large extent, these are for the AD and WG chairs; they can redirect back to the authors as needed, but let’s not focus on them right now. The third and fourth points are squarely in the authors’ court.

Regarding my third DISCUSS point, about Section 5.2, in your revised version you’ve added,

     Note: The IPsec Tunnel Type specified in RFC5566 is obsolete. A
     new tunnel type is needed to represent the IPsec Tunnel underlay
     path.

I don’t think it’s a good idea for us to be publishing RFCs that are effectively obsolete on delivery. If a new tunnel type is needed, then that work should be done before you publish a solution that depends on it! For that matter, Section 5.3 in the revision now has,

[Linda] We have made the change in the version-24 as below:
       “Note: The IPsec Tunnel Type specified in RFC 5566 is obsolete. To indicate that the prefixes 192.0.2.4/30 and 192.0.2.8/30 are carried using a hybrid of IPsec underlay paths, a new tunnel type, such as one designed for SDWAN-Hybrid environments, is required. The specific definition and mechanism of such a tunnel type are expected to be addressed in future specifications.”


   UPDATE #1a for the client prefix 192.0.2.4/30:

     - MP-NLRI Path Attribute:
         192.0.2.4/30
         Nexthop: 192.0.2.2 (C-PE2)
     - Encapsulation Extended Community: TYPE = IPsec
     - Color Extended Community: RED

Which has the same problem (but no disclaimer). It also recurs in Section 5.4, unchanged from the previous versions.
[Linda] Change to IPsecSA with a note:
      “Note: The term "IPsecSA" is used here solely to illustrate the need for a new tunnel type. The specific definition and mechanism for such a tunnel type are expected to be defined in future specifications. “

There’s also a second problem, which is more critical than the (already serious) problem of using an obsolete type in a new RFC. That is, you don’t say anywhere what the intended *semantics* of the "Encapsulation Extended Community: TYPE = IPsec” are. What I understood (but I might be wrong) from our previous conversation is that it’s intended as a hint that when resolving the client route, if there are multiple tunnel types associated with 192.0.2.2, then the IPsec tunnel type should be preferred. As we discussed previously, I don’t think this is needed, RFC 9012 already has all the machinery you need using Color Extended Community. (Keep in mind that a thing can have more than one Color Extended Community associated with it.)

[Linda] The new IPsecSA tunnel type explicitly signals the intended semantics for using IPsec tunnels in specific scenarios. As this is an informational document on use cases and requirement, it doesn’t define the tunnel type. While RFC 9012’s Color Extended Community provides a robust mechanism for encoding preferences, IPsecSA adds an essential layer of specificity for environments requiring strict adherence to IPsec-based encapsulation policies.

While I don’t insist that you follow the approach I suggest, I do think the spec has to be clear about what the "Encapsulation Extended Community: TYPE = IPsec” (or its replacement) is *for*, since it’s clearly *not* for what RFC 9012 documents the semantics of an Encapsulation Extended Community to be. Right now, this is left up to the imagination of the reader. Leaving things to the imagination of the reader is the opposite of what an RFC should do.

[Linda] We agree. A new IPsecSA tunnel type in the Encapsulation Extended Community is intended to explicitly indicate a preference or requirement for using IPsec SA for traffic encapsulation in specific scenarios.


Regarding my fourth DISCUSS point, about Section 3.1.5, my understanding from our conversation is that the security model is based on route reflectors having configured (possibly by a management system of course) policy that controls what PEs are allowed to receive what routes. Here’s your updated paragraph that makes it more explicit (thank you):

   BGP is well suited for this purpose. RFC4684 has specified the
   procedure to constrain the distribution of BGP UPDATE to only a
   subset of nodes. Route-Reflector (RR) [RFC4456], as an integral
   part of the SD-WAN controller, has the policy governing
   communication among peers. The RR only propagates the BGP UPDATE
   from an edge to others within the same SD-WAN VPN.

I continue to wonder why you need RFC 4684 at all, given that you’re telling me that the “Route-Reflectors… has the policy governing communication among peers”, that is, it already *knows* where the routes are supposed to go, so why does it need RFC 4684 to tell it?
[Linda]  The reference to RFC4684 was removed in v-23. The updated paragraph is:
      “BGP is well suited for this purpose. A Route-Reflector (RR) [RFC4456], integrated into the SD-WAN controller, has the policy governing the communication among peers. The RR ensures that BGP UPDATE from an edge only is propagated to the edges within the same SD-WAN VPN.”

Also, irrespective of the details of the above, I think the Security Considerations section deserves to have a clearer description of the security model, instead of having it only embedded in the middle of Section 3.1.5. (My understanding with the revised text, is that all security properties depend on the correct configuration and operation of the route reflectors. Which is fine, but shouldn’t you say so?)

[Linda] We have revised the section to include a clearer description of the security model, as you suggested. The updated text now explicitly states that the security properties of the SD-WAN depend heavily on the correct configuration and operation of the Route Reflector (RR), which acts as the central control point. This includes secure communication channels, policy enforcement, and mitigation of risks associated with Internet-facing WAN ports.


Regards,

—John

> On Apr 5, 2024, at 5:49 PM, Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:
>
> John,
>
> Thank you very much for spending time with us during IETF 119 explaining your concerns of the draft.
>
> We have revised the draft that addressed all the comments and suggestions from the IESG LC comments and discussion during the  IETF119 meeting.
>
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
> efense.com%2Fv3%2F__https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-i
> etf-bess-bgp-sdwan-usage%2F__%3B!!NEt6yMaO-gk!Aig25lrJiALWg7GcYb1GZy4G
> v6IxUHna2EKPVJEx8bud-CQ8epcnZiXymefsUgLlR7_4hQYYmcS64Cu37Ii0qmA%24&dat
> a=05%7C02%7Clinda.dunbar%40futurewei.com%7Cd3c9d07693c54c6b1f6808dc59a
> 32139%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638483804391192490%
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik
> 1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=k9IliE%2FLFPTZTwl2vsgjVnLz9IcL
> MSQGfQ0%2FAmVIklk%3D&reserved=0 Can you please review and let us know
> if the draft can be moved forward to RFC?
>
> This document describes the SD-WAN use cases, which explain why WAN port advertisements for the underlay path and client prefix advertisements need to be separated and illustrate how the BGP-based control plane can effectively manage large-scale SD-WAN   overlay networks with minimal manual intervention.
>
> Thank you very much,
> Linda
>
> -----Original Message-----
> From: John Scudder <[e-mail]<mailto:[e-mail]>>
> Sent: Wednesday, February 28, 2024 9:05 AM
> To: Linda Dunbar <[e-mail]<mailto:[e-mail]>>
> Cc: The IESG <[e-mail]<mailto:[e-mail]>>;
> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>;
> [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
> Subject: Re: John Scudder's Discuss on
> draft-ietf-bess-bgp-sdwan-usage-20: (with DISCUSS and COMMENT)
>
> Hi Linda,
>
> A few replies to some of the more specific/actionable points, below.
>
>> On Feb 27, 2024, at 10:47 PM, Linda Dunbar <[e-mail]<mailto:[e-mail]>> wrote:
> ...
>>  ### Error in how RFC 9012 is used
>>
>> In Section 5.2, the Encapsulation Extended Community is misused. See
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furl
>> defense.com%2Fv3%2F__https%3A%2F%2Fnam11.safelinks.protection.outlook
>> .com%2F%3Furl%3Dhttps*3A*2F*2Fmail__%3BJSUl!!NEt6yMaO-gk!Aig25lrJiALW
>> g7GcYb1GZy4Gv6IxUHna2EKPVJEx8bud-CQ8epcnZiXymefsUgLlR7_4hQYYmcS64Cu3O
>> fo47_s%24&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cd3c9d07693c54
>> c6b1f6808dc59a32139%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6384
>> 83804391203378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2
>> luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=l0LUHAnLoET%2
>> BfYWWEH5eov3gNTNZggKdtF6cdo%2F8OkY%3D&reserved=0
>> archive.ietf.org%2Farch%2Fmsg%2Fidr%2FumBB5yfoC3mFMpIWIT2K8159Gos%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cb65cbbac81144d1fbb1808dc386ead26%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638447295225231753%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=CKLRVL8ylb5Ey6U3cmYMo2A%2FsmtBpLj8Ir%2BQ9Oq%2FwFU%3D&reserved=0 for related explanation of the error. The error recurs in Sections 5.3 and 5.4.
>>
>> [Linda] Please see the discussions related to the topic. For SD-WAN scenario, simple NextHop is not enough for client routes advertisement because different client routes need to be forwarded by different underlay paths. It is not practical to include all the information about the underlay path with the client routes advertisement.
>
> To paraphrase my reply to the other thread linked above, just because you want a nail, that doesn't mean Encapsulation Extended Community is a nail. In that last reply, I suggested a few other mechanisms you could use, but if you think you must have some kind of tunnel affinity indicator that isn’t color, you can specify one, there are plenty of unused extended community code points available. But Encapsulation Extended Community has already been specified and does not have the semantics you want.
>
> (As an aside, anywhere you’re referencing a code point, if you’re not
> using the exact name found in the IANA registry, please mention the
> numeric value also.)
>
>> Also, there is no such thing as “TYPE = IPsec” (referenced in
>> Sections 5.2 and 5.4), see
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fwww__%3BJSUl!!NEt6yMaO-gk!Aig25lrJiALWg7GcYb1GZy4Gv6IxUHna2EKPVJEx8bud-CQ8epcnZiXymefsUgLlR7_4hQYYmcS64Cu37FMbm5A%24&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cd3c9d07693c54c6b1f6808dc59a32139%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638483804391211116%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=uaV5OP%2BjfxETbvUnUcYfHmNShsM8BzKZaQnlrsaTN7w%3D&reserved=0 .
>> iana.org%2Fassignments%2Fbgp-tunnel-encapsulation%2Fbgp-tunnel-encaps
>> u
>> lation.xhtml%23tunnel-types&data=05%7C02%7Clinda.dunbar%40futurewei.c
>> o
>> m%7Cb65cbbac81144d1fbb1808dc386ead26%7C0fee8ff2a3b240189c753a1d5591fe
>> d
>> c%7C1%7C0%7C638447295225239072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
>> A
>> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdat
>> a
>> =qrDlj1%2F2jHbhRd2G40zQMNybiwzNz3iN%2FBkrJ78grew%3D&reserved=0
>>
>> [Linda] RFC5566 has specified IPsec Tunnel Type (IPsec in Tunnel-mode: Tunnel Type = 4 [RFC4302], [RFC4303]). We can add the reference.
>
> RFC 5566 status is Obsolete, Tunnel Type = 4 status is Deprecated (that’s why I put the link to the registry there, in part). I don’t think we should be publishing new RFCs with normative references to Obsolete RFCs and Deprecated code points.
>
>> This one should be straightforward to fix. It does lead me to be
>> worried about the level of review the document has received, though.
>>
>> ### Section 3.1.5, security model
>>    BGP is well suited for this purpose. RFC4684 has specified the
>>   procedure to constrain the distribution of BGP UPDATE to only a
>>   subset of nodes. Each edge node informs the Route-Reflector (RR)
>>   [RFC4456] on its interested SD-WAN VPNs. The RR only propagates
>>   the BGP UPDATE from an edge to others within the same SD-WAN VPN.
>>
>> RFC 4684 is driven by demand -- a PE will advertise RT membership
>> NLRI to "request" that it receive routes with the given RT. So, this
>> means the security model is that the client router is implicitly
>> trusted to declare its VPN
>> membership(s) truthfully and accurately. I don't see this addressed
>> in the Security Considerations.
>>
>> [Linda] Section 3.2 states that the SD-WAN Local Network Controller, e.g., RR in BGP-controlled SD-WAN, is managing the policy governing communication among  peers.
>>
>> Here is the wording added in Section 3.1.5 to address your concern:
>> “Route-Reflector (RR) [RFC4456], as an integral part of the SD-WAN controller, has the policy governing communication among peers. The RR only propagates the BGP UPDATE from an edge to its authorized peers.”
>
> If the RR has to be explicitly configured to police all propagation of routes, instead of trusting RT membership NLRI… what value does RFC 4684 bring? You’re already requiring that the distribution topology be comprehensively configured.
>
> (As an aside, no BGP speaker “propagates BGP UPDATE” messages, that’s
> not a thing, the closest we get in our standards is BMP Route
> Mirroring mode, but that’s not applicable here. What you mean is that
> the RR only propagates BGP routes from an edge to its authorized
> peers.)
>
>>
>> ---------------------------------------------------------------------
>> -
>> COMMENT:
>> ———————————————————————————————————
> ...
>> [Linda] The term “Client Route” is adopted from the RFC4364. In this document, client route means the prefixes attached to the client ports of an SD-WAN edge. Add this to the Terminology section.
>
> I don’t see “client route” in RFC 4364, but if you’ve added a definition that’s fine.
>
> ...
>> What anti-DDoS mechanism is that? None is specified here, nor referenced.
>>
>> [Linda] anti-DDoS is a commonly used tool for any interface facing ports. It is out of the scope of this document to describe the details. Is adding the following sentence helpful?
>>        “The anti-DDoS mechanism comprises numerous components, and their detailed discussion is beyond the scope of this document.”
>
> Not helpful to me — if it’s a commonly used tool, surely there might be some reference available for it. But I see Roman has raised this point too, I’ll defer to him for further discussion of it.
>
>>   ### Figure 7
>>
>> Figure 7 is mangled to the point of being unreadable.
>>
>> [Linda] Figure 7 is to show underlay paths can be via trusted VPN and “untrusted network”. Over the “Untrusted Network”, packets have to be encrypted. We greatly appreciate  any suggestion to make it better.  The intent is to demonstrate some traffic have to be forwarded via trusted VPN, while other traffic can be forwarded via either untrusted network (with encryption) or trusted VPN.
>
> I literally mean that the lines and boxes and such don’t line up, there are boxes without labels, etc. It looks like the ASCII-art got trashed in version 16, so my suggestion would be to revert to what was in version 15 as “figure 8”. Even that version is a little funky — is it really your intent that there be no connection between A3 and the adjacent PE? Seems like it couldn’t possibly be, since as currently pictured C-PE-a has no connection to the trusted VPN and therefore isn’t actually illustrating “hybrid”. So probably add that arc too.
>
> —John