Re: [arch-d] [Apn] Questions for APN: Q#3 and Q#4

"Pengshuping (Peng Shuping)" <pengshuping@huawei.com> Tue, 22 September 2020 03:06 UTC

Return-Path: <pengshuping@huawei.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E252A3A125D for <architecture-discuss@ietfa.amsl.com>; Mon, 21 Sep 2020 20:06:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-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 Y8o1H1DwqIkT for <architecture-discuss@ietfa.amsl.com>; Mon, 21 Sep 2020 20:06:33 -0700 (PDT)
Received: from huawei.com (szxga01-in.huawei.com [45.249.212.187]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF0D63A125B for <architecture-discuss@iab.org>; Mon, 21 Sep 2020 20:06:32 -0700 (PDT)
Received: from DGGEML404-HUB.china.huawei.com (unknown [172.30.72.57]) by Forcepoint Email with ESMTP id 2FF415BF1EE7B07D83A6; Tue, 22 Sep 2020 11:06:27 +0800 (CST)
Received: from DGGEML532-MBX.china.huawei.com ([169.254.8.242]) by DGGEML404-HUB.china.huawei.com ([fe80::b177:a243:7a69:5ab8%31]) with mapi id 14.03.0487.000; Tue, 22 Sep 2020 11:06:23 +0800
From: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>
To: "tony.li@tony.li" <tony.li@tony.li>
CC: "apn@ietf.org" <apn@ietf.org>, "network-tokens@ietf.org" <network-tokens@ietf.org>, "architecture-discuss@iab.org" <architecture-discuss@iab.org>
Thread-Topic: [Apn] [arch-d] Questions for APN: Q#3 and Q#4
Thread-Index: AdaNaBxLqPf7XieqTPGfrgD6k9Jj2wAJYM0AAIqDBkAACU85gAAjjkfw
Date: Tue, 22 Sep 2020 03:06:24 +0000
Message-ID: <4278D47A901B3041A737953BAA078ADE193EB76D@DGGEML532-MBX.china.huawei.com>
References: <4278D47A901B3041A737953BAA078ADE193C39B8@dggeml512-mbx.china.huawei.com> <6FFCB682-20EC-4DDD-8E2C-B2D6B2E4007C@tony.li> <4278D47A901B3041A737953BAA078ADE193E1DC3@DGGEML532-MBX.china.huawei.com> <E603D14A-E3F2-42B6-918A-1FBDAF974FA7@tony.li>
In-Reply-To: <E603D14A-E3F2-42B6-918A-1FBDAF974FA7@tony.li>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.153.195.37]
Content-Type: multipart/alternative; boundary="_000_4278D47A901B3041A737953BAA078ADE193EB76DDGGEML532MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/zABsCbOkJTtJwYaXEiWAahLL_Sc>
Subject: Re: [arch-d] [Apn] Questions for APN: Q#3 and Q#4
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Sep 2020 03:06:36 -0000

Hi Tony,

Please find my responses in line. Thank you!

From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of tony.li@tony.li
Sent: Monday, September 21, 2020 10:03 PM
To: Pengshuping (Peng Shuping) <pengshuping@huawei.com>
Cc: apn@ietf.org; network-tokens@ietf.org; architecture-discuss@iab.org
Subject: Re: [Apn] [arch-d] Questions for APN: Q#3 and Q#4


Hi Shuping,



APN doesn’t really introduce any change in any routing protocol. The goal is to be able to better classify packets and assign them to policies. How these policies are defined and operated are outside the scope of APN and rely on existing routing policy technology.


Then perhaps RTG is not appropriate.  Perhaps INT would be more to the point.


[Shuping] IPv6 is only one of the data planes for APN. Others are MPLS, VxLAN etc. We can utilize the existing routing technologies, but some extensions would be needed for enabling the APN. These extensions are the focuses of the RTG WGs. So the RTG area would be more appropriate.


Extension headers have been there for a while so I don’t believe that utilizing existing IPv6 extension headers could be considered as a “major change in the data plane”.


I await specifics. I infer that you want at least an order of magnitude increase in the scale of forwarding plane statistics. To my mind, that alone qualifies.


[Shuping] Existing traffic steering mechanisms can be utilized and the scalability of those mechanisms needs to be considered altogether. It is solution related. In some scenarios APN can actually relief the scalability requirement since originally n tuples are required for traffic steering but still it won't achieve the accurate fine-granularity traffic steering purpose, but with APN few tuples would be needed and more accurate.


Basically, in APN, the application data packets contains some bits in the header that will be used by the operator ingress devices in order to steer the packet into a pre-defined and installed policy (e.g. a traffic engineered path or a source routed path). The current state of routing protocols allow the provisioning, computation and installation of these policies without any additional change.


If the point is not additional control, then your needs seem to be focused on scale.  What granularity of detail are you anticipating and what is the resulting scale? I infer that DSCP is an inadequate mechanism, so what classification mechanism are you suggestiing? Or is are we trying to do full per-flow tracking? If so, what managerial mechanisms are you suggesting for offloading this? Current day telemetry is nowhere near this.


[Shuping] The information carried in the packets for traffic operations is actually open and the traffic classification is up to the operators’ policy configuration.
Please refer to the “Open App-Info” at the 2nd slide of this presentation.
https://github.com/APN-Community/IETF108-Side-Meeting-APN/blob/master/4%20Shuping%20Peng%20-%20Huawei%20-%20Application-aware%20Networking%20(APN)%20Framework.pdf


Is there a discussion anywhere of the costs of this approach and a cost/benefit analysis? Have you considered the scalability of a solution?  What about the added complexity to the architecture? My apologies if I’ve missed something obvious.


I’ll renew these questions as you haven’t addressed them.

[Shuping]

These are all good questions and topics to be explored on APN as we progress the work further. These questions are all solution related. Very briefly I will put some thoughts here.

>Cost: the convey and resolution of the application-aware information for traffic operations within the limited network domain

>Benefits: the application-aware network service provisioning such as fine-granularity traffic operation and performance monitoring & visualization.

>Scalability: the main action is to steer traffic according to the application-aware information. Many existing traffic steering mechanisms (e.g. ACL) can be utilized and it would be the scalability of those mechanisms to consider. In some scenarios it actually reliefs the scalability requirement since originally n tuples are required for traffic steering and still it won't achieve the accurate fine granularity traffic steering purpose, but with APN few tuples would be needed and more accurate.

>Complexity: failed to see any complexity to be added to the architecture except the requirements for the application-aware information convey and resolution.


Best regards,

Shuping





Tony

p.s. I agree with Christian.