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

[John Scudder <[e-mail]>]

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]> wrote:
...
>   ### 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.
>
> [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://www.iana.org/assignments/bgp-tunnel-encapsulation/bgp-tunnel-encapsulation.xhtml#tunnel-types
>
>  [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