Subject: [Apn] Questions for APN: Q#3 and Q#4

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Fri, 18 Sep 2020 05:35:28 +0000

Dear all,

Following the previous emails on the first two questions, I will continue the discussions on Question #3 and #4.
I have also copied the arch-d and network-tokens mailing lists since these two questions would be relevant to a larger community.

#3. Which area in IETF would the APN work fit better?
Answer: Since APN mainly focuses on the application-aware network service provisioning within the network domain, and the potential work items are all on the RTG area from the data plane to the control & manage planes. Therefore, the RTG area in IETF fits better. For the potential work items please refer to this presentation,
https://github.com/APN-Community/IETF108-Side-Meeting-APN/blob/master/4%20Shuping%20Peng%20-%20Huawei%20-%20Application-aware%20Networking%20(APN)%20Framework.pdf

#4. What is the relationship between APN and other attempts in IETF’s history?
Answers: The attempts in history mainly focus on carrying the applications’ requirements at the transport layer not at the network layer like APN.
Please refer to this draft about the attempts: https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-13.

Best regards,
Shuping

From: Apn [mailto:[email-masked]] On Behalf Of Pengshuping (Peng Shuping)
Sent: Wednesday, September 16, 2020 10:07 AM
To: [email-masked]
Subject: Re: [Apn] Question List for APN

Dear all,

I am going to start posting the answers to the listed questions based on the previous work and discussions. If you have any comments please let us know. Thank you!

#1. Which layer is for APN to do the application-aware work?
Answer: The IP network layer. When the application-information is carried on this layer, it can be read by the routers along the path as well as the middle boxes, which makes the network aware of the applications in a native manner.

#2. Does APN provide services within a limited-domain or Internet?
Answer: The main purpose of APN is to provide application-aware network services to the customers within the controlled operators’ networks. Therefore, it is within a limited domain.

Best regards,
Shuping

From: Lizhenbin
Sent: Monday, September 14, 2020 10:35 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Pengshuping (Peng Shuping) <[email-masked]<mailto:[email-masked]>>
Subject: Question List for APN

Hi Folks,
Thanks very much for your attention to APN work. After much preparation work, we summarized the key questions to be clarified for APN which also were always asked. In fact in the past discussion and the APN side meeting of IETF108, many of these questions were discussed and clarified. Here we propose these questions together for your convenience.

The questions to be clarified are as follows:
#1. Which layer is for APN to do the application-aware work?
#2. Does APN provide services within a limited-domain or Internet?
#3. Which area in IETF would the APN work fit better?
#4. What is the relationship between APN and other attempts in IETF’s history?
#5. What are the valuable use cases/usage scenarios of APN?
#6. Is the fine-granularity operations needed/desired in the network?
#7. Why not just use DSCP?
#8. Does APN violate network neutrality?
#9. Will APN raise security issues since application-aware information is carried in the APN packets?
#10. Will APN raise privacy issues since application-aware information is carried in the APN packets?

Shuping Peng will send the detailed answers for these questions in the mailing list in the following one or two weeks. The questions and answers may be not only be sent in the APN mailing list, but also be copied to the architecture discussion mailing list and the network token mailing list for more cross-area feedback if necessary.

If you have any comments on these questions and answers, we can go on to discuss through the mailing list.

Best Regards,
Zhenbin (Robin)

From: Apn [mailto:[email-masked]] On Behalf Of Lizhenbin
Sent: Tuesday, August 18, 2020 7:22 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Apn] Welcome to APN Mailing List

Hi Folks,

Welcome to join the APN mailing list. We are glad to have more discussion through the mailing list as the follow-up of the IETF108 APN side meeting.
In the process of APN work, many historic work items such as SPUD, PLUS, etc. have been proposed. It has been tried to be clarified that APN focuses
on the network layer and limited domains. Concerns on the security and privacy issues also have been proposed many times about the work. It also
has been tried to be clarified that in the trustable limited domains the security and privacy issues can be under control. These are the reasons why APN
work is based in the RTG area instead of ART/TSV areas.

But because of too much historic work to be clarified and its proposing the cross-area discussion for which RTG/APP/TSV/INT/SEC/IRTF are involved, it is
necessary to have more discussion to clarify the scope and work items for APN. We wish the mailing list would be helpful to the work and promoting the
cross-area communication to understand each other better.

You can get yourself up to speed with our discussions so far by seeing the materials at < https://github.com/APN-Community/>, especially the materials
From the virtual IETF 108  APN side meeting at < https://github.com/APN-Community/IETF108-Side-Meeting-APN>. This link also gives you pointers to
some of the relevant Internet-Drafts.

Over the next few weeks we will try to guide discussion by introducing some questions for debate. But please also raise your own issues and concerns
and contribute to the exchanges on this list.

Look forwarding to have more fun discussion in the mailing list.

Best Regards,
Dan & Zhenbin

---

From: [email-masked]
Date: Fri, 18 Sep 2020 08:30:46 -0700

Hi Shuping,

Thank you for including arch-d. Yes, what you’re proposing is a major architectural shift.

I’ve read some of your documents and it seems like you are interested in changing much more than a few routing protocols.  This would make major changes to the data plane throughout the Internet as well as the management plane.  

Is there a discussion anywhere of the costs of this approach and a cost/benefit analysis? Have you considered the scalability of a solution?  What about the added complexity to the architecture? My apologies if I’ve missed something obvious.

Regards,
Tony

> On Sep 17, 2020, at 10:35 PM, Pengshuping (Peng Shuping) <[email-masked]> wrote:
> 
> Dear all,
>  
> https://github.com/APN-Community/IETF108-Side-Meeting-APN/blob/master/4%20Shuping%20Peng%20-%20Huawei%20-%20Application-aware%20Networking%20(APN)%20Framework.pdf <https://github.com/APN-Community/IETF108-Side-Meeting-APN/blob/master/4%20Shuping%20Peng%20-%20Huawei%20-%20Application-aware%20Networking%20(APN)%20Framework.pdf>
>  
> Please refer to this draft about the attempts: https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-13 <https://tools.ietf.org/html/draft-irtf-panrg-what-not-to-do-13>.
>  
> Best regards,
> Shuping
>  
>  
> From: Apn [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Pengshuping (Peng Shuping)
> To: [email-masked] <mailto:[email-masked]>
> To: [email-masked] <mailto:[email-masked]>
> Cc: Pengshuping (Peng Shuping) <[email-masked] <mailto:[email-masked]>>
>  <> 
> From: Apn [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Lizhenbin
> To: [email-masked] <mailto:[email-masked]>
> You can get yourself up to speed with our discussions so far by seeing the materials at < https://github.com/APN-Community/ <https://github.com/APN-Community/>>, especially the materials
> From the virtual IETF 108  APN side meeting at < https://github.com/APN-Community/IETF108-Side-Meeting-APN <https://github.com/APN-Community/IETF108-Side-Meeting-APN>>. This link also gives you pointers to
> _______________________________________________
> Architecture-discuss mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/architecture-discuss <https://www.ietf.org/mailman/listinfo/architecture-discuss>

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Mon, 21 Sep 2020 01:48:03 +0000

Hi Tony,

Thank you for your comments! Please find some clarifications on APN here.

APN doesn’t really introduce any change in any routing protocol. The goal is to be able to better classify packets and assign them to policies. How these policies are defined and operated are outside the scope of APN and rely on existing routing policy technology.

Extension headers have been there for a while so I don’t believe that utilizing existing IPv6 extension headers could be considered as a “major change in the data plane”.

Basically, in APN, the application data packets contains some bits in the header that will be used by the operator ingress devices in order to steer the packet into a pre-defined and installed policy (e.g. a traffic engineered path or a source routed path). The current state of routing protocols allow the provisioning, computation and installation of these policies without any additional change.

Best regards,
Shuping

From: Tony Li [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Friday, September 18, 2020 11:31 PM
To: Pengshuping (Peng Shuping) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [arch-d] Questions for APN: Q#3 and Q#4

Hi Shuping,

Regards,
Tony

On Sep 17, 2020, at 10:35 PM, Pengshuping (Peng Shuping) <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

Best regards,
Shuping

Dear all,

Best regards,
Shuping

From: Lizhenbin

Hi Folks,

Best Regards,
Zhenbin (Robin)

Hi Folks,

Best Regards,
Dan & Zhenbin

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

---

From: [email-masked]
Date: Mon, 21 Sep 2020 07:03:21 -0700

Hi Shuping,

> APN doesn’t really introduce any change in any routing protocol. The goal is to be able to better classify packets and assign them to policies. How these policies are defined and operated are outsi…

Then perhaps RTG is not appropriate.  Perhaps INT would be more to the point.

> Extension headers have been there for a while so I don’t believe that utilizing existing IPv6 extension headers could be considered as a “major change in the data plane”.

I await specifics. I infer that you want at least an order of magnitude increase in the scale of forwarding plane statistics. To my mind, that alone qualifies.

> Basically, in APN, the application data packets contains some bits in the header that will be used by the operator ingress devices in order to steer the packet into a pre-defined and installed poli…

If the point is not additional control, then your needs seem to be focused on scale.  What granularity of detail are you anticipating and what is the resulting scale? I infer that DSCP is an inadequate mechanism, so what classification mechanism are you suggestiing? Or is are we trying to do full per-flow tracking? If so, what managerial mechanisms are you suggesting for offloading this? Current day telemetry is nowhere near this.

> Is there a discussion anywhere of the costs of this approach and a cost/benefit analysis? Have you considered the scalability of a solution?  What about the added complexity to the architecture? My…

I’ll renew these questions as you haven’t addressed them.

Tony

p.s. I agree with Christian.

---

From: "Pengshuping (Peng Shuping)" <[email-masked]>
Date: Tue, 22 Sep 2020 03:06:24 +0000

Hi Tony,

Please find my responses in line. Thank you!

From: Apn [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, September 21, 2020 10:03 PM
To: Pengshuping (Peng Shuping) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Apn] [arch-d] Questions for APN: Q#3 and Q#4

Hi Shuping,

[Shuping] IPv6 is only one of the data planes for APN. Others are MPLS, VxLAN etc. We can utilize the existing routing technologies, but some extensions would be needed for enabling the APN. These extensions are the focuses of the RTG WGs. So the RTG area would be more appropriate.

[Shuping] Existing traffic steering mechanisms can be utilized and the scalability of those mechanisms needs to be considered altogether. It is solution related. In some scenarios APN can actually relief the scalability requirement since originally n tuples are required for traffic steering but still it won't achieve the accurate fine-granularity traffic steering purpose, but with APN few tuples would be needed and more accurate.

[Shuping] The information carried in the packets for traffic operations is actually open and the traffic classification is up to the operators’ policy configuration.
Please refer to the “Open App-Info” at the 2nd slide of this presentation.
https://github.com/APN-Community/IETF108-Side-Meeting-APN/blob/master/4%20Shuping%20Peng%20-%20Huawei%20-%20Application-aware%20Networking%20(APN)%20Framework.pdf

[Shuping]

These are all good questions and topics to be explored on APN as we progress the work further. These questions are all solution related. Very briefly I will put some thoughts here.

>Cost: the convey and resolution of the application-aware information for traffic operations within the limited network domain

>Benefits: the application-aware network service provisioning such as fine-granularity traffic operation and performance monitoring & visualization.

>Scalability: the main action is to steer traffic according to the application-aware information. Many existing traffic steering mechanisms (e.g. ACL) can be utilized and it would be the scalability of those mechanisms to consider. In some scenarios it actually reliefs the scalability requirement since originally n tuples are required for traffic steering and still it won't achieve the accurate fine granularity traffic steering purpose, but with APN few tuples would be needed and more accurate.

>Complexity: failed to see any complexity to be added to the architecture except the requirements for the application-aware information convey and resolution.

Best regards,

Shuping

Tony