Hi Linda,
Thanks for considering all of my comments. I'll respond to your two emails separately. Comments inline. I snipped the obvious agreements. Cheers, Adrian From: Linda Dunbar <linda.dun...@futurewei.com> Sent: 07 February 2024 00:23 To: adr...@olddog.co.uk; last-c...@ietf.org Cc: andrew-i...@liquid.tech; bess-cha...@ietf.org; bess@ietf.org; draft-ietf-bess-bgp-sdwan-us...@ietf.org; matthew.bo...@nokia.com Subject: RE: Last Call: <draft-ietf-bess-bgp-sdwan-usage-19.txt> (BGP Usage for SD-WAN Overlay Networks) to Informational RFC 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 <adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> > Sent: Saturday, February 3, 2024 3:54 PM To: last-c...@ietf.org <mailto:last-c...@ietf.org> Cc: andrew-i...@liquid.tech <mailto:andrew-i...@liquid.tech> ; bess-cha...@ietf.org <mailto:bess-cha...@ietf.org> ; bess@ietf.org <mailto:bess@ietf.org> ; draft-ietf-bess-bgp-sdwan-us...@ietf.org <mailto:draft-ietf-bess-bgp-sdwan-us...@ietf.org> ; matthew.bo...@nokia.com <mailto:matthew.bo...@nokia.com> 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-d iscovery ). I will ask Matthews to add the link to the implementation reports. [AF] OK. Adding the pointer to the implementation report of the IDR document as a link in the Datatracker for this document would be helpful. But it doesn't cover the whole picture, does it? Of course, it is not mandatory for an Informational document, but it would be really helpful to know who has put a system together as described in this document, does it include all of the components, what problems were encountered, has there been any interop? [snip] --- The running footer seems to be broken ("xxx, et al.") [Linda] ? should I remove the footnote (Dunbar, et al)? [AF] The footer should be there. It should read something like "Dunbar, et al." Currently is reads "xxx, et al." [snip] --- 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". [AF] OK, I see the change in -20. --- 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? [AF] Whether it delays the process or not, is not the issue (although I can see why it might worry you). Later on, I think you say that there is material in MEF70.1 that you did not want to repeat, but which is important, etc. It really is a normative reference. The good thing, however, is that MEF70.1 seems to be freely available for download, so I believe it will not change the publication process for your draft. [snip] --- 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"? [AF] RFC 9522 has. Path steering is the ability to forward packets using more information than just knowledge of the next hop. Examples of path steering include IPv4 source routes [RFC0791], RSVP-TE explicit routes [RFC3209], Segment Routing (SR) [RFC8402], and Service Function Chaining [RFC7665]. Path steering for TE can be supported via control plane protocols, by encoding in the data plane headers, or by a combination of the two. This includes when control is provided by a controller using a network-facing control protocol. 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. [AF] This seems better. Thanks. --- 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. [AF] Well, yes, but only 2 months before. [snip] --- 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." [AF] OK. That's quite a change, but it is clear. [snip] --- 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. [AF] OK, so you are saying you need a different term to distinguish a sub-class of SD-Wan edge nodes. That's fine. I just did not find the definition clear enough or any meaning for the letters "C-PE" [snip] ---
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
