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

[Gyan Mishra <[e-mail]>]

Hi Shuping

Most Welcome!!

In-line responses

On Sat, Jan 30, 2021 at 8:36 AM Pengshuping (Peng Shuping) <
[e-mail]> wrote:

> 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
>
> Gyan> Will do.  I would be happy to be Co-Author of the draft.  I  will
> add updates to the draft based on my comments provided.
>
> 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.
>
>  Gyan> I will add to the draft
>
> 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.
>
>  Gyan> I can add some verbiage
>
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.
>
> Gyan> I can update
>
> 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.
>
> Gyan> Sure I can add to the draft
>
> 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.
>
> Gyan> Will do
>
> 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]> wrote:
>
> 
>
> Hi Shuping,
>
>
>
> Inline ..
>
>
>
> *From:* Pengshuping (Peng Shuping) <[e-mail]>
> *Sent:* Tuesday, January 26, 2021 9:40 PM
> *To:* James Guichard <[e-mail]>;
> draft-per-app-networking-considerations <
> [e-mail]>
> *Cc:* [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]
> <[e-mail]>]
> *Sent:* Tuesday, January 26, 2021 7:17 PM
> *To:* Pengshuping (Peng Shuping) <[e-mail]>;
> draft-per-app-networking-considerations <
> [e-mail]>
> *Cc:* [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]> *On Behalf Of *Pengshuping (Peng
> Shuping)
> *Sent:* Thursday, January 21, 2021 9:08 PM
> *To:* draft-per-app-networking-considerations <
> [e-mail]>
> *Cc:* [e-mail]; [e-mail]; [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] <[e-mail]>] *On
> Behalf Of *Pengshuping (Peng Shuping)
> *Sent:* Tuesday, December 15, 2020 11:12 AM
> *To:* [e-mail]; [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]
> https://www.ietf.org/mailman/listinfo/apn
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *



*M 301 502-134713101 Columbia Pike *Silver Spring, MD