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

[David Schinazi <[e-mail]>]

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?

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.

Therefore, I believe this work should not proceed at the IETF.

Regards,
David


On Wed, 10 March 2021 14:47 UTC, "Pengshuping (Peng Shuping)" <
[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