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 again, Linda.

 

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

 

Best,

Adrian

 

From: Linda Dunbar <[e-mail]> 
Sent: 08 February 2024 01:58
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, 

 

Please see below for the resolutions to your remaining comments. 

 

Thank you very much for the detailed comments. 

 

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

 

===

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

 

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?

 

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

 

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.

 

---

 

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." ?

 

---

 

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.

 

[snip]

 

---

 

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

being) Normative.

 

[AF] Answer?

 

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

For what it is worth, I think there is hardware that can encrypt/decrypt at
line rate on its interfaces.

 

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

 

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.

 

---

 

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"

 

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

 

[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"?

 

---

 

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"

 

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

 

[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.o
rg%2Fassignments%2Fbgp-tunnel-encapsulation%2F
<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%7C0fee8ff2a3b240189c753a1
d5591fedc%7C1%7C0%7C638425940755803339%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wL
jAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=mSt
ZDjKr4QlIqZ4xCFRJq1VMje4TBHt4KZR%2Bvl108H8%3D&reserved=0>
&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C16410e6ba9194144d6e908dc2502b
313%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638425940755803339%7CUnknow
n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
Mn0%3D%7C0%7C%7C%7C&sdata=mStZDjKr4QlIqZ4xCFRJq1VMje4TBHt4KZR%2Bvl108H8%3D&r
eserved=0

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.

 

 ---

 

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.

 

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?

 

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?

 

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

 

[snip]