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

[Linda Dunbar <[e-mail]>]

John,
Thank you very much for the detailed comments.
See the replies below to address your discussion points.

Linda

-----Original Message-----
From: John Scudder via Datatracker <[e-mail]>
Sent: Tuesday, February 27, 2024 4:19 PM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: John Scudder's Discuss on draft-ietf-bess-bgp-sdwan-usage-20: (with DISCUSS and COMMENT)

John Scudder has entered the following ballot position for
draft-ietf-bess-bgp-sdwan-usage-20: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fhandling-ballot-positions%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cf5f2c86a4f274f21f70808dc37e20eec%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638446691280685631%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=kzAe1rn6Lsl0Yahh8P5vO20AKgtL5qgnpMzOFtO2%2BTI%3D&reserved=0
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bess-bgp-sdwan-usage%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cf5f2c86a4f274f21f70808dc37e20eec%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638446691280693385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=uHr7%2B1kW2k9gdYWwLdihBeUYFkLtA%2FnrGYtGyONW7m0%3D&reserved=0



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

## DISCUSS

I have several concerns with this document, and I can't support it being
published in its current form. Details are below, listed roughly in order of
severity.

### What's it for?

My most fundamental concern is that I can't understand what this document is
for. It doesn't specify a procedure. It doesn't provide enough detail to allow
me to understand how to use the underlying technologies to build an SD-WAN
service. (Also some of the details that are provided are wrong, see subsequent
item.) It's not an architecture or framework document in the usual sense. It
does motivate at a high level, the understanding that one *can* use BGP as the
control plane, and IPSec as the data plane [*], to build an SD-WAN service, if
one knows how... but do we need an RFC for that?
[Linda] This document is intended to describe the SD-WAN scenarios and demonstrate the applicability of BGP as the control plane for multiple scenarios of SD-WAN (Software Defined WAN) overlay networks.

The closest I could find to a thesis statement was the abstract's "The document
aims to demonstrate how the BGP-based control plane is used for large-scale
SD-WAN overlay networks with little manual intervention." I guess if we allow
the word "demonstrate" to mean "motivate at a high level" rather than
"specify", then we can say it's not too far off. I don't see why we need an RFC
for that, though.

[Linda] This document (if published as the RFC) serves as a valuable resource offering comprehensive insights into the utilization of BGP as the control plane for SD-WAN overlay networks. This document is designed to provide the network industry with clear guidance on the methodologies and rationales behind harnessing BGP for SD-WAN control, elucidating the specific scenarios in which BGP proves to be an effective control mechanism for SD-WAN overlays.


[*] Or the concatenation of IPSec and "traditional" BESS VPN technologies, in
the "differential" case.

### Is it in charter?

Looking at the BESS charter, I don't see how this document fits. If it weren't
for the preceding question, I probably wouldn't have thought to look. But as it
stands, I have to ask: why does the WG think this is a chartered work item?
[Linda] BESS Charter states " The BGP Enabled Services (BESS) working group is responsible for
defining, specifying, and extending network services based on BGP."
This document is discussing using BGP for controlling a new network service(i.e., SD-WAN).


### 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%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fidr%2FumBB5yfoC3mFMpIWIT2K8159Gos%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cf5f2c86a4f274f21f70808dc37e20eec%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638446691280699157%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=AweC6NSJdVNUQyaEe3TO9lBQFsv%2Br%2BDOySf1xTZb2RA%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.

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%2Fwww.iana.org%2Fassignments%2Fbgp-tunnel-encapsulation%2Fbgp-tunnel-encapsulation.xhtml%23tunnel-types&data=05%7C02%7Clinda.dunbar%40futurewei.com%7Cf5f2c86a4f274f21f70808dc37e20eec%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638446691280703388%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=7PdBUNYeUXtjMK2pp3HxQjzA5XJ93GJCqIBlpEomCSc%3D&reserved=0

[Linda] RFC5566 has specified IPsec Tunnel Type (IPsec in Tunnel-mode: Tunnel Type = 4 [RFC4302], [RFC4303]).  We can add the reference.

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."


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

## COMMENT

### What's a "client route"?

The document talks about "client routes", "client route updates", etc. It never
defines the concept. I assume that these are analogous to a CE route in an RFC
4364 VPN, but the casual usage and lack of definition are unhelpful.
[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.

### MP-NRLI

There's no such thing as "MP-NLRI". I guess you mean MP_REACH_NLRI and
MP_UNREACH_NLRI. If you want to collectively refer to these as "MP-NLRI" then I
think you need to add a definition.
[Linda] Yes, Add the following definition in the terminology section.

MP-NLRI:                In this document, the term "MP-NLRI" serves as a concise reference for "MP_REACH_NLRI".



### Anti-DDoS

Section 6.2.2 has

                                                     For all packets
     from the Internet-facing WAN ports, the additional anti-DDoS
     mechanism has to be enabled to prevent potential attacks from
     the Internet-facing ports.

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."



### 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.

Linda