Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

John E Drake <jdrake@juniper.net> Fri, 22 April 2022 12:48 UTC

Return-Path: <jdrake@juniper.net>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD5D63A143D; Fri, 22 Apr 2022 05:48:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.008
X-Spam-Level:
X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=VhBxZ1Xr; dkim=pass (1024-bit key) header.d=juniper.net header.b=KR0UvKpb
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 3OOK7bDIMHvH; Fri, 22 Apr 2022 05:48:48 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 5625D3A07AC; Fri, 22 Apr 2022 05:48:45 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 23M12OW7001539; Fri, 22 Apr 2022 05:48:34 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=c18CfvefjBN2Pn6M7CqU+P3qDdTsNvXHQtPUgAV2YXk=; b=VhBxZ1Xr/1CvXnYD1mcVgKuYwXz4fYWayCIY6BH6/sy1yZimBLWIEe7FZzhJybS1tn27 hzwSZPkPsY5pgiiEUrlEFISzKpDFmw4iEfpUvLsLwvV2D9928Zt79P9D6ihHN1LlDKM+ 4Wrhaj9kEB9z1nPcHr+mBvJB/QIhuvAgbqjJLKraJi0EFq6F9wSJk4XVZ+E6WRCEeVfR rnNV0vQJV0p0JpF8HhoneBJTSvtJtfdoY2hbkGxIpCmDesBaCK21YMq9DDtl2/loSuZL gWVZwLactVQFITDtGUSNhc/QptMFK/MMgaBdVw/S4tcsNszakM/8u4aIHqZwZaFO69JM KQ==
Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2170.outbound.protection.outlook.com [104.47.59.170]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3fka4ahs1m-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Apr 2022 05:48:33 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XkjA1Z01+YeI7su8YwNZIbX9qsfqVxAz+0b3sqXc+7LufWC1gSwr9f4PeZ8WbRa9LkAijOkmkqNj5q08Ntuq+lPOnBXaHrvmdJBge0zCfepprjwKLQ4ZYligZq3SiarzkAzZj46GtiKQ16yMgg/iIWM28wu3VkDWLN9+pe2fbF22Zh/mgtQ3TpQKV7jdm7jb6acG9edv4TsTQLFuQxbAKWKUpNjPxtFrG1FcYraHd5i9r15wNp6L3Avq+NNFLgtROAsCI98Z5wDE7p3QsIFXDEy3FeHf1vIqx1rH3F8rEoBaZfgQd8DPvfI+xKiStU4gre3V5jX8JpjjShpte1QpyA==
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=c18CfvefjBN2Pn6M7CqU+P3qDdTsNvXHQtPUgAV2YXk=; b=MwAvTDI/tvc5aRzSlAsHsXucbhXCFrbqkWFhU+TR9y0WHHU8jis7iZ+0ISyrAS/dzDd4wPz8IagVyqf7ey8hYGX/RkqTQB/9tgiy6yZRdjFtorDpJ5ef1EUuOchLft0Fn3Mbh+P/9uwyRwvtlpjflv24AgPR9dZgfICkf291t8ig+lUJOdcUVXK8HWAv7OM+MHrCRfsGwk5SYQnhA6abiHAT17RjynF7ct/U2TYMExbN7MIGFZyl/9I2qge0jLTynaqDldp71y3N7np9jiZhEgip8B+ZxDBmIPjiB3CVuowgxsuWM6FruxPYAuUT0GlwZspdFov0pBpxKXj7u35Z7g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=c18CfvefjBN2Pn6M7CqU+P3qDdTsNvXHQtPUgAV2YXk=; b=KR0UvKpbth7LHM0KsuVdrWtdcNz414SSZR3pMJHpo3nb1it6KZwZPeYklJkbQwI+Z+Wp6bMmn1o5OhnDbnTKeGo1ixMS8dsxC0NBAFEk+sNnLDKSi7Ia/h9sqPYWy+0dUwz2uCNgMyZxG4gsbfs0Gmu9QoN31wWsyO9d17URXFY=
Received: from BY3PR05MB8081.namprd05.prod.outlook.com (2603:10b6:a03:366::15) by BN7PR05MB5761.namprd05.prod.outlook.com (2603:10b6:408:a::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5206.6; Fri, 22 Apr 2022 12:48:29 +0000
Received: from BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::8db8:fd72:6beb:3657]) by BY3PR05MB8081.namprd05.prod.outlook.com ([fe80::8db8:fd72:6beb:3657%7]) with mapi id 15.20.5206.006; Fri, 22 Apr 2022 12:48:29 +0000
From: John E Drake <jdrake@juniper.net>
To: "Dongjie (Jimmy)" <jie.dong@huawei.com>, Stewart Bryant <stewart.bryant@gmail.com>
CC: Robert Raszuk <rraszuk@gmail.com>, Greg Mirsky <gregimirsky@gmail.com>, "mpls@ietf.org" <mpls@ietf.org>, "pals-chairs@ietf.org" <pals-chairs@ietf.org>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "draft-bocci-mpls-miad-adi-requirements@ietf.org" <draft-bocci-mpls-miad-adi-requirements@ietf.org>, DetNet Chairs <detnet-chairs@ietf.org>
Thread-Topic: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements
Thread-Index: AQHYTxj5nEHZYRJXU0Ok7Fv3Tnx3IKzwTy+AgAFll4CAAoWBAIAAc5kAgAAB1gCAANKeAIAAGgxAgAAeXsCAABd8AIAEpa4AgAFLioCAACxmEA==
Date: Fri, 22 Apr 2022 12:48:29 +0000
Message-ID: <BY3PR05MB8081851F2807C88BF0D34C37C7F79@BY3PR05MB8081.namprd05.prod.outlook.com>
References: <402e03c9-9c20-685e-937a-13b5a3ebca59@pi.nu> <3a4ceaeb2acc4eddb587c1e7688cd685@huawei.com> <CA+RyBmV4AM8y2-RMACFgyU9q2-8wkaYT2_xWSdtTvUCwf7_g_A@mail.gmail.com> <CA+b+ERmoakg3_tdjKFxxNbhRLvxRkVjopCohO0vg--=EwpMNSg@mail.gmail.com> <CA+RyBmV-KoD9sMRfNwh7c9i=09uNXNcaWZBHFoiUQyNn-Mtjbg@mail.gmail.com> <CA+b+ERk5PabBO9R4SVeK6=TKfjBEnDKNvwvuH=DUSfUGu-7JVA@mail.gmail.com> <e821ee06e06b47dfbd67826ce85c8eb5@huawei.com> <BY3PR05MB8081E3FF1A0A948E4BED816DC7F39@BY3PR05MB8081.namprd05.prod.outlook.com> <BY3PR05MB8081E1CC4D0C24B792FBB717C7F39@BY3PR05MB8081.namprd05.prod.outlook.com> <904a3b81990c45cf9c863f79a550faac@huawei.com> <03E68A02-D575-44FC-8C1E-A7F2B9949625@gmail.com> <644e49ad78044853b6ab4af225edf4d3@huawei.com>
In-Reply-To: <644e49ad78044853b6ab4af225edf4d3@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.6.401.20
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2022-04-22T12:48:27Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=a52893b9-ce7d-44b6-8c48-fe6cc2e6aee9; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 79a5bced-2495-4199-9e04-08da245e66ad
x-ms-traffictypediagnostic: BN7PR05MB5761:EE_
x-ms-exchange-atpmessageproperties: SA|SL
x-microsoft-antispam-prvs: <BN7PR05MB576104B1FA227E0616D7A79EC7F79@BN7PR05MB5761.namprd05.prod.outlook.com>
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 1vORBOuXZSeLmNHHgrw1se1gvGOYHPPwU0MokdFNEEWR3DMLOx+Z9MLm3jg02TYHb+HgBKhuyt4wphliD/6Ky0hRquxlIUA+XojOKEV/DSuPEy08vbwTk0X6dr78YeB+LM6jJ3UnO9OYgJL/tOLsB23OZ4GpGZFtxFSY/sxoYU7GkFXrf8wRW/kfg/1t7l8rJ6MK/IGteza3NXSEUk9HCE2u7WFqqGJwNlzAQxMGhuPUayoE2/JrLDLc7cJ3VZMSHiiG9jYHvoQ+gfmrrepw9+PdFa9dWHPxkQDVemCr/7MIsNyMQu/E95l5EEkHZClLLYI6j9Ku9Xksn5Z3+gjAwiiMLf+yMYgMUSbIkXypbihj6z0T5yT7034XPbBUcHPjju11GK7WQCaFN2oMF/DdRrN4/TxbZtLVxBtLeHex9LZ9INRTLm5wy601cw+NRNE0USHJN68kL4wjfusTq9S6O9tgtJX9jjHs9vdjN/gBNsRjUB8s7kMpeAelEXOdDWUhID9vCH3uUTnjRWOlmagl+sUFckdg9eoYJdF3/ADe+MR6U8Dx8/pweA99KTOBe5tKM4gRGw5RtqGjo+EnBUhPmDp4kG0b2ypemRTcn82dpKFPvyU1bLT21YofKWelz/RQKS7sxBNM78XlGQj5Tb76D1TJl3IHDnF8m8cT8epQJhiGWzTz04ouaeZgeu+HWBz4KICxC1jHtYRDkHzPvHPZHBbBTDop90neraxRbuAuwgJLt2Ew5+WGpPJYMj9+7B2dtQ4HAXwbDDqOWi7VCfuN3LGgOVqAr7B9ifcnpHMUygfTOBm2D/7O9tS0N775ImrjJ+OvMqO+f/DuzQ+V0asJ+Q==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR05MB8081.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(4636009)(366004)(316002)(5660300002)(30864003)(122000001)(52536014)(8936002)(110136005)(54906003)(83380400001)(53546011)(6506007)(7696005)(55016003)(2906002)(966005)(508600001)(26005)(9686003)(33656002)(38070700005)(66574015)(71200400001)(86362001)(186003)(38100700002)(76116006)(8676002)(66446008)(4326008)(64756008)(66476007)(166002)(66556008)(66946007)(559001)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: zVaVxslTYcmD3CttQfsg7H1jay7Gbnja16EYzhXXL7TxyAvrXVOwkrYnY4xIqZotunGUPLbp+R7Im6RiFp9rwKENiTOlgratTqTByrTrpjHPxt8aAmQJ+NtdGXYJ09TTT4iMF3fcnch3UT8v/85MXN/UGTDdSFrOANejivgcgc42abB6tnSDmywEaGuw92OD736R8I4SJY6ByU4U2+NhYz9mvNVXDVXG8l+Dd6HKC4inNsMkeQBpjxZ1lLJX4UlXD9Bju1k7VwqeWUQiwWghK/1kwJnSu11kU6ZDNXD0vkcvy6+CjSzZytlydZK4ZUyfoi9F0MTD6xk4KMEPTyMfOnEPg/WcoxlyKpArQbL6+ZuVlAT3C0EbJLxWsryszxK3c8XOjPvRBiAmJWyPBwESLDhT+1Ot7FmtyTMrtWGpkVifaHt8CLcu2Dms1nxE8USMJPu1VGMbvLSgU3mNBhz7bpJjfJkVVtSDN4E8AwcRiS4WrRhOfeevGOk1ZJ4rAhTsQtEP0HhN0YlsJegmdURJF8gY07EyMjX4zdt83ZwRmbGoayhD91cz3JCIMjvL4bgfOHBB2tnf7LQc8kV0JMvpB9QuPjCLoaGd5B6+AaT9Pc2Voh9x0zrekUHZmEXtvOzMpJXFLQ0RQ4/yumdbtHydOwHjE1p2/5+I8R/wd6vaZhOWZ3LaXUiTBIsgvLNgh7xa5k6CkYPGg4thD0ZYo+aCZsGU1j7T7AJy9mMnsny9VuC91TRb4GsmEKDCoqD2+9QPYTxzZIRx8NuyyLYg6q9GcU5TCKwLi37NKsDlOEpm/RhLmA9DL+n7fl9cVCUg0d9pbwg4MaXP206Bo4l8hNIsyqyy2bECLe5Oj8lLaA2FbC6EEja8a2OnE6TnQ/PIbManL9XjRrT3AKSbjqP6TXfF4AFBobhF37U9k1B+Vfce1yvj395bcl/TBCy86M+UW7IqHkqnyAmmHYhDOBH3AvHBD4lGDCrrI09cIUMNhcRteRiyWiE4RFTG/CPwqT0Z8mkcuCDvDvexoi9p4Zb4BJLQ/jQzPGNs3IPedRa/ouayfTXlr4Vzs/zOtE5B0J3tJJSlyLSbGRftDCf+7T2ylHecuedGOSi3RjFU5kLHJz5hfxWPDk1Asy6YQwJXJbeiWt2Atusx2ksNErVAHeu+CszoFs6eYYa2bGqWsLGLJ//15EVVi1lGhMCRSmMHL25y9xtdmTurkkoil18yS6rgVDs653h6tjQpwKeA3M1TlJWJEtyc0xWpnt60lyMHCjExkWbPREYLvx6c3690CBbCzjXTVde0AQ3q+c4Olr4+HibPdbre/BR7RMvKAln7EqlezlYRUXw+YCIS8GGztvNUM1oRebnzJ9QW9u0hdF2fTvJxpfI0yulomheYemHsZZhur8iofdmCN2Fe85IFN+2TK0311ZZzTHlURa/Z9cNO959WuMl4ftIViyZ7MZ+0j9rn7cB03fpE1wQckNWZ8WKWB5+L3mwpIiZSi5AqlvTWp0zgkX4N8rW5pKheZou22lDD6bEdVE6iNTGFaVuZ364JUfrbLl2Dv0V5LU+NsUQIUJP3D/AjVe2ogcNNTUHpjhS7qF1kSG17EoZbJqNjdnNeLJ87w/LPePI4QpPXQCFCgT8CfC/LkglZaVGwAmDCUJUoD0tMzfbZP0L0LJsgOlBOzkoYLxp5di6459ZzNm70qSxyR7zQEJpmijSNBvbRN5vy6X28oTzn3NRQYlPRxNGvPHyAcw==
Content-Type: multipart/alternative; boundary="_000_BY3PR05MB8081851F2807C88BF0D34C37C7F79BY3PR05MB8081namp_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY3PR05MB8081.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 79a5bced-2495-4199-9e04-08da245e66ad
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Apr 2022 12:48:29.3901 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ERvYPqd0uaHGmSsE0481qCBhilT+ed+cHPBHAmpBE2NUHIuy/kgZMB7O8Z5MqQeZj+0f2yWOqHZXma+KdvNSJA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR05MB5761
X-Proofpoint-ORIG-GUID: F2C8CRVlr8XTkctofnbWfhU3xmBbI6Sj
X-Proofpoint-GUID: F2C8CRVlr8XTkctofnbWfhU3xmBbI6Sj
X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.858,Hydra:6.0.486,FMLib:17.11.64.514 definitions=2022-04-22_03,2022-04-22_01,2022-02-23_01
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 lowpriorityscore=0 malwarescore=0 phishscore=0 mlxlogscore=999 spamscore=0 priorityscore=1501 bulkscore=0 adultscore=0 mlxscore=0 impostorscore=0 clxscore=1015 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000 definitions=main-2204220056
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/-bqlGrs0K50uQUhDTabxG1l6dp8>
Subject: Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Apr 2022 12:48:54 -0000

Tony has already proposed and defined network action sub-stack indicator which is exactly right.

Yours Irrespectively,

John



Juniper Business Use Only
From: Dongjie (Jimmy) <jie.dong@huawei.com>
Sent: Friday, April 22, 2022 6:08 AM
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: John E Drake <jdrake@juniper.net>; Robert Raszuk <rraszuk@gmail.com>; Greg Mirsky <gregimirsky@gmail.com>; mpls@ietf.org; pals-chairs@ietf.org; mpls-chairs@ietf.org; draft-bocci-mpls-miad-adi-requirements@ietf.org; DetNet Chairs <detnet-chairs@ietf.org>
Subject: RE: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

[External Email. Be cautious of content]

Hi Stewart,

Thanks for sharing your opinion.

One of my concern is that there are two types of indicators, and they cannot be represented using the same term.

   - The first one (call it indicator-1) is used to indicate the presence of any non-forwarding-label information in the packet. As discussed it may be realized as a bSPL. It does not indicate the type of actions to be performed.

   - The second type of indicator (call it indicator-2) is used to indicate the presence of a specific type of action. Such action may or may not have associated data with it.  This may be realized as a Flag or an action type in the packet.

The semantics and processing of the above two indicators are different, thus we need two separate terms for them.

Perhaps we can call the first one Ancillary Information Indicator (if you think "data" is specific to the parameters), and the second one Network Action Indicator. I'm open to the terms as long as we agree that we need two of them.

Best regards,
Jie

From: Stewart Bryant [mailto:stewart.bryant@gmail.com]
Sent: Thursday, April 21, 2022 10:21 PM
To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>
Cc: Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>; John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>; Robert Raszuk <rraszuk@gmail.com<mailto:rraszuk@gmail.com>>; Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>; mpls@ietf.org<mailto:mpls@ietf.org>; pals-chairs@ietf.org<mailto:pals-chairs@ietf.org>; mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; draft-bocci-mpls-miad-adi-requirements@ietf.org<mailto:draft-bocci-mpls-miad-adi-requirements@ietf.org>; DetNet Chairs <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements


Hi Jie

On 18 Apr 2022, at 16:23, Dongjie (Jimmy) <jie.dong=40huawei.com@dmarc.ietf.org<mailto:jie.dong=40huawei.com@dmarc.ietf.org>> wrote:

Hi John,

The diffs show that the term ADI was in the previous versions of the requirements document, and just replaced by NAI in the latest version:

https://www.ietf.org/rfcdiff?url2=draft-bocci-mpls-miad-adi-requirements-04.txt<https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-bocci-mpls-miad-adi-requirements-04.txt__;!!NEt6yMaO-gk!UhgTylz3aWWV1_HnrZtQUhs1LldCoOPeHMUA-T0r9xeepnzpXNIPTfRVbyI1f0s$>

No it is more than just a name change. There is a concept change and we re-wrote a bunch of text to align with the NAI approach. For example an NAI may not have AD to indicate.


And the draft name still shows that the requirements were originally on ADI.

We agreed that for continuity this should be changed on adoption.


As Robert and I mentioned, the term ancillary data is generic and refers to all types network actions information, including those with and without additional action data.  Thus NAI can be considered as one type of ancillary data.

No an action is an action (a doing thing) and data is a parameter of qualifier to such an action.

Of course you can have an ADI with null data but you have to explain that each time. The NAI is a cleaner concept.


And ADI is the indicator of the presence of ANY non-label information in the MPLS packet.

Yes, but note that it is a DATA indicator not an action indicator and there may be no data.

I think that this has become a discussion on the precise semantics of various English expressions rather that an engineering discussion on how this will work and what its utility is. I would very much like to move from the English to the engineering.

Best regards

Stewart


Following it there may be indicators of each specific network action. And my understanding is the requirements in section 3.2 was mainly on the ADI.




Best regards,
Jie

From: John E Drake [mailto:jdrake=40juniper.net@dmarc.ietf.org]
Sent: Monday, April 18, 2022 10:02 PM
To: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; Robert Raszuk <rraszuk@gmail.com<mailto:rraszuk@gmail.com>>; Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; pals-chairs@ietf.org<mailto:pals-chairs@ietf.org>; mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; draft-bocci-mpls-miad-adi-requirements@ietf.org<mailto:draft-bocci-mpls-miad-adi-requirements@ietf.org>; DetNet Chairs <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: RE: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

Hi,

I just checked and the term 'ancillary data indicator (ADI)' is *not* used in the requirements draft.

Yours Irrespectively,

John


Juniper Business Use Only
From: John E Drake
Sent: Monday, April 18, 2022 8:24 AM
To: Dongjie (Jimmy) <jie.dong=40huawei.com@dmarc.ietf.org<mailto:jie.dong=40huawei.com@dmarc.ietf.org>>; Robert Raszuk <rraszuk@gmail.com<mailto:rraszuk@gmail.com>>; Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; pals-chairs@ietf.org<mailto:pals-chairs@ietf.org>; mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; draft-bocci-mpls-miad-adi-requirements@ietf.org<mailto:draft-bocci-mpls-miad-adi-requirements@ietf.org>; DetNet Chairs <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: RE: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

Jimmy,

I think it was Matthew who noted that the requirements draft initially focused too much on ancillary data rather than on network actions and that ancillary data is actually a characteristic of a network action.  I.e., when you define a network action, you define, among other things, whether it has ancillary data, what is that ancillary data, and whether the ancillary data is in-stack or post-stack.  Given this, there is no need for an ancillary data indicator and we should probably retire the term.

Yours Irrespectively,

John


Juniper Business Use Only
From: mpls <mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>> On Behalf Of Dongjie (Jimmy)
Sent: Monday, April 18, 2022 6:37 AM
To: Robert Raszuk <rraszuk@gmail.com<mailto:rraszuk@gmail.com>>; Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; pals-chairs@ietf.org<mailto:pals-chairs@ietf.org>; mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; draft-bocci-mpls-miad-adi-requirements@ietf.org<mailto:draft-bocci-mpls-miad-adi-requirements@ietf.org>; DetNet Chairs <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

[External Email. Be cautious of content]

Hi Greg and Robert,

Thanks for the discussion. I agree with Robert's interpretation and analysis here.

It is also my understanding that the definition of ADI and NAI are different.  ADI is used to indicate that there is information in addition to the legacy label stack in the packet, while NAI is used to indicate a certain type of network action. The existence of NAI and the optional data associated with the action need an indicator, which is the ADI.

Best regards,
Jie

From: Robert Raszuk [mailto:rraszuk@gmail.com]
Sent: Monday, April 18, 2022 6:03 AM
To: Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>>
Cc: Dongjie (Jimmy) <jie.dong@huawei.com<mailto:jie.dong@huawei.com>>; mpls@ietf.org<mailto:mpls@ietf.org>; mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; pals-chairs@ietf.org<mailto:pals-chairs@ietf.org>; draft-bocci-mpls-miad-adi-requirements@ietf.org<mailto:draft-bocci-mpls-miad-adi-requirements@ietf.org>; DetNet Chairs <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
Subject: Re: [mpls] working group adoption poll on draft-bocci-mpls-miad-adi-requirements

Hi Greg,

Yes indeed both definitions are very different.

AD definition treats anything new to the current label stack as an optional add-on == ancillary while NAI treats only optional parameters or metadata associated with newly defined actions as ancillary.

Basically two different perspectives :)

Cheers,
R.



On Sun, 17 Apr 2022 at 23:57, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
Hi Robert,
thank you for sharing your understanding of these terms. I believe, quite strongly, that synchronizing our interpretations of terms, building a clear unambiguous dictionary is essential to progressing any collaborative project. Let's see how this discussion goes.
There may be some further tightening of the dictionary in the framework document as NAI(ADI) defined as follows:
Network Action Indication (NAI): An indication in the packet that a certain network action is to be perfomed. There may be associated ancillary data in the packet.
That definition led me to my understanding of the relationship between indicators and ancillary data.

Regards,
Greg

On Sun, Apr 17, 2022 at 8:01 AM Robert Raszuk <rraszuk@gmail.com<mailto:rraszuk@gmail.com>> wrote:
Hi Greg,

> As I understand it, some network actions may not have ancillary data associated.

I was under the impression reading Jie's note that actions *itself* are the Ancillary Data. Your definition of "Ancillary Data" seems to be limited to action parameters or metadata which is likely why you draw such conclusions.

See the definition which clearly supports my understanding of it:


Ancillary Data (AD): Data relating to the MPLS packet that may be

      used to affect the forwarding or other processing of that packet,

      either at an Label Edge Router (LER) [RFC4221] or Label Switching

      Router (LSR).  This data may be encoded within a network action

      sub-stack (see below) (in-stack data), and/or after the bottom of

      the label stack (post-stack data).

Best,
Robert.


On Sat, 16 Apr 2022 at 02:33, Greg Mirsky <gregimirsky@gmail.com<mailto:gregimirsky@gmail.com>> wrote:
Hi Jie,
thank you for your detailed analysis. I have a question about the use of ADI vs. NAI in our documents. As I understand it, some network actions may not have ancillary data associated. If that is correct, referring to these actions as Ancillary Data Indicators might be confusing to a reader. Should these network actions be referred to as no-Ancillary Data Indicators (NADI)? That seems confusing to me even more. I find NAI being a logical generic term that clearly characterizes network actions that don't have ancillary data associated as well as network actions that have associated ancillary data. In my opinion, it is the definition of the particular network action that defines the required behavior and associates it with any data that we refer to as ancillary data. I am supporting the change in terminology and using NAI in our documents, including the requirements draft.

What do you think?

Regards,
Greg

On Thu, Apr 14, 2022 at 8:13 PM Dongjie (Jimmy) <jie.dong=40huawei.com@dmarc.ietf.org<mailto:40huawei.com@dmarc.ietf.org>> wrote:
Hi all,

Thanks to the authors for the effort on this document. I believe this is useful work which will help to guide the framework and solution design.

Compared to the previous version (-03), there are many changes in the recent update, which takes some time to give it a review. And I suggest people to also check the diffs from the previous version.

Please find below some of my comments and suggestions to this document, and I'd appreciate the authors' thoughts.

1. It is a good start that the requirements are classified into 3 categories:

        - General Requirements
        - Requirements on ADIs
        - Requirements on Ancillary Data

Since the requirements are driven by the use cases, rather than the on-going framework or candidate solutions, it is important and reasonable to keep using the general terms "Ancillary Data Indicator" and "Ancillary Data" in the requirements, and remove the solution specific terms (such as ISD, PSD, NAS) from this document.

2. In this version the term "Ancillary Data Indicator" is changed to "Network Action Indicator". While there is some difference between the definition of the two terms:

Ancillary Data Indicator (ADI): A indicator in the MPLS label stack that ancillary data exists in this packet.  It MAY also indicate the specific type of the ancillary data.

Network Action Indication (NAI): An indication in the packet that a certain network action is to be performed.  There may be associated ancillary data in the packet.

The above definition shows that ADI firstly is the indicator of the existence of the ancillary data, and optionally can be the indicator of specific type of ancillary data.  While NAI is only the indicator of a certain type of network action.

Thus NAI cannot replace ADI directly in this document. I'd suggest to add the ADI back to the terminology section, and change all the NAI in section 3.2 back to ADI. If needed, the requirements on NAI can be added as separate items.

3. For backward compatibility and consistency, It is suggested to add the below items to section 3.1 as general requirements:

1) Solutions meeting the requirements set out in this document MUST be compatible with existing MPLS mechanisms.

2) Solutions meeting the requirements set out in this document MUST reuse existing MPLS mechanisms when possible.

3) For network actions which are developed or under development in IETF, the encoding and processing of the network action data MUST be reused.

Best regards,
Jie

> -----Original Message-----
> From: mpls [mailto:mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>] On Behalf Of Loa Andersson
> Sent: Wednesday, April 13, 2022 5:29 PM
> To: mpls@ietf.org<mailto:mpls@ietf.org>; draft-bocci-mpls-miad-adi-requirements@ietf.org<mailto:draft-bocci-mpls-miad-adi-requirements@ietf.org>
> Cc: pals-chairs@ietf.org<mailto:pals-chairs@ietf.org>; mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>; DetNet Chairs
> <detnet-chairs@ietf.org<mailto:detnet-chairs@ietf.org>>
> Subject: [mpls] working group adoption poll on
> draft-bocci-mpls-miad-adi-requirements
>
> Working Group,
>
> This is to start a two week poll on adopting poll on
> draft-bocci-mpls-miad-adi-requirements
> as a MPLS working group document.
>
> THough we normally do two weeks pretty stric, in this case I have allowed a
> couple of extra days due to holliday season.
>
> Please send your comments (support/not support) to the mpls working group
> mailing list (mpls@ietf.org<mailto:mpls@ietf.org>). Please give a technical motivation for your
> support/not support, especially if you think that the document should not be
> adopted as a working group document.
>
> There is no IPRs disclosure against this document.
>
> The both authors have stated on the MPLS wg mailing list that they are
> unaware of any IPRs that relates to this document.
>
> The working group adoption poll ends May 2, 2022.
>
> /Loa
> --
> Loa Andersson                        email: loa@pi.nu<mailto:loa@pi.nu>
> Senior MPLS Expert                          loa.pi.nu@gmail.com<mailto:loa.pi.nu@gmail.com>
> Bronze Dragon Consulting             phone: +46 739 81 21 64
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org<mailto:mpls@ietf.org>
> https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!WJf53wk5rBU2WY2PmBXLDSUYHvcXzm-ELUspxjwvCZ_2eFbmZy-b4uD7ODO7iPs$>

_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!WJf53wk5rBU2WY2PmBXLDSUYHvcXzm-ELUspxjwvCZ_2eFbmZy-b4uD7ODO7iPs$>
_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!WJf53wk5rBU2WY2PmBXLDSUYHvcXzm-ELUspxjwvCZ_2eFbmZy-b4uD7ODO7iPs$>
_______________________________________________
mpls mailing list
mpls@ietf.org<mailto:mpls@ietf.org>
https://www.ietf.org/mailman/listinfo/mpls<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/mpls__;!!NEt6yMaO-gk!UhgTylz3aWWV1_HnrZtQUhs1LldCoOPeHMUA-T0r9xeepnzpXNIPTfRVcvYEgeE$>