Re: [Apn] Issues to be closed #13-#15

"Black, David" <David.Black@dell.com> Tue, 28 December 2021 20:47 UTC

Return-Path: <David.Black@dell.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 0D08A3A1983; Tue, 28 Dec 2021 12:47:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level:
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, 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_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com
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 8x6h6S8y8kfV; Tue, 28 Dec 2021 12:47:11 -0800 (PST)
Received: from mx0a-00154904.pphosted.com (mx0a-00154904.pphosted.com [148.163.133.20]) (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 270B23A1982; Tue, 28 Dec 2021 12:47:11 -0800 (PST)
Received: from pps.filterd (m0170389.ppops.net [127.0.0.1]) by mx0a-00154904.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 1BSK8qXH019378; Tue, 28 Dec 2021 15:47:09 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=smtpout1; bh=vAZNatIWD7wiQoBBoSQei9xBLAgj1SClMLbGo0g0Ohs=; b=O+OsnFxP3E7vwUvSAwsa2Tj1Utzh0VgogFywMmO4jq5pUOja3Rgq5Jgt8hssplrnV3gH S1Onscq0S7DaLMNEupRuLxYSPxIT1iNqeRDUlqyfDe8wpldUdHQ7MGx0tzA6ICvYIQnK D5yk4nDFd16GE6G+n7abxkG4WRI+BZpNiA+ZcNCJ/UpkQfdhA7BOncII5Wa70okbQvOP bQXLFm5LvEkvYMx23IyB6ljii4Az6fiY+gu57TKUndyTguK90VyBhUFyH7BpY/77FMQQ hu5JlOUFEmvE1b4YV1VlD1uSDki70NBcwhCI6MH/PzZlih+aETI3kBo+M+q+KPTfd2fh 3w==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0a-00154904.pphosted.com (PPS) with ESMTPS id 3d7fjg4ye0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Dec 2021 15:47:08 -0500
Received: from pps.filterd (m0144104.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 1BSKjHZr169892; Tue, 28 Dec 2021 15:47:07 -0500
Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-00154901.pphosted.com with ESMTP id 3d7ukwjak8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Dec 2021 15:47:07 -0500
Received: from m0144104.ppops.net (m0144104.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 1BSKl7Q2174683; Tue, 28 Dec 2021 15:47:07 -0500
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2101.outbound.protection.outlook.com [104.47.70.101]) by mx0b-00154901.pphosted.com with ESMTP id 3d7ukwjak4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 28 Dec 2021 15:47:06 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n5BzpfIGaYUWLb3zSeoeLxBzGek8HSylj1Md3zzG74YijyR8bNU8oiDAXSAE87gBDfTq3DqgwnNaI2PYQB1cSYKv0Rt249DGzcwOYcrwtBQkwFl41N77J6UGrlBau0BaIZ8I3bn+Bf/11bTIl+UEqBFVnrZU+VxBXjQ5NpkyW9Z7pM0g0gFkFshZzsAugBQasCUFphG3sFlKBY+nCwdV5+Xe1RnrZ9sp3EtRqqTebAlpIYKxvPErjX1WNWGIsjL7eELDSvVw0tulHzaIPxXJnvugscql3NaOzCqVcV9hynkoUtYXZly+kqGMJTYUDTMOHuYsTar5xL7CZqBHUAJvVw==
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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vAZNatIWD7wiQoBBoSQei9xBLAgj1SClMLbGo0g0Ohs=; b=AE359uslsELBRS7jiUenAhkXsD20G6gzH4yGWLX2oREfxqjuIfB/bCe7TEHbsXIuhRSjddGy7V3U0y3OE8h5kTQlg1FZKUN2wgVePZGpT/oElHBenAhdkXHPSXC9Xft+7dzLA3AjakFYvgc0eZ4JnjB/CDsj/e4BZSUom+DX2rmbVsej805DwqdLXyjnXUc9M3CXK3KNnik/FhI0vRjNVXLPqWQMKoPY+6z63hqfrXka3D0grOUJ+g2NOp1tkRdTOr1wHf5+IWkStOws0Toyu83j2u7tv6l63Z4BETIPVmAyPl4cteEMvVK9EfAOBrnQDjsRV6JWJmL5ATeouLFi/g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dell.com; dmarc=pass action=none header.from=dell.com; dkim=pass header.d=dell.com; arc=none
Received: from MN2PR19MB4045.namprd19.prod.outlook.com (2603:10b6:208:1e4::9) by BL0PR1901MB1986.namprd19.prod.outlook.com (2603:10b6:207:31::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4823.22; Tue, 28 Dec 2021 20:47:04 +0000
Received: from MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::2825:237b:6e94:80bb]) by MN2PR19MB4045.namprd19.prod.outlook.com ([fe80::2825:237b:6e94:80bb%4]) with mapi id 15.20.4823.023; Tue, 28 Dec 2021 20:47:04 +0000
From: "Black, David" <David.Black@dell.com>
To: "Pengshuping (Peng Shuping)" <pengshuping@huawei.com>, apn <apn@ietf.org>
CC: "rtgwg@ietf.org" <rtgwg@ietf.org>, "kaduk@mit.edu" <kaduk@mit.edu>, "Black, David" <David.Black@dell.com>
Thread-Topic: Issues to be closed #13-#15
Thread-Index: Adf7hW46cGloX9HjQFWrMCFASI4RzwAo00VA
Date: Tue, 28 Dec 2021 20:47:04 +0000
Message-ID: <MN2PR19MB4045B088CBCB1BC1DB0F29CF83439@MN2PR19MB4045.namprd19.prod.outlook.com>
References: <7c11140562304435a12563139f6361f7@huawei.com>
In-Reply-To: <7c11140562304435a12563139f6361f7@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_34759c52-a6db-4813-b00f-5ea20e29646d_Enabled=true; MSIP_Label_34759c52-a6db-4813-b00f-5ea20e29646d_SetDate=2021-12-28T20:23:17Z; MSIP_Label_34759c52-a6db-4813-b00f-5ea20e29646d_Method=Privileged; MSIP_Label_34759c52-a6db-4813-b00f-5ea20e29646d_Name=Public; MSIP_Label_34759c52-a6db-4813-b00f-5ea20e29646d_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_34759c52-a6db-4813-b00f-5ea20e29646d_ActionId=169d6b9c-1a98-4ea3-aae9-54372ce36925; MSIP_Label_34759c52-a6db-4813-b00f-5ea20e29646d_ContentBits=0
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: fd7981e0-f3d6-4770-cd70-08d9ca43349a
x-ms-traffictypediagnostic: BL0PR1901MB1986:EE_
x-microsoft-antispam-prvs: <BL0PR1901MB198607A1BB5208050DD8BDB183439@BL0PR1901MB1986.namprd19.prod.outlook.com>
x-exotenant: 2khUwGVqB6N9v58KS13ncyUmMJd8q4
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: nT4AKETjJrHmdJXVdsCnDT1mI+ZQy10zyt5UStBxLYHNE0VYh8VG+Y/Xz5cP/mNDxLSMi+uYBiQcasIfHpE+iAoneO5qWgkui5R+BKgMfEMKQZoimeBHDv5LibLxVpPIY9rh3jsfFCcjlPZ8Lpq22aweG12FdGqFMU47+BHTGfOXw+rnhFwIcfH2yKWbzHqi93NfLIEANCjGRoU7rB4OsTl3KM67tQp3VHTICevmNruHwM7F4Bpa05j4UIAfpGLJN2ro/mSoaNe6hwHd3RCa4QY2McVXTbKYvZjLv+MPicohgidWNeF/jjOD+Pwhcnm/zc7qUmv7NFAl42w1rOcvLW56jG9e3Hf83rpe2Liw74kQsHt5OBaizIQtXTMezOlI/lIVN2jPsBouA8gdzlCeJqDncbVy5acp5OYycDaBWnGYb39wTx2PxykZGeQVdBO7TMb63UEWPRBm1lKprLQHSnGGDx8XjiuG3ddXHYf/90pjKs3c+wB1kAb8JfqIu/RIDyO4MwqsLIcJXJ51/tQ1z+eMh0ubHWCG/gcdeCuXG0gOoOZuJ6pnriVyLE7iC37RRaOX4VuvEwdY1FCVHUwoICTdG41+04YA1myV9b/OTn1fIF1l9IayQoZhAwu+Pf4YAFltUbtgpL36sEt73NHgKE1RqkCHm+GRsbTd1AT4UxEO+jjQ6Gd1giz0EiAxBKUj1JZJB4d0o7gYbvVbEB9OkTdDAzOc9bE0YbNWzg1uQ6xo/LLDcE4yWNNoD2M65pu/3YUWB5SfBkZNZ2ThIhzXGi76FzAcPLGCm/kjTfENDUR5jENgmSDH4V8Ytf2UdbV1
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR19MB4045.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(55016003)(8936002)(5660300002)(9686003)(52536014)(6506007)(38070700005)(83380400001)(8676002)(786003)(4326008)(316002)(54906003)(38100700002)(107886003)(110136005)(66446008)(66476007)(66556008)(64756008)(86362001)(966005)(82960400001)(33656002)(53546011)(7696005)(2906002)(76116006)(186003)(71200400001)(66946007)(30864003)(166002)(26005)(508600001)(122000001)(579004)(559001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: HrbrFirmxMqNpYIzws3+Z2JLJ0tjCKiP9DGiAqA7Cx9pcGeItYI61szyHwYqrGr5IISz1Z+YxenXh0l4Kk9cilSuE5Fd56/1TF/K4R1SHQ2jHGI9Sxt6lVQ/cxlzs+dHq4ykDWl6oqEGBg+CwaXGpMmIdBRR/xPQXOX0LhGwmW+rYTwzXDxnv0nWOoAX7ANpsDnkEglARhTZnUTtKYyD942lgj+2ZyxbAblS2ErdmItW/+bMdnb0r0gGxkpnCwzzb8Il3lKM80x90KNq1Wom6UxLTGNHmeSxNMz2G8Xxl365IVgOnXUxI2Dn4Lej1aY/Q/DwvbjqDC/56b7hEciAgGHpgjcW1tgY9yvWhjWv3rX1hUyugZd6T3WLGRHbZp27vJ49tupvC+w81vHWY3Nm7K4Z980nNDV9jkTgK+2yH/L9QHAIqhNHmv68QJJBEwe+I13lUFOgeNVC4bZbkCvBYUsiY6O0tKCn3b5D+qIEC1+6qEKpK7m9JTXlQgN+SduDkmrunp9ni2VT2LPzL5o+99Omw7XCj38QmVmraDCVYbzx0VkrTeZ1B7lQS7LQ5NU18wlJ0X9Ql0Ic3HdOLd6qVnTG837S4XbH75JabTqddfvHNgoOBmQjCREYSUZLBWzBx+UYRyphuxQc3kjUv0Ehm6TrzgUWSlt+OdIxDXDgukpAsIvf9e9DT0uyavxTWTBUvQGphPBPAVbB46NzVHarjaABocC5hVqGzBvuSof4dRtvLVqgL9QV9zgUV2Dm8RR0uBx01gW0Bo3v4RKCCpHVaZ9WEtLgVNXcGiQEnSuovEtmRadpos/U8mJZojw889V1CNYmG34gowQxnWdLrpKlz1rODaf1EU+/pqv52i827oECBKuRpLO355ODp0Jlx8irJtOKG2MSTRJ9/p591evdy6x2j43VbFAqBpjZe6zI0jheiq3a1o6M1KjszgkZrBGEREp0ZAOqduyCTNQV9UMNzQR8XT2aCF6OXfS0Q1kmOCnVmr2jmhkfMZJGhSSnDEjJOftX5cr8YEYwyozPbT63i9lBhs+bhZziB4SPyW6r+L99XpFGK8No0HHAWuZuNqZcEWRULAXh6Vr6HCyxMxg85jeZraAKHL9yXUbc/bmOwHjdNLYmyUxHsWVvzdYvrFdHtyXaBuNXBiqG9Pzkdc7Du6u0uWfqvYCK0Nls/CxYcCHv+jD0yZ7MjKtPyLPGLA3YssnKECrN4HQ/+dLSHhF/COy7WumuGg+beIZutfhun5R3HjvqQ6HQjTbll/R3lLDtiYKxds/xfa3t80niIxsrT/wAPAGdvbbfaxHnsqTVA/5E42LN/9q+xjNTgYakhqF30UmJmQBWcGY+FTRlp/LkEAtaJKoKPLjE5F4he2rCoaB4LglLW23nINVSwYwDGCZidmsgTUBewZyrnU2tMVeriMXVtIRAb0v9AgkigNI9Ne8m3vSUXoIxmGI4FPJ9jyIRXcKR4vQ7zLYmvmzuhAYKjWL1kgq3LjurnJaaGP3iwCAtUbyNZ/dMMJjPcFdCrshPoNc46xLlRXm+dCK1Ni5fYz6lTxb8eUlFudY4cybkVZPbBlJ+SWcDF2Lk/CGix0eLTQL/TxOzidxNn9WEBWDFew==
Content-Type: multipart/alternative; boundary="_000_MN2PR19MB4045B088CBCB1BC1DB0F29CF83439MN2PR19MB4045namp_"
MIME-Version: 1.0
X-OriginatorOrg: Dell.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR19MB4045.namprd19.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: fd7981e0-f3d6-4770-cd70-08d9ca43349a
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Dec 2021 20:47:04.3034 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 945c199a-83a2-4e80-9f8c-5a91be5752dd
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: KIAW0J9Y+5e4nUbe8zNgeIMtjmSVuBarOJ5GwgEy1EwuSUxVBfvLXDfbCOIyOVfmmQ+gD43pDAfPXQ4nTTiAhg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR1901MB1986
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-12-28_12:2021-12-28, 2021-12-28 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 malwarescore=0 adultscore=0 lowpriorityscore=0 clxscore=1011 suspectscore=0 impostorscore=0 phishscore=0 mlxlogscore=999 spamscore=0 priorityscore=1501 mlxscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112280091
X-Proofpoint-GUID: P6IxiMdZhZ6CasNoeiz_njK-cwkhwY6C
X-Proofpoint-ORIG-GUID: P6IxiMdZhZ6CasNoeiz_njK-cwkhwY6C
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 suspectscore=0 spamscore=0 phishscore=0 malwarescore=0 bulkscore=0 mlxlogscore=999 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112280092
Archived-At: <https://mailarchive.ietf.org/arch/msg/apn/yLzJeDw7ivsXQ9Jj-KZtn_VSb_c>
Subject: Re: [Apn] Issues to be closed #13-#15
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: Tue, 28 Dec 2021 20:47:17 -0000

Issues 13-15 appear to have stemmed from the third main bullet on slide #2 of https://datatracker.ietf.org/meeting/111/materials/slides-111-apn-7-the-apn-attribute-00, which states that "The structured APN Attribute can be used as an opaque value to map to a policy".  That's problematic because the APN Attribute includes parameters.  Consider two APN Attributes that have the same APN ID, but differ only in parameters (e.g., bandwidth, latency, loss ratio, jitter - see slide #4).  When used as an input for opaque policy mapping, parameter differences result in those two APN Attributes mapping to different policies, which may or may not be the desired outcome.

It appears that Shuping agrees, as I read the responses to issues #14 and #15 below as indicating that the slide was incorrect in its use of "APN Attribute" and should have used "APN ID" instead, i.e., the correct statement would have been that "The APN ID can be used as an opaque value to map to policy."  If that is what is intended, then this is a fine resolution to issues #13 and #14 that I raised, provided that the drafts are clear that policy lookup is based on APN ID, not APN ID + APN parameters (i.e., the entire APN attribute).

Thanks, --David

From: Pengshuping (Peng Shuping) <pengshuping@huawei.com>
Sent: Monday, December 27, 2021 7:54 PM
To: apn
Cc: rtgwg@ietf.org; Black, David; kaduk@mit.edu
Subject: Issues to be closed #13-#15


[EXTERNAL EMAIL]
Hi all,

All the issued to be closed is going to be listed in this link https://github.com/APN-Community/Issues/issues [github.com]<https://urldefense.com/v3/__https:/github.com/APN-Community/Issues/issues__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnl-Oy_6k$>.

Following the issues we posted in the last week, we post our responses to the issues #13-#15 this week. Please either leave your comments in the mailing list or directly in the github, so we can finally close these issues. Thank you!


13. Is opaque used solely wrt privacy of info from which APN ID is derived? Is that just opaque lookup based on ID? From: David Black #13
https://github.com/APN-Community/Issues/issues/13 [github.com]<https://urldefense.com/v3/__https:/github.com/APN-Community/Issues/issues/13__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnpPKw6mM$>

In this draft https://datatracker.ietf.org/doc/html/draft-li-apn-framework-04 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-li-apn-framework-04__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnlPEVW24$>, it states that "the APN attribute is acquired based on the existing information in the packet header such as 5-tuple and QinQ (S-VLAN and C-VLAN) at the edge devices of the APN domain".


There is also a requirement [REQ 1d] in 5.1. APN Attribute Conveying Requirements,
https://datatracker.ietf.org/doc/html/draft-li-apn-framework-04#section-5.1 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-li-apn-framework-04*section-5.1__;Iw!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnq5rmQEF$>
[REQ 1d].  APN ID MUST be acquired from the existing available information of the packet header without interference into the payload.


14. What is opaque lookup? Which parameters are supposed to use? What exactly are you looking? From: David Black #14
https://github.com/APN-Community/Issues/issues/14 [github.com]<https://urldefense.com/v3/__https:/github.com/APN-Community/Issues/issues/14__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnp3aDxRw$>

The opaque lookup means about the lookup using APN ID. The APN ID itself does not have any privacy info but only a string of bits used by the network devices to perform policy enforcements locally.


15. Is opaque contradictory to the APN parameters? Does such a "treat as opaque" case actually use the full richness of attributes? From: Zhang Zhaohui/Benjamin Kaduk #15
https://github.com/APN-Community/Issues/issues/15 [github.com]<https://urldefense.com/v3/__https:/github.com/APN-Community/Issues/issues/15__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnix_FnGG$>

Opaque is for the APN ID. The APN parameters are used to express more detailed requirements on the network. It is not contradictory.


**********************************************
Happy New Year to All! :)
**********************************************

Best Regards,
Shuping


From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Pengshuping (Peng Shuping)
Sent: Monday, December 20, 2021 9:39 AM
To: apn <apn@ietf.org<mailto:apn@ietf.org>>
Cc: gregory.mirsky@ericsson.com<mailto:gregory.mirsky@ericsson.com>; jri.ietf@gmail.com<mailto:jri.ietf@gmail.com>; eckelcu@cisco.com<mailto:eckelcu@cisco.com>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>
Subject: [Apn] Issues to be closed #10-#12

Hi all,

All the issued to be closed is going to be listed in this link https://github.com/APN-Community/Issues/issues [github.com]<https://urldefense.com/v3/__https:/github.com/APN-Community/Issues/issues__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnl-Oy_6k$>.

Following the issues we posted in the last week, we post our responses to the issues #10-#12 this week. Please either leave your comments in the mailing list or directly in the github, so we can finally close these issues. Thank you!


10. Is APN designed for a single domain or multiple domains? From: Charles Eckel #10
https://github.com/APN-Community/Issues/issues/10 [github.com]<https://urldefense.com/v3/__https:/github.com/APN-Community/Issues/issues/10__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnj7JJaPJ$>

APN is designed for a single operator's limited and controlled domain(s). There could be multiple domains within this operator. At the provider edge node of each domain, the APN attribute could be used to steer the traffic into corresponding network services such as an explicit SRv6 path.


11. Is it a normal case that 1 SP has multiple domains? From: Greg Mirsky #11
https://github.com/APN-Community/Issues/issues/11 [github.com]<https://urldefense.com/v3/__https:/github.com/APN-Community/Issues/issues/11__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnjqmKlSL$>

Yes, it is a very normal case that one SP has multiple domains under its administration, especially when the network scale is large.


12. Is that the entire value of these APN tunnels is to communicate information across domains? From: Jana Iyengar #12
https://github.com/APN-Community/Issues/issues/12 [github.com]<https://urldefense.com/v3/__https:/github.com/APN-Community/Issues/issues/12__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnrl9F9f5$>

We would not call these tunnels are APN tunnels. They are the normal tunnels such as SRv6 policies or MPLS tunnels. APN attributes are encapsulated in the outer tunnel header to trigger the policy enforcement for the network service provisioning in a flexible and efficient way in the various nodes along the tunnel.


**********************************************
How time flies! Another Christmas is coming.
Merry Christmas to all! :)
**********************************************

Best Regards,
Shuping


From: Apn [mailto:apn-bounces@ietf.org] On Behalf Of Pengshuping (Peng Shuping)
Sent: Monday, December 13, 2021 9:59 AM
To: apn <apn@ietf.org<mailto:apn@ietf.org>>
Cc: ted.ietf@gmail.com<mailto:ted.ietf@gmail.com>; rick@tropicalstormsoftware.com<mailto:rick@tropicalstormsoftware.com>; watsonbladd@gmail.com<mailto:watsonbladd@gmail.com>; kaduk@mit.edu<mailto:kaduk@mit.edu>; farinacci@gmail.com<mailto:farinacci@gmail.com>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>
Subject: [Apn] Issues to be closed #5-#9

Hi all,

All the issued to be closed is going to be listed in this link https://github.com/APN-Community/Issues/issues [github.com]<https://urldefense.com/v3/__https:/github.com/APN-Community/Issues/issues__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnl-Oy_6k$>.

Following the issues we posted in the last week, we post our responses to the issues #5-#9 this week. Please either leave your comments in the mailing list or directly in the github, so we can finally close these issues. Thank you!


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? From: Dino Farinacci #5
https://github.com/APN-Community/Issues/issues/5 [github.com]<https://urldefense.com/v3/__https:/github.com/APN-Community/Issues/issues/5__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnq0xVmwI$>

Following the APN framework as defined in the https://datatracker.ietf.org/doc/html/draft-li-apn-framework-04 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-li-apn-framework-04__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnlPEVW24$>, the traffic are tagged with APN ID at the network edge, against which the traffic can be steered into the network services such as SRv6 policies that can satisfy their various SLA requirements.


6. What is the problem domain of APN? What is the problem APN is trying to solve? From: Rick Taylor #6
https://github.com/APN-Community/Issues/issues/6 [github.com]<https://urldefense.com/v3/__https:/github.com/APN-Community/Issues/issues/6__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnkYf9lwo$>

In this problem statement draft https://datatracker.ietf.org/doc/html/draft-li-apn-problem-statement-usecases-04 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-li-apn-problem-statement-usecases-04__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnpLPWZMy$>, the three challenges that APN is trying to target at are listed as followings,

1.        Challenges of lack of fine-granularity service information

2.        Challenges of Traditional Differentiated Service Provisioning

3.        Challenges of Supporting New 5G and Edge Computing Technologies


Several concrete use cases that could benefit from APN have also been recorded in IETF drafts and presented in previous meetings.

l  https://tools.ietf.org/html/draft-liu-apn-edge-usecase [tools.ietf.org]<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-liu-apn-edge-usecase__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnhbqtbjB$>

l  https://tools.ietf.org/html/draft-zhang-apn-acceleration-usecase [tools.ietf.org]<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-zhang-apn-acceleration-usecase__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnpnoPh0f$>

l  https://tools.ietf.org/html/draft-yang-apn-sd-wan-usecase [tools.ietf.org]<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-yang-apn-sd-wan-usecase__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnq_0Av9q$>


The work items to be covered were presented in the following slides,
https://datatracker.ietf.org/meeting/111/materials/slides-111-apn-8-apn-work-items-00 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/111/materials/slides-111-apn-8-apn-work-items-00__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnpnxU_LS$>.


7. Why do we need an abstract container for service info across all tunneling mechanisms? From: Watson Ladd #7
https://github.com/APN-Community/Issues/issues/7 [github.com]<https://urldefense.com/v3/__https:/github.com/APN-Community/Issues/issues/7__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVngjvW7VR$>

As presented in the APN BoF @IETF111, from this use case we can see that the carried information can be used to trigger the IOAM performance measurement or perform fine-granular traffic steering at the edge of the intermediate domain without the need to further resolve the 5-tuple of the inner packets.
https://datatracker.ietf.org/meeting/111/materials/slides-111-apn-apn-use-cases-01 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/111/materials/slides-111-apn-apn-use-cases-01__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnhr86psC$>


8. Do we have a protocol mechanism to enforce what's in the APN marking and when it's removed? From: Benjamin Kaduk #8
https://github.com/APN-Community/Issues/issues/8 [github.com]<https://urldefense.com/v3/__https:/github.com/APN-Community/Issues/issues/8__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnsqlNJRL$>

The draft https://datatracker.ietf.org/doc/draft-li-apn-header/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-li-apn-header/__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnsZrhoye$> specifies the APN header which includes the APN ID and/or parameters, that is, the APN marking.


This draft https://datatracker.ietf.org/doc/draft-li-apn-framework/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-li-apn-framework/__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnoj0_o2v$> specifies that the APN marking will be encapsulated in the outer tunnel encapsulation and removed together with the tunnel encapsulation at the end of each tunnel.


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? From: Ted Hardie #9
https://github.com/APN-Community/Issues/issues/9 [github.com]<https://urldefense.com/v3/__https:/github.com/APN-Community/Issues/issues/9__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnlWFKThE$>

The draft https://datatracker.ietf.org/doc/draft-li-apn-header/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-li-apn-header/__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnsZrhoye$> specifies two types of APN ID which have different lengths. APN is not used to identify individuals. Usually a physical port can be used to identify a group of users, and the user group ID can be carried in APN.


Best Regards,
Shuping


From: Pengshuping (Peng Shuping)
Sent: Tuesday, December 7, 2021 9:45 AM
To: apn <apn@ietf.org<mailto:apn@ietf.org>>
Cc: rtgwg@ietf.org<mailto:rtgwg@ietf.org>; Lars Eggert <lars@eggert.org<mailto:lars@eggert.org>>; 'sergey.fomin@nokia.com' <sergey.fomin@nokia.com<mailto:sergey.fomin@nokia.com>>; 'Bernier, Daniel' <daniel.bernier@bell.ca<mailto:daniel.bernier@bell.ca>>
Subject: Issues to be closed #1-#4

Hi all,

All the issued to be closed is going to be listed in this link https://github.com/APN-Community/Issues/issues [github.com]<https://urldefense.com/v3/__https:/github.com/APN-Community/Issues/issues__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnl-Oy_6k$>.

In the following weeks, we are going to post our responses to the issues. Please either leave your comments in the mailing list or directly in the github, so we can finally close these issues. Thank you!


1. What happens to a flow if a hop can't meet the APN requirements? From: Lars Eggert #1
https://github.com/APN-Community/Issues/issues/1 [github.com]<https://urldefense.com/v3/__https:/github.com/APN-Community/Issues/issues/1__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVngi47HI4$>

As described in https://datatracker.ietf.org/doc/html/draft-li-apn-framework-04#section-5 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-li-apn-framework-04*section-5__;Iw!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnrADgRIl$>, the APN requirements include APN Attribute Conveying Requirements and APN attribute Handling Requirements.

In the APN attributes, the carrying of the APN parameters is optional as stated in https://datatracker.ietf.org/doc/html/draft-li-apn-header-00#section-3 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-li-apn-header-00*section-3__;Iw!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnk6VV9pq$>. The typical APN parameters are the network performance requirements such as bandwidth, latency, etc.

If a hop cannot meet the APN requirements, which would mean that the hop cannot handle the APN attributes, then it will be up to the local configuration. We can explore more on this topic, but generally the flow needs to be forwarded without any interruption, probably in a default mode.


2. Does APN introduce a new data plane when it is supposed to work with any data plane? From: Sergey Fomin #2
https://github.com/APN-Community/Issues/issues/2 [github.com]<https://urldefense.com/v3/__https:/github.com/APN-Community/Issues/issues/2__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnot4LyUl$>

APN does not introduce a new data plane. APN uses and makes necessary extensions to the existing data plane to carry the APN header as defined in https://datatracker.ietf.org/doc/draft-li-apn-header/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-li-apn-header/__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnsZrhoye$>. The encapsulation example on the IPv6 data plane is suggested in https://datatracker.ietf.org/doc/draft-li-apn-ipv6-encap/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-li-apn-ipv6-encap/__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnjLzn_F_$>.


3. Do we need to define a new data plane to carry this info, while you could use existing mechanisms? From: Sergey Fomin #3
https://github.com/APN-Community/Issues/issues/3 [github.com]<https://urldefense.com/v3/__https:/github.com/APN-Community/Issues/issues/3__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnlyjVzBd$>

Some extensions may be needed. For example, new IPv6 HBH or DOH options would need to be defined to carry the APN header in the IPv6 data plane.
In https://datatracker.ietf.org/doc/draft-peng-apn-scope-gap-analysis/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-peng-apn-scope-gap-analysis/__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnhwgBgl-$>, we listed existing mechanisms and made some analysis and comparisons.


4. Is it expected that the APN ID and parameters be "normalized' (standardized) or be defined domain specific From: Daniel Bernier #4

The draft https://datatracker.ietf.org/doc/draft-li-apn-header/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-li-apn-header/__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnsZrhoye$> specifies the APN header which includes the APN ID and parameters. APN works within an operator's controlled and limited domain, so the APN ID and parameters can be defined as domain specific.


Best Regards,
Shuping



From: Architecture-discuss [mailto:architecture-discuss-bounces@ietf.org] On Behalf Of Pengshuping (Peng Shuping)
Sent: Monday, December 6, 2021 9:17 AM
To: apn <apn@ietf.org<mailto:apn@ietf.org>>
Cc: architecture-discuss@iab.org<mailto:architecture-discuss@iab.org>; rtgwg@ietf.org<mailto:rtgwg@ietf.org>
Subject: [arch-d] Issues to be closed

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/ [mailarchive.ietf.org]<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/apn/OoOgezkAAbd2uFrY2Mk4ZxSbVzM/__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnl7brFjX$>
[2] https://datatracker.ietf.org/meeting/111/materials/minutes-111-apn-00.txt [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/111/materials/minutes-111-apn-00.txt__;!!LpKI!0MSGVo3fSviZMiLBp1IYBCcOzn0troLV9BzVf6MTvLTMrPeWhnkI3nEVnufmaVjt$>

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)

  1.  Why APN is needed when there are multiple existing mechanisms, just as DetNet and Network Slicing?
  2.  How privacy affects APN, especially about accidental breach of privacy and subversion of decapsulation?
  3.  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.
  4.  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.
  5.  We also need more understanding of how APN is relevant in encrypted environments.
  6.  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