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

[John Scudder via Datatracker <[e-mail]>]

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://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-sdwan-usage/



----------------------------------------------------------------------
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?

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.

[*] 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?

### Error in how RFC 9012 is used

In Section 5.2, the Encapsulation Extended Community is misused. See
https://mailarchive.ietf.org/arch/msg/idr/umBB5yfoC3mFMpIWIT2K8159Gos/ for
related explanation of the error. The error recurs in Sections 5.3 and 5.4.

Also, there is no such thing as “TYPE = IPsec” (referenced in Sections 5.2 and
5.4), see
https://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml#tunnel-types

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.


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

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

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

### Figure 7

Figure 7 is mangled to the point of being unreadable.