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

[Gyan Mishra <[e-mail]>]

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 <[e-mail]> 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:[e-mail]] *代表 *Gyan Mishra
> *发送时间:* 2021年1月17日 08:55
> *收件人:* Pengshuping (Peng Shuping)
> *抄送:* [e-mail]; [e-mail]
> *主题:* 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) <
> [e-mail]> 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:[e-mail]]
> *Sent:* Saturday, January 16, 2021 11:22 AM
> *To:* Pengshuping (Peng Shuping) <[e-mail]>
> *Cc:* [e-mail]; [e-mail]
> *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) <
> [e-mail]> 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
> [e-mail]
> 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