Understood. I think the application awareness is an evolution into itself as it becomes more intelligent at that layer.
Gyan On Mon, Jan 18, 2021 at 4:19 AM Feng Yang <[email protected]> wrote: > Yes. Agree. We see APN benefit on many cases. And especially on the edge > devices. The edge would be smarter and smarter driven by application > requirements. For example, the edge can decide if an application traffic > flow can be served with some particular service chain, network path, or > combination of them. This requires some connections between application and > network. > > > > BR， > > > > 杨锋 > > Feng Yang > > > > *发件人:* Apn [mailto:[email protected]] *代表 *Gyan Mishra > *发送时间:* 2021年1月17日 08:55 > *收件人:* Pengshuping (Peng Shuping) > *抄送:* [email protected]; [email protected] > *主题:* 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]> wrote: > > Hi Gyan, > > > > It is truly great to receive your such positive feedback and support on > this work! Welcome on board! J > > 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]] > *Sent:* Saturday, January 16, 2021 11:22 AM > *To:* Pengshuping (Peng Shuping) <[email protected]> > *Cc:* [email protected]; [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 > > > > 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]> wrote: > > 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. > > > > > > _______________________________________________ > rtgwg mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/rtgwg > > -- > > [image: 图像已被发件人删除。] <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > > > *M 301 502-134713101 Columbia Pike > <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> > *Silver > Spring, MD > > > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > > > *M 301 502-134713101 Columbia Pike > <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> > *Silver > Spring, MD > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *M 301 502-134713101 Columbia Pike *Silver Spring, MD
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
