Subject: [Apn] FW: [External] Re: [arch-d] APN (Application-aware Networking) Mailing List

From: <[email-masked]>
Date: Tue, 18 Aug 2020 10:09:17 +0100

From: Architecture-discuss <[email-masked]> On Behalf Of Spencer Dawkins at IETF
Sent: 17 August 2020 19:52
To: Lizhenbin <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [External] Re: [arch-d] APN (Application-aware Networking) Mailing List

This email originated outside the University. Check before clicking links or attachments.

Adding the PANRG chairs, in case I get something wrong about PANRG ... 

On Fri, Aug 14, 2020 at 7:37 PM Joe Touch <[email-masked] <mailto:[email-masked]> > wrote:

This WG appears to be revisiting the issues of the expired trigtran wg. It might be useful to understand why that did not succeed and whether you are asking the same question twice and expecting a different answer. 

Joe. thank you for nudging me on this thread. 

PANRG (https://datatracker.ietf.org/rg/panrg/about/ <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Frg%2Fpanrg%2Fabout%2F&data=02%7C01%7Cd.king%40lancaster.ac.uk%7Cf3df80414d9e4329a2ff08d842dec957%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637332871918266347&sdata=Tg9VKUA2LkLSNrWkEhYKSmK4LENqhUAmA1xbAP%2BnTfY%3D&reserved=0> ) has a draft about the history of Path-Aware Networking (https://datatracker.ietf.org/doc/draft-irtf-panrg-what-not-to-do/ <https://datatracker..ietf.org/doc/draft-irtf-panrg-what-not-to-do/> ), and why most path-aware networking technologies haven't been deployed, although it seems they should have been deployed (especially to the people who proposed them). 

TRIGTRAN specifically is covered in https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-12#section-5.5 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-irtf-panrg-what-not-to-do-12%23section-5.5&data=02%7C01%7Cd.king%40lancaster.ac.uk%7Cf3df80414d9e4329a2ff08d842dec957%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637332871918276293&sdata=ILlxhGKKPRf%2Fb1jU9Gi4v9IvVPUN8yBKY0N6L4vBt5s%3D&reserved=0> , but TRIGTRAN was one of eight technologies considered, and we found enough commonality to justify summarizing what we learned in 12 lessons (https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-12#section-2 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-irtf-panrg-what-not-to-do-12%23section-2&data=02%7C01%7Cd.king%40lancaster.ac.uk%7Cf3df80414d9e4329a2ff08d842dec957%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637332871918276293&sdata=rrgMWiFCTSMd%2Fs30xtQ2%2BhKdMac4avJyaehlYiU27yo%3D&reserved=0> ), and then considering whether what we've learned is still relevant (https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-12#section-3 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-irtf-panrg-what-not-to-do-12%23section-3&data=02%7C01%7Cd.king%40lancaster.ac.uk%7Cf3df80414d9e4329a2ff08d842dec957%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637332871918286260&sdata=LnZuyulU7uqLEtIypz6hpl3iW%2FkFGyJXAx261f5mVYI%3D&reserved=0> ). Some are, some aren't. 

This document doesn't have any standing in the IETF, other than providing information, but I hope it's helpful for you (full disclosure, I'm the editor).

Best,

Spencer

Joe

> On Aug 12, 2020, at 9:25 PM, Lizhenbin <[email-masked] <mailto:[email-masked]> > wrote:
> 
> Hi Folks,
> 
> The APN mailing list has been created. If you have interest in the work, please subscribe.
> 
> List address: [email-masked] <mailto:[email-masked]> 
> Archive: https://mailarchive.ietf.org/arch/browse/apn <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fapn&data=02%7C01%7Cd.king%40lancaster.ac.uk%7Cf3df80414d9e4329a2ff08d842dec957%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637332871918286260&sdata=%2F1ao5J2uRqGeBbEzIZ9%2BjBG0OCSynGnROUDhjEgBcsw%3D&reserved=0> 
> To subscribe: https://www.ietf.org/mailman/listinfo/apn <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fapn&data=02%7C01%7Cd.king%40lancaster.ac.uk%7Cf3df80414d9e4329a2ff08d842dec957%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637332871918286260&sdata=NO6q1VztegN7jvxh36PjA45zfkv4r6xk2%2B6PTIissAU%3D&reserved=0> 
> 
> Purpose:
> This email list is the discussion list for the Application-aware Networking (APN). Application-aware Networking is a mechanism whereby traffic flows can be steered and routed within the network to ensure that the specific service levels needed by applications can be delivered.  
> 
> This list belongs to IETF area: RTG
> 
> 
> Look forward to going on to have more discussion in the mailing list.
> 
> 
> 
> Best regards, 
> Zhenbin (Robin)
> 
> 
> 
> ________________________________________
> 发件人: Architecture-discuss [[email-masked] <mailto:[email-masked]> ] 代表 Lizhenbin [[email-masked] <mailto:[email-masked]> ]
> 发送时间: 2020年7月29日 0:17
> 收件人: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
> 抄送: [email-masked] <mailto:[email-masked]> 
> 主题: [arch-d] APN (Application-aware Networking) Side Meeting
> 
> Hi All,
> We will have the APN side meeting at 12:30 - 14:00 UTC on July 30 (Thursday). The agenda and the WebEx information is provided in the following link.
> https://github.com/APN-Community/IETF108-Side-Meeting-APN <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAPN-Community%2FIETF108-Side-Meeting-APN&data=02%7C01%7Cd.king%40lancaster.ac.uk%7Cf3df80414d9e4329a2ff08d842dec957%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637332871918296209&sdata=q0qRltwYw%2BPQkbSnTNyjHqfuKCb30mB%2BiV35oDOl0jI%3D&reserved=0> 
> 
> There has been several similar work like APN such as SPUD and PLUS. Recently Network Token work was also proposed. The side meeting is to try to clarify the scope of APN comparing with other work. The possible usecases are also proposed for the APN work. Another goal of the side meeting is to clarify the security and privacy issues which are always proposed against such application-ware networking work. In RTGWG session held yesterday, the presentation of APN work discussed the possible scenarios related with the security and privacy issues. The following slides is for your reference:
> https://www.ietf.org/proceedings/108/slides/slides-108-rtgwg-8-rtgwg-apn6-01 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fproceedings%2F108%2Fslides%2Fslides-108-rtgwg-8-rtgwg-apn6-01&data=02%7C01%7Cd.king%40lancaster.ac.uk%7Cf3df80414d9e4329a2ff08d842dec957%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637332871918296209&sdata=OJh2urJmlvVjUFzga8%2FE7KlltKBgDY6rL83Yc7uz7k8%3D&reserved=0> 
> 
> Since it is a complex cross-area work and there is much background information, wish you could join the side meeting if you have interest in the work and your comments and suggestions are appreciated.
> 
> 
> Best Regards,
> Daniel & Zhenbin (Robin)
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked] <mailto:[email-masked]> 
> https://www.ietf.org/mailman/listinfo/architecture-discuss <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Farchitecture-discuss&data=02%7C01%7Cd.king%40lancaster.ac.uk%7Cf3df80414d9e4329a2ff08d842dec957%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637332871918306166&sdata=Vb%2FUuRJPJcpK3syIwVcYV221%2BTs9TPSOcspp8LmKT8w%3D&reserved=0> 
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked] <mailto:[email-masked]> 
> https://www.ietf.org/mailman/listinfo/architecture-discuss <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Farchitecture-discuss&data=02%7C01%7Cd.king%40lancaster.ac.uk%7Cf3df80414d9e4329a2ff08d842dec957%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637332871918306166&sdata=Vb%2FUuRJPJcpK3syIwVcYV221%2BTs9TPSOcspp8LmKT8w%3D&reserved=0> 

_______________________________________________
Architecture-discuss mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/architecture-discuss <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Farchitecture-discuss&data=02%7C01%7Cd.king%40lancaster.ac.uk%7Cf3df80414d9e4329a2ff08d842dec957%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637332871918306166&sdata=Vb%2FUuRJPJcpK3syIwVcYV221%2BTs9TPSOcspp8LmKT8w%3D&reserved=0>

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 18 Aug 2020 10:33:22 +0100

Dan, thanks for forwarding this to the APN list.

I think it is important both to learn from history and not to simply repeat work that has already been done.

But in doing this, we should also understand the difference between the work of PANRG and APN. In some senses the way in which the application interacts with the lower layers may be the same: it classes its traffic flows and selects the network characteristics it wants for the traffic. But the difference appears (to me) to be that PANRG is concerned with selecting between transport-layer ‘paths’ for flows, while APN is concerned with routing packets that belong to the same flow.

Am I confused about this distinction?

The distinction is, I think, fairly fundamental with respect to how the behaviors might be delivered by the network. But:

*	The ways that the applications might communicate with the lower layers could be very similar (see also Network Tokens)
*	It is possible that the PANRG work might be ‘stacked’ over the APN work

Best,

Adrian

From: Apn <[email-masked]> On Behalf Of [email-masked]
Sent: 18 August 2020 10:09
To: [email-masked]
Subject: [Apn] FW: [External] Re: [arch-d] APN (Application-aware Networking) Mailing List

From: Architecture-discuss <[email-masked] <mailto:[email-masked]> > On Behalf Of Spencer Dawkins at IETF
Sent: 17 August 2020 19:52
To: Lizhenbin <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> 
Subject: [External] Re: [arch-d] APN (Application-aware Networking) Mailing List

TRIGTRAN specifically is covered in https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-12#section-5.5 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-irtf-panrg-what-not-to-do-12%23section-5..5&data=02%7C01%7Cd.king%40lancaster.ac.uk%7Cf3df80414d9e4329a2ff08d842dec957%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637332871918276293&sdata=ILlxhGKKPRf%2Fb1jU9Gi4v9IvVPUN8yBKY0N6L4vBt5s%3D&reserved=0> , but TRIGTRAN was one of eight technologies considered, and we found enough commonality to justify summarizing what we learned in 12 lessons (https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-12#section-2 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-irtf-panrg-what-not-to-do-12%23section-2&data=02%7C01%7Cd.king%40lancaster.ac.uk%7Cf3df80414d9e4329a2ff08d842dec957%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637332871918276293&sdata=rrgMWiFCTSMd%2Fs30xtQ2%2BhKdMac4avJyaehlYiU27yo%3D&reserved=0> ), and then considering whether what we've learned is still relevant (https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-12#section-3 <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-irtf-panrg-what-not-to-do-12%23section-3&data=02%7C01%7Cd.king%40lancaster.ac.uk%7Cf3df80414d9e4329a2ff08d842dec957%7C9c9bcd11977a4e9ca9a0bc734090164a%7C0%7C1%7C637332871918286260&sdata=LnZuyulU7uqLEtIypz6hpl3iW%2FkFGyJXAx261f5mVYI%3D&reserved=0> ). Some are, some aren't. 

Best,

Spencer

Joe