[Apn] Issues to be closed

"Pengshuping (Peng Shuping)" <pengshuping@huawei.com> Mon, 06 December 2021 01:17 UTC

Return-Path: <pengshuping@huawei.com>
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 26C2A3A05F8; Sun, 5 Dec 2021 17:17:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 F-lpFoAgI1xe; Sun, 5 Dec 2021 17:17:04 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3183A05E2; Sun, 5 Dec 2021 17:17:03 -0800 (PST)
Received: from fraeml707-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4J6lqd3tsPz67LyN; Mon, 6 Dec 2021 09:15:57 +0800 (CST)
Received: from canpemm100005.china.huawei.com (7.192.105.21) by fraeml707-chm.china.huawei.com (10.206.15.35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Mon, 6 Dec 2021 02:16:59 +0100
Received: from canpemm500008.china.huawei.com (7.192.105.151) by canpemm100005.china.huawei.com (7.192.105.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.20; Mon, 6 Dec 2021 09:16:58 +0800
Received: from canpemm500008.china.huawei.com ([7.192.105.151]) by canpemm500008.china.huawei.com ([7.192.105.151]) with mapi id 15.01.2308.020; Mon, 6 Dec 2021 09:16:58 +0800
From: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
To: apn <apn@ietf.org>
CC: "rtgwg@ietf.org" <rtgwg@ietf.org>, "architecture-discuss@iab.org" <architecture-discuss@iab.org>
Thread-Topic: Issues to be closed
Thread-Index: AdfoHJnwy/+Z96LGTTGQqV+7k0p1Lg==
Date: Mon, 06 Dec 2021 01:16:57 +0000
Message-ID: <31b6fb560a03474f8d1a31e55cd1746f@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.112.41.150]
Content-Type: multipart/alternative; boundary="_000_31b6fb560a03474f8d1a31e55cd1746fhuaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/O0j5_8uuJiV8xqm2gHnJ7pnLxno>
Subject: [Apn] Issues to be closed
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, 06 Dec 2021 01:17:09 -0000

Dear all,

Following the summary report on the APN@IETF112 [1], we list the questions/comments we received during the BoF as recorded in the meeting minutes [2] as below. Please have a look at these questions and let us know if there are any other key questions being missed out.

We are going to start answering these questions and try to close them one by one. Your attention and participation into the discussions are very welcomed. The tool would be the Github issue tracker. If you have better suggestion please let us know. Thank you!

[1] https://mailarchive.ietf.org/arch/msg/apn/OoOgezkAAbd2uFrY2Mk4ZxSbVzM/
[2] https://datatracker.ietf.org/meeting/111/materials/minutes-111-apn-00.txt

Part 1: General Questions

1.       What happens to a flow if a hop can't meet the APN requirements?

2.       Does APN introduce a new data plane when it is supposed to work with any data plane?

3.       Do we need to define a new data plane to carry this info, while you could use existing mechanisms?

4.       Is it expected that the APN ID and parameters be "normalized' (standardized) or be defined domain specific?

5.       If the APN is trying to make app get better service for it from the network, how does it do that? Especially when every app want better service?

6.       What is the problem domain of APN? What is the problem APN is trying to solve?

7.       Why do we need an abstract container for service info across all tunneling mechanisms?

8.       Do we have a protocol mechanism to enforce what's in the APN marking and when it's removed?

9.       How large is the space of APN attributes? If the existing field is enough to identify and individual (e.g. by physical port), could the attribute carry a user identifier?

Part 2: APN Domain

10.   Is APN designed for a single domain or multiple domains?

11.   Is it a normal case that 1 SP has multiple domains?

12.   Is that the entire value of these APN tunnels is to communicate information across domains?

Part 3: Opaque

13.   Is opaque used solely wrt privacy of info from which APN ID is derived? Is that just opaque lookup based on ID?

14.   What is opaque lookup? Which parameters are supposed to use? What exactly are you looking?

15.   Is opaque contradictory to the APN parameters? Does such a "treat as opaque" case actually use the full richness of attributes?

Part 4: Security/Privacy

16.   What is the mechanism that forces this attribute to be stripped at the network operator's boundary?

17.   Is this literally a mechanism for creating and sharing arbitrary metadata about arbitrary aggregates across arbitrary boundaries, which creates as much or more room for trouble?

Part 5: Flow Label

18.   Could the flow label be used for APN, which is designed for similar purpose?

Part 6: 5 Tuple

19.   Is that "structured attribute" more accurate than "tag"? How resulting resolution complexity will compare with 5-tuples being used?

20.   Does APN ID carry a piece of information that is potentially semantically *richer* than the five tuple and making that available to path elements that would not otherwise have that data?

21.   How can the edge routers estimate APN ID and parameters (latency, bandwidth, etc.) just from 5-tuple? Is there any interface or API between application and APN domain controller?

Part 6: Diffserv

22.   Why copying inner TOS to outer TOS and using existing equipment is not enough?

23.   Is APN able to express such "policies" so that a developer does not hardcode DSCP bits with a Excel spreadsheet on its desk to know what mapping means what?

Part 7: Network Slicing

24.   Is APN similar to or the same as Network Slice, just with a different name?

25.   Is the gap that existing approaches, e.g., Network Slice, only provide limited granularity but APN an unlimited one?

26.   Is slicing more general because addressing MULTI operator scenarios?

Part 8: DetNet

27.   What does APN bring that isn't already being done within DetNet?

Part 9: Open Mic

28.   What does the APN architecture add that isn't in existing IETF architectures and solutions?

29.   Why do we need an agnostic mechanisms instead of just hacking into existing mechanism individually? This adds to why having a single WG to focus on a technology agnostic mechanism would be useful before various data plane encapsulations are developed separately?

30.   If a problem does exist it does not have to be solved in the data plane, it could be the management plane.

31.   What different treatment will the network give my traffic if I'm in finance vs. marketing?

32.   Is there violation of the user's privacy/security?

Part 10: Chairs Summary (may overlap with previous questions as a summary)

33.   Why APN is needed when there are multiple existing mechanisms, just as DetNet and Network Slicing?

34.   How privacy affects APN, especially about accidental breach of privacy and subversion of decapsulation?

35.   Use cases need to explain more about what is needed from the APN attribute and what policies are applied in the network. We need more detailed "killer" use case examples.

36.   The APN attribute should not become a way of carrying arbitrary metadata. It is not clear at this stage what information needs to be in the APN attribute versus what information could be in the APN attribute.

37.   We also need more understanding of how APN is relevant in encrypted environments.

38.   Should APN be applied to multiple transport/underlay protocols or should it be better to pick just one and use it in all APN-enabled networks?

Best Regards,
Shuping