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

[Feng Yang <[e-mail]>]

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

-- 

 <http://www.verizon.com/> 图像已被发件人删除。

Gyan Mishra

Network Solutions Architect 

M 301 502-1347
13101 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-1347
13101 Columbia Pike 
Silver Spring, MD