Ketan Talaulikar has entered the following ballot position for
draft-ietf-bess-bgp-sdwan-usage-32: 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:
----------------------------------------------------------------------

Thanks to the authors and the WG for their work on this document.

I have a few high-level aspects in this document that I would like to discuss.

<discuss-1> The abstract of this document says:

   This document explores the complexities involved in managing large
   scale Software Defined WAN (SD-WAN) overlay networks, along with
   various SD-WAN scenarios. Its objective is to illustrate how a
   BGP-based control plane can effectively manage these overlay
   networks by distributing edge service reachability information,
   WAN port attributes, and underlay path details, thereby minimizing
   manual provisioning.

To my knowledge there are SD-WAN solutions from several vendors that are
widely deployed today. Some of them use IETF protocols for specific
functionalities while others use proprietary mechanisms (here I am not
referring to IPSec or TLS but routing protocols). This text (and a few
similar in the body of the document) gives the impression of comparison
between a BGP-based solution that is not fully specified (not even the
framework is specified) in this document against solutions deployed out
there.

As easy way to address this would be to rephrase such text to not make
claims or comparisons. Perhaps just plainly state how use of BGP can
potentially replace other proprietary mechanisms used in SD-WAN solution?
E.g., the first sentence is problematic since it can be read as existing
solutions have complexities that are solved by BGP without any supporting
evidence or evaluation of those other solutions.

<discuss-2> Introduction section says:

   This document captures the SD-WAN scenarios, control-plane
   behaviors, and forwarding considerations that motivate current and
   future IETF work on SD-WAN. Publishing this material as an RFC
   provides a stable, citable foundation for related protocol
   specifications and ensures a shared understanding of the problem
   space across the industry.

As mentioned in the previous point, there are multiple SD-WAN solutions
that have been developed by various vendors using IETF technologies
like BGP (but with proprietary extensions) or entirely proprietary
solutions. AFAIK, none of these solutions support interoperability between
SD-WAN gateways and controllers from different vendors. Please correct
me if I am wrong. So, I wonder where and how the standardization of SD-WAN
at the IETF is happening to enable such interoperability that is after all
the purpose of the IETF. The BGP extensions are but a small portion of what
an SD-WAN solution entails. Do the claims made in that text hold?

Why not just say "This document captures the SD-WAN scenarios, control-plane
behaviors, and forwarding considerations using BGP." or something like that?

<discuss-3> In continuation of the previous point. There is no SD-WAN WG that
is chartered today to study and undertake the work necessary for a standards
based open and interoperable SD-WAN solution. Without that in place, I do not
understand the value or benefit of publication of this document via the IETF
track. It could as well be via ISE?

<discuss-4> Section 3.1.5 says

   An SD-WAN edge must use a secure channel, such as TLS following
   BCP195[RFC9325] or Ipsec [RFC4301], to its designated RR for
   exchanging BGP UPDATE messages.

I assume that IPsec tunnels need to be setup between the edge and
the controller and this tunnel has IP addresses on both ends that are used
to setup a BGP Session over it - i.e., in tunnel mode per RFC4301 with both
AH and ESP. If so, please clarify. I am unable to find a similar IETF
specification for setting BGP over TLS tunnels. I don't think BCP195 covers
these aspects. Can you please clarify this use of TLS with an appropriate
reference?


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

I support the DISCUSS position of Med.



_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to