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 <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
===
<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.
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.
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.
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?
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.
---
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?
---
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.
---
3.1.4
It might be helpful to move the definition of ZTP from the last para in the section to be the first.
[Linda] changed.
---
3.1.5
OLD
edges' loopback address
NEW1
edges' loopback addresses
NEW2
edge's loopback address
END
[Linda] Thanks.
---
3.1.5
One SD-WAN edge node may only be authorized to communicate with a
small number of other SD-WAN edge nodes. In this circumstance, the
property of the SD-WAN edge node cannot be propagated to other
nodes that are not authorized to communicate.
Why "cannot" instead of "need not"?
[Linda] Should not.
after all, if two nodes are not authorized to communicate then any attempt to communicate will fail authorization policy checks. The knowledge of edge node properties is useless, but harmless (except possibly for scaling issues). Unless, of course, you
are proposing "authorization by obscurity".
---
3.1.5
s/insecure/unsecured/
[Linda] changed.
---
3.1.5
The text should make reference to the figure.
The figure is the first mention of "peer groups"
[Linda] change the word in the figure to “Authorized peers”
---
I feel that the references to [SECURE-EVPN] are (or are very close to
being) Normative.
---
3.2
Figure 2 needs some tidying up.
The figure should be referenced from the text.
The key to the figure is the first and only mention of NVo3 in the document. The IETF appears to use "NVO3". You should either correct that, expand the abbreviation, and provide a citation, or simply drop the text.
[Linda] Add the reference.
---
3.3
Please expand "SLA"
[Linda] Added.
---
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.
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.
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.
---
3.3
Suppose a flow traversing multiple segments, such as A<->B<->C<-
>D, has Policy 2) above. The flow can cross different underlays in
different segments, such as over Private underlay between A<->B
without encryption or over the public Internet between B<->C
protected by an IPsec SA.
This is not the same use of "segment" as in 3.1.1 or 3.1.3, or is it?
In any case, surely the SD-WAN edge only has control over the edge function. Thus, if there is the possibility that one segment will be over the public Internet, the SD-WAN edge is going to need to perform end-to-end encryption (meaning that traffic over
the private segments is also encrypted. That is, the SD-WAN edge, while it can choose the forwarding path out of its various ports, cannot control whether some transit PE (possibly an ASBR) provides additional function (such as encryption over the segment).
Of course, it may be that you do not mean "Suppose a flow traversing multiple segments, such as A<->B<->C<->D". You might mean, "Suppose a service includes flows traversing multiple segments, such as A<->B, A<->D, C<->B, and C<->D as shown in Figure 3".
But I am only guessing.
[Linda] Your guess is correct. I have changed the text. Thank you.
---
3.4
This scenario refers to an existing VPN (e.g., EVPN or IPVPN)
Need citations for EVPN and IPVPN, and should probably expand EVPN.
[Linda] added the reference.
---
3.4
Figure 4 is a bit messy. It should be referenced from the text.
[Linda] added.
---
4.1
Client service provisioning can follow the same approach as MPLS
VRFs. A client VPN can establish the communication policy by
specifying the Route Targets to be imported and exported.
Alternatively, traditional Match and Action ACLs can identify the
specific routes allowed or denied to or from the client VPN.
"Route Target" needs to be set in the context of BGP.
Please expand "ACL" and give a citation.
[Linda] added.
---
4.3
Section title needs to be in Title Case.
[Linda] Changed.
---
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.
---
4.3
Each SD-WAN edge may have
the default values assigned to them for the respective attributes.
Maybe...
Each SD-WAN edge may have
default values configured for the IPsec parameters.
[Linda] changed.
---
4.3
For
a BGP-controlled SD-WAN, BGP UPDATE messages can propagate each
node's IPsec-related attribute values for peers to choose the
common values supported, traditionally done by IPsec IKEv2
[RFC7296].
The codicil to this paragraph seems misplaced. I guess you are saying that the choice is notified to the peer using IKEv2? Or something else?
[Linda] In the context of a BGP-controlled SD-WAN, BGP UPDATE messages can disseminate IPsec-related attribute values for each node, facilitating peer selection of mutually supported values—instead of the process facilitated by IPsec
IKEv2 [RFC7296]
---
Section 5 reminded me of the name of this document. But page 14 is a long way in before we get to the point. So, I think that, possibly, the document title (and Abstract and Introduction) are a bit off target.
Probably you have something like...
An Introduction to SD-WAN Use Cases, Provisioning, and Forwarding
[Linda] Add the sentence to the Introduction section:
This document describes the SD-WAN Use Cases, Provisioning, and forwarding. It outlines the utilization of BGP as a control plane for SD-WAN overlay networks and service…
---
5.1
When multiple IPsec tunnels are established between two pairwise
edge nodes
I don't know what a "pairwise edge node" is. Do you mean:
When multiple IPsec tunnels are established between two edge nodes
[Linda] Yes. The IPsecme group like to use “pairwise key”. Changed.
---
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”
---
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.
---
5.2
Alternatively, the C-PE2 can use two separate BGP UPDATE messages
to reduce the size of the BGP UPDATE messages, especially for
IPsec tunnels terminated at edge nodes or WAN ports, as IPsec SA
tunnels have many attributes which can change at different
frequencies than clients' routes updates, such as IPsec SA keys
periodical changes.
I think that is s/updates/update/ and s/periodical/periodic/
[Linda] Changed.
---
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)
---
5.2
s/UPdATE U2:/UPDATE U2:/
s/as described in the [SECURE-EVPN]/as described in [SECURE-EVPN]/ s/Color-Extended-Community/Color Extended Community/ s/client routes policies/client routes' policies/ s/UPDATE messages propagation/UPDATE message propagation/
[Linda] changed.
---
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.
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?
---
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.
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.
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?
---
6.2.2
The figure is messed up
The figure needs a title and a number
The figure should be cited from the text
[Linda] corrected.
---
10.1
The reference text of BCP 195 is unusual
[Linda] BCP 195 consists of RFC8996 and RFC9325
---
10.2
The reference for 802.3 seems incomplete
[Linda] fixed.
---
-----Original Message-----
From: IETF-Announce <ietf-announce-bounces@xxxxxxxx> On Behalf Of The IESG
Sent: 01 February 2024 16:58
To: IETF-Announce <ietf-announce@xxxxxxxx>
Cc: andrew-ietf@xxxxxxxxxxx; bess-chairs@xxxxxxxx; bess@xxxxxxxx; draft-ietf-bess-bgp-sdwan-usage@xxxxxxxx;
matthew.bocci@xxxxxxxxx
Subject: Last Call: <draft-ietf-bess-bgp-sdwan-usage-19.txt> (BGP Usage for SD-WAN Overlay Networks) to Informational RFC
The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - 'BGP Usage for SD-WAN Overlay Networks'
<draft-ietf-bess-bgp-sdwan-usage-19.txt> as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@xxxxxxxx mailing lists by 2024-02-15. Exceptionally, comments
may be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of the Subject line to allow automated sorting.
Abstract
The document discusses the usage and applicability of BGP as the
control plane for multiple SD-WAN scenarios. The document aims to
demonstrate how the BGP-based control plane is used for large-
scale SD-WAN overlay networks with little manual intervention.
SD-WAN edge nodes are commonly interconnected by multiple types of
underlay networks owned and managed by different network
providers.
The file can be obtained via
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
