Re: [bess] Last Call: <draft-ietf-bess-bgp-sdwan-usage-19.txt> (BGP Usage for SD-WAN Overlay Networks) to Informational RFC

[Adrian Farrel <[e-mail]>]

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 <[e-mail]> 
Sent: 07 February 2024 00:23
To: [e-mail]; [e-mail]
Cc: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]
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 <[e-mail] <mailto:[e-mail]> > 
Sent: Saturday, February 3, 2024 3:54 PM
To: [e-mail] <mailto:[e-mail]> 
Cc: [e-mail] <mailto:[e-mail]> ;
[e-mail] <mailto:[e-mail]> ; [e-mail]
<mailto:[e-mail]> ; [e-mail]
<mailto:[e-mail]> ; [e-mail]
<mailto:[e-mail]> 
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]

 

---