Adrian and Joel,
Thank you very much for the suggestions.
I have updated the description per your suggested wording:
/Here are some key characteristics of “SDWAN” networks:/
/- Augment of transport, which refers to utilizing overlay paths
over different underlay networks. Very often there are multiple parallel
overlay paths between any two SDWAN edges, some of which are private
networks over which traffic can traverse with or without encryption,
others require encryption, e.g. over untrusted public networks. /
/- Enable direct Internet access from remote sites, instead
hauling all traffic to Corporate HQ for centralized policy control. /
/- Some traffic flows can be forwarded based on their application
identifiers instead of based on destination IP addresses. For example,
by placing the traffic flows onto specific overlay paths based on their
application IDs. /
/- The traffic flows forwarding can also be based on specific
performance criteria (e.g. packets delay, packet loos, jitter) to
provide better application performance by choosing the right underlay
that meets or exceeds the specified criteria./
Thank you very much.
Linda
-----Original Message-----
From: Joel M. Halpern <[email protected]>
Sent: Friday, July 31, 2020 6:35 AM
To: [email protected]; Linda Dunbar <[email protected]>;
'Najem, Basil' <[email protected]>; [email protected]
Cc: [email protected]
Subject: Re: [bess] Thought about "Application Routing" in
draft-dunbar-bess-bgp-sdwan-usage
So Adrian does not feel like is a lone voice, let me agree publicly that
the terminology you are using is either wrong or more likely ambiguous
as to its purpose. If you really want to use the term, define it
explicitly please.
Yours,
Joel
On 7/31/2020 4:34 AM, Adrian Farrel wrote:
Hi Linda,
Thank you so much for continuing to try to accommodate me. Please
consider this my last attempt to fix this unless someone else on the
mailing list joins in to support my opinion.
I do not believe the term “application forwarding” is either defined
in the document or particularly meaningful. It is no better than
“application routing” in this respect.
I think that you are trying to refer to “individual traffic flows
associated with a specific application” (although you may intend to
refer to “individual packets”). And you are either trying to describe
how traffic is “classified” onto paths/tunnels (as in bullet 3) or
trying to indicate how packets may be handled within the network
(possibly bullet 4), or both.
You also have the use of an application identifier as a mechanism to
classify traffic. If you go down that path you must discuss privacy
and netneutrality even if all you have to say is that this function
takes place within a private (enterprise) network where all users are
assumed to be required to comply with the network operator’s usage rules.
I’ll stop now.
Once again, thanks for trying to make me happy 😊
Best,
Adrian
*From:*Linda Dunbar <[email protected]
<mailto:[email protected]>>
*Sent:* 30 July 2020 23:34
*To:* Najem, Basil <[email protected] <mailto:[email protected]>>; [email protected]
<mailto:[email protected]>;
[email protected] <mailto:[email protected]>
*Cc:* [email protected]
<mailto:[email protected]>
*Subject:* RE: Thought about "Application Routing" in
draft-dunbar-bess-bgp-sdwan-usage
Adrian,
Thank you very much for the comments and suggestions.
Per your suggestions, we have changed the wording to the following. Do
you think it is clear?
Here are some key characteristics of “SDWAN” networks:
-Augment of transport, which refers to utilizing overlay paths over
different underlay networks. Very often there are multiple parallel
overlay paths between any two SDWAN edges, some of which are private
networks over which traffic can traverse with or without encryption,
others require encryption, e.g. over untrusted public networks.
-Enable direct Internet access from remote sites, instead hauling all
traffic to Corporate HQ for centralized policy control.
-Some traffic can be forwarded based on their application IDs instead
of based on destination IP addresses. For example, placing traffic
onto specific overlay paths based on their application IDs.
-The Application forwarding can also be based on specific performance
criteria (e.g. packets delay, packet loos, jitter) to provide better
application performance by choosing the right underlay that meets or
exceeds the specified criteria.
If it is not clear, can you help to wordsmith it?
Linda Dunbar
*From:*Najem, Basil <[email protected] <mailto:[email protected]
<mailto:[email protected] <mailto:[email protected]>>>
*Sent:* Tuesday, July 28, 2020 9:46 AM
*To:* [email protected] <mailto:[email protected]>
<mailto:[email protected]>; Linda Dunbar
<[email protected] <mailto:[email protected]
<mailto:[email protected] <mailto:[email protected]>>>;
[email protected] <mailto:[email protected]> <mailto:[email protected]>
*Cc:* [email protected]
<mailto:[email protected]>
<mailto:[email protected]>
*Subject:* RE: Thought about "Application Routing" in
draft-dunbar-bess-bgp-sdwan-usage
Hi Adrian;
Given the context in the document, I’d revert back to the original
paragraph (my proposed text in the thread) and change “route/routed”
to “forward/forwarded”.
Regards;
Basil
*From:*Adrian Farrel <[email protected]
<mailto:[email protected]>>
*Sent:* July-28-20 10:07 AM
*To:* Najem, Basil <[email protected] <mailto:[email protected]
<mailto:[email protected] <mailto:[email protected]>>>;
'Linda Dunbar' <[email protected]
<mailto:[email protected]>>; [email protected] <mailto:[email protected]>
<mailto:[email protected]>
*Cc:* [email protected]
<mailto:[email protected]>
<mailto:[email protected]>
*Subject:* [EXT]RE: Thought about "Application Routing" in
draft-dunbar-bess-bgp-sdwan-usage
The issue I am trying to get at is that the text you have in the draft
is unclear and probably going to explode.
* We have an approximate solution for that
The secondary issue is whether you are talking about
routing/forwarding within the network, or placing the traffic onto tunnels at the edge.
* You are pretty clear on what you mean, and I am fine with that since
it fits with my understanding of VPN.
* Possibly Linda is thinking about how those tunnels are maintained
and operated to meet the service levels that they offer. That would
be (I think) out of scope for a BGP VPN
Maybe we can polish the paragraph in question to become…
Better user experience can be provided by placing traffic flows for an
application onto tunnels over an underlay network that meet or exceed
the specified performance criteria (e.g., packets delay, packet lose,
jitter) for those traffic flows.
Cheers,
Adrian
*From:*Najem, Basil <[email protected] <mailto:[email protected]
<mailto:[email protected] <mailto:[email protected]>>>
*Sent:* 28 July 2020 14:28
*To:* [email protected] <mailto:[email protected]>
<mailto:[email protected]>; 'Linda Dunbar'
<[email protected] <mailto:[email protected]
<mailto:[email protected] <mailto:[email protected]>>>;
[email protected] <mailto:[email protected]> <mailto:[email protected]>
*Cc:* [email protected]
<mailto:[email protected]>
<mailto:[email protected]>
*Subject:* RE: Thought about "Application Routing" in
draft-dunbar-bess-bgp-sdwan-usage
Let’s get back to what SD-WAN is doing: it can steer/forward the
application traffic based on specified performance criteria value
requirement. This criteria is set by the subscriber (user) to ensure a
better experience (by choosing the best tunnel over an underlay). Not
sure what’s the issue here Adrian? Can we capture this statement as
per your suggestion and remove the word “route” (or routed) and
replace it with “forward” (or forwarded)?
Regards;
Basil
*From:*Adrian Farrel <[email protected]
<mailto:[email protected]>>
*Sent:* July-28-20 9:19 AM
*To:* 'Linda Dunbar' <[email protected]
<mailto:[email protected]>>; Najem, Basil
<[email protected] <mailto:[email protected]
<mailto:[email protected] <mailto:[email protected]>>>;
[email protected] <mailto:[email protected]>
<mailto:[email protected]>
*Cc:* [email protected]
<mailto:[email protected]>
<mailto:[email protected]>
*Subject:* [EXT]RE: Thought about "Application Routing" in
draft-dunbar-bess-bgp-sdwan-usage
Thanks to both Linda and Basil,
My response is a little unthought as I am currently following two
simultaneous sessions (sorry about that), but it seems to me that the
answers from the two of you seem to be slightly at odds.
Basil is talking about steering whole traffic flows onto tunnels to be
carried over the network; Linda is talking about routing individual
packets within the network.
I would still caution you to avoid tying too tightly to the term
“application”. A single application may generate multiple flows with
different performance criteria and you will treat the flows differently.
Conversely, two applications may generate flows that have identical
performance criteria.
Thanks,
Adrian
*From:*Linda Dunbar <[email protected]
<mailto:[email protected]>>
*Sent:* 28 July 2020 14:05
*To:* Najem, Basil <[email protected] <mailto:[email protected]
<mailto:[email protected] <mailto:[email protected]>>>;
[email protected] <mailto:[email protected]>
<mailto:[email protected]>; [email protected] <mailto:[email protected]>
<mailto:[email protected]>
*Cc:* [email protected]
<mailto:[email protected]>
<mailto:[email protected]>
*Subject:* RE: Thought about "Application Routing" in
draft-dunbar-bess-bgp-sdwan-usage
Adrian,
You said:
/As will be seen from the Application Aware Networking (APN) effort,
the concept of traffic flows being routed according to the identity of
the application is made complicated by various privacy and security
concerns, not to mention issues of registering application
identities./
The "Application" doesn't necessary mean all the bits in the payload.
The "Application" can be any criteria that Client has indicated to
Network Operators, for example the IPsec SA header bits, the TCP/UDP
port number, the Source Addresses, etc.
The network will not alter the forwarding behavior unless there is the
request from the client to inform the network to forward their traffic
based on its provided criteria.
This draft, which was written 2 years ago, is indeed to show that BGP
can be effectively used to “/do something similar to APN: that is, to
classify the service that a particular application-sourced flow wants
to receive from the network”./
Since SDWAN is over different types of underlay networks, with
different performance and security aspects, clients may want their
specific traffic to traverse specific underlay networks, or specific peers.
Yes, indeed that the goal is to “ the packets are 'coloured' for
routing and treatment in the network.”
There is another draft in IDR to describe the encoding “Color” or
“IPsec SA ID”:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
tracker.ietf.org%2Fdoc%2Fdraft-dunbar-idr-sdwan-edge-discovery%2F&
data=02%7C01%7Clinda.dunbar%40futurewei.com%7C9eec1ed693124518fec508d8
3545d5a4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6373179213533748
40&sdata=ljuFqIHRJbFcAox2pqZgWSQN6jODGvfT9%2Bn44PR9ta0%3D&rese
rved=0
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdat
atracker.ietf.org%2Fdoc%2Fdraft-dunbar-idr-sdwan-edge-discovery%2F&
;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C9eec1ed693124518fec508d
83545d5a4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637317921353374
840&sdata=ljuFqIHRJbFcAox2pqZgWSQN6jODGvfT9%2Bn44PR9ta0%3D&res
erved=0>
Welcome your comments to that draft.
I will attend the APN side meeting on Thurs to understand more.
Linda Dunbar
-----Original Message-----
From: Najem, Basil <[email protected] <mailto:[email protected]
<mailto:[email protected] <mailto:[email protected]>>>
Sent: Tuesday, July 28, 2020 7:10 AM
To: [email protected] <mailto:[email protected]>
<mailto:[email protected]>; [email protected] <mailto:[email protected]>
<mailto:[email protected]>
Cc: [email protected]
<mailto:[email protected]>
<mailto:[email protected]>
Subject: RE: Thought about "Application Routing" in
draft-dunbar-bess-bgp-sdwan-usage
Thanks Adrian for your comment.
How about changing the paragraph to something like:
"The application can be routed based on specific performance criteria
(e.g. packets delay, packet lose, jitter) to provide a better
experience by choosing a tunnel over an underlay that meets or exceeds
the specified performance criteria threshold for that application"
Regards;
Basil
-----Original Message-----
From: Adrian Farrel <[email protected] <mailto:[email protected]
<mailto:[email protected] <mailto:[email protected]>>>
Sent: July-28-20 8:01 AM
To: [email protected] <mailto:[email protected]> <mailto:[email protected]>
Cc: [email protected]
<mailto:[email protected]>
<mailto:[email protected]>
Subject: [EXT]Thought about "Application Routing" in
draft-dunbar-bess-bgp-sdwan-usage
Hi,
As Linda noted in her agenda slot today,
draft-dunbar-bess-bgp-sdwan-usage version 08 introduced a new
paragraph in the Introduction that says:
- The Application Routing can also be based on specific
performance criteria (e.g. packets delay, packet loos, jitter)
to provide better application performance by choosing the
right
underlay that meets or exceeds the specified criteria.
Firstly, s/loos/loss/ 😊
But I am concerned by the concept of "application routing" and I note
that the term is not used elsewhere in the document nor is the concept
expanded upon.
As will be seen from the Application Aware Networking (APN) effort,
the concept of traffic flows being routed according to the identity of
the application is made complicated by various privacy and security
concerns, not to mention issues of registering application identities.
Fortunately, I suspect that this draft wants to do something similar
to
APN: that is, to classify the service that a particular
application-sourced flow wants to receive from the network. This may
be considerably more complex than DSCP, but the concept is the same
that either a tunnel/pipe/flow is negotiated and established for use
by the application, or the packets are 'coloured' for routing and
treatment in the network.
I would suggest two things:
1. Be a lot more clear about what is meant by "application routing"
possibly even using a different term 2. Have a look at the APN work -
side meeting on Thursday; see
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
ub.com%2FAPN-Community%2FIETF108-Side-Meeting-APN&data=02%7C01%7Cl
inda.dunbar%40futurewei.com%7C9eec1ed693124518fec508d83545d5a4%7C0fee8
ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637317921353374840&sdata=J0U
SmGqeVz9pR5MmJRoOdTZFrmmJ8JiSFKAz4wuNgNs%3D&reserved=0
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit
hub.com%2FAPN-Community%2FIETF108-Side-Meeting-APN&data=02%7C01%7C
linda.dunbar%40futurewei.com%7C9eec1ed693124518fec508d83545d5a4%7C0fee
8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637317921353374840&sdata=J0
USmGqeVz9pR5MmJRoOdTZFrmmJ8JiSFKAz4wuNgNs%3D&reserved=0>
for all the details
Best,
Adrian
----------------------------------------------------------------------
--------
External Email: Please use caution when opening links and attachments
/ Courriel externe: Soyez prudent avec les liens et documents joints
----------------------------------------------------------------------
--
*/External Email:/*/Please use caution when opening links and
attachments / /*/Courriel externe:/*/Soyez prudent avec les liens et
documents joints /
----------------------------------------------------------------------
--
*/External Email:/*/Please use caution when opening links and
attachments / /*/Courriel externe:/*/Soyez prudent avec les liens et
documents joints /
_______________________________________________
BESS mailing list
[email protected] <mailto:[email protected]>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
ietf.org%2Fmailman%2Flistinfo%2Fbess&data=02%7C01%7Clinda.dunbar%4
0futurewei.com%7C9eec1ed693124518fec508d83545d5a4%7C0fee8ff2a3b240189c
753a1d5591fedc%7C1%7C0%7C637317921353374840&sdata=6XAaNduwfa3MmKOC
u8eHydfaNzI%2F1dfgjfrBZiRXL4E%3D&reserved=0