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

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Thu, 08 October 2020 11:52 UTC

Return-Path: <evyncke@cisco.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 7B36D3A03FA; Thu, 8 Oct 2020 04:52:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=T+Yaymbb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=gBtYERlE
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 ijVYkTk0t9B6; Thu, 8 Oct 2020 04:52:15 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B0F93A09C6; Thu, 8 Oct 2020 04:52:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42553; q=dns/txt; s=iport; t=1602157935; x=1603367535; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=hlORY8Gi3RGtlF4h9uUD5YfgHie3wH13hlSAKiMJ3P8=; b=T+Yaymbbo4Og/TchJYwUPaHjLll+xyIfP7ssBV35S6r+KhRbeq5lVxzG ESgl+Hfbjpv5fJv20nzfSlqTrOGRt635UXWfxsqrSpLm2CWukd2lLq7a3 KpooY7TD8aNqTt2WNHVFlgAJWqiVEv+paBdBQ7xiWJkmCiCd4agdxyfLE k=;
IronPort-PHdr: 9a23:+t7RRhIV4rbNxxn4J9mcpTVXNCE6p7X5OBIU4ZM7irVIN76u5InmIFeGvKs/jELAQojarflDjrmev6PhXDkG5pCM+DAHfYdXXhAIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtVBc/halyUqXq3vnYeHxzlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CyBwAk/H5f/4QNJK1WAQmCWIEjLyMGKAdwWS8shD2DRgONUZh7gS4UgREDVQgDAQEBDQEBLQIEAQGESgIXgXICJTUIDgIDAQELAQEFAQEBAgEGBG2FXAyFcgEBAQEDEhEdAQElBwsBDwIBCBEDAQEBFgEKAQYDAgICMBQJCAEBBAENBSKDBAGBfk0DLgGeBgKBOYgVAUt2gTKDAQEBBYUlGIIQCTeBAYJygl1MQoJEg3QBHRuBQT+BESccgk0+g3YaAQMPOhYJCQ6CQTOCLZApgxuHBYwAkAqBCgqCaI9aiw0DH4MTigWUF5Mam2gFhC8CBAIEBQIOAQEFgVYBN4FXcBU7KgGCPlAXAg2OKxeBAgEJgkKKVnQ3AgYBCQEBAwl8iwYRF4IeAQE
X-IronPort-AV: E=Sophos;i="5.77,350,1596499200"; d="scan'208,217";a="570710550"
Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Oct 2020 11:52:13 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 098BqDAx021579 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Oct 2020 11:52:13 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 06:52:13 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 8 Oct 2020 06:52:12 -0500
Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 8 Oct 2020 06:52:12 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kPp7war/M0Zk+P1qcMiEKgdUFZM5IyQpeLd7EV/83tycDmpDIeGjERao1nrOMXu1RfGtN8ihY5UaArbwnkl4k3/vK4GMKhJeOR+WvOfo9viNQG6mfObJF54yU0V/Us9zLJcK00mOYpEFEFxPvvejn/z1wUbPVX5R/k07UQSfN+qrT2gJ5YiLQuohz88pqen5W6WBq/Zq8L7+mxd9S0hbQG6DDopwskisHz8JhXG60UIUIbrnqs2q2uCfDgAwsldLPKgoJUy/b8+/qzA7vV4ckb0kXAmRWdkNrKcVdxbgK40k6LiWsHJUN2D6W5vG8z2kMs+4MRSxC82ZTAoHc+Dukg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hlORY8Gi3RGtlF4h9uUD5YfgHie3wH13hlSAKiMJ3P8=; b=aAhs7pAz838TuArNalvy38+TIug6bfTpQMNBsSD5xBuaHp0nK8JrBWOLiqPX8U5PuPoutHff8AAG24xckpVsdobQcOnvFojRHJ95zOj+ytfMlaSUaH8TgAuQ2Gf1UvWIBROUNy8hFLo8okjFVye6MnAa5nSwSg3IUpV0/3ewNOYvCqx6cT/v9FUj1U3MA94s3fSvO2k3zwZU8Q/mxrjEFksaP+rV2tCS20vPVXMREHoXN7pl3cyg80t2eB2l+i9YW5ox1E7vL52Sy0/2DeUnX+lwtanz9GAKLApwnog2+k+cRddtYE19E20Dt+ABlUSz05agOJYZVU3svcNiOkhc6w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hlORY8Gi3RGtlF4h9uUD5YfgHie3wH13hlSAKiMJ3P8=; b=gBtYERlEL8AOmvI5gcJ37anG07DS8mmlws9jqfDOhL65yvK+OH0HJEVYz5Dk5Li2eoamhzOW6D1EDihzFRk4DKVXpoFH44KP4NKUgg9f++PTLxxQJCEMfZ4KMY5Qgzqr22c2nZMZU9SIUoCZ1saNqc4MC+yGSlCGYrC+yMxgKf4=
Received: from MWHPR11MB1853.namprd11.prod.outlook.com (10.175.55.17) by MWHPR11MB1680.namprd11.prod.outlook.com (10.172.54.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3433.34; Thu, 8 Oct 2020 11:52:10 +0000
Received: from MWHPR11MB1853.namprd11.prod.outlook.com ([fe80::b814:a5b3:83e7:80f1]) by MWHPR11MB1853.namprd11.prod.outlook.com ([fe80::b814:a5b3:83e7:80f1%3]) with mapi id 15.20.3455.025; Thu, 8 Oct 2020 11:52:10 +0000
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: Lizhenbin <lizhenbin@huawei.com>, 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/e9QACRuswABv4EisAAM97iA
Date: Thu, 08 Oct 2020 11:52:10 +0000
Message-ID: <9540508A-0E64-4EC6-AA6B-1A98F2F0E717@cisco.com>
References: <SN6PR13MB2334258C1D6048C4DA1D813E85360@SN6PR13MB2334.namprd13.prod.outlook.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D938909C6@DGGEMM532-MBX.china.huawei.com> <216F154B-144F-41C8-9913-BC6C5E540996@cisco.com> <5A5B4DE12C0DAC44AF501CD9A2B01A8D938A4E23@DGGEMM532-MBX.china.huawei.com>
In-Reply-To: <5A5B4DE12C0DAC44AF501CD9A2B01A8D938A4E23@DGGEMM532-MBX.china.huawei.com>
Accept-Language: fr-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.41.20091302
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2001:420:c0c1:36:4547:e946:96f1:ba38]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ace50a3b-2fc6-4f5b-08f7-08d86b80970f
x-ms-traffictypediagnostic: MWHPR11MB1680:
x-microsoft-antispam-prvs: <MWHPR11MB1680958874B8D651564614B9A90B0@MWHPR11MB1680.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: cnnDkWl2zhmqh24BQtkJj1twbsxQpr1GhGHxY12UIJYI1guSwdsHp/v4rMK4fdSkDdOREz0XOW8sgPrSh+uup/NYVMIYJ5KntFtewmXf86EUnWyjehvbMtqypER0h8hMHfaJFguFw9vEyZT6WSTWGrtaZmkB76kJSHIL94Yhac3mXWL/t9HH/GQQoTTtXTeboQ5YTjCtAkorFx62bLBii3+Y+h8zKGZW9T7rSapchk22fh3oRCXrHBl4kTG9muyUqOo5Si7j6TxwU6mrFP9GOz4bcFUcK8qbtjKfmFmyOgl4J43VCV+HOF7QpOlWCkHsX8gDv1cJWOEFVvlgCoN5Lw==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1853.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(366004)(376002)(396003)(346002)(5660300002)(66574015)(6512007)(316002)(76116006)(2906002)(6486002)(4326008)(66556008)(86362001)(66446008)(64756008)(71200400001)(6506007)(66476007)(66946007)(53546011)(186003)(110136005)(478600001)(8676002)(91956017)(33656002)(2616005)(36756003)(8936002)(83380400001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: l1g5hjYS0hXsKqz2RMYp8NGW0l9ap+UFKRZRQYNNCaEYKuGxOnL0tqT4eyMGH8FBZbWi1v8KoPuW8TW79qjrXWh1+EwH4wdp0NqzM6XL8X9Em06DF1PPdRC3oN+HNJi2ljmb/Vulw23ZbWzqM8bOZGkFYhbdFKodPuRWG/jWb6NWm3EzPSxFa3M+EO4NaQYZhIQ+9LPpKHvLeg6chsjJj8+yEN7g14EQqFQDIldOqlD9JdUowAt1zfbOF8Q3teI8S9oXBhFC2Aij0IGB6/CmAXXc7Xzf2TKMpWTwQUrCPbnOdyeSsZwy55UIE1MHBv5HkIuCf1xmj2q1Ni2MLBglaaYic5IK1+RSwYYHLNFyG+l54hE+HDnw6UJyq9uYAejmRMTKGhcezHpyl+oMMmq34UqQ8GYGxQ3PY/+iZYRfKujPlAe/Q8Nexj3hwmr51KCRsJm0HLN0fMwMggrH6OY77qyqePBp+Qcnfv7Tfe/G2u+tmq9MC1MInrMmhPmsQ9xuqjXczVX/TGAaUapsOGZUkBIxSg6FAIOT2N2g9FpT53AqQjlGaVyQV5N+/MS+QhoNXNtjqOmt6cHTEjDP5oVr/sdsSzmwguCXFx/4m+5UMRZaltuyavNgSnAI3JBCmdezk+l/A6VAIxNLC//FkKjdgfXGnF7Pqe9areVDL02Bc5q5+GQbx9KyWhLRsepCjNiLpyx5P7X8Iwkii4h/C7dLKg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_9540508A0E644EC6AA6B1A98F2F0E717ciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1853.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ace50a3b-2fc6-4f5b-08f7-08d86b80970f
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2020 11:52:10.5766 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: oURrxp4BP34ysqJMoteHEoE578XOeLoLGz3Xw3q0aQJyyQnMseLn7prcYeN7TES0ZUe4lcKpmou6+Km/OYFRYQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1680
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: alln-core-10.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/mEmJACJlwHleybEUw0ENXSqzrP0>
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: Thu, 08 Oct 2020 11:52:19 -0000

Hello Robin,

I hope that you and your family were able to enjoy a nice family time !

About the VLAN, if you consider that the APN6 ‘tag’ is originated by the CE device, then indeed it will stay intact accross the SP access network and could be propagated across L2VPN/EVPN but then:

  1.  It really requires deep packet inspection to get access to the .1Q tag in the SP network in case of L2VPN/EVPN
  2.  How can residential/enterprise intranet  VLAN information traverse the CE device? Or should the CE device use the ‘internal/private network’ VLAN tag to mark the traffic ?

I will need to think more about the ‘user’ information but it appears to me that is rather ‘SP subscriber’ and not “individual user” (such as a student in a University). Did I get the high-level view right?

Regards

-éric

From: Lizhenbin <lizhenbin@huawei.com>
Date: Thursday, 8 October 2020 at 10:28
To: Eric Vyncke <evyncke@cisco.com>, 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>
Subject: RE: Questions about draft-li-6man-app-aware-ipv6-network-02

Hi Eric,
Sorry for the delayed reply because we are having an 8-day holiday. Please refer to my reply inline.

Best Regards,
Robin



From: Eric Vyncke (evyncke) [mailto:evyncke@cisco.com]
Sent: Tuesday, September 29, 2020 4:07 PM
To: Lizhenbin <lizhenbin@huawei.com>; Linda Dunbar <linda.dunbar@futurewei.com>; IPv6 List <ipv6@ietf.org>; draft-li-6man-app-aware-ipv6-network@ietf.org
Cc: apn@ietf.org
Subject: Re: Questions about draft-li-6man-app-aware-ipv6-network-02

Robin,

About Linda’s interesting questions about APN, I also wonder why using VLAN tagging as this tag will be lost quickly after a couple of hops while the IPv6 prefix will be kept (this is what DT Terastream did if not mistaken).
[Robin] The VLAN tagging will truly be lost after a couple of hops. This is why we call it is used in the limited domains. In fact the VLAN tagged packet may traverse the metro network where L2VPN/EVPN + MPLS/SR are used before it arrives at the BRAS device. After the VLAN tagged packet are used for accounting at the BRAS, the packet whose VLAN tagging is removed maybe enter the IP core network where L3VPN + MPLS/SR are used for the transport. In the process, the packet will traverse a trusted domain under the control of one carrier. And it is possible that the user and service identification information represented by the VLAN tagging can be mapped to the possible MPLS encapsulated information or IPv6 encapsulated information if SRv6 is used as the transport tunnel for the purpose of fine-granularity services. This is an example that the user/service information can be acquired at the edge of network without interfering the original user packet though the information is not as accurate as that could be carried by the original packet.


Else, I agree with you that Flow-Id should not be used as it is assumed to be opaque.

Still puzzled though about the ‘user’ information as if the traffic is encrypted it is also often to hide the user identity.
[Robin] The above example show how to get the ‘user’ information (VLAN tagging) and how to use the ‘user’ information (in the limited domains). The information will be lost after traversing the limited domains. If still hope to use the user information, the only possibility is the possible user information encrypted. It is another problem beyond the scope of APN and face much challenges of security, privacy, etc.
In order to explain the issue clearly, I will try use another method. In fact the packet traverse the network can adopt the form of ‘X in Y’ where Y is the original packet and X is the outer encapsulation. You mentioned the user information in X. In fact, the outer encapsulation Y (here VLAN tagging is the example of Y) can also provide some user information besides the original user information in X. In the limited domains, the ‘X in Y’ can be changed to ‘X in Y in Z’ (IP in VLAN in MPLS/SRv6) or ‘X in Z’ (IP in MPLS/SRv6) where Y (VLAN tagging) is mapped to Z (MPLS/SRv6). APN work focuses on the user information in the ‘X in Y’, ‘X in Y in Z’ and ‘X in Z’. There is other work, especially in the APP/TSV area, which focuses directly on the user information in X.  They seems similar, but are different in essence.


Regards


-éric

From: ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> on behalf of Lizhenbin <lizhenbin@huawei.com<mailto:lizhenbin@huawei.com>>
Date: Monday, 28 September 2020 at 19:33
To: Linda Dunbar <linda.dunbar@futurewei.com<mailto:linda.dunbar@futurewei.com>>, IPv6 List <ipv6@ietf.org<mailto:ipv6@ietf.org>>, "draft-li-6man-app-aware-ipv6-network@ietf.org<mailto:draft-li-6man-app-aware-ipv6-network@ietf.org>" <draft-li-6man-app-aware-ipv6-network@ietf.org<mailto:draft-li-6man-app-aware-ipv6-network@ietf.org>>
Cc: "apn@ietf.org<mailto:apn@ietf.org>" <apn@ietf.org<mailto:apn@ietf.org>>
Subject: RE: Questions about draft-li-6man-app-aware-ipv6-network-02

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<mailto:ipv6@ietf.org>>; draft-li-6man-app-aware-ipv6-network@ietf.org<mailto: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