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

["Pengshuping (Peng Shuping)" <[e-mail]>]

Dear Gyan,

Truly appreciate your detailed review and constructive suggestions! Thank you very much!

Please find in line below.

From: Gyan Mishra [mailto:[e-mail]]
Sent: Saturday, January 30, 2021 1:49 AM
To: James Guichard <[e-mail]>
Cc: Pengshuping (Peng Shuping) <[e-mail]>; draft-per-app-networking-considerations <[e-mail]>; [e-mail]
Subject: 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.

Shuping> Yes, you are right. It is better to be clearly defined. Please find the updated draft in the APN Github and the diff attached.
Please feel free to make your suggested updates directly on the draft. So we can update it in the next version. Thank you!
https://github.com/APN-Community/APN-Scope-Gap-Analysis

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.

Shuping> Yes, it is good to add this.

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.

Shuping> It is worth discussing about the encoding places of the APN ID. Indeed, the current HBH is not actually usable for now. Does the DOH have the same problem?
Flow label is a good place to encode the APN ID since it is within the IPv6 header. Just it has been standardized to be used for load balancing as specified in https://tools.ietf.org/html/rfc6438. Not sure whether it could be reused for carrying APN ID.

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.

Shuping> Yes, you are right. At the network edge device, the 5-tuple DPI can be used to formulate a APN ID which will be carried within the packets. Then within the operator domain, the APN ID can be used for performance measurement and visualization, etc. We can also trick this paragraph in the draft as well.

In the summary section maybe using the word closed operator domain instead of limited domain.

Shuping> Since “limited domain” is a term in RFC8799, so we used it. But we actually meant to say “closed operator domain”. Maybe we could add a sentence somewhere in the draft saying that the limited domain is the closed operator domain. Please suggest.

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.

Shuping> It is great to know about this real deployment scenario of the Tier1 provider. It will be very important to have this case in the draft, that is, in this scenario, APN could help achieve more performance guarantee along the end to end path.

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.

Shuping> The same as above. Please add this to the draft.

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.

Shuping> We have some use cases in 5G network slice and DETNET, please find them in this draft, https://tools.ietf.org/html/draft-li-apn-problem-statement-usecases-01#page-8. For the case of SD-WAN, we want to show what APN can help in both overlay and underlay, especially for the SD-WAN run by operators. SD-WAN is very important for operators to serve enterprises to access to the Cloud. We have a dedicated draft on the use case of SD-WAN, https://tools.ietf.org/html/draft-yang-apn-sd-wan-usecase-00. With CMCC, we are currently updating the draft. If you have any comments, please feel free to let us know so we can include them in the new version.

Thank you very much!

Best regards,
Shuping



Kind Regards

Gyan
Sent from my iPhone


On Jan 27, 2021, at 8:58 AM, James Guichard <[e-mail]<mailto:[e-mail]>> wrote:

Hi Shuping,

Inline ..

From: Pengshuping (Peng Shuping) <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, January 26, 2021 9:40 PM
To: James Guichard <[e-mail]<mailto:[e-mail]>>; draft-per-app-networking-considerations <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.tools.ietf.org%2Fbof%2Ftrac%2Fwiki%2FWikiStart&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C6618f31adebe4b33616008d8c26cd918%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637473120074542537%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=11d%2FYq9JsFmuBEgJxtwqBJuT57RAEEjQtl4r1WTMxWY%3D&reserved=0>

Please find the updated draft attached (diff) as well as in the APN Github.
https://github.com/APN-Community/APN-Scope-Gap-Analysis<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAPN-Community%2FAPN-Scope-Gap-Analysis&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C6618f31adebe4b33616008d8c26cd918%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637473120074542537%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=IM6SWEaZfTyuGeDqnRsJrwNw%2FI7WQ02JyqkWJl1p77U%3D&reserved=0>

Thank you!

Best regards,
Shuping


From: James Guichard [mailto:[e-mail]]
Sent: Tuesday, January 26, 2021 7:17 PM
To: Pengshuping (Peng Shuping) <[e-mail]<mailto:[e-mail]>>; draft-per-app-networking-considerations <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> On Behalf Of Pengshuping (Peng Shuping)
Sent: Thursday, January 21, 2021 9:08 PM
To: draft-per-app-networking-considerations <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-peng-apn-scope-gap-analysis&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C6618f31adebe4b33616008d8c26cd918%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637473120074552532%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=YbIvQ5%2BqaZ%2F3pdP0bORohEFHnEpqyc0SUxkYu6WvPVs%3D&reserved=0>, 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/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fapn%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C6618f31adebe4b33616008d8c26cd918%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637473120074552532%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VWpJ1hWJOLKpxMGa%2BR7%2FRDnDPOng5fYbXo8Kq9j4T1Y%3D&reserved=0> 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:[e-mail]] On Behalf Of Pengshuping (Peng Shuping)
Sent: Tuesday, December 15, 2020 11:12 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-peng-apn-scope-gap-analysis&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C6618f31adebe4b33616008d8c26cd918%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637473120074562528%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Z1Am4g4glUXFQN%2B9nCa5EfT%2BSv72y2uePbabIfaBbtc%3D&reserved=0>.



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<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-peng-apn-scope-gap-analysis-00.txt&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C6618f31adebe4b33616008d8c26cd918%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637473120074562528%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=LGLvNFJXBaUa16MnoBqXb3zBf%2BVAMqqYZz2o%2BxGWQKQ%3D&reserved=0>

Status:         https://datatracker.ietf.org/doc/draft-peng-apn-scope-gap-analysis/<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-peng-apn-scope-gap-analysis%2F&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C6618f31adebe4b33616008d8c26cd918%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637473120074572521%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eul72kSsRaOdhmLLIhCUPLTwA5ljXCOUazL0%2BMtJn6c%3D&reserved=0>

Htmlized:       https://datatracker.ietf.org/doc/html/draft-peng-apn-scope-gap-analysis<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-peng-apn-scope-gap-analysis&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C6618f31adebe4b33616008d8c26cd918%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637473120074572521%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gEjtLZoxN993ebyBof91g6DCNqIgq%2BCBN1RaMHjv544%3D&reserved=0>

Htmlized:       https://tools.ietf.org/html/draft-peng-apn-scope-gap-analysis-00<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-peng-apn-scope-gap-analysis-00&data=04%7C01%7Cjames.n.guichard%40futurewei.com%7C6618f31adebe4b33616008d8c26cd918%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637473120074582516%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5GhYyQvPE3M6oqJV8duSSYIyYSdEXcCafHGEPjbXFtQ%3D&reserved=0>





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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/apn