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> 
Sent: 28 July 2020 14:28
To: adr...@olddog.co.uk; 'Linda Dunbar' <linda.dun...@futurewei.com>; 
bess@ietf.org
Cc: 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> 
Sent: July-28-20 9:19 AM
To: 'Linda Dunbar' <linda.dun...@futurewei.com>; Najem, Basil 
<basil.na...@bell.ca>; bess@ietf.org
Cc: 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> >; 
adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> ; 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: 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://datatracker.ietf.org/doc/draft-dunbar-idr-sdwan-edge-discovery/

 

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> > 
Sent: Tuesday, July 28, 2020 7:10 AM
To: adr...@olddog.co.uk <mailto:adr...@olddog.co.uk> ; 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: 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> > 

Sent: July-28-20 8:01 AM

To: 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: [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%2Fgithub.com%2FAPN-Community%2FIETF108-Side-Meeting-APN
 
<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAPN-Community%2FIETF108-Side-Meeting-APN&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C456da5e6ae9e4fc3ff6808d832ef2ef0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637315350161504633&amp;sdata=B4QkVHS%2FkUs%2BWFZgAFQ64BDIhNlIqYxnSrlQNOx%2Bblg%3D&amp;reserved=0>
 
&amp;data=02%7C01%7Clinda.dunbar%40futurewei.com%7C456da5e6ae9e4fc3ff6808d832ef2ef0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637315350161504633&amp;sdata=B4QkVHS%2FkUs%2BWFZgAFQ64BDIhNlIqYxnSrlQNOx%2Bblg%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 

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

Reply via email to