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

[Gyan Mishra <[e-mail]>]

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-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 A**rchitect *



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