Re: [Apn] FW: A new draft on APN for your review, thank you!

Hi Shuping 

I reviewed the APN BOF proposal and have a few comments.  Some of the comments may apply to the gap or other drafts.

5-tuple is mentioned numerous times and it maybe good to define the 5-tuple which I believe you are referencing from IPv6 flow label RFC 6437 which is source / destination IP port and protocol.  In the Gap draft and maybe here maybe worth mentioning flow label meant to be used local significance stateless mode for uniform distribution load balancing 5-tuple used as input key to hash function.  Stateful is where the packet marking happens signals for classification of service.  It maybe possible to use flow label classification for APN ID instead of using HBH or DOH TLV encoding which may be punted to slow path until that processing paradigm changes to improve overall eh processing in the fast path.

As far as the 5-tuple DPI I believe most vendor routers can handle but as you stated the variable for IPv6 is if you have a Christmas tree of extension headers to be shift through to get to the transport layer.  The DPI issue as well is on open internet where you may come across and in those cases as we have seen the hbh or DOH is being dropped filtered or ignored so then the 5-tuple DPI may not be as bad.  For closed operator domains where APN is working as it’s within the operators domain the 5-tuple DPI is not an issue as extension header usage is within the operators control and if using SRv6 SRH they would filter any other EHs do SRH steering is not impacted.

In the summary section maybe using the word closed operator domain instead of limited domain.
Also worth mentioning that the steering benefits of the APN aware SR path instantiation on the head end SR source node only applies within the operators closed domain as myself and Linda brought up and once you exit the fine grain classification for 5G Network slice or DETNET use cases is lost once you exit the operators domain to the public internet.  In general from an APN use case perspective the gains unfortunately are limited with fine grain once your exit the wireless operator 3GPP RAN xHaul to the internet destination all fine grain classification gains are lost the rest of the way the packet travels to its final destination which could be anywhere in the world.  The majority of the entire path maybe on the public internet outside of operators domain depending on some variables of the wireless operator is also a Tier 1  provider like Verizon we could deliver the entire way close to the last mile endpoint still staying within the closed operator domain.  For DETNET use case across a private operator core is most of the hops could be APN aware and only when you are handing off to customer edge last hops would you lose the APN fine granularity.  For DETNET use case on public internet you run into similar closed domain situation as with 5G that as long as you are a Tier 1 or 2 majority of the path to the edge can be protected APN aware.

For the use case example I think using the 5G network slice and DETNET use case would be better than SD WAN example in my opinion as the main use cases for APN.

Kind Regards 

Gyan

Sent from my iPhone

> On Jan 27, 2021, at 8:58 AM, James Guichard <james.n.guichard@futurewei.com> wrote:
> 
> 
> Hi Shuping,
>  
> Inline ..
>  
> From: Pengshuping (Peng Shuping) <pengshuping@huawei.com> 
> Sent: Tuesday, January 26, 2021 9:40 PM
> To: James Guichard <james.n.guichard@futurewei.com>; draft-per-app-networking-considerations <draft-per-app-networking-considerations@ietf.org>
> Cc: apn@ietf.org
> Subject: RE: [Apn] FW: A new draft on APN for your review, thank you!
>  
> Hi James,
>  
> Many thanks for your detailed review! I have accepted most of your comments and suggestions, which are very helpful. Thank you!
>  
> About the following two points, I would like to know about your opinions.
>  
> 1.       I would like to still keep one identifier since we aim to have one composite APN identifier which includes several fields instead of having them as separate identifiers.
>  
> Jim> perhaps I was unclear in my comments. The point is that the identifier can represent > 1 “entity” dependent upon the use case. It may be a single identifier “value” but it should be clear that that value may represent more than a single requirement. If you use the wording “composite APN identifier” then I think this is clearer.
>  
> 2.       I did not explicitly add the “data plane” because the APN identifier will also be exchanged in the control plane to facilitate the service provisioning (e.g. traffic steering and performance measurement, etc.).
>  
> Jim> true and fair enough.
>  
> Please find the updated BoF description.
> https://trac.tools.ietf.org/bof/trac/wiki/WikiStart
>  
> Please find the updated draft attached (diff) as well as in the APN Github.
> https://github.com/APN-Community/APN-Scope-Gap-Analysis
>  
> Thank you!
>  
> Best regards,
> Shuping
>  
>  
> From: James Guichard [mailto:james.n.guichard@futurewei.com] 
> Sent: Tuesday, January 26, 2021 7:17 PM
> To: Pengshuping (Peng Shuping) <pengshuping@huawei.com>; draft-per-app-networking-considerations <draft-per-app-networking-considerations@ietf.org>
> Cc: apn@ietf.org
> Subject: RE: [Apn] FW: A new draft on APN for your review, thank you!
>  
> Hi Shuping,
>  
> Attached some comments and minor editorial corrections that I hope you will find useful.
>  
> Thanks!
>  
> Jim
>  
> From: Apn <apn-bounces@ietf.org> On Behalf Of Pengshuping (Peng Shuping)
> Sent: Thursday, January 21, 2021 9:08 PM
> To: draft-per-app-networking-considerations <draft-per-app-networking-considerations@ietf.org>
> Cc: apn@ietf.org; int-area@ietf.org; rtgwg@ietf.org
> Subject: [Apn] FW: A new draft on APN for your review, thank you!
>  
> Dear authors,
>  
> We have updated the APN BoF Proposal as attached. The suggestions in your draft and the discussions with you offline inspired us a lot. The support of the user/app group is explicitly shown in the text although it was implicitly included. We have made a lot of efforts on clarifying the scope of the work, introducing the basic solution, and describing the concrete use case. Please advise whether we are clear now and how we can improve further, especially on the privacy concerns. Thank you!
>  
> This posted draft, https://datatracker.ietf.org/doc/html/draft-peng-apn-scope-gap-analysis, would be able to give you more complete information. Please also refer to the recent discussions in the archives https://mailarchive.ietf.org/arch/browse/apn/ if you have not subscribed the APN mailing list yet. Based on discussions and suggestions we received, we will update this draft accordingly. Your reviews and comments will be very much appreciated.
>  
> Thank you!
>  
> Best regards,
> Shuping
>  
>  
>  
> From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Pengshuping (Peng Shuping)
> Sent: Tuesday, December 15, 2020 11:12 AM
> To: apn@ietf.org; rtgwg@ietf.org
> Subject: [Apn] A new draft on APN for your review, thank you!
>  
> Dear all,
>  
> A new draft on APN has been posted, https://datatracker.ietf.org/doc/html/draft-peng-apn-scope-gap-analysis.
>  
> In this draft, we clarified the scope of the APN work in IETF, introduced an example use case and the basic solution. Moreover, we compared with the existing “similar” work/solutions and did corresponding gap analysis.
>  
> Your review and comments are very much appreciated. Thank you!
>  
> Best regards,
> Shuping
>  
>  
> A new version of I-D, draft-peng-apn-scope-gap-analysis-00.txt
> has been successfully submitted by Shuping Peng and posted to the IETF repository.
>  
> Name:              draft-peng-apn-scope-gap-analysis
> Revision: 00
> Title:                 APN Scope and Gap Analysis
> Document date:      2020-12-16
> Group:              Individual Submission
> Pages:              11
> URL:            https://www.ietf.org/archive/id/draft-peng-apn-scope-gap-analysis-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-peng-apn-scope-gap-analysis/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-peng-apn-scope-gap-analysis
> Htmlized:       https://tools.ietf.org/html/draft-peng-apn-scope-gap-analysis-00
>  
>  
> Abstract:
>    The APN work in IETF is focused on developing a framework and set of
>    mechanisms to derive, convey and use an identifier to allow for
>    implementing fine-grain user-, application-, and service-level
>    requirements at the network layer.  This document describes the scope
>    of the APN work and the solution gap analysis.
>  
>  
> -- 
> Apn mailing list
> Apn@ietf.org
> https://www.ietf.org/mailman/listinfo/apn