Re: [Apn] APN presentation in SAAG on Thursday.

[Lizhenbin <[e-mail]>]

Hi David,
Please refer to my reply inline.

Best Regards,
Robin


From: Apn [mailto:[e-mail]] On Behalf Of David Schinazi
Sent: Saturday, March 13, 2021 2:44 AM
To: Lizhenbin <[e-mail]>; Pengshuping (Peng Shuping) <[e-mail]>; APN <[e-mail]>
Subject: Re: [Apn] APN presentation in SAAG on Thursday.

Hello Zhenbin and Shuping,

Thank you for the discussion in SAAG. Now that I have a better understanding of your proposal, I would like to share some thoughts here on the list.

But first let's make sure I understood you correctly. In the meeting you mentioned that the client device (e.g. mobile phone) does not send any APN-related data, and that there is a network device that looks at the 5-tuple, and uses a classification mechanism to infer the APN data (application ID, user ID, etc.). In theory, any network appliance that wishes to provide applications with different treatment could run the same classifier. You made the argument that this classifier might be expensive to run on every network appliance, so you would prefer to run it once, and write the result in the packet so other network appliances can simply use the result. You also mentioned that there is a non-IETF encapsulation mechanism being used between these network appliances. Is my understanding correct? If not, can you point out anything I misunderstood?
[Robin]
1. It is right to run it once with the classification mechanism and the result can be carried in the limited network domain.
2. Because of the time reason, I did not explain more about the tunnel encapsulation in the SAAG session. Here I can explain more about the tunnel. Firstly, the GTP-u tunnel is standardized in 3GPP and also complied with the IETF standards on TCP/IP. Secondly the tunneled packet will go on to traverse the mobile transport network which will adopt the MPLS, SR and other tunnel encapsulation (that is the tunneled packet will be tunneled again). In addition, now there also exists work to use SRv6 tunnel as the alternative of GTU-u tunnel in IETF DMM WG. Finally, according to your example, I only explained the principle of wireless access. In fact in the fixed access and other enterprise network scenario, there will the use cases that packet will be directly tunneled through MPLS/SR/VXLAN without GTP-u.


Assuming I understood correctly, then I don't see a need for IETF to solve this problem. You are free to modify the non-IETF encapsulation protocol to augment it with this APN information, you do not need to have this information in an IPv6 extension header, and you do not need an IETF standard.
[Robin] As the above explanation and our clarification in the slide, the APN attribute info need be carried along with the MPLS/VXLAN/SR tunnels which are standardized in IETF (that is they are the IETF encapsulation). When SR is used, there is the SR over IPv6 (refer to the latest RFC8976). Thus for the SRv6 tunnel, the APN attribute info need to be encapsulated in the IPv6 extension header.

Therefore, I believe this work should not proceed at the IETF.
[Robin] If you think the APN attribute info can be carried along with the MPLS/SR/VXLAN tunnel, we need to proceed the work in the RTG area of IETF since most of the tunnels are standardized in the area. That is also the reason why I as the person always work in the RTG area presented the work in the sessions of the ART/SEC/INT areas. I wish the cross-area communication in the IETF can be help understand each other more.


Regards,
David


On Wed, 10 March 2021 14:47 UTC, "Pengshuping (Peng Shuping)" <[e-mail]<mailto:[e-mail]>> wrote:
> Hi Folks,
>
> Thanks to the ADs and the Chairs, we are going to present APN (Application-aware Networking) in the SAAG working group at 13:00-15:00 (UTC+1) Thursday.
>
> APN is focused on developing a framework and set of mechanisms to derive, convey and use an attribute information to allow for the implementation of fine-grain user (group)-, application (group)-, and service-level requirements at the network layer. APN works within a limited trusted domain, which typically is defined as a service provider's limited domain in which MPLS, VXLAN, SR/SRv6 and other tunnel technologies are adopted to provide services.
>
> In the presentation, we would like to introduce the concepts, clarify the scope, attract people to understand and discuss the topic, and collect feedback and suggestions on this work, to further address the main concerns that were raised by the IESG.
>
> For the SECers, we would like to especially know about what the security issues are when the APN attribute is used within a limited operator's controlled domain.
>
> Please find the latest version of the key draft, clarifying the scope and the gap analysis.
> https://datatracker.ietf.org/doc/html/draft-peng-apn-scope-gap-analysis-01
>
> We have been discussing in the APN mailing list regarding the various aspects of APN. If you have not subscribed, you are very welcome to subscribe. You can also find the archived discussions.
> https://datatracker.ietf.org/wg/apn/about/
>
> More information about APN can be found here.
> https://github.com/APN-Community
>
> Best Regards,
> Shuping