ShuPing, What kind of features are included in the APN control plane?
I am under the impression that APN is about encoding some Application related metadata within the packets, is it correct? Once an application flow is mapped to an SR-TE path, the intermediate nodes along the SR-TE path don't really check the anything carried by the packets, which defeats the purpose of having the packets carrying those additional metadata, isn't it? It seems making more sense for the Ingress node to pass those Application related metadata, which are actually encoded by the client nodes, to its controller for creating an optimal path for the application flow. What do you think? My two cents, Linda Dunbar From: Pengshuping (Peng Shuping) <[email protected]> Sent: Monday, January 18, 2021 8:22 PM To: Gyan Mishra <[email protected]>; Linda Dunbar <[email protected]> Cc: [email protected]; [email protected] Subject: RE: [Apn] A new draft on APN for your review, thank you! Hi Linda, Gyan, Yes, the APN control remains within the SR closed domain. Based on the APN characteristics the traffic is steered into an SR-TE path or a network slice. Once the traffic leaves this limited domain, the APN characteristics can be removed. We also described an use case on SD-WAN (run by operators) in this new draft. It would be good if we could get your views. Thank you! Best regards, Shuping From: Gyan Mishra [mailto:[email protected]] Sent: Tuesday, January 19, 2021 9:01 AM To: Linda Dunbar <[email protected]<mailto:[email protected]>> Cc: Pengshuping (Peng Shuping) <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [Apn] A new draft on APN for your review, thank you! Hi Linda On Mon, Jan 18, 2021 at 6:18 PM Linda Dunbar <[email protected]<mailto:[email protected]>> wrote: Gyan, You stated that .... the app aware head end can map to an appropriately steered SR-TE path that can now be instantiated to meet the new fine grain value added service customer SLA requirement at a premium cost. Do you assume that the SR-TE goes from the "app aware head end" to the destination of the "app"? Good question and my response was a bit confusing as the demarkation customer side versus operator side. My thoughts were the In the APN scenario since we are signaling from the App at the customer end to 5G RAN xHaul 5G gateway edge app request to Ingres PE SE source node which maps based on APN characteristics to SR-TE steered path over Enhanced VPN network slice provisioned to egress PE then handoff to internet final destination. In line answers Or are you assuming that one SR-TE path be instantiated from the "App aware head end" to an egress node of the SR domain? It would be SR source node mapped SR-TE path to egress PE as stated above. If there are multiple hops from the SR egress node to the final destination of the "app", then performance becomes unpredictable within the segments outside the SR domain, correct? Agreed. Only APN controls we have are within the SR closed domain. Thank you, Linda Dunbar From: Apn <[email protected]<mailto:[email protected]>> On Behalf Of Gyan Mishra Sent: Saturday, January 16, 2021 6:55 PM To: Pengshuping (Peng Shuping) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: [Apn] A new draft on APN for your review, thank you! Thank you Shuping!! I am excited to join the team to collaborate and bring to the table operators real world experiences and issues and how APN can help operators. To help set an operator baseline as for SLA strategies that are used today and where APN can fill the gap and provide improvement with fine grained SLAs applicability below: Historically QOS 5-tuple packet classification marking and PHB scheduling has been the primary means of providing customer SLA from a scheduling in profile guaranteed bandwidth perspective along with a full mesh of SLA OAM ping type probes which most vendors routers support that can monitor end to end jitter, latency that can report to the NOC monitoring dashboard when problems arise to ensure that the customer SLAs are being met. Also along with NMS tools such as IPFIX and Netconf/Yang and now in some cases SDN or SD-WAN overlay controllers that can provide per flow jitter end delay measurement course grain SLA which has worked well for a long time. So I don't think any gap here that would require APN. The above endpoint to endpoint SLA monitoring and is not inband to the flow itself as each flow may or may not have the same characteristics as each flow is in a different QOS class and there maybe other characteristics to the flow itself, thus the endpoint end to end coarse grain ends up being not an accurate representation of the customer flow characteristics and SLA. However this has not been an issue for operators so we have not had a need for fine grain SLA. Outside of the network slicing framework for 5G or DETNET Enhanced VPN use cases, I don't see the need for APN fine grain SLA. So with the APN application awareness the QOE marking I was referring to is the application flow characteristics from the service aware app or app aware edge device. So that application flow characteristics that has the delay, jitter and bandwidth variables that the app aware head end can map to an appropriately steered SR-TE path that can now be instantiated to meet the new fine grain value added service customer SLA requirement at a premium cost. Responses in-line On Sat, Jan 16, 2021 at 9:17 AM Pengshuping (Peng Shuping) <[email protected]<mailto:[email protected]>> wrote: Hi Gyan, It is truly great to receive your such positive feedback and support on this work! Welcome on board! :) Gyan> Thank you Indeed APN provides a new fine granularity marking. "A new paradigm of QoE type marking" as you called sounds very inspiring. Would you like to elaborate a bit more? Gyan> I was drawing parity between QoS marking / scheduling to APN QOE marking / mapping to SR-TE path where the marking referred to is the application flow characteristics that has the bandwidth delay jitter values requested by the flow. Would you also like to elaborate more on the benefits which you as an operator could receive when using SLA parameters such as bandwidth, delay, jitter? We got some concerns before regarding the forwarding efficiency imposed by taking those parameters. What are your opinions on this "potential issue"? How to encapsulate them more efficiently? Gyan> I think in today's shared infrastructure resource network model, our coarse grain granularity works well and there is not any gap to be filled. No issues. The gap to be filled with APN I think is with any Enhanced VPN network slice use case such as for 5G or any other where the network resources are provisioned providing a degree or isolation and lesser degree of being shared as traditional VPN and OAM telemetry that depicts the customer SLA bandwidth, latency and delay requirements are being met. The APN fine granularity can now map to the network slice resources provisioning parameters. When services are provisioned for a customer for a particular SLA the service functions are deployed and built out end to end for the customer initial turbo. Their is a clear demarcation between customer CPE infrastructure and provider side infrastructure and the provider does not have any "trust" relationship which the customer traffic - for example QOS marking where the provider marks and reclassifies the customer traffic based on SLA. The shift here with APN is that now we are providing application signaling application characteristics information that it sends to the application aware edge device to act on and provide the appropriate service. That is a big issue for operators as we don't trust any marking or anything sent by a customer. Both enterprise or service providers would have this issue. Their maybe a way to make this work and get around customer to provider signaling. As far as forwarding efficiencies as the application characteristics information is carried in hbh and doh from the service aware app to the application aware edge the issue today that exists with extension header length and number options encoded TLVs as well as number of extension headers to be processed can impact with processing in the slow path. As we know there are more and more applications as we know such as OAM and others that will want to use hbh or doh, once we solve the hbh efficient processing in the fast path issue on 6man we can resolve this forwarding efficiency issue . I wonder if we could use SFC NSH header to encode the TLVs. Other option is to create a néw APN encapsulation header that contains bandwidth, delay, jitter information encoded as TLVs. That maybe the best way to go. As I think it's going to take time for hbh doh processing improvements to the fast path to happen. These elaborations could be further integrated into the relevant drafts if you like, to serve as the potential work items of APN in IETF. Gyan> Understood. I would be interested in collaborating. Thank you! To all, it would also be good to hear your opinions and suggestions as well. Thanks! Best regards, Shuping From: Gyan Mishra [mailto:[email protected]<mailto:[email protected]>] Sent: Saturday, January 16, 2021 11:22 AM To: Pengshuping (Peng Shuping) <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Re: A new draft on APN for your review, thank you! Hi Shuping and Authors I am a new member of APN after reading through the all the APN drafts. Very interesting and great idea. Great way to leverage IPv6 data plane extension header concept along with SRv6 path steering coloring for 5G network slicing to create a new paradigm of QOE type marking matching and scheduling APN flow to map to discrete SR-TE paths via SDN controller. I am very interested in the APN concepts and the SLA gap that exists for operators to convey bandwidth, delay and jitter which is has been a Day 1 missing gap for QOS 5-tuple packet classification marking and scheduling. Was out of scope of QOS but it would have been nice for operators if that were possible. With this new APN architecture operators can now signal via IPv6 EH options encoded sub-tlv for bandwidth, delay and jitter in IPv6 EH headers HBH, DOH or SRH. I like it. I would be interested in collaborating on the APN efforts. Some feedback on the problem statement draft: https://tools.ietf.org/html/draft-li-apn-problem-statement-usecases-01<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-apn-problem-statement-usecases-01&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cd13e178ed4f4481e8f0608d8bc210a49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637466197405396491%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=lCxKsEFTEobKzPZXTzrhpubKYVi1irW2MQJByiKUKZw%3D&reserved=0> In the problem statement draft section 3 some feedback. Also feedback overall for the APN architecture. For operators QOS DSCP marking and PHB scheduling has been able to provide IP SLA bandwidth guarantees for services provided today with Gold Bronze Silver QOS guaranteed based on traffic types voice, video data for decades. However it did not provide any fine IP SLA granularity for bandwidth, delay and jitter which has really been out of scope for QOS. Their have been other methods that most vendors have IP SLA application probes to monitor bandwidth, delay, jitter to stay within certain pre defined operator constraints. However there has never been a method to take SLA parameters such as bandwidth, delay, jitter and instantiate a path. The paradigm has now expand to include 5G network slicing and shared and dedicated resources and isolation capabilities and DETNET framework to improve real time voice and video services. With the paradigm change for 5G, APN is now a much needed to provide the fine granularity SLA that now discretely includes bandwidth, delay and jitter components in real time as part of the provisioning process of the SR-TE path instantiation mapping. Kind Regards Gyan On Mon, Dec 14, 2020 at 10:12 PM Pengshuping (Peng Shuping) <[email protected]<mailto:[email protected]>> wrote: 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%7Clinda.dunbar%40futurewei.com%7Cd13e178ed4f4481e8f0608d8bc210a49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637466197405416479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=k0BTUNcxNLCbsYLCewo0PoYFh7DeEp8neP7qeJuVKYo%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%7Clinda.dunbar%40futurewei.com%7Cd13e178ed4f4481e8f0608d8bc210a49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637466197405416479%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=V2VEcXjJucl%2BOySJPwCjhFWVDDvQugtZGmDmi4Ki2GU%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%7Clinda.dunbar%40futurewei.com%7Cd13e178ed4f4481e8f0608d8bc210a49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637466197405426476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=mnVgVfIDE0U6nRywj155WPcvl96nKY8nbAnrdmyDPXc%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%7Clinda.dunbar%40futurewei.com%7Cd13e178ed4f4481e8f0608d8bc210a49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637466197405426476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wN0L9TNYzMunqotHfRheaNnxdjQQk78FjfMs%2BAWmbwg%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%7Clinda.dunbar%40futurewei.com%7Cd13e178ed4f4481e8f0608d8bc210a49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637466197405436467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6YQkvurbsJ%2Fye0hVjy4Z4ySy5uW1ccftL%2Bfa6awSUqw%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. _______________________________________________ rtgwg mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/rtgwg<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frtgwg&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cd13e178ed4f4481e8f0608d8bc210a49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637466197405436467%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=K4LVP5Pd4B8mrO75Bc9KlMtuDfe4L8itFtAD39KgIgI%3D&reserved=0> -- [??????????]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cd13e178ed4f4481e8f0608d8bc210a49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637466197405446461%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6B9iMCzSm%2Bqd6LYru0eR27ZJ0Vade3p6PEtH13q8Oz4%3D&reserved=0> Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%3Fentry%3Dgmail%26source%3Dg&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cd13e178ed4f4481e8f0608d8bc210a49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637466197405456457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VQpbT3mjqr65v5Fw4w9v%2BhRx%2BAVHOUNaqmcL00opuZM%3D&reserved=0> Silver Spring, MD -- [??????????]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cd13e178ed4f4481e8f0608d8bc210a49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637466197405456457%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Qhxu8r4GpDRKfOgL22TEidHGq617HbyOTBeQ98%2BHodI%3D&reserved=0> Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.google.com%2Fmaps%2Fsearch%2F13101%2BColumbia%2BPike%3Fentry%3Dgmail%26source%3Dg&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cd13e178ed4f4481e8f0608d8bc210a49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637466197405466449%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VZBoTPhYP469cRWo3waB04ZsLd8ThChuexrBEdtnlMc%3D&reserved=0> Silver Spring, MD -- [??????????]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7Cd13e178ed4f4481e8f0608d8bc210a49%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637466197405466449%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=niyKJ5HThA91ED3Z3ThlF3YGwUL5TM2Hqw0EAOtDx2Y%3D&reserved=0> Gyan Mishra Network Solutions Architect M 301 502-1347 13101 Columbia Pike Silver Spring, MD
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
