Adrian,
Thank you very much for the extensive comments and suggestions.
I am breaking the resolutions in two separate emails. This one addresses the comments to Section 3.1.2. Will have another email addressing the remaining comments.
Can you check if the resolutions to your comments inserted below are acceptable?
Thank you,
Linda
-----Original Message-----
From: Adrian Farrel <adrian@xxxxxxxxxxxx>
Sent: Saturday, February 3, 2024 3:54 PM
To: last-call@xxxxxxxx
Cc: andrew-ietf@xxxxxxxxxxx; bess-chairs@xxxxxxxx; bess@xxxxxxxx; draft-ietf-bess-bgp-sdwan-usage@xxxxxxxx; matthew.bocci@xxxxxxxxx
Subject: RE: Last Call: <draft-ietf-bess-bgp-sdwan-usage-19.txt> (BGP Usage for SD-WAN Overlay Networks) to Informational RFC
From: Adrian Farrel <adrian@xxxxxxxxxxxx>
Sent: Saturday, February 3, 2024 3:54 PM
To: last-call@xxxxxxxx
Cc: andrew-ietf@xxxxxxxxxxx; bess-chairs@xxxxxxxx; bess@xxxxxxxx; draft-ietf-bess-bgp-sdwan-usage@xxxxxxxx; matthew.bocci@xxxxxxxxx
Subject: RE: Last Call: <draft-ietf-bess-bgp-sdwan-usage-19.txt> (BGP Usage for SD-WAN Overlay Networks) to Informational RFC
Hi,
I read this document again as part of its second Last Call. I have a few comments that should ideally be fixed before passing the draft on to the RFC Editor. (I ran out of steam around Section 6, sorry.)
Thanks,
Adrian
===
I wondered about the implementation status of this document. One might say that an Informational I-D has nothing to be implemented, but this document seems to be telling us which elements of other RFCs to use and combine to make a working system. Seeing
that some of my comments note that the text appears to recommend using a deprecated code point, and that the BESS wiki notes "Implementation Status" as one of the working group last call checklist items, I thought it might be nice if this document has an RFC
7942 section to help us know how solid the processes are.
[Linda] There are two implementations of the extension of BGP to control SD-WAN (https://wiki.ietf.org/group/idr/implementations/draft-ietf-idr-sdwan-edge-discovery
).
I will ask Matthews to add the link to the implementation reports.
---
Please fix John Drake's contact details.
[Linda] changed.
---
You have a different number of people on the front page and in the Authors' Addresses section.
[Linda] Thanks for catching the error. Fixed.
---
The RFC Editor is going to ask you whether you can find a different way of saying "traditional" in the many cases in this document. Mainly, I think you can just delete the word.
[Linda] Thanks for the suggestion. Deleted the “traditional” from the document.
---
The running footer seems to be broken ("xxx, et al.")
[Linda] ? should I remove the footnote (Dunbar, et al)?
---
The document title and abstract should not assume that the reader is familiar with the abbreviation "SD-WAN"
[Linda] expanded the acronym.
---
Why does the document title say "overlay networks" while the Abstract says "multiple scenarios".
[Linda] specifically: “multiple scenarios of SD-WAN (Software Defined WAN) overlay networks”.
---
Why isn't [MEF70.1] a normative reference? It seems that this document leans on it heavily for the definition of SD-WAN and for other material.
[Linda] Will listing non-IETF standard as normative delay the process?
---
1.
s/IP Packets/IP packets/
[Linda] changed.
---
1.
- Some traffic can be forwarded by edge nodes, based on their
application identifiers instead of destination IP addresses
I think this is unintentionally ambiguous. Presumably it is not the application identifiers of the edge nodes.
I believe you are talking about traffic steering, although "forwarding"
may be an acceptable term. We normally think about forwarding onto a link or toward a next hop, and steering onto a path.
[Linda]. By the way, does IETF have a formal definition of “Steering” vs. “Forwarding”?
Are the following sentences better (or more accurate)?
- Some traffic can be steered onto specific overlay paths based on the packets matching a predefined condition instead of destination IP addresses. The matching condition can be one or multiple fields of the IP header of the packets. More detailed attributes for steering traffic are described in the Table7 and Table 8 of [MEF70.1]. Using IPv6 [RFC8200] packets as an example, the Flow Label, the source address, a specific extension header field, or a combination of multiple IP header fields can be used to steer traffic.
.
---
1.
- Some traffic can be forwarded by edge nodes, based on their
application identifiers instead of destination IP addresses,
by placing the traffic onto specific overlay paths based on
the application-specific policies. An "application identifier"
in this document refers to one or multiple fields of the IP
header of the packets.
I think this use of "application identifier" (and, later, "recognizing
applications") is significantly misleading. At best, what you have here is a "flow identifier". Further, you say that this is done "instead of the destination IP address", yet the destination IP address is surely a "field of the IP header of the packet".
(By the way, by the time you get to Section 3.3, you are talking about flows.)
[Linda] This document was written before the “APN initiative. I can see why mentioning “Application ID” becomes so sensitive.
You go on to say:
More detailed attributes that can be
used for identifying applications are described in the Table7
and Table 8 of [MEF70.1]
Table 7 includes fields that are not part of the IP header.
- In general, matching on source and destination port IDs is
considered an acceptable way of identifying traffic flows. But this
is contrary to what you have previously said and is, in any case,
problematic with some forms of encryption.
- The concept of "Custom match including heuristic/algorithmic
matching" is clearly not intended to relate purely to fields in
the IP header, but includes some form of DPI. It is arguable that an
SD-WAN edge node is part of the customer's network, and that the
customer is allowed to inspect any user's traffic within their
network. This, however, probably only applies to certain types of
customer network. It is also likely to fail in the presence of
end-to-end encryption.
I do not find this topic discussed further in the draft, and I think
it needs to be specifically excluded, or explained in some detail.
I refer the AD to the discussion of "APN" within the IETF and to the
careful efforts that have been made to attempt to achieve
application flow identification for different traffic treatments and
for traffic steering at the edge of the network without recourse to
DPI. This is, I think a serious problem with the document.
[Linda] totally got it. I am removing all reference of “Application Id” from the document.
Table 8 also includes fields that are not part of the IP header.
- Using the Ethertype of the encapsulating Ethernet frame may be a
tool that can be used, but you would need to make that clear as it
is obviously not part of the IP header. Further, as the note in the
table says, not all implementations will have access to the Ethertype
of the received frame.
[
It is possible that including a reference to Section 8 of MEF 70.1 might be helpful here, but I note that that document says:
Although the term "Application Flow" includes the word "Application"
there is only a loose connection between the two.
So, while you could continue to use the term "application" in your draft, I think that would be a bad idea. Sure, reference that fact that MEF 70.1 uses the term, but say something like:
As noted in [MEF70.1] there is only a loose connection between an
"Application" and what [MEF70.1] calls an "Application Flow". To
avoid any confusion and remove any implication that individual
applications can be identified by SD-WAN edge nodes, this document
uses the term "traffic flow" (or simply "flow"). A flow is a
collection of packets between the same source and destination pair
that are subject to the same forwarding and policy decisions at the
ingress SD-WAN edge node, and are identified by the settings of one
or more fields in the packet headers.
[Linda] Thank you very much for the suggestion.
---
1.
[Net2Cloud-Problem] describes the network-related problems
relating to connecting enterprises' branch offices to dynamic
workloads in different Cloud Data Centers (DC). SD-WAN has been
positioned as a flexible way to solve those issues; however, this
can create significant scaling issues when hundreds or thousands
of nodes need to be interconnected by SD-WAN overlay networks.
I was distracted by this paragraph. I'm not sure it adds to the document, and it seems to present some challenges: for example, this document purports to address "large-scale SD-WAN overlay networks"
(Abstract) yet here you say that there is a scaling problem for large networks. Asides from this, the only mention of scalability is in Section 5.1
My suggestion would be to scrap this paragraph since it is really only saying that you can use SD-WAN to address some problems of, erm, SD-WAN deployments.
If you *do* decide to keep the paragraph, then I suggest adding a new section to the draft for "Scalability Considerations."
[Linda] Take your suggestion. Removed this paragraph.
---
1.
BGP for SD-WAN overlay is a
different layer from the underlay networks' BGP control plane
instances.
I think, more importantly, it is a different BGP instance. Or is it?
[Linda] Yes. Changed to the following to make it clearer:
“It's important to distinguish the BGP instance as the control plane for SD-WAN overlay from the BGP instances governing the underlay networks”.
---
2.
Controller: Used interchangeably with SD-WAN controller to manage
SD-WAN overlay path creation/deletion and monitor the
path conditions between sites.
The overlay paths are somewhat trivial, I believe, seeing that in the overlay all edges are adjacent and the path is a single hop. Reading ahead, the more important (the only?) roles of the controller are to manage subscription of edge nodes to the SD-WAN,
to assist with ZTP, and to determine which edges should be connected to which other edges.
[Linda] Is the following statement better?
“Controller: Used interchangeably with SD-WAN controller to manage SD-WAN overlay networks in this document. In the specific context of BGP-controlled SD-WAN, the controller functions as an integral
component of the BGP Route Reflector.”
---
2.
s/A SD-WAN/An SD-WAN/
[Linda] Changed.
---
2.
CPE-Based VPN is defined in this section, but the term is not used anywhere in the document.
This is somewhat confusing, and looking at the scenarios in section 3, it appears that you intend that all deployments use CPE-CPE security of some form. This appears to be a fundamental component of the SD-WAN that you are describing. Perhaps you need
to bring this point out very clearly in the description of what an SD-WAN is.
[Linda] thanks for catching it. The term was used in the earlier version. Removed the term.
---
2.
SD-WAN IPsec SA: IPsec Security Association between two SD-WAN
ports or nodes.
The "nodes" in this case are SD-WAN edges (or CPEs).
And the "ports" are ports on those nodes. Possibly "WAN ports" q.v.
[Linda] Changed.
---
2.
SD-WAN over Hybrid Networks
The term used in the document seems to be "Hybrid Underlay"
[Linda] Yes. Changed to make it clearer.
---
2.
s/an Network/a Network/
[Linda] changed.
---
2.
It seems to me to be confusing to define a new term "C-PE" which:
- doesn't seem to stand for anything
- means "SD-WAN Edge node" which is already defined
- "can be Customer Premises Equipment (CPE)" which is a very similar
abbreviation
Why can you not stick with "SD-WAN Edge node"?
[Linda] For SD-WAN network expended from VPN, need to emphasize the C-PE having additional port o another network.
---
2. and 3.1.4
Decide between "Zero Touch Provisioning" and "zero-touch provisioning"
[Linda] Zero Touch Provisioning
---
3.1.1
Please expand VRF and provide a citation
[Linda] added.
---
3.1.1
As SD-WAN is an overlay network arching over multiple types of
networks, MPLS L2VPN/L3VPN or pure L2 underlay can continue using
the VPN ID, VN-ID, or VLAN in the data plane to differentiate
packets belonging to different SD-WAN VPNs.
There are some unexplained abbreviations here.
[Linda] Add the reference.
---
3.1.2
Please expand UNI
[Linda] Added.
---
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
