Re: [bess] Thought about "Application Routing" in draft-dunbar-bess-bgp-sdwan-usage

[Joel M. Halpern]

This wording is better.
there are still two aspects where I think we can be clearer.
First, referring to generic packet forwarding and only later saying "we 
mean tunnel selection" is still prone to confusing readers and prone to 
confusing discussions of our intent later when folks use this document 
for other work.
Second, it would be good if we could avoid wording that implies that 
application identifier is a field in the packet.  Some sort of wording 
that refers to it as a process performed by the SD-WAN edge is one way 
to improve it.   I tried suggesting it was heuristic (which it is) as a 
way to clarify it.  I am sure there are other ways.

Yours,
Joel

On 8/3/2020 1:08 PM, Linda Dunbar wrote:
Joel,
How about this statement?
-      Some traffic flows can be forwarded based on their application 
identifiers instead of based on destination IP addresses, by the edge 
nodes placing the traffic flows onto specific overlay paths based on 
their application requirement.
It is more than " application oriented QoS goals". Some applications are 
restricted to certain nodes. So regardless of the destination, their 
traffic are placed in the Overlay path between those "certain nodes".
Linda
-----Original Message-----
From: Joel Halpern Direct <jmh.dir...@joelhalpern.com>
Sent: Monday, August 3, 2020 11:52 AM
To: Linda Dunbar <linda.dun...@futurewei.com>; adr...@olddog.co.uk; 
'Najem, Basil' <basil.na...@bell.ca>; bess@ietf.org
Cc: draft-dunbar-bess-bgp-sdwan-us...@ietf.org
Subject: Re: [bess] Thought about "Application Routing" in 
draft-dunbar-bess-bgp-sdwan-usage
The way you are wording that third bullet, it looks like it is expecting 
the network (past the SD-WAN edges) to be looking for application 
identifiers in making the packet forwarding decisions.
Is what you are looking for:
    Selection of tunnels to be used for traffic subsets based on
    heuristic application identification to meet application
    oriented QoS goals?
Yours,
Joel
On 8/3/2020 12:35 PM, Linda Dunbar wrote:
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 <j...@joelhalpern.com <mailto:j...@joelhalpern.com>>
Sent: Friday, July 31, 2020 6:35 AM
To: adr...@olddog.co.uk <mailto:adr...@olddog.co.uk>; Linda Dunbar 
<linda.dun...@futurewei.com <mailto:linda.dun...@futurewei.com>>;
'Najem, Basil' <basil.na...@bell.ca <mailto:basil.na...@bell.ca>>; bess@ietf.org 
<mailto:bess@ietf.org>
Cc: draft-dunbar-bess-bgp-sdwan-us...@ietf.org 
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
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 <linda.dun...@futurewei.com 
<mailto:linda.dun...@futurewei.com>>
*Sent:* 30 July 2020 23:34
*To:* Najem, Basil <basil.na...@bell.ca 
<mailto:basil.na...@bell.ca>>; adr...@olddog.co.uk 
<mailto:adr...@olddog.co.uk>
<mailto:adr...@olddog.co.uk>;
bess@ietf.org <mailto:bess@ietf.org> <mailto:bess@ietf.org>
*Cc:* draft-dunbar-bess-bgp-sdwan-us...@ietf.org 
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
*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 <basil.na...@bell.ca <mailto:basil.na...@bell.ca
<mailto:basil.na...@bell.ca <mailto:basil.na...@bell.ca>>>
*Sent:* Tuesday, July 28, 2020 9:46 AM
*To:* adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> 
<mailto:adr...@olddog.co.uk>
<mailto:adr...@olddog.co.uk>; Linda Dunbar
<linda.dun...@futurewei.com <mailto:linda.dun...@futurewei.com
<mailto:linda.dun...@futurewei.com
<mailto:linda.dun...@futurewei.com>>>;
bess@ietf.org <mailto:bess@ietf.org> <mailto:bess@ietf.org> 
<mailto:bess@ietf.org>
*Cc:* draft-dunbar-bess-bgp-sdwan-us...@ietf.org 
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
*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 <adr...@olddog.co.uk 
<mailto:adr...@olddog.co.uk>>
*Sent:* July-28-20 10:07 AM
*To:* Najem, Basil <basil.na...@bell.ca <mailto:basil.na...@bell.ca
<mailto:basil.na...@bell.ca <mailto:basil.na...@bell.ca>>>;
'Linda Dunbar' <linda.dun...@futurewei.com 
<mailto:linda.dun...@futurewei.com>>; bess@ietf.org <mailto:bess@ietf.org>
<mailto:bess@ietf.org> <mailto:bess@ietf.org>
*Cc:* draft-dunbar-bess-bgp-sdwan-us...@ietf.org 
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
*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 <basil.na...@bell.ca <mailto:basil.na...@bell.ca
<mailto:basil.na...@bell.ca <mailto:basil.na...@bell.ca>>>
*Sent:* 28 July 2020 14:28
*To:* adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> 
<mailto:adr...@olddog.co.uk>
<mailto:adr...@olddog.co.uk>; 'Linda Dunbar'
<linda.dun...@futurewei.com <mailto:linda.dun...@futurewei.com
<mailto:linda.dun...@futurewei.com
<mailto:linda.dun...@futurewei.com>>>;
bess@ietf.org <mailto:bess@ietf.org> <mailto:bess@ietf.org> 
<mailto:bess@ietf.org>
*Cc:* draft-dunbar-bess-bgp-sdwan-us...@ietf.org 
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
*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 <adr...@olddog.co.uk 
<mailto:adr...@olddog.co.uk>>
*Sent:* July-28-20 9:19 AM
*To:* 'Linda Dunbar' <linda.dun...@futurewei.com 
<mailto:linda.dun...@futurewei.com>>; Najem, Basil
<basil.na...@bell.ca <mailto:basil.na...@bell.ca
<mailto:basil.na...@bell.ca <mailto:basil.na...@bell.ca>>>;
bess@ietf.org <mailto:bess@ietf.org> <mailto:bess@ietf.org>
<mailto:bess@ietf.org>
*Cc:* draft-dunbar-bess-bgp-sdwan-us...@ietf.org 
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
*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 <linda.dun...@futurewei.com 
<mailto:linda.dun...@futurewei.com>>
*Sent:* 28 July 2020 14:05
*To:* Najem, Basil <basil.na...@bell.ca <mailto:basil.na...@bell.ca
<mailto:basil.na...@bell.ca <mailto:basil.na...@bell.ca>>>;
adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> 
<mailto:adr...@olddog.co.uk>
<mailto:adr...@olddog.co.uk>; bess@ietf.org <mailto:bess@ietf.org> 
<mailto:bess@ietf.org>
<mailto:bess@ietf.org>
*Cc:* draft-dunbar-bess-bgp-sdwan-us...@ietf.org 
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
*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%2Fdat
a 
tracker.ietf.org%2Fdoc%2Fdraft-dunbar-idr-sdwan-edge-discovery%2F&amp
;
data=02%7C01%7Clinda.dunbar%40futurewei.com%7C9eec1ed693124518fec508d
8
3545d5a4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637317921353374
8 
40&amp;sdata=ljuFqIHRJbFcAox2pqZgWSQN6jODGvfT9%2Bn44PR9ta0%3D&amp;res
e
rved=0
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda
t 
atracker.ietf.org%2Fdoc%2Fdraft-dunbar-idr-sdwan-edge-discovery%2F&am
p 
;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C9eec1ed693124518fec508
d
83545d5a4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63731792135337
4 
840&amp;sdata=ljuFqIHRJbFcAox2pqZgWSQN6jODGvfT9%2Bn44PR9ta0%3D&amp;re
s
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 <basil.na...@bell.ca <mailto:basil.na...@bell.ca
<mailto:basil.na...@bell.ca <mailto:basil.na...@bell.ca>>>
Sent: Tuesday, July 28, 2020 7:10 AM
To: adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> 
<mailto:adr...@olddog.co.uk>
<mailto:adr...@olddog.co.uk>; bess@ietf.org <mailto:bess@ietf.org> 
<mailto:bess@ietf.org>
<mailto:bess@ietf.org>
Cc: draft-dunbar-bess-bgp-sdwan-us...@ietf.org 
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
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 <adr...@olddog.co.uk <mailto:adr...@olddog.co.uk
<mailto:adr...@olddog.co.uk <mailto:adr...@olddog.co.uk>>>

Sent: July-28-20 8:01 AM

To: bess@ietf.org <mailto:bess@ietf.org> <mailto:bess@ietf.org> 
<mailto:bess@ietf.org>

Cc: draft-dunbar-bess-bgp-sdwan-us...@ietf.org 
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>
<mailto:draft-dunbar-bess-bgp-sdwan-us...@ietf.org>

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%2Fgit
h 
ub.com%2FAPN-Community%2FIETF108-Side-Meeting-APN&amp;data=02%7C01%7C
l
inda.dunbar%40futurewei.com%7C9eec1ed693124518fec508d83545d5a4%7C0fee
8 
ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637317921353374840&amp;sdata=J0
U
SmGqeVz9pR5MmJRoOdTZFrmmJ8JiSFKAz4wuNgNs%3D&amp;reserved=0
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgi
t 
hub.com%2FAPN-Community%2FIETF108-Side-Meeting-APN&amp;data=02%7C01%7
C 
linda.dunbar%40futurewei.com%7C9eec1ed693124518fec508d83545d5a4%7C0fe
e
8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637317921353374840&amp;sdata=J
0 USmGqeVz9pR5MmJRoOdTZFrmmJ8JiSFKAz4wuNgNs%3D&amp;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
BESS@ietf.org <mailto:BESS@ietf.org> <mailto:BESS@ietf.org>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
ietf.org%2Fmailman%2Flistinfo%2Fbess&amp;data=02%7C01%7Clinda.dunbar%
4 
0futurewei.com%7C9eec1ed693124518fec508d83545d5a4%7C0fee8ff2a3b240189
c 
753a1d5591fedc%7C1%7C0%7C637317921353374840&amp;sdata=6XAaNduwfa3MmKO
C
u8eHydfaNzI%2F1dfgjfrBZiRXL4E%3D&amp;reserved=0


_______________________________________________
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess