Early Review of draft-ietf-idr-sdwan-edge-discovery-18
review-ietf-idr-sdwan-edge-discovery-18-rtgdir-early-talaulikar-2024-11-01-00

Hello,

I have been selected to do a routing directorate early review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-idr-sdwan-edge-discovery/

The routing directorate will, on request from the working group chair, perform
an early review of a draft before it is submitted for publication to the IESG.
The early review can be performed at any time during the draft’s lifetime as a
working group document.

As this document has completed working group last call, my focus for the review
was to determine whether the document is ready to be published. Please consider
my comments along with the other working group last call comments.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

Document: draft-ietf-idr-sdwan-edge-discovery-18
Reviewer: Ketan Talaulikar
Review Date: 1 November, 2024
Intended Status: Standards Track
Summary: Not Ready

Note: This is a "first pass" review since I faced challenges in understanding
the document and the solution details therein.

Summary of the document:
It seems that the intention of this document is to first describe a very
specific SD-WAN solution (one where BGP can be leveraged), and then second to
specify how BGP is used for the signaling and setup of that solution. Is my
understand correct thus far?
Further the document introduces a new BGP SAFI for the signaling/setup of the
SD-WAN tunnel-based underlay and then uses the existing BGP SAFIs for
associating the SD-WAN "client routes" with those underlay tunnels. Is this
correct?

Major:

1) The relationship of this document with the Informational document
draft-ietf-bess-bgp-sdwan-usage is not clear. I see a lot of overlap.
I get the impression that the BESS document is the one that describes a
BGP-based SD-WAN solution framework (albiet it also ventures into some BGP
encoding aspects). The v12 of this document referenced the BESS document but
was later removed.
Note: the IESG returned the BESS document to the WG with several issues
raised - many of them seem applicable to this document as well.

2) There are no references to any SD-WAN specifications - I believe this is
done at MEF? I was not able to find an IETF informational document other than
the BESS document in (1).

3) The new SAFI for the underlay tunnel establishment (section 6) is
underspecified. There is no description of the NH encoding nor about which
other attributes (e.g., TEA) are mandatory or optional. There is no
description of which TEA sub-TLVs are required/used. Section 7 and 8 introduce
new TLVs for the TEA but do not describe how they are originated or handled.
Are they originated from the controller or from the SD-WAN PE device? Is the
controller simply reflecting (as an RR) all routes to all edges? The
procedures are not specified. If they are covered in a different document,
please provide pointers to the same.

4) For the "client routes", the document claims very wide applicability to all
sorts of AFI/SAFIs in BGP in section 5 without adequate description of the
procedures. E.g., BGP-LU (1/4) or MPLS-L3VPN - they carry MPLS labels. I
assume this document adds a Tunnel Encap ExtCom (or TEA depending on
something?) to those routes. However, how is the label handled? Do we send
MPLS labeled packets over those underlay tunnels?

Editorial:

While this is an editorial observation at this point, it should be considered
as a major issue since the document is challenging from a readability and ease
of comprehension perspective. I believe the document would improve
significantly if it was reorganized in a more logical flow and would like to
offer some suggestions in this regard. First, a section to describe the
applicability of this solution to specific type(s) of SD-WAN solutions (also
indicate where this is not applicable) - using references to other documents
would help. Second, a section to describe the overall working of the
solution parts with a reference diagram and the elements therein and the
interactions between them - an outside operations view perhaps. A sequence/flow
or steps without getting into the BGP details would help. Third, then get into
the encoding and mechanics/working of the new underlay SAFI in one section
(including new TLVs) followed by the use of an appropriate existing overlay
 SAFI for the client routes. Fourth, the use of the two BGP SAFIs - underlay
tunnel setup and overlay SD-WAN client route - how they tie and work together
with flows/sequence including the use of existing concepts like route
reflection, RTC, etc..

Nits:
Document throws up warnings and comments in idnits that should be easy to
resolve.

BGP UPDATE is a BGP message type. There is an over emphasis on "UPDATE"
through the document which I found odd.

I hope this helps.

Thanks,
Ketan