Re: [Apn] Questions about draft-li-6man-app-aware-ipv6-network-02

Lizhenbin <lizhenbin@huawei.com> Mon, 28 September 2020 17:33 UTC

Return-Path: <lizhenbin@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 53E373A12E9; Mon, 28 Sep 2020 10:33:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-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 gQAFMeXuy_-d; Mon, 28 Sep 2020 10:33:13 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 42C6B3A12D5; Mon, 28 Sep 2020 10:33:13 -0700 (PDT)
Received: from lhreml710-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 00AF2FE36336BD08C371; Mon, 28 Sep 2020 18:33:09 +0100 (IST)
Received: from lhreml710-chm.china.huawei.com (10.201.108.61) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 28 Sep 2020 18:33:09 +0100
Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml710-chm.china.huawei.com (10.201.108.61) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Mon, 28 Sep 2020 18:33:09 +0100
Received: from DGGEMM532-MBX.china.huawei.com ([169.254.7.14]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0487.000; Tue, 29 Sep 2020 01:33:06 +0800
From: Lizhenbin <lizhenbin@huawei.com>
To: Linda Dunbar <linda.dunbar@futurewei.com>, IPv6 List <ipv6@ietf.org>, "draft-li-6man-app-aware-ipv6-network@ietf.org" <draft-li-6man-app-aware-ipv6-network@ietf.org>
CC: "apn@ietf.org" <apn@ietf.org>
Thread-Topic: Questions about draft-li-6man-app-aware-ipv6-network-02
Thread-Index: AdaTZqEn8gTX6C5CTS2Ceg4YlCkN3QCT/e9Q
Date: Mon, 28 Sep 2020 17:33:06 +0000
Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D938909C6@DGGEMM532-MBX.china.huawei.com>
References: <SN6PR13MB2334258C1D6048C4DA1D813E85360@SN6PR13MB2334.namprd13.prod.outlook.com>
In-Reply-To: <SN6PR13MB2334258C1D6048C4DA1D813E85360@SN6PR13MB2334.namprd13.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.45.218.208]
Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D938909C6DGGEMM532MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/ekEcK4ob4rz_PPoFRNubfhqf2mY>
Subject: Re: [Apn] Questions about draft-li-6man-app-aware-ipv6-network-02
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, 28 Sep 2020 17:33:15 -0000

Hi Linda,
Please refer to my reply inline. APN mailing list is copied.


Best Regards,
Zhenbin (Robin)

From: Linda Dunbar [mailto:linda.dunbar@futurewei.com]
Sent: Saturday, September 26, 2020 2:23 AM
To: IPv6 List <ipv6@ietf.org>; draft-li-6man-app-aware-ipv6-network@ietf.org
Subject: Questions about draft-li-6man-app-aware-ipv6-network-02

Zhenbin, et al,

I have some questions on the draft-li-6man-app-aware-ipv6-network-02:

Page 5: App-aware Edge Device: This network device receives packets from IPv6 enabled applications and obtains the application characteristic information.

I am curious how does App-aware Edge Device derives the application characteristics information ?  Your draft mentioned VLAN tagging, How VLAN tagging can provide Application characteristics information?
[Robin] There are different ways for VLAN tagging to provide application characteristics information. Here I propose one example: the user hosts/apps can connect to the home gateway which can add different VLANs called S-VLAN to identify the different services. For example VLAN1 is used for Internet service and VLAN2 is used for IPTV service. The home gateway will connect to the DSLAM on which the VLAN call C-VLAN will be added to identify the home user. So when the IP-based edge network device receives the packet, it can derive the user ID and service type information from the VLAN tagging. We have explained that the APN work focuses on the limited domains rather than open Internet. The VLAN tagging shows that there is similar practice in the access network.


Page 6: Is the Application-aware ID another extension field? Or part of existing extension header? Like a subTLV within the Hop-by-hop options Header Type?
[Robin] Application-aware ID is an option which can be used in DOH/HBH/SRH. It is part of existing extension headers. It can be seen as a type of TLV.

Questions about the  Application-Aware ID structure in Figure 4:
Why not use IPv6 Header "Priority/Traffic class" field to represent the SLA Level?
[Robin] The design is to take integrity into account. That is, all the information can be obtained from the single Application-aware ID. Traditionally we can get different parts' information to compose some type of tuple. The process has effect on the forwarding performance and the scalability of forwarding entries.

Can you use IPv6 Header's "Flow Label" field to represent the App ID and Flow ID?
[Robin] Integrity is the same reason for the problem. In addition "flow label" will be used for ECMP. Reusing it may cause the compatibility issue.

How can network acquire the information about "USER" information? I would think most applications encrypt their user information.
[Robin] The above example shows that C-VLAN can be used to acquire USER information. Though the application may encrypt their user information, not only APN needs the USER information, but also the carriers need to learn the USER information for accounting to get revenue. There already exists the possible way to solve the issue.

What kind of functions do you envision to be listed in the Figure 6's Function ID?
[Robin] Figure 6 is to reuse the SRv6 SID. The function ID means just the functions supported by the existing SRv6. The Application-aware ID is put into the arguments of the SRv6 SID. The function ID part will not have effect on the Application-aware ID.


[Robin] Thanks for your comments and questions. Now the draft is in the early phase. The usage of the Application-aware ID option can be further discussed.

Thank you very much.

Linda Dunbar