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

[Linda Dunbar <[e-mail]>]

Adrian,

Thank you. Below are the resolutions to your additional comments.
Please let us know if you have further comments.

Thank you very much,
Linda

From: Adrian Farrel <[e-mail]>
Sent: Thursday, February 8, 2024 4:33 AM
To: Linda Dunbar <[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

Hi again, Linda.

Here is the response to your second email. Again, comments in line, with snipping of agreed points.

Best,
Adrian


-----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

===
<snipped, see previous email for the resolutions>
---

3.1.2

I had a lot of trouble working out what this section is trying to say.

   The client service requirements describe the port interface
   requirement at the SD-WAN edge to connect the client network to
   the SD-WAN service.

[Linda] The client service requirements describe the SD-WAN edge's ports, also known as SD-WAN client interface, which connect the client network to the SD-WAN service.

 [AF] OK. Probably Do you intend that "the interface is the set of ports" or "each port is an interface"? Depending on this you have:
s/known as SD-WAN/collectively known as the SD-WAN/
Or
s/interface/interfaces/

[Linda] Changed.


The requirements describe the requirement?
And what are those requirements?

[Linda] those requirements are:

  *   The SD-WAN client interface should support IPv4 & IPv6 address prefixes and Ethernet (as described in [IEEE802.3] standard).
  *   The client service should support the SD-WAN UNI service attributes at the SD-WAN edge as described in MEF 70.1, Section 11.
[AF] OK. Clear if stated like this.

   The client interface ports can support IPv4 & IPv6 address
   prefixes and Ethernet (as described in [IEEE802.3] standard).

How does a port support an address prefix?
[Linda] The interface should support IPv4/IPv6.

   It is worth noting that this "interface"

Which interface?
[Linda] SD-WAN client interface.

   is called SD-WAN UNI in
   [MEF 70.1] with a set of attributes (described in Section 11 in
   MEF 70.1); these attributes (in MEF 70.1) describe the expected
   behavior and requirements to support the connectivity to the
   client network.

I presume that this is focused on the case that the SD-WAN edge is a PE not a CPE?

[Linda] when provider managed SD-WAN, the SD-WAN edge is PE. For SD-WAN provided to enterprises, the SD-WAN is CPE.

[AF] The thing that "confused" me is when you say that the UNI supports the connectivity to the client network. In the CPE case, isn't the CPE part of the client network? Where is the UNI?
[Linda] For a network service provider managed SD-WAN (or VPN), the UNI have links to enterprises CPEs. For an enterprise managed SD-WAN, the UNI connect to internal branches (e.g., HR, engineering, etc).

   The client service should support the SD-WAN UNI service
   attributes at the SD-WAN edge as described in MEF 70.1, Section
   11.

What is the "client service"?
[Linda] client service interface.

What does "should" mean here?

[AF] I think you haven't answered this, and you have reproduced it in your new text, above. Does "should" mean "must" or are there acceptable exceptions (if so, what?)?
[Linda] what is the right term?  You can sell an IPv4 only SD-WAN edge, which is a non IETF (or MEF70.1) compliant device,  if a buyer is willing to pay.
Therefore, it is "SHOULD" instead of "MUST" ?

Isn't it the case that the attributes in MEF 70.1/11 apply at an interface not at a node?
[Linda] Yes

Do these attributes apply to the configuration/management of the client service interface, or to the marking of packets on the interface, or to the handling of packets on the interface?

[Linda] described in detail in MEF70.1. The MEF people insisted adding the statement. Too long to reiterate in this draft.

[AF] I can accept that if you make the MEF document a normative reference.
[Linda] okay. Changed to normative.

---

3.1.3

   For example, a retail business requires the point-of-sales (PoS)
   application to be on a different topology from other applications.
   The PoS application is routed only to the payment processing
   entity at a hub site; other applications can be routed to all
   other sites.

The second sentence is true, but does not justify the asserted requirement in the first sentence.
[Linda] ? The first sentence only says the example of PoS being on a different topology. Why need justification?

[AF] in the first sentence, notwithstanding that it is an example, you have said that "a retail business requires the point-of-sales (PoS) application to be on a different topology from other applications." This is a strong assertion.
Is it possible that you mean "For example, if a retail..." and for the second sentence, "In this case, the PoS..." ?

[Linda] I see what you mean. Changed.
---

3.1.3

The figure in this section needs to be tidied up, should be labeled, and should be referred to by number in the text. Subsequent figures in the document will need to be renumbered.
[Linda] Added the sentence that the "===" for non payment traffic, "---" for the payment traffic.
The traffic from the PoS application follows a tree topology (denoted as "----" in the figure below), whereas other traffic can follow a multipoint-to-multipoint topology (denoted as "===").

The figure doesn't really make clear the differences in the topologies.
For example, in the figure, and considering the "tree topology" it looks like Site 1 and Site 2 could be connected.

Part of the problem here may be that the "topology" relates to the underlay (which is not the business of the SD-WAN service or customer), while what you probably want to describe is the connectivity services in the two cases (which are multipoint-to-point, and any-to-any).

Maybe "connectivity matrix" is the term you need in place of "topology".

The final paragraph of the section seems to be talking about both different connectivity requirements for different traffic flows, as well as different service demands for those flows.

[Linda] just another example.

[AF] Forgive me, but I am still struggling with "topology" in this context especially when I see, in your figure that Site 1 appears to be connected to Site 2 using ---
To reiterate...
In the overlay (i.e., the SD-WAN) the connectivity service is Site(n) to/from Gateway for payment traffic, and any-to-any for non-payment traffic. That is the *service*.
In the underlay (i.e., the provider's network) the connectivity service may be delivered on any topology that the provider chooses.

If "topology" is a term of art used in the SD-WAN world to refer to the connectivity service, then this is OK, but I think the term needs to be explained in the terminology section to disambiguate it from what the reader might assume.
[Linda]  MEF SD-WAN projects call them different topologies: one topology is multi-point to point (or hub & spoke). Another topology is Any-to-Any.

[snip]

---

I feel that the references to [SECURE-EVPN] are (or are very close to
being) Normative.

[AF] Answer?
[Linda] We just want to acknowledge that the sub-TLVs listed here are copied from the SECURE-EVPN. Not really a reference.

[snip]

---

3.3

   Since IPsec requires additional
   processing power and the encrypted traffic over the Internet does
   not have the premium SLA commonly offered by Private VPNs,
   especially over a long distance, it is more desirable for traffic
   over a private VPN to be forwarded without encryption.

This seems to be putting it too strongly!
[Linda] I have to disagree on this one.  All nodes, and Cloud services,  have upper limits on the IPsec traffic bandwidth.

s/is more desirable/may be acceptable/
[Linda]
Actually, the SLA of traffic over the Internet has nothing to do with how traffic is handled on the Private VPN. What you are possibly  saying is that the high performance SLAs commonly offered by Private VPNs mean that it may not be possible to deliver traffic that both meets the SLA and is subject to edge-to-edge encryption.
[Linda] all nodes have limitation on the amount of traffic to be encrypted/decrypted. When Private VPN is available, the current practice is utilizing the private VPN first.

[AF] Here is the core of it! s/is more desirable/is current practice/
[Linda] I see. Changed.

For what it is worth, I think there is hardware that can encrypt/decrypt at line rate on its interfaces.
[Linda] Yes. But the Hardware encryption/decryption has upper capacity limit too.

And what you are actually saying is, "If it is necessary to send some traffic without encryption, then current practice is to select traffic that will be sent over the Private VPN because that underlay is likely to be more secure."
[Linda] Yes, you are correct.


By the way, the term "private VPN" (used in various places in the
document) is a little odd. "Private Virtual Private Network"?

[Linda] Private VPN also include private TDM network, like wavelength, T3, or OC-n.

[AF] OK. So (per suggestion below) you need to add this to the terminology section.

I suspect that a "private VPN" may be a VPN that is supported wholly by a single network service provider without using any elements of the public Internet and without any traffic passing out of the immediate control of that service provider. Perhaps you could add the term to Section 2.

[Linda] Good suggestion. Added to the Terminology Section.

---

3.3

   3) Some flows, especially Internet-bound browsing ones, can be
     handed off to the Internet without any encryption.

That is probably "without any further encryption" because such flows are probably already encrypted.
[Linda] depending on the website. Some are encrypted, some are not.

[AF] Right. We agree about the facts, just not about the wording!
Your words say that those flows that would normally be encrypted can be handed off to the Internet without any encryption. That is not what you mean.
Hence, insert the word "further"
[Linda] Thanks for the suggestion. Added.

[snip]

---

4.3

   SD-WAN edge nodes must negotiate various cryptographic parameters
   to establish IPsec tunnels between them.

Except, of course, those that don't use IPsec tunnels.
[Linda] Yes. Only need to negotiate to establish IPsec tunnels.

[AF] So,

   SD-WAN edge nodes must negotiate various cryptographic parameters
   to establish any IPsec tunnels between them.
[Linda] Yes. Changed per your suggestion.


[snip]

---

5.1

     In a traditional IPsec
     VPN, separate routing protocols must run in parallel in each
     IPsec Tunnel

Surely not separate routing protocols.
Probably not even separate routing protocol instances.
Perhaps, separate routing protocol adjacencies?
[Linda] changed to "In an IPsec VPN, separate routing instances need to run in parallel in each IPsec Tunnel if the client routes need be load shared among the IPsec tunnels"

[AF] So you are sure you mean "separate routing instances"? In a separate routing instance, there are separate routing tables, interfaces, and routing protocol parameters. Are you really sure you don't mean "separate routing adjacencies" or even, "the separate IPsec Tunnels are treated as parallel links"?

[Linda] Yes. Using OSPF as an example, Link State Advertisement messages are exchanged on all of the parallel IPsec Tunnels between two edges.
---

5.2

I think RFC 9012 calls it the "Tunnel Encapsulation attribute" not "Tunnel-Encap Path Attributes"
[Linda] Tunnel Encapsulation Attribute is a BGP Path Attribute.

[AF] To reiterate, RFC 9012 calls it the "Tunnel Encapsulation attribute"
[Linda] Yes, changed across the document.


[snip]

---

5.2

     - Suppose that a given packet "C" destined towards the client
       addresses attached to C-PE2 (e.g., prefix 192.0.2.4/30) can be
       carried by any IPsec tunnels terminated at C-PE2.

It doesn't matter, but any reason why the packet is called "C"?

s/tunnels/tunnel (since the packet can ultimately only be carried by one
tunnel)

[AF] Answer?
[Linda] just a name to reference the given packet. I may call it " ... a given packet "Linda",,,",
Is the following better?
-              Suppose that a given packet, denoted as "C", destined towards the client addresses attached to C-PE2 (e.g., prefix 192.0.2.4/30) can be carried by any IPsec tunnels terminated at C-PE2.

[snip]

---

In 5.2, 5.3, and 5.4 you have lines such as:

   Encapsulation Extended Community: TYPE = IPsec

But I think this should be:

   BGP Tunnel Encapsulation Attribute Tunnel Type = IPsec

[Linda] Client route are advertised by the "Encapsulation Extended Community". The IPsec tunnel terminated at the WAN port is advertised by "Tunnel Encapsulation Path Attribute".
For client routes that can be carried by either MPLS or IPsec, the Encapsulation Extended Community = SD-WAN-Hybrid. For client routes that are carried by IPsec only, the Encapsulation Extended Community = IPsec.


That said, https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fbgp-tunnel-encapsulation%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C16410e6ba9194144d6e908dc2502b313%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638425940755803339%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=mStZDjKr4QlIqZ4xCFRJq1VMje4TBHt4KZR%2Bvl108H8%3D&reserved=0<https://www.iana.org/assignments/bgp-tunnel-encapsulation/>
shows IPsec to be deprecated by RFC 9012. This seems to leave you with a bit of a problem!

Skimming draft-ietf-idr-sdwan-edge-discovery, it looks like it handles IPsec by offering sub-TLVs to the SDWAN-Hybrid Tunnel Encapsulation Attribute. Perhaps you just need to rewrite around this?

[AF] OK for your first answer, but 9012 says that the Tunnel Type in the Encapsulation Extended Community and that its semantics are the same as semantics of a Tunnel TLV in a Tunnel Encapsulation attribute.
9012 also says of the Tunnel Encapsulation attribute Tunnel Type that the field contains values from the IANA registry "BGP Tunnel Encapsulation Attribute Tunnel Types" [IANA-BGP-TUNNEL-ENCAP].
And, finally, in 14.2 of 9012, "IPsec in Tunnel-mode (DEPRECATED)".
When I look at the tunnel type registry (above) I don't see any non-deprecated way of indicating IPsec.

So this takes us to the solution potentially offered by draft-ietf-idr-sdwan-edge-discovery and my request that the examples in these sections lean on that draft more clearly.
[Linda] Since this draft is only for describing the user cases, scenarios, provide justification for the protocol extension (draft-ietf-idr-sdwan-edge-discovery), we will remove the protocol types specified by draft-ietf-idr-sdwan-edge-discovery.

 ---

Looks like you have used [SD-WAN-EDGE-Discovery] in a normative way.
That is, you can't do the things suggested in this document until that draft is an RFC.

[Linda] this is an informational draft. here only illustrate as an example.

[AF] I disagree. You are telling us how to use BGP to manage IPsec tunnels in support of SD-WAN. You do so by telling us which component protocols to use. The specifications of those protocols are normative references.
[Linda] then it gets into recursive loop. The BGP Usage is supposed to be the one illustrating the use cases, requirement, and how BGP can be used to control the SD-WAN to justify why protocol extension is needed. The SD-WAN-EDGE-Discovery is the detailed protocol extension.
I can remove the reference to SD-WAN-EDGE-Discovery and use a loose term to state why a new type might be needed.


On the other hand, I did wonder what is the difference between
25      SDWAN-Hybrid
[Linda] over MPLS or IPsec

and
20      Any-Encapsulation
[Linda] Specific type.

While draft-ietf-bess-bgp-multicast-controller that defines Any-Encapsulation seems to be about multicast, I think that the encapsulation type is defined to support multicast or unicast.
[Linda] they are different.

[AF] They are different because 20 allows any specific type while 25 allows only two specific types? So you could do MPLS or IPsec using 20?
[Linda]  I am confused. This document didn't say anything about type = 20. Why need to elaborate 20?

It could be that the answer is how you handle IPsec. Depends on the answer to the previous point.

---

6.

   The procedures described in Section 6 of RFC8388 are applicable
   for the SD-WAN client traffic.

This is true, but surely it only applies to Ethernet-based client services. What about IP services?

[AF] Answer?
[Linda] this section is intended to illustrate a walk through for one exemplary traffic. Not intended for illustrate for all possible client traffic.

[snip]

---

10.1

The reference text of BCP 195 is unusual
[Linda] BCP 195 consists of RFC8996 and RFC9325

[AF] I know that. Have you looked at your text? It says...

   [BCP195]  RFC8996, RFC9325.

That is not a properly formed reference.
[Linda] changed to "BCP 195 consists of RFC8996 and RFC9325"

[snip]