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 <adr...@olddog.co.uk>
Sent: Saturday, February 3, 2024 3:54 PM
To: 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
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.
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
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-boun...@ietf.org<mailto:ietf-announce-boun...@ietf.org>> On
Behalf Of The IESG
Sent: 01 February 2024 16:58
To: IETF-Announce <ietf-annou...@ietf.org<mailto:ietf-annou...@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: 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-c...@ietf.org<mailto:last-c...@ietf.org> mailing lists by 2024-02-15.
Exceptionally, comments may be sent to i...@ietf.org<mailto:i...@ietf.org>
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
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-bess-bgp-sdwan-usage%2F&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C16410e6ba9194144d6e908dc2502b313%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638425940755812038%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=2AgKoIKs%2BO10Rap8YVi1M6AHbnFubxqF6ApCKR%2BE5r8%3D&reserved=0
No IPR declarations have been submitted directly on this I-D.
_______________________________________________
IETF-Announce mailing list
ietf-annou...@ietf.org<mailto:ietf-annou...@ietf.org>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fietf-announce&data=05%7C02%7Clinda.dunbar%40futurewei.com%7C16410e6ba9194144d6e908dc2502b313%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C638425940755818008%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=hCQ%2BJZVIuOBU7NfpU4t%2BNMOvKEwqwP0KPZiN5F3gp2s%3D&reserved=0
_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess
