[Apn] Fwd: [IAB] IETF 111 reports: APN BOF

Jari Arkko <jari.arkko@piuha.net> Mon, 02 August 2021 08:29 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: apn@ietfa.amsl.com
Delivered-To: apn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3369B3A134D for <apn@ietfa.amsl.com>; Mon, 2 Aug 2021 01:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78Z2zY5djkge for <apn@ietfa.amsl.com>; Mon, 2 Aug 2021 01:29:34 -0700 (PDT)
Received: from p130.piuha.net (p130.piuha.net [193.234.219.226]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF903A134C for <apn@ietf.org>; Mon, 2 Aug 2021 01:29:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A9BFA6601E7 for <apn@ietf.org>; Mon, 2 Aug 2021 11:29:32 +0300 (EEST)
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2YWZmVn5ahs for <apn@ietf.org>; Mon, 2 Aug 2021 11:29:31 +0300 (EEST)
Received: from smtpclient.apple (unknown [193.234.219.226]) by p130.piuha.net (Postfix) with ESMTPS id D50306600EF for <apn@ietf.org>; Mon, 2 Aug 2021 11:29:30 +0300 (EEST)
From: Jari Arkko <jari.arkko@piuha.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_9ECA5F9F-420B-4F4A-B330-436D1C36DB31"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Message-Id: <7FF6833D-0FF1-4FC1-932C-812C85AACD36@piuha.net>
References: <BE2D7F4A-D5C6-42EF-95F4-95866BD4A428@piuha.net>
To: apn@ietf.org
Date: Mon, 02 Aug 2021 11:28:30 +0300
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/CUYiqc9ON-fexjDRXACaBfpYRww>
Subject: [Apn] Fwd: [IAB] IETF 111 reports: APN BOF
X-BeenThere: apn@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Application-aware Networking <apn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/apn>, <mailto:apn-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/apn/>
List-Post: <mailto:apn@ietf.org>
List-Help: <mailto:apn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/apn>, <mailto:apn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Aug 2021 08:29:39 -0000

IAB members are expected to track and report on BOFs that they visit during the IETF week. Our reports are mostly made for the AD and the IAB and are just for information, but I like to send my reports to the BOF list as well in case it is useful. Of course, what is in this report is just an individual opinion. ADs, the group itself, etc. typically have different views.

Jari

> Begin forwarded message:
> 
> From: Jari Arkko <jari.arkko@piuha.net>
> Subject: [IAB] IETF 111 reports: APN BOF
> 
> The BOF was well run and there was enough information and plenty of time for (IMO, high quality) discussion. Thank you Adrian Farrell, Bob Hinden, and Dan Voyer for running the meeting and allowing the discussion to flow and and making sure everyone got to make their points, including prioritising new people’s comments from the mic. We should probably do that more often.
> 
> Martin Vigoureux, the AD, underlined the need for any standards work in this space to have sufficient diversity of participants and players. He also said the proposal may have started on the wrong foot, but they've changed the approach significantly. Lets give the BOF a fair shot. Similarly, Adrian noted that the effort should not be understood according to the name "application-aware", but rather according to the actual proposals as the evolving function may not match the name any more.
> 
> Zhenbin Li introduced APN. The basic idea is that packets will  be classified on the edge according to their 5-tuples and access ports, and a structured attribute attached to the packet as it is tunneled through the network. Application or user identity  based classification is not in scope. The benefit of APN is that you only do the 5-tuple mapping once, and the rest of the network can operate based on the APN attributes.
> 
> Gyan Mishra talked about why existing mechanisms are insufficient. DSCP markings do not have enough bits. IPv6 flow labels, SFC serviceIDs, SR binding SIDs, etc. are lacking according to the proponents, largely based on argument about them being used in special circumstances (?) Although to me it seemed that any design based on a new APN encapsulation protocol would also be used in the special circumstance of APN being deployed in that particular network. Three other short presentations were also given by Luis Contreras, Chongfeng Xie, and Shuping Peng.
> 
> The main points in discussion revolved around:
> 
> 1/ Whether new technology and tunneling/encapsulation technology is needed, or if existing tools are sufficient.
> 
> 2/ Whether there are issues in distributing a very general information field, rather than a specific and limited information item.
> 
> I'd say there was fairly broadly shared opinion among the chat and mic line participants that these two are issues. We could discuss the details, there are interesting points to dwell into, and certainly no uniform agreement on all details. But maybe the high-level bit is that there are some concerns at least.
> 
> I suggested that maybe a more realistic approach at the IETF would be to write an informational document that explains how to use network edge classification to encode a tag with very few bits, and  how to transport that tag using existing IETF encapsulations. That might reduce both of the above concerns.
> 
> Martin declared the BOF a success in terms of being able to discuss the topic. But he said that there is undeniably a gap that needs to be filled between the proponents and the community. The objective is generally well understood, but there's a question mark why the objective cannot be achieved using existing tools.
> 
>