Re: [Apn] APN Charter

["Pengshuping (Peng Shuping)" <[e-mail]>]

Dear Andrew, all,

It is truly great to see so many constructive suggestions on helping to improve the APN Charter even in the current blocks and the way of conducting the following work. I can see that most of the comments are due to the conciseness of the current Charter, and I agree that more concrete description would be helpful.

I also found that most of the comments center on a few points, so here I try to provide more information to help clarification and understanding.

The common comments and further clarifications:

1. What is an APN domain?

By APN domain we intend the operator infrastructure where APN is used from edge to edge (ingress to egress) and where the packet is encapsulated using an outer header incorporating the APN information.

APN aims to leverage the ability to apply policies to traffic flows entering into the infrastructure (APN domain).  For example, at the headend (ingress) traffic is steered into a given path/policy, at a midpoint node the corresponding performance measurement data is collected, and at a service node a given function is executed.

APN assumes traffic is tunnel encapsulated edge-to-edge tunnel encapsulation within a limited trusted domain.  It means that the source and destination addresses of the packet are the endpoints of the tunnel (i.e. the domain edges), and nothing about the payload source and destination can be deduced, which substantially reduces the privacy concerns.

Typically, an APN domain is defined as a Network Operator controlled limited domain, in which MPLS, VXLAN, SR/SRv6 and other tunnel technologies are adopted to provide network services.

Some of these words above could be put into the Charter if everybody agrees since it will help clear the doubts in people's minds.

2. What is a fine-granularity service?

To be more precise, APN enables "fine-granularity network service provisioning (traffic operations)" of network operators.

Driven by the ever-emerging diverse demanding services, the lack of the fine-granularity information about the services in the network will cause the following issues: 1) the service information is not clearly described and known by the network, 2) the fine-granularity service provisioning capability is not fully utilized, 3) a fine-granularity service scheduling and measurement cannot be achieved.

One of the key objectives of APN is for network operators to provide fine-granularity SLA guarantees instead of coarse-grain traffic operations.  This will allow to provide differentiated services for different applications and increase revenue accordingly.  Among various applications being carried and running in the network, some revenue-producing applications such as online gaming, video streaming, and enterprise video conferencing have much more demanding performance requirements such as low network latency and high bandwidth.  In order to achieve better Quality of Experience (QoE) for end users and engage customers, the network needs to be able to provide fine-granularity and even application group-level SLA guarantee.

Again, some of these words above could be put into the Charter if everybody agrees since it will help clear doubts.

3. How to deal with the Security and Privacy concerns?

I believe that it has been emphasized, through even the usage of the normative language in the Charter, that the APN work will not affect the network outside of the APN domain and the security and privacy consideration is a must to produce the work in this WG. This shows the importance.

Charter: "...APN info MUST be removed when the packets leave the APN domain. Both security and privacy MUST be carefully considered in this framework."

A separate draft on these aspects could also be added as a milestone of this WG, and experts can contribute on that draft to define the key principles to follow.

4. How is APN different from existing labeling or encapsulation methods? Whether the existing encapsulations and header fields can be reused?

The gap analysis draft [3] has explained on this extensively. APN extends the ability of packet marking (APN Information) in order to give a better fine tuning capability to operators. Thanks to the years' hard work of the network engineers, the network capabilities have become very rich such as deterministic networking and network slicing which can provide more network functions than QoS. APN can further unleash these capabilities. The APN work does not interfere with TE (all flavors), or Slicing (whatever flavor is) or any other form of traffic engineering. It is a complement to all of these. The APN header containing these marking bits can be encapsulated in the existing encapsulations, and APN is not to change any protocol behavior nor to change data plane procedures and functions.

For more information, please refer to the latest version of the APN related drafts.
[1] https://datatracker.ietf.org/doc/html/draft-li-apn-framework-06
[2] https://datatracker.ietf.org/doc/html/draft-li-apn-problem-statement-usecases-07
[3] https://datatracker.ietf.org/doc/html/draft-peng-apn-scope-gap-analysis-05

Thank you!

Best Regards,
Shuping


From: Apn [mailto:[e-mail]] On Behalf Of Andrew Alston - IETF
Sent: Thursday, October 6, 2022 2:57 PM
To: [e-mail]
Subject: [Apn] APN Charter

Hi All,

As we move forward with attempting to charter the APN working group, as you may have seen there have been a few blocks on the charter which was submitted.

I'd like to see some discussion on the block points to see if we can come to consensus on the list as to how best to deal with these issues so that we can proceed.

The full draft charter for those that didn't see it can be found at https://www.ietf.org/charter/charter-ietf-apn-00-00.txt.

Comments were as per what appeared on the list.

Any thoughts, comments or suggestions would be appreciated and once I have feedback we can then work it into some revisions and continue from there.

Thanks

Andrew Alston
Routing AD





Internal All Employees