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

From: Gyan Mishra <[email-masked]>
Date: Fri, 15 Jan 2021 22:21:30 -0500

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-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/rtgwg
>
-- 

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

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

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Sat, 16 Jan 2021 14:17:19 +0000

Hi Gyan,

It is truly great to receive your such positive feedback and support on this work! Welcome on board! ☺

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?

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?

These elaborations could be further integrated into the relevant drafts if you like, to serve as the potential work items of APN in IETF.

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-masked]]
Sent: Saturday, January 16, 2021 11:22 AM
To: Pengshuping (Peng Shuping) <[email-masked]>
Cc: [email-masked]; [email-masked]
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.

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-masked]<mailto:[email-masked]>> 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.

Best regards,

Shuping

has been successfully submitted by Shuping Peng and posted to the IETF repository.

Revision: 00

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:

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtgwg
--

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

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 16 Jan 2021 19:54:35 -0500

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-masked]> 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!
>
>
>
> *From:* Gyan Mishra [mailto:[email-masked]]
> *Sent:* Saturday, January 16, 2021 11:22 AM
> *To:* Pengshuping (Peng Shuping) <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: A new draft on APN for your review, thank you!
>
>
>
>
>
> Hi Shuping and Authors
>
>
>
> 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
> *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
>
>
>
-- 

*Gyan Mishra*

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 18 Jan 2021 23:17:59 +0000

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"?
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?  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?

Thank you,
Linda Dunbar

From: Apn <[email-masked]> On Behalf Of Gyan Mishra
Sent: Saturday, January 16, 2021 6:55 PM
To: Pengshuping (Peng Shuping) <[email-masked]>
Cc: [email-masked]; [email-masked]
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-masked]<mailto:[email-masked]>> 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.

Best regards,
Shuping

From: Gyan Mishra [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, January 16, 2021 11:22 AM
To: Pengshuping (Peng Shuping) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: A new draft on APN for your review, thank you!

Hi Shuping and Authors

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%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137419084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VQoNzSdsSbgc%2F9lDz3JwRqSDg%2B7lCTgHV6D0J5Kpn28%3D&reserved=0>

Kind Regards

Gyan

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%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137429088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uKovbSAdPRwqjOH0AUd%2B%2FJaL0xLTAI6opNNHWF3bfFg%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.

Best regards,

Shuping

Revision: 00

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%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137429088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MFz5R9izAJaAynIrDdzYjsBms8JFwOngSxhZonoDHbw%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%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137439077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MeNtmTCiYC7QkRy9WXm85jSUlkepGc9lv6xQJCWv6pc%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%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137439077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=iZTnzeOp%2Fq%2Bxx%2F%2FLJzEjOHrwMbbGhvzL1FfY359QwDE%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%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137449072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mNCd7xvmf9tD%2BTlPzv%2BHCPtp5KgUGCdYT2aj12OM0eM%3D&reserved=0>

Abstract:

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
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%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137449072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=P2QvtwUq6ri1jmrCIdvQzqHljcn7DmJlUmexhbPYbMI%3D&reserved=0>
--

[??????????]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137459068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vGmub31JolhYCpAcIVvHa%2Bn1KmJv%2BRpUWEs0k9werYo%3D&reserved=0>

Gyan Mishra

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%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137459068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yH5A477%2BXxrvEhoVQyqItm1ovZgwMdyfuOm6sMsEjPU%3D&reserved=0>
Silver Spring, MD

--

[http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137469061%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=D2ILPwC0WuqyAP%2FPhvlfoCv9S0wfREbS4zaWrr6GSwU%3D&reserved=0>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 18 Jan 2021 19:42:59 -0500

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-masked]> 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-masked]] *代表 *Gyan Mishra
> *发送时间:* 2021年1月17日 08:55
> *收件人:* Pengshuping (Peng Shuping)
> *抄送:* [email-masked]; [email-masked]
> *主题:* Re: [Apn] A new draft on APN for your review, thank you!
>
>
>
>
>
> Thank you Shuping!!
>
>
>
> 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
> 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
> *M 301 502-134713101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver
> Spring, MD
>
>
>
> --
>
> *M 301 502-134713101 Columbia Pike
> <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g> *Silver
> Spring, MD
>
>
>
-- 

*Gyan Mishra*

---

From: Gyan Mishra <[email-masked]>
Date: Mon, 18 Jan 2021 20:00:39 -0500

Hi Linda

On Mon, Jan 18, 2021 at 6:18 PM Linda Dunbar <[email-masked]>
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-masked]> *On Behalf Of * Gyan Mishra
> *Sent:* Saturday, January 16, 2021 6:55 PM
> *Subject:* Re: [Apn] A new draft on APN for your review, thank you!
>
>
>
>
>
> Thank you Shuping!!
>
>
>
> <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%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137419084%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=VQoNzSdsSbgc%2F9lDz3JwRqSDg%2B7lCTgHV6D0J5Kpn28%3D&reserved=0>
>
>
>
> <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%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137429088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=uKovbSAdPRwqjOH0AUd%2B%2FJaL0xLTAI6opNNHWF3bfFg%3D&reserved=0>
> .
>
>
>
> <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%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137429088%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MFz5R9izAJaAynIrDdzYjsBms8JFwOngSxhZonoDHbw%3D&reserved=0>
>
> Status:
> <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%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137439077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MeNtmTCiYC7QkRy9WXm85jSUlkepGc9lv6xQJCWv6pc%3D&reserved=0>
>
> Htmlized:
> <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%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137439077%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=iZTnzeOp%2Fq%2Bxx%2F%2FLJzEjOHrwMbbGhvzL1FfY359QwDE%3D&reserved=0>
>
> Htmlized:
> <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%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137449072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=mNCd7xvmf9tD%2BTlPzv%2BHCPtp5KgUGCdYT2aj12OM0eM%3D&reserved=0>
>
>
>
>
>
> Abstract:
>
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Frtgwg&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137449072%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=P2QvtwUq6ri1jmrCIdvQzqHljcn7DmJlUmexhbPYbMI%3D&reserved=0>
>
> --
>
> <https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137459068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vGmub31JolhYCpAcIVvHa%2Bn1KmJv%2BRpUWEs0k9werYo%3D&reserved=0>
>
> *Gyan Mishra*
>
> <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%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137459068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=yH5A477%2BXxrvEhoVQyqItm1ovZgwMdyfuOm6sMsEjPU%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%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137469061%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=D2ILPwC0WuqyAP%2FPhvlfoCv9S0wfREbS4zaWrr6GSwU%3D&reserved=0>
>
> *Gyan Mishra*
>
-- 

*Gyan Mishra*

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Tue, 19 Jan 2021 02:22:08 +0000

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-masked]]
Sent: Tuesday, January 19, 2021 9:01 AM
To: Linda Dunbar <[email-masked]>
Cc: Pengshuping (Peng Shuping) <[email-masked]>; [email-masked]; [email-masked]
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-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> On Behalf Of Gyan Mishra

Thank you Shuping!!

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.

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.

Responses in-line

 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.

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.

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.

Best regards,
Shuping

Hi Shuping and Authors

Kind Regards

Gyan

Dear all,

Best regards,

Shuping

Revision: 00

Pages:              11

Abstract:

[图像已被发件人删除。]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137459068%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=vGmub31JolhYCpAcIVvHa%2Bn1KmJv%2BRpUWEs0k9werYo%3D&reserved=0>

Gyan Mishra

M 301 502-1347

--

[图像已被发件人删除。]<https://nam11.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.verizon.com%2F&data=04%7C01%7Clinda.dunbar%40futurewei.com%7C10d7dc22e06f40ceed6b08d8ba8289b0%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637464417137469061%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=D2ILPwC0WuqyAP%2FPhvlfoCv9S0wfREbS4zaWrr6GSwU%3D&reserved=0>

Gyan Mishra

M 301 502-1347
13101 Columbia Pike<https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>
Silver Spring, MD

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Feng Yang" <[email-masked]>
Date: Mon, 18 Jan 2021 17:19:59 +0800

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-masked]] 代表 Gyan Mishra
发送时间: 2021年1月17日 08:55
收件人: Pengshuping (Peng Shuping)
抄送: [email-masked]; [email-masked]
主题: Re: [Apn] A new draft on APN for your review, thank you!

Thank you Shuping!!

 

Responses in-line 

On Sat, Jan 16, 2021 at 9:17 AM Pengshuping (Peng Shuping) <[email-masked]> 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

 

Thank you! 

Best regards,

Shuping

 

Hi Shuping and Authors 

 

Kind Regards 

Gyan

On Mon, Dec 14, 2020 at 10:12 PM Pengshuping (Peng Shuping) <[email-masked]> wrote:

Dear all, 

Best regards, 

Shuping 

Revision: 00

Pages:              11

 

Abstract:

 

-- 

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

Gyan Mishra

M 301 502-1347
13101 Columbia Pike <https://www.google.com/maps/search/13101+Columbia+Pike?entry=gmail&source=g>  
Silver Spring, MD

-- 

Gyan Mishra

M 301 502-1347
13101 Columbia Pike 
Silver Spring, MD

---

From: Linda Dunbar <[email-masked]>
Date: Wed, 20 Jan 2021 16:52:34 +0000

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-masked]>
Sent: Monday, January 18, 2021 8:22 PM
To: Gyan Mishra <[email-masked]>; Linda Dunbar <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [Apn] A new draft on APN for your review, thank you!

Hi Linda, Gyan,

Best regards,
Shuping

From: Gyan Mishra [mailto:[email-masked]]
Sent: Tuesday, January 19, 2021 9:01 AM
To: Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: Pengshuping (Peng Shuping) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Apn] A new draft on APN for your review, thank you!

Hi Linda

You stated that

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

Thank you Shuping!!

Responses in-line

Best regards,
Shuping

Hi Shuping and Authors

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>

Kind Regards

Gyan

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>.

Best regards,

Shuping

Revision: 00

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:

_______________________________________________
rtgwg mailing list
[email-masked]<mailto:[email-masked]>
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

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

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

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Thu, 21 Jan 2021 02:33:48 +0000

Hi Linda,

Thank you for your questions! It gives me an opportunity to explain the core idea and basic solution of APN here, which seems that it needs to be clearly clarified.

The basic solution of APN is like this:

In the control plane, the network controller receives requests from user groups and application groups to obtain certain network services such as an optimal path, and the controller will calculate the optimal path candidates and select one for this request.  (The requested services could also include network slice, service function chain, deterministic path, etc.) The policy of the network service as well as the associated user groups and application groups information, called APN identifier which is a structured value, is sent to the network headend, and the matching logic (as standardized in MEF70, please also refer to another email thread which you just replied to) of differentiating this traffic is sent to the network edge devices.  The user groups and application groups information does not have to be the actual identity information to protect the privacy. It is also because the network devices only need a bit string to do the traffic steering and don't need to know who and what applications.

In the data plane, at the network edge devices the traffic flow is differentiated according to the matching logic sent by the controller, constructs the APN identifier, encodes it in the packets and sends to the network headend. At the network headend, the traffic can be steered into the optimal path according to the APN identifier, and continuously the APN identifier can be further carried in the tunnel encapsulation header and serve other value-added services provisioning such as fine-granularity performance measurements and monitoring results visualization via the controller.

The above-mentioned is a basic solution. The network services can also be provisioned in a flow-driven manner as you described, and the control plane could be on demand as well. The service requirements parameters can also be added in this case as Gyan has shown great interests.

Please let me know if anything is unclear. Your views and suggestions are very welcomed.

Best regards,
Shuping

From: Linda Dunbar [mailto:[email-masked]]
Sent: Thursday, January 21, 2021 12:53 AM
To: Pengshuping (Peng Shuping) <[email-masked]>; Gyan Mishra <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: [Apn] A new draft on APN for your review, thank you!

ShuPing,

My two cents,
Linda Dunbar

From: Pengshuping (Peng Shuping) <[email-masked]<mailto:[email-masked]>>
Sent: Monday, January 18, 2021 8:22 PM
To: Gyan Mishra <[email-masked]<mailto:[email-masked]>>; Linda Dunbar <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: [Apn] A new draft on APN for your review, thank you!

Hi Linda, Gyan,

Best regards,
Shuping

Hi Linda

You stated that

In line answers

Thank you Shuping!!

Responses in-line

Best regards,
Shuping

Hi Shuping and Authors

Kind Regards

Gyan

Dear all,

Best regards,

Shuping

Revision: 00

Pages:              11

Abstract:

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347

--

Gyan Mishra

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Fri, 22 Jan 2021 02:08:12 +0000

Dear authors,

We have updated the APN BoF Proposal as attached. The suggestions in your draft and the discussions with you offline inspired us a lot. The support of the user/app group is explicitly shown in the text although it was implicitly included. We have made a lot of efforts on clarifying the scope of the work, introducing the basic solution, and describing the concrete use case. Please advise whether we are clear now and how we can improve further, especially on the privacy concerns. Thank you!

This posted draft, https://datatracker.ietf.org/doc/html/draft-peng-apn-scope-gap-analysis, would be able to give you more complete information. Please also refer to the recent discussions in the archives https://mailarchive.ietf.org/arch/browse/apn/ if you have not subscribed the APN mailing list yet. Based on discussions and suggestions we received, we will update this draft accordingly. Your reviews and comments will be very much appreciated.

Thank you!

Best regards,
Shuping

From: Apn [mailto:[email-masked]] On Behalf Of Pengshuping (Peng Shuping)
Sent: Tuesday, December 15, 2020 11:12 AM
To: [email-masked]; [email-masked]
Subject: [Apn] A new draft on APN for your review, thank you!

Dear all,

Best regards,

Shuping

Revision: 00

Pages:              11

Abstract:

---

From: tom petch <[email-masked]>
Date: Sat, 23 Jan 2021 12:09:26 +0000

From: Int-area <[email-masked]> on behalf of Pengshuping (Peng Shuping) <[email-masked]>
Sent: 22 January 2021 02:08

Dear authors,

We have updated the APN BoF Proposal as attached. The suggestions in your draft and the 

<tp>

Whatever APN may stand for!  I looked at the I-D and the Abstract uses APN with no explanation of what it is:-(  It needs expanding on first use and while I could read on and perhaps find an explanation yet the idea is that the Abstract tells readers whether or not this is of interest to them and this Abstract does not.  The rest of the I-D may be clearer but I am not gong to spend time finding out:-)

Tom Petch

discussions with you offline inspired us a lot. The support of the user/app group is explicitly shown in the text although it was implicitly included. We have made a lot of efforts on clarifying the scope of the work, introducing the basic solution, and describing the concrete use case. Please advise whether we are clear now and how we can improve further, especially on the privacy concerns. Thank you!

Thank you!

Best regards,
Shuping

Dear all,

Best regards,

Shuping

Revision: 00

Pages:              11

Abstract:

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Sun, 24 Jan 2021 07:50:22 +0000

Dear Tom,

Thank you for your interest! 

First of all, APN stands for Application-aware Networking

I had attached a APN BoF proposal document in my last email but probably it was too big to be delivered successfully. The APN6 was also introduced in this draft in the intarea WG (https://tools.ietf.org/html/draft-per-app-networking-considerations). Sorry for any confusions caused. 

Please find the APN BoF proposal in the IETF wiki for more information. 
https://trac.tools.ietf.org/bof/trac/wiki/WikiStart

The archived discussions in this APN mailing list can be found here. 
https://mailarchive.ietf.org/arch/browse/apn/

To subscribe the APN Mailing list,
https://www.ietf.org/mailman/listinfo/apn

Here are some relevant drafts and materials for your reference. 

*	Scope & Gap analysis
https://tools.ietf.org/html/draft-peng-apn-scope-gap-analysis
*	Problem statement & Use cases
https://tools.ietf.org/html/draft-li-apn-problem-statement-usecases
https://tools.ietf.org/html/draft-liu-apn-edge-usecase
https://tools.ietf.org/html/draft-zhang-apn-acceleration-usecase
https://tools.ietf.org/html/draft-yang-apn-sd-wan-usecase
*	Framework
https://datatracker.ietf.org/doc/draft-li-apn-framework/
*	Security & Privacy
https://datatracker.ietf.org/doc/draft-peng-apn-security-privacy-consideration
*	APN Community
https://github.com/APN-Community
*	Per-Application Networking Considerations
https://tools.ietf.org/html/draft-per-app-networking-considerations

Thank you! 

Best regards, 
Shuping

> -----Original Message-----
> From: tom petch [mailto:[email-masked]]
> Sent: Saturday, January 23, 2021 8:09 PM
> To: Pengshuping (Peng Shuping) <[email-masked]>;
> draft-per-app-networking-considerations
> <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]
> Whatever APN may stand for!  I looked at the I-D and the Abstract uses
> APN with no explanation of what it is:-(  It needs expanding on first use and
> while I could read on and perhaps find an explanation yet the idea is that the
> Abstract tells readers whether or not this is of interest to them and this
> Abstract does not.  The rest of the I-D may be clearer but I am not gong to
> spend time finding out:-)
> 
> Tom Petch
> 
> discussions with you offline inspired us a lot. The support of the user/app
> group is explicitly shown in the text although it was implicitly included. We
> have made a lot of efforts on clarifying the scope of the work, introducing
> the basic solution, and describing the concrete use case. Please advise
> whether we are clear now and how we can improve further, especially on
> the privacy concerns. Thank you!
> 
> This posted draft,
> https://datatracker.ietf.org/doc/html/draft-peng-apn-scope-gap-analysis,
> would be able to give you more complete information. Please also refer to
> the recent discussions in the archives
> https://mailarchive.ietf.org/arch/browse/apn/ if you have not subscribed
> the APN mailing list yet. Based on discussions and suggestions we received,
> we will update this draft accordingly. Your reviews and comments will be
> very much appreciated.
> 
> Thank you!
> 
> Best regards,
> Shuping
> 
> 
> 
> 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.
> 
> 
>

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 25 Jan 2021 18:29:00 +0000

Shuping, 

Some comments to the draft-peng-apn-scope-gap-analysis-00:

I find Page 4 last sentence really hit the key purpose of APN: at the headend to steer into corresponding path, at the midpoint to collect corresponding performance measurement data, and at the service function to execute particular policies.
But all the labels and IDs described in Section 6 are for homogeneous network, APN ID is supposed to achieve the above purposes through different nodes. 

Is my understanding correct?  If yes, I recommend to write those key points in the Abstract and Introduction to make it more clear to people. 

The document stated in several places that APN Identifier is a Structured value. What structure is the APN ID?  Can the APN ID be mapped into  the labels described in Section 6? i.e. the SFC Service ID, Binding SID, FlowSpec Label, etc? 

Some minor comments:
Section 6.1:  IPv6 flow label is manipulated by application themselves. Network can not make changes to them, nor can network know the meaning of the flow labels inserted by the Applications (unless the Application controller has signals to the network controllers)

Linda

-----Original Message-----
From: Apn <[email-masked]> On Behalf Of Pengshuping (Peng Shuping)
Sent: Sunday, January 24, 2021 1:50 AM
To: tom petch <[email-masked]>; draft-per-app-networking-considerations <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Apn] A new draft on APN for your review, thank you!

Dear Tom,

I had attached a APN BoF proposal document in my last email but probably it was too big to be delivered successfully. The APN6 was also introduced in this draft in the intarea WG (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-per-app-networking-considerations&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463026426%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=APYvMROCre177UK3puGuTPHB%2FfoyGTWWXFedDS6ZNHw%3D&amp;reserved=0). Sorry for any confusions caused. 

Please find the APN BoF proposal in the IETF wiki for more information. 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.tools.ietf.org%2Fbof%2Ftrac%2Fwiki%2FWikiStart&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463026426%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=MqJnzeO5AJDOaZrouSSgE%2B0qpNOOcnuQ7f7Fw8rUnK0%3D&amp;reserved=0

The archived discussions in this APN mailing list can be found here. 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fbrowse%2Fapn%2F&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463026426%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Y2GZzG%2FvD%2Fx3R79BB9ub%2BWe94PU9W6HetLSa%2BnbhKLk%3D&amp;reserved=0

To subscribe the APN Mailing list,
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fapn&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463026426%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=bJq8Gq9GLTuf3u9yxOH2AXTCWEOiTkQksuHuZ6RljgE%3D&amp;reserved=0

*	Scope & Gap analysis
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-peng-apn-scope-gap-analysis&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463026426%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=yOGg7DMeeocdWA%2FGV3xQyVnwpjwzcgMg113ZyvlbjZ4%3D&amp;reserved=0
*	Problem statement & Use cases
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-li-apn-problem-statement-usecases&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463026426%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=F0V7aEgDM66QDuuj7WpVcbbQCUPpboODOG7YWAUIAqI%3D&amp;reserved=0
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-liu-apn-edge-usecase&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463036422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=yyUVM4FRoXdcUrHqBDapxv4kWg9tVU1PVkQrPMcwsS4%3D&amp;reserved=0
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-zhang-apn-acceleration-usecase&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463036422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=boJWFr0HyVGOXbaEHWuxL1bGNzQZOcxtf1U8SSuqyus%3D&amp;reserved=0
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-yang-apn-sd-wan-usecase&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463036422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2FBjFyaRwiGHeFSYU35iGzWchFa62d9dDYoKjNMAz1VE%3D&amp;reserved=0
*	Framework
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-li-apn-framework%2F&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463036422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Ce%2FXfkJ8ha0%2BQOv8DT026VMXG08rqLKpLSxCH1KROBo%3D&amp;reserved=0
*	Security & Privacy
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-peng-apn-security-privacy-consideration&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463036422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=ykF6YreMnI7IzBn%2F1kxyRd9bvJybLd9DQj5GYcd5sl8%3D&amp;reserved=0
*	APN Community
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FAPN-Community&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463036422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=JEJ%2FSzHnQ9VOQwndMgtFCovpYIZ08GYYL8ZkM9rA%2Bto%3D&amp;reserved=0
*	Per-Application Networking Considerations
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-per-app-networking-considerations&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463036422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=DdibzIJhpoDJpMKuI9VMn%2FtCnOqaEnqo%2BmTkv1wReOg%3D&amp;reserved=0

Thank you! 

Best regards,
Shuping

> From: Int-area <[email-masked]> on behalf of Pengshuping 
> (Peng
> Shuping) <[email-masked]>
> APN with no explanation of what it is:-(  It needs expanding on first 
> use and while I could read on and perhaps find an explanation yet the 
> idea is that the Abstract tells readers whether or not this is of 
> interest to them and this Abstract does not.  The rest of the I-D may 
> be clearer but I am not gong to spend time finding out:-)
> 
> Tom Petch
> 
> discussions with you offline inspired us a lot. The support of the 
> user/app group is explicitly shown in the text although it was 
> implicitly included. We have made a lot of efforts on clarifying the 
> scope of the work, introducing the basic solution, and describing the 
> concrete use case. Please advise whether we are clear now and how we 
> can improve further, especially on the privacy concerns. Thank you!
> 
> This posted draft,
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-peng-apn-scope-gap-analysis&amp;
> data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8
> c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6374707144630364
> 22%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=snNr80f38d4QiUx1UtvKMwAXm5GHQ
> 4IgoiJDwU0Wo5Y%3D&amp;reserved=0, would be able to give you more 
> complete information. Please also refer to the recent discussions in 
> the archives
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail
> archive.ietf.org%2Farch%2Fbrowse%2Fapn%2F&amp;data=04%7C01%7Clinda.dun
> bar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff2a3b24
> 0189c753a1d5591fedc%7C1%7C0%7C637470714463036422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=OujoFq5BkZzTJcNAvjj8zHJf2xt7BiAd0pq24%2FU4%2FLE%3D&amp;reserved=0 if you have not subscribed the APN mailing list yet. Based on discussions and suggestions we received, we will update this draft accordingly. Your reviews and comments will be very much appreciated.
> 
> Thank you!
> 
> Best regards,
> Shuping
> 
> 
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-peng-apn-scope-gap-analysis&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463036422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=snNr80f38d4QiUx1UtvKMwAXm5GHQ4IgoiJDwU0Wo5Y%3D&amp;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.
> 
> 
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Farchive%2Fid%2Fdraft-peng-apn-scope-gap-analysis-00.txt&amp
> ;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d
> 8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463036
> 422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi
> I6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=7mqepW8aF1FkP9Yf4uldFoEooDoa
> k%2BmmNLzEZlMj2RY%3D&amp;reserved=0
> 
> Status:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-peng-apn-scope-gap-analysis%2F&amp;data
> =04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03c
> bfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463036422%7
> CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1
> haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=KVYBICPA%2FgvgBtn6vv3VaaypRavG8V%
> 2F2ZoSJfULGGLQ%3D&amp;reserved=0
> 
> Htmlized:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-peng-apn-scope-gap-analysis&amp;
> data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8
> c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6374707144630464
> 21%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI
> 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=vUrvPtT9Oj3yHtleUAeljP1JeQ3Hr
> uTVz2hktBxulJk%3D&amp;reserved=0
> 
> Htmlized:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-peng-apn-scope-gap-analysis-00&amp;data=04%7
> C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%
> 7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463046421%7CUnkn
> own%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi
> LCJXVCI6Mn0%3D%7C3000&amp;sdata=NLKsZz6esqGO6eUhLqp2hUoMstG1wds60HNYtj
> Gvi90%3D&amp;reserved=0
> 
> 
> 
> 
> 
> Abstract:
> 

--
Apn mailing list
[email-masked]
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fapn&amp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463046421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=he1%2F62XzA9JgoJd%2BKD%2FKZzGmksmKXNG4e03FeuYK8m0%3D&amp;reserved=0

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Tue, 26 Jan 2021 04:13:20 +0000

Dear Linda, 

Your suggestions are very good. I have updated the draft and uploaded it to the APN Github. Please feel free to make any further changes. Thank you!

https://github.com/APN-Community/APN-Scope-Gap-Analysis

Please find some more comments in line below. 

> Sent: Tuesday, January 26, 2021 2:29 AM
> To: Pengshuping (Peng Shuping) <[email-masked]>; tom petch
> <[email-masked]>; draft-per-app-networking-considerations
> I find Page 4 last sentence really hit the key purpose of APN: at the headend
> to steer into corresponding path, at the midpoint to collect corresponding
> performance measurement data, and at the service function to execute
> particular policies.
> But all the labels and IDs described in Section 6 are for homogeneous
> network, APN ID is supposed to achieve the above purposes through
> different nodes.
> 
> Is my understanding correct?  If yes, I recommend to write those key points
> in the Abstract and Introduction to make it more clear to people.
> 

Yes, it is correct. Your suggestions are great. I have explicitly put these information in the Abstract and Introduction. Please make further changes wherever needed. Thank you!

> The document stated in several places that APN Identifier is a Structured
> value. What structure is the APN ID?  Can the APN ID be mapped into  the
> labels described in Section 6? i.e. the SFC Service ID, Binding SID, FlowSpec
> Label, etc?

The APN ID structure design proposal and its encapsulation in IPv6 data plane are introduced in https://tools.ietf.org/html/draft-li-6man-app-aware-ipv6-network-02. More description is added in the updated version of the draft. The APN ID can be used to serve the functional purpose of all these labels.

> 
> Some minor comments:
> Section 6.1:  IPv6 flow label is manipulated by application themselves.
> Network can not make changes to them, nor can network know the meaning
> of the flow labels inserted by the Applications (unless the Application
> controller has signals to the network controllers)
> 

Yes, it is right. Just as far as I know, when the packets go into a tunnel, e.g. SRv6, generally the IPv6 flow label will be recalculated and encapsulated.

Best regards, 
Shuping

> To: tom petch <[email-masked]>;
> I had attached a APN BoF proposal document in my last email but probably it
> was too big to be delivered successfully. The APN6 was also introduced in
> this draft in the intarea WG
> (https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftoo
> ls.ietf.org%2Fhtml%2Fdraft-per-app-networking-considerations&amp;data=
> 04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d
> 8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6374707
> 14463026426%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJ
> QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=APY
> vMROCre177UK3puGuTPHB%2FfoyGTWWXFedDS6ZNHw%3D&amp;reserve
> d=0). Sorry for any confusions caused.
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.
> tools.ietf.org%2Fbof%2Ftrac%2Fwiki%2FWikiStart&amp;data=04%7C01%7Cl
> inda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7
> C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463026426
> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=MqJnzeO5AJDOaZ
> rouSSgE%2B0qpNOOcnuQ7f7Fw8rUnK0%3D&amp;reserved=0
> 
> archive.ietf.org%2Farch%2Fbrowse%2Fapn%2F&amp;data=04%7C01%7Clin
> da.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0
> fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463026426%
> 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Y2GZzG%2FvD%2Fx
> 3R79BB9ub%2BWe94PU9W6HetLSa%2BnbhKLk%3D&amp;reserved=0
> 
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.ietf.org%2Fmailman%2Flistinfo%2Fapn&amp;data=04%7C01%7Clinda.dun
> bar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff
> 2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463026426%7CUnk
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
> k1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=bJq8Gq9GLTuf3u9yxOH2A
> XTCWEOiTkQksuHuZ6RljgE%3D&amp;reserved=0
> 
> s.ietf.org%2Fhtml%2Fdraft-peng-apn-scope-gap-analysis&amp;data=04%7C
> 01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03c
> bfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463
> 026426%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
> 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=yOGg7DM
> eeocdWA%2FGV3xQyVnwpjwzcgMg113ZyvlbjZ4%3D&amp;reserved=0
> s.ietf.org%2Fhtml%2Fdraft-li-apn-problem-statement-usecases&amp;data=0
> 4%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8
> c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63747071
> 4463026426%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=F0V7
> aEgDM66QDuuj7WpVcbbQCUPpboODOG7YWAUIAqI%3D&amp;reserved=0
> s.ietf.org%2Fhtml%2Fdraft-liu-apn-edge-usecase&amp;data=04%7C01%7Cli
> nda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C
> 0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463036422
> %7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=yyUVM4FRoXdcUr
> HqBDapxv4kWg9tVU1PVkQrPMcwsS4%3D&amp;reserved=0
> s.ietf.org%2Fhtml%2Fdraft-zhang-apn-acceleration-usecase&amp;data=04%
> 7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c0
> 3cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6374707144
> 63036422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=boJWFr
> 0HyVGOXbaEHWuxL1bGNzQZOcxtf1U8SSuqyus%3D&amp;reserved=0
> s.ietf.org%2Fhtml%2Fdraft-yang-apn-sd-wan-usecase&amp;data=04%7C01
> %7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa
> 5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63747071446303
> 6422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=%2FBjFyaRwi
> GHeFSYU35iGzWchFa62d9dDYoKjNMAz1VE%3D&amp;reserved=0
> *	Framework
> tracker.ietf.org%2Fdoc%2Fdraft-li-apn-framework%2F&amp;data=04%7C01
> %7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa
> 5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63747071446303
> 6422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Ce%2FXfkJ8h
> a0%2BQOv8DT026VMXG08rqLKpLSxCH1KROBo%3D&amp;reserved=0
> *	Security & Privacy
> tracker.ietf.org%2Fdoc%2Fdraft-peng-apn-security-privacy-consideration&a
> mp;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42f
> e274b08d8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7
> C637470714463036422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjA
> wMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;
> sdata=ykF6YreMnI7IzBn%2F1kxyRd9bvJybLd9DQj5GYcd5sl8%3D&amp;reserv
> ed=0
> *	APN Community
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2FAPN-Community&amp;data=04%7C01%7Clinda.dunbar%40futur
> ewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff2a3b240189
> c753a1d5591fedc%7C1%7C0%7C637470714463036422%7CUnknown%7CT
> WFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> CJXVCI6Mn0%3D%7C3000&amp;sdata=JEJ%2FSzHnQ9VOQwndMgtFCovpYIZ
> 08GYYL8ZkM9rA%2Bto%3D&amp;reserved=0
> s.ietf.org%2Fhtml%2Fdraft-per-app-networking-considerations&amp;data=0
> 4%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe274b08d8
> c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C63747071
> 4463036422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ
> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=Ddibz
> IJhpoDJpMKuI9VMn%2FtCnOqaEnqo%2BmTkv1wReOg%3D&amp;reserved=
> 0
> 
> Thank you!
> 
> Best regards,
> Shuping
> 
> 0189c753a1d5591fedc%7C1%7C0%7C637470714463036422%7CUnknown%
> 7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haW
> wiLCJXVCI6Mn0%3D%7C3000&amp;sdata=OujoFq5BkZzTJcNAvjj8zHJf2xt7Bi
> Ad0pq24%2FU4%2FLE%3D&amp;reserved=0 if you have not subscribed the
> APN mailing list yet. Based on discussions and suggestions we received, we
> will update this draft accordingly. Your reviews and comments will be very
> much appreciated.
> >
> > Thank you!
> >
> > Best regards,
> > Shuping
> >
> >
> >
> tracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-peng-apn-scope-gap-analysis&amp
> ;data=04%7C01%7Clinda.dunbar%40futurewei.com%7C8aa274f07f8a42fe2
> 74b08d8c03cbfa5%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6
> 37470714463036422%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sda
> ta=snNr80f38d4QiUx1UtvKMwAXm5GHQ4IgoiJDwU0Wo5Y%3D&amp;reserv
> ed=0.
> >
> >
> >
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
> w.ietf.org%2Fmailman%2Flistinfo%2Fapn&amp;data=04%7C01%7Clinda.dun
> bar%40futurewei.com%7C8aa274f07f8a42fe274b08d8c03cbfa5%7C0fee8ff
> 2a3b240189c753a1d5591fedc%7C1%7C0%7C637470714463046421%7CUnk
> nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
> k1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=he1%2F62XzA9JgoJd%2BK
> D%2FKZzGmksmKXNG4e03FeuYK8m0%3D&amp;reserved=0