Re: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS

Alexander Vainshtein <Alexander.Vainshtein@rbbn.com> Tue, 22 June 2021 15:01 UTC

Return-Path: <Alexander.Vainshtein@rbbn.com>
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 654B43A2800 for <mpls@ietfa.amsl.com>; Tue, 22 Jun 2021 08:01:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.09
X-Spam-Level:
X-Spam-Status: No, score=-2.09 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_H2=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rbbn.com header.b=UyU/ucVi; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.com header.b=PXHp9riS
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 0KFDE3QNDLWK for <mpls@ietfa.amsl.com>; Tue, 22 Jun 2021 08:01:48 -0700 (PDT)
Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.112]) (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 650743A2808 for <mpls@ietf.org>; Tue, 22 Jun 2021 08:01:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rbbn.com; s=rbbnselector03122020; t=1624374104; i=@rbbn.com; bh=msxV9rt+LsiJzCkZQacQFaInIqRJ57lw51sl4gz5j5w=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=UyU/ucVi/Muzepi1PVfM4691Q+Sp6MoLna6Vnisrw3y3EZFdkVbk4kULoXdcOCcq2 AkWq+rl1x25ObLuqEK85GTnNDAg/eBQYBL+OCkodjua7LZ0aBvLL4zbXsa90Wwx8JX l98j2AII+Ki1ajOQ5OTIy6acfGAL6mrs40uCO8Q90vCCxAE5RFm4I1IcHj382qFYod NyoFcEYLWPfoRGmbJHWXvabNMRj3Mrld2FmmTfCmzoPrithq/fkB+w2FHWtZrs2seP x0B8UDfaCmi50dVpvuMith7bpb+WgK5Moi0yVdQHYZPT5KuZYeMlWEDZcqgXOFhy/e 70rvZee1YAN9A==
Received: from [100.113.7.10] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-b.eu-central-1.aws.symcld.net id 18/20-50909-75BF1D06; Tue, 22 Jun 2021 15:01:43 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WTe0xbVRzHOffFhVBy14IcCEjW6KbDdrCR2cz FTE2WDt0GPjKnYXAZhdaUC/QhD/8YaOdwDx6SbQFpy9YWGbBZIY5qJ9DqJjDCayoDQYcjKLAB A8MGI8V7e8uc/3zz+Z3v9/zO+d2cS6LCG/4RpCJfp9AwtFpMBGLKrbImyTuPBlJjDZ4wmet7E yarGXtN5jHWoLIR20Vctjq4Cnbj8s66n3F5y+U9cqt1GZEPffyLv7z63KdEIv4ermLSsvNTce X80Cias+wh81vLlpAiYDxFngCBJKBsKLzgOOvPF9cx6JzvQvmiAcDPzKuAKzDKicJS+z1vTEi ZEfhXfzfCF2MA2r/qZ2MBJEHthI/mejCOQ6hn4czCFMGFUMoCYM9Fhzckot6F43/3+0KHYLPJ 5g2FUJUAtpWcQzgDY3c3lQyhHAuoZPh5RRvgj/shEM4ap7ydAqjDsH/IQXAMqKfgg+4m72aUC oMjE2YvQ4qC1qt9KM+hcOqOB+fHOwVga18Jxhsb4Zfto75QFBw0nwQ874P1xQs+3gKHWy2+jB oO3DXgPG+GhvsmHz8NG06P+3pGwtu3Wr2jQcpKwJtnvsb5oguDbX+2+FKx0LT0I1EOpNVP3Jx nBpberkCrvZ9gA+yqmsD49RdgrXOB4DkG1p2fQde5p+MO8uR6LfBvALI0jSpTqcuiVWpJXGys JC5uu2SHRPailC6UpEkVeskRBaPT0KwppfO0Um1B1hF1upRR6JoB+wTTc4mDDtAzMy91g3ASE YcK9HMDqcLgtOz0AiWtVaZo9GqF1g0iSVIMBYXLrLdBo8hU5Geo1OxDXrchGSQOETg5W6DNob O0qkze6gbFgCyfMl5AyW+vmVi9OcRpl9vC6uwyp/cbrKw+8OrkJU6XXZwOz3HaYrSxajdxujY 2xmpZrauRdY+7G1EhxmQziogwQTB3MsWdrNQzj++1/o8NgqgIkQD4+fkJg3IUmiyV7v/+NAgj gVgkwLkuQSpG9/j60+xkCDtZA9HLTaaj/7MiihDLM10Jk36WAEuHiGpOlBcc2vVPVUZR6ttv2 a6shYOXLm/r6Ce3d+PR1v3u3PJR7XgO3UvEb/pd9JHzyskMh302uDBpb8VzVQ/xn9qyF+8ZcY wMj66LPmHXh0zudB0tTuucn+k9kxBvqjl6dtgiGhUyfukexwevJutfrrsWL7/qGCwV/jGKv5n 6+sSeMqTgMBU8soZtzPtmd3NkSefIWB6zL71GvNd5bAVZdDuuV25eaU+OSop5Pzcp6O7DG18k Ht+fmDK9a0fr6Vv4b5/gs6ELM/krlQnP99bX1dfoxAcDzDl9sGnbMdeHWqo9OeXSG8grrl8bD 9jQ89+FGgxlSzFbF8WYVknHbUE1WvpfqYt2E94EAAA=
X-Env-Sender: Alexander.Vainshtein@rbbn.com
X-Msg-Ref: server-5.tower-238.messagelabs.com!1624374099!41712!1
X-Originating-IP: [104.47.56.172]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.75.3; banners=rbbn.com,-,-
X-VirusChecked: Checked
Received: (qmail 3608 invoked from network); 22 Jun 2021 15:01:40 -0000
Received: from mail-co1nam11lp2172.outbound.protection.outlook.com (HELO NAM11-CO1-obe.outbound.protection.outlook.com) (104.47.56.172) by server-5.tower-238.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 22 Jun 2021 15:01:40 -0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Knqsrjkd4U7P0GBMLsajRv238nBxFu4KtP/Msm/ggyVHhqpReEhms6Pz/zIu4NdsnDw3ep/LEEdNXN5bqQkMOmePcArkwCmkBJ0x+3FTKlZ783OvfdDiVfGYWvu4Mo7pLj4oq+EflVjVOvEMyWbiGXO3l4U/Ejw63/zmQEK/wyqcCc7CY4aYBl6nk3k6gcIjAGYnXvvJwl1t1lLDeKWmwklkVFby+RwBWzYGmzqq2pm4aokh4OKDKkGyTN8lyp40cVf21TFkYVX3C+2Uis2TpCmcBOSX3cttB6AQPd86OIVJzLVEYk/0gQGYghENyNDQqBMWktPCPzUTB7y29DPN3g==
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=F9opqkuvU2Wj8Ic/Fou2C+I7bTN3+fSkmLnvY4pKAUk=; b=S1CN3XMydqio+oQCNi4TGUsn15cjBReOlLx8GR1x7R6Wem/kCGKnRESb+/Fg0iGjQ7AoW5ThgoRJPSpa06DR/rbtZa/o1aTkf/+0YKsuHK4GwJdZ/glqHtXU65B4/mvrqimmIDv/Up2O9CpIdr1GlmM55M06x6NVei2nCXfOxGLI5bOgyOxGw6qURbUXvGLWsiORixWREP7vNqKApmmMv7nZKTuFi3IaaCshbHuaFDfvW1d+cESgAkD57JKyobe3f/57LVzLukwlTkeuXF0/qBSfwQ1j3K2zOP+7A53R4usma8/lQ/0ziuOcNgVVuqwy9mm2ExepWpgiVcE81y+fuw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=rbbn.com; dmarc=pass action=none header.from=rbbn.com; dkim=pass header.d=rbbn.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector2-SonusNetworks-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F9opqkuvU2Wj8Ic/Fou2C+I7bTN3+fSkmLnvY4pKAUk=; b=PXHp9riSyPqoUWfDFfklQDQQMLHYJxCrwObTxiIPJCoCd6DZ7GLlIEaR9MoTjSnjy8rumuZ1i/qYoikw1FTF4chO4SYl/F8lcDTK8a3AauzsiPJD6hsv4Bfh8r/c8redU+Ruh83luJ+UEvCnG9N69iNMqPYfpPkX13kNvVGSCAI=
Received: from MW4PR03MB6395.namprd03.prod.outlook.com (2603:10b6:303:122::9) by CO2PR03MB2278.namprd03.prod.outlook.com (2603:10b6:102:11::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4242.19; Tue, 22 Jun 2021 15:01:36 +0000
Received: from MW4PR03MB6395.namprd03.prod.outlook.com ([fe80::42d:520b:ac94:ab62]) by MW4PR03MB6395.namprd03.prod.outlook.com ([fe80::42d:520b:ac94:ab62%7]) with mapi id 15.20.4195.030; Tue, 22 Jun 2021 15:01:35 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
To: John E Drake <jdrake@juniper.net>
CC: "mpls@ietf.org" <mpls@ietf.org>, Haoyu Song <hsong@futurewei.com>, "Jeffrey (Zhaohui) Zhang" <zzhang=40juniper.net@dmarc.ietf.org>, Loa Andersson <loa@pi.nu>
Thread-Topic: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS
Thread-Index: AQHXY0tvWXYojRPFIEm2oOWwKl8E8KsX5L3ggABbPICAAAh/AIAABEIAgAAgBoCABc90gIAAAKsggAAJYgCAAAFUIIAAKigAgAAFe6CAAGBaAIABL2cggAARzwCAAAoTcA==
Date: Tue, 22 Jun 2021 15:01:35 +0000
Message-ID: <MW4PR03MB63952599D725AD5717547F3AF6099@MW4PR03MB6395.namprd03.prod.outlook.com>
References: <c7d696de-4d83-6e3b-7d10-dc787fdabc73@pi.nu,> <MW4PR03MB639576D1C4B872AA0F5A8553F6309@MW4PR03MB6395.namprd03.prod.outlook.com> <202106170323552620410@zte.com.cn> <MW4PR03MB6395DE6E57E7CBF041ABE8E2F60E9@MW4PR03MB6395.namprd03.prod.outlook.com> <E512176A-02D5-4F74-8644-EAC4E3938AEF@gmail.com> <MW4PR03MB6395DA0A79E5882ECAC2B7E4F60E9@MW4PR03MB6395.namprd03.prod.outlook.com> <BL0PR05MB5652F9023D07DA3FC8479DDCD40E9@BL0PR05MB5652.namprd05.prod.outlook.com> <ed6341bc-5508-5fb6-f5c2-e55154c22f2e@pi.nu> <BL0PR05MB5652596A808CD766C250F369D40E9@BL0PR05MB5652.namprd05.prod.outlook.com> <DM6PR13MB2762515FA53CC3403C2DCA44B60E9@DM6PR13MB2762.namprd13.prod.outlook.com> <9f5f81aa-4529-8d83-ef5a-1c809bf3251c@pi.nu> <MW4PR03MB6395BF21A477029E8C3C68BDF60A9@MW4PR03MB6395.namprd03.prod.outlook.com> <32ece802-18b3-fb0a-db41-212fb566d22e@pi.nu> <MW4PR03MB639525BB442881B0B8F922B4F60A9@MW4PR03MB6395.namprd03.prod.outlook.com> <BY3PR05MB80817B45C5AC0BD9FDA54E93C70A9@BY3PR05MB8081.namprd05.prod.outlook.com> <MW4PR03MB63954ECABD96C12A7A7F9447F60A9@MW4PR03MB6395.namprd03.prod.outlook.com> <BY3PR05MB80813036D6A3E378D9CA2297C70A9@BY3PR05MB8081.namprd05.prod.outlook.com> <MW4PR03MB6395E25BC8D22EE5246CD4B2F6099@MW4PR03MB6395.namprd03.prod.outlook.com> <BY3PR05MB808131C5A8BD9A38CBEBF255C7099@BY3PR05MB8081.namprd05.prod.outlook.com>
In-Reply-To: <BY3PR05MB808131C5A8BD9A38CBEBF255C7099@BY3PR05MB8081.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [109.67.43.220]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c0351abc-9a55-412a-4aa2-08d9358ea172
x-ms-traffictypediagnostic: CO2PR03MB2278:
x-microsoft-antispam-prvs: <CO2PR03MB2278F32D355B3E2FEE87872FF6099@CO2PR03MB2278.namprd03.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: OgtGBQDiaARV1xSJu3Mfo7nfGC7h2NSLIuPQUQNvnIEbOVpALJKRVDt++AapWg+o7f3x1lNFoA6p1MpKYLq4PQde74rYQdsZvjU5x6rPHp8Q3bEjyvXeAbB+A7tTjsDvIBGi07xRxdyUFaCS1Tba41/T94J9edbIqvsuqwjZK/IgB4HZbDr3dCM6CmZ+odraWAGz1k0hmAy2Md/pG1zY4BTYq1aeC8eW+f6AObVqAmdYMH/yzDn7SiH5DnvZpPO3JevUiDbMya2VpKcQEJMv2XqSxzakOF4Ljfbth0xnjvuzPamzMOX/Clo+TE5qt8/kuE8uF8APNqGII1hK0NO1XVEHXs75Qg6Y1oWjJxc0FWn5XYhKEefWC7kN2w675x7SCUg1e0GUwFjtK7FziCIP2m7v3LOgJlG384DGegqxBKxtUmYrRcEGHj9DHOfwfizPNTPAzSu9jzo5IsKmpqdMuxg5+dRhFdagB5PNOIqPqvXFes9sdCOUacdi62ErumYSNKvzsg+A2MuoO2CLMVhtujxxRDowFT6uQor6pcKsKdJyJEFbKu4EJ5Vv+eYbdn1ymSkaJSshEmFj6MT/WJVy8RRX1YM7w0bRPgP/0vX+g2HOnat0zYkQcYSiQSes3ryZCDnvYZ/PHDjkut86wXirPktoWnZdN9uZHU5JAJZD/Yj81uKxVOfzozx7L22oMuqoKBeOlFS3XRcL+5WeyaGJalsI7DeVRueHy2uzZy78G2N1Y9BdbuVEZL2SrzlEQjNW
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW4PR03MB6395.namprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(39860400002)(376002)(136003)(396003)(346002)(54906003)(2906002)(33656002)(6506007)(53546011)(8936002)(86362001)(6916009)(45080400002)(30864003)(316002)(7696005)(186003)(66446008)(66946007)(4326008)(966005)(8676002)(478600001)(166002)(66574015)(38100700002)(76116006)(66556008)(9686003)(71200400001)(64756008)(26005)(66476007)(52536014)(83380400001)(5660300002)(122000001)(55016002)(579004)(559001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?drWSI913YuImTEyEEA3Br49qV6evTxhJdUANksShYKgpFa6cnHOr1RoTw2ae?= =?us-ascii?Q?HEZJBdAa1NVR+fKTAYDBjfqiSlQjiRCX8Z+xaSNCq9di6XMyfNBJVri7E68r?= =?us-ascii?Q?EEfRiGkTcAK+uQ/F/B8nbVCkan+O+PXe5JYsW64JqE9I8dII6wXTH609ooyz?= =?us-ascii?Q?0YBoHJNyKS6YlBKf7jLfn5so9mlRWSYz8I4l61+CwaQDqVlPEW2F6HXHgK47?= =?us-ascii?Q?YP8uDWk0Z2EZzXEJFdDBLw5atd+xD+Kb68PTtN8N9FjBFvDgGe6Wx3EORX9j?= =?us-ascii?Q?A7LSfIf+TN4vEuaoAOlrFyTxBc1gOfS0Riivic0Yi4FvCinKKwm0+OZf5/o2?= =?us-ascii?Q?gok9pV9bHtkZL7KGnaPRd480CrOzyFmV/Mdi/1t1mksk413m5mo0x/dU0wYc?= =?us-ascii?Q?mPCL675jYzDaJdaPnxMn3jcmzXO2dkGJXRWZoHkl3bkroSQNj/NIO9yjXtMG?= =?us-ascii?Q?LFsoq465lzAYcCvTlEaceH6JHwNH93d2qxg8BJF/xyP3ph1KHwzacM0IAxhM?= =?us-ascii?Q?28JdbSfp8NsacyR39WnnW7Gl9adozUbZQk1qpJewyWV0h5kK7uH6b5hn8UyR?= =?us-ascii?Q?FvSw9WURTalhSUWXrPXmN7I5WNb5p+TeEX/OUhHxKY2gQSI2s1LuClt8P1QI?= =?us-ascii?Q?B0R4TGuruHvzghYM9cGcWjFkMaPhAWiOB2O7vdnb6Bt9WYjD8kqVpbZnrOHa?= =?us-ascii?Q?43qcOUlKwi66NwcXxpOoKaNReBsOFLEan6jSvzDmdz7N8Zb9KPPHMsdoDNKG?= =?us-ascii?Q?IbKGSu77QNzQdTNJIpIPZQTrNhcLbYbe15WYOHWr9HRdC0O5IIsP1gKHF6Yf?= =?us-ascii?Q?ZYKhIJFhWf1Ft8iKrLMvLTLWyI92gZiuVKATwUjRwNJOAFQqx6AfLm9gQl8S?= =?us-ascii?Q?kJZyp6riaSqiis67ZjZifedXwbk9aakZ7jyoohje7LOhUjsYxicw5N5sDuMg?= =?us-ascii?Q?kEzQaI6QhEe391JvMhcJGVllnAqkZjz188v3n+fBvSEoEUOmD4yGzJgG14KX?= =?us-ascii?Q?XEW3+zUaF+S/Odd2pPWCbxybE5/slsF4Ly6ytLl6Zr88xLPXYQai1cqYyGTo?= =?us-ascii?Q?sR/Hok4pypTDV5HuwTSIh8eOUsTHoWk7tfUlqwSzn9oL0g1Eh0cA0Lk1HHFR?= =?us-ascii?Q?pD/EpMsw4lXI0lQja+jEoSIsn4ZNW0e/t1iRVmKkWOmSs1PMy8KEz+t/k75i?= =?us-ascii?Q?5+01cVixGy1bDkpisRJGHr8D8GBFRVXn9YO1Q+L9WBvw0VY6N/JQ1L0w4+zt?= =?us-ascii?Q?xehecJyZCDPRINmG+Fq7GT+Q50vhGu5ln7/f9jrVbaXaC2lPSvWmwk6uuXUo?= =?us-ascii?Q?6xSPzGdgGZ+mdrnSh+VoyHzC?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MW4PR03MB63952599D725AD5717547F3AF6099MW4PR03MB6395namp_"
MIME-Version: 1.0
X-OriginatorOrg: rbbn.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MW4PR03MB6395.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c0351abc-9a55-412a-4aa2-08d9358ea172
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2021 15:01:35.8093 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /5Q6xc7XJ9eIaBlB4b2NokW9ua5lqrEmjh/imKpu2d0IKDlZ6yKBVf7eJlsf378mL+AB8P9K2PxS2KrLFu5+qA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO2PR03MB2278
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/q_9JFQUnVkMNuAFMYwo9sLZEfR8>
Subject: Re: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS
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: Tue, 22 Jun 2021 15:01:57 -0000

John,
Again, lots of thanks for your comments.

Please see inline below.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@rbbn.com

From: John E Drake <jdrake@juniper.net>
Sent: Tuesday, June 22, 2021 5:06 PM
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com>
Cc: mpls@ietf.org; Haoyu Song <hsong@futurewei.com>om>; Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org>rg>; Loa Andersson <loa@pi.nu>
Subject: RE: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS

Hi,

Comments inline.

Yours Irrespectively,

John



Juniper Business Use Only
From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>
Sent: Tuesday, June 22, 2021 9:27 AM
To: John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; Haoyu Song <hsong@futurewei.com<mailto:hsong@futurewei.com>>; Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org<mailto:zzhang=40juniper.net@dmarc.ietf.org>>; Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>
Subject: RE: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS

[External Email. Be cautious of content]

John,
Lots of thanks for your comment.

A few points:

1.         I have sent the previous email as a response to your aside claim that "RFC 8662 does not define what a transit LSR should do when it finds an [ELI, EL] pair at the top of the MPLS label stack, either when it understands the label pair or when it doesn't". As I see it, both Bruno and I have demonstrated that this behavior is defined

[JD]  Perhaps I missed it, but nowhere in RFC 8662 do I see a statement of the form:  "This document updates the transit LSR behavior defined in RFC 6790 to allow a transit LSR that understands entropy labels to remove an [ELI, EL] pair that it sees at the top of an MPLS label stack.  This requires a transit LSR to indicate this capability to other LSRs in the SR domain and it requires the ingress LSR to ensure that when it inserts [ELI, EL] pairs in the MPLS label stack they will only be at the top of the MPLS label stack when received by a transit LSR with this capability."
[[Sasha]] I have not seen any such statement either. However, I think that we may be dealing with a terminology issue. I believe that in SR a node that originates advertisement, say, of an IGP Prefix SID, is considered as the egress node for the segment represented by this SID, even if it is a transit node for an LSP that includes this SID in the middle of the stack of SIDs. This is why they have assumed that considerations of 6790 pertaining to egress LERs are sufficient.


  1.  My reading of your comment to my response "If that's the behavior that we want, then RFC 8662 is not deployable" is that:

     *   You agree that some behavior has been defined in RFC 8662

[JD]  Your email, to which I responded, referenced RFC 6790 not RFC 8662 and I was commenting on this sentence:  "Any other LSR (including PHP LSRs) MUST drop such packets.".  I.e., it is referring to non-egress, or transit, LSRs.  [[Sasha]] Please see my previous comment


     *   You claim that the defined behavior makes RFC 8662 non-deployable

[JD]  See my previous comment.


  1.  I respectfully disagree with (2b) above because:

     *   My reading of RFC 6790 is that {ELI, EL} pairs in any case can be only inserted if the node that receives ELI at the top of the stack has signaled its capability to handle such a pair

[JD]   RFC 6970 only talks about egress LSRs advertising this capability.[[Sasha]] Please see my previous comment about terminology. Please note also that the signaling drafts I have mentioned, define signaling of Entropy Label Capability (ELC) by all router. In particular, the Signaling Entropy Label Capability and Entropy Readable Label Depth Using ISIS<https://datatracker.ietf.org/doc/html/draft-ietf-isis-mpls-elc-13> draft says:

   Bit 3 in the Prefix Attribute Flags [RFC7794<https://datatracker.ietf.org/doc/html/rfc7794>] is used as the ELC Flag

   (E-flag), as shown in Figure 1.  If a router has multiple interfaces,

   the router MUST NOT announce the ELC for any local host prefixes

   unless all of its interfaces are capable of processing ELs.  If a

   router supports ELs on all of its interfaces, it SHOULD set the ELC

   for every local host prefix it advertises in IS-IS.
>From my POV, this specification means that the {ELI, EL} tuple may be safely inserted into the label stack immediately after any IGP Prefix SID advertised with PHP by a router that has also advertised ELC capability in IS-IS.


b.       While RFC 8662 does not define any mechanisms for signaling ability to handle {ELI, EL} pair at the top of the stack, it provides Informational references to a couple of drafts that define such signaling in IS-IS and OSPF, and these drafts have been already approved for publication as RFCs

[JD]  See my first comment above.


     *   With this signaling in place in an SR domain, {ELI, EL} pairs can be inserted in the label stack in the following positions:

                                                                  i.      Immediately following an IGP Prefix SID that has been advertised (with PHP) by a node that has signaled its capability to support {ELI, EL}

[JD]  See my first comment above.  I am not saying that RFC 8662 doesn't work.  Rather, like RFC 5886 it is under-specified.
[[Sasha]] From my POV, the above-mentioned signaling drafts provide the missing specification. This is quite different from RFC 5586.


                                                                ii.      Immediately following an Adjacency SID that represents an IGP adjacency between the advertising node and the node that signaled its capability to support {ELI, EL}

     *   Depending on specific network topology and the specific stack of SIDs, the rules above may be too restrictive to provide effective load balancing, or not. But IMHO and FWIW this is not really different from the situation with "vanilla" RFC 6790 if, e.g., some of the PEs where a given L3VPN service is represented, have advertised their ability to handle {ELI, EL} via LDP or RSVP-TE, and some did not advertise such capability.
My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>

From: John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>
Sent: Monday, June 21, 2021 9:56 PM
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; Haoyu Song <hsong@futurewei.com<mailto:hsong@futurewei.com>>; Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org<mailto:zzhang=40juniper.net@dmarc.ietf.org>>; Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>
Subject: RE: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS

Comment inline.

Yours Irrespectively,

John



Juniper Business Use Only
From: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>
Sent: Monday, June 21, 2021 11:46 AM
To: John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; Haoyu Song <hsong@futurewei.com<mailto:hsong@futurewei.com>>; Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org<mailto:zzhang=40juniper.net@dmarc.ietf.org>>; Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>
Subject: RE: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS

[External Email. Be cautious of content]

John,
"Great minds think alike".

Regarding your aside comment on RFC 8662:
The last para of Section 4.3 of RFC 6790<https://clicktime.symantec.com/3EvxQY3dZE6MCzRCky9z2rr6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3PDwoeDbzi3ETXLKkVKHdzL6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fdatatracker.ietf.org%2A2Fdoc%2A2Fhtml%2A2Frfc6790%2A2Asection-4.3__%2A3BIw%2A21%2A21NEt6yMaO-gk%2A21Uk8p6mR2CzJJFXxJuweTWC-0CDe7odXjIzcOP6yLGVqs-46um02ro1mHgEYFFvI%2A24__%3BJSUlJSUlJSUlJSUlJSUlJQ%21%21NEt6yMaO-gk%21RH_x4Yy-jTEqPMKiyMGCocKS-X0kXu_C0ArR_wJSIAgx76WXM8Mm5xSMw-aGDt8%24> says:


   As stated in Sections 4.1<https://clicktime.symantec.com/3BjFjLGdKqJxXP2G6xuL1M76H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3Q8XJjsAd3fUwja7w7zBq576H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fdatatracker.ietf.org%2A2Fdoc%2A2Fhtml%2A2Frfc6790%2A2Asection-4.1__%2A3BIw%2A21%2A21NEt6yMaO-gk%2A21Uk8p6mR2CzJJFXxJuweTWC-0CDe7odXjIzcOP6yLGVqs-46um02ro1mHfo9sMUI%2A24__%3BJSUlJSUlJSUlJSUlJSUlJQ%21%21NEt6yMaO-gk%21RH_x4Yy-jTEqPMKiyMGCocKS-X0kXu_C0ArR_wJSIAgx76WXM8Mm5xSMre1vkh0%24> and 5<https://clicktime.symantec.com/3Nq2VVAPq9XCTjsgwnp77NH6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3W3scAvqRKZF6Hd9aBjBfFo6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fdatatracker.ietf.org%2A2Fdoc%2A2Fhtml%2A2Frfc6790%2A2Asection-5__%2A3BIw%2A21%2A21NEt6yMaO-gk%2A21Uk8p6mR2CzJJFXxJuweTWC-0CDe7odXjIzcOP6yLGVqs-46um02ro1mHyGgu2ZY%2A24__%3BJSUlJSUlJSUlJSUlJSUlJQ%21%21NEt6yMaO-gk%21RH_x4Yy-jTEqPMKiyMGCocKS-X0kXu_C0ArR_wJSIAgx76WXM8Mm5xSMISv8PZA%24>24>, an egress LSR that signals both ELC

   and implicit null MUST pop the ELI and the next label (which should

   be the EL), if it encounters a packet with the ELI as the topmost

   label.  Any other LSR (including PHP LSRs) MUST drop such packets, as

   per Section 3.18 of [RFC3031]<https://clicktime.symantec.com/3ENxypfQnY6TWQf4EL29AHf6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3WQ3TqWDKFmsEnTM4eLJ4SG6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fdatatracker.ietf.org%2A2Fdoc%2A2Fhtml%2A2Frfc3031%2A2Asection-3.18__%2A3BIw%2A21%2A21NEt6yMaO-gk%2A21Uk8p6mR2CzJJFXxJuweTWC-0CDe7odXjIzcOP6yLGVqs-46um02ro1mHgqlxMBs%2A24__%3BJSUlJSUlJSUlJSUlJSUlJQ%21%21NEt6yMaO-gk%21RH_x4Yy-jTEqPMKiyMGCocKS-X0kXu_C0ArR_wJSIAgx76WXM8Mm5xSMCPiuYwU%24>24>.



[JD]  If that's the behavior that we want, then RFC 8662 is not deployable.

All that is needed is to clarify the (rather, self-evident) rules for SIDs for which the originating routers  effectively signal Implicit Null  (explicitly or implicitly), including:

  1.  All Adj-SIDs
  2.  All EPE SIDs
  3.  IGP Prefix SIDs that have been advertised with PHP (P-flag cleared in IS-IS, NP-flag cleared in OSPF)
  4.  BGP Prefix SIDs advertised with Implicit Null in the NLRI of  the BGP-LU route.

I do not think that I have missed anything (Binding SIDs are not involved in PHP).

My 2c,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>

From: John E Drake <jdrake@juniper.net<mailto:jdrake@juniper.net>>
Sent: Monday, June 21, 2021 3:52 PM
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>; Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; Haoyu Song <hsong@futurewei.com<mailto:hsong@futurewei.com>>; Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org<mailto:zzhang=40juniper.net@dmarc.ietf.org>>
Subject: RE: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS

Hi,

I agree with Sasha's email, below, which is proposing what I was proposing several months ago.

As an aside, RFC 8662 does not define what a transit LSR should do when it finds an [ELI, EL] pair at the top of the MPLS label stack, either when it understands the label pair or when it doesn't.

Yours Irrespectively,

John



Juniper Business Use Only
From: mpls <mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>> On Behalf Of Alexander Vainshtein
Sent: Monday, June 21, 2021 6:55 AM
To: Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; Haoyu Song <hsong@futurewei.com<mailto:hsong@futurewei.com>>; Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org<mailto:zzhang=40juniper.net@dmarc.ietf.org>>
Subject: Re: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS

[External Email. Be cautious of content]


Loa,

Regarding your question "Would you include adding a copy of the GAL higher up in the stack to make sure that it is within readable depth for any LSR?"  my answer is NO.



I have already said on this thread that if GAL is exposed as ToS but not BoS to an existing standards-compliant MPLS forwarder, it will not know how to handle it since such handling has not ever been defined - not in RFC 5586<https://clicktime.symantec.com/3B4HUFbyoxVqmUo7QNkPWDS6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3LFH4qVDAVUpzHHufyXwucN6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F3LpX2kp84U26BibbLu6xFzk6H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Furldefense.com%2A2A2Fv3%2A2A2F__https%2A2A3A%2A2A2Fdatatracker.ietf.org%2A2A2Fdoc%2A2A2Fhtml%2A2A2Frfc5586__%2A2A3B%2A2A21%2A2A21NEt6yMaO-gk%2A2A21QiStnftbs7rzJ6JZRtxhV6LZks_wNvQJ-rNe5phnYEW6lEzzVD0vSHtMt9fY588%2A2A24__%2A3BJSUlJSUlJSUlJSUlJSUl%2A21%2A21NEt6yMaO-gk%2A21Uk8p6mR2CzJJFXxJuweTWC-0CDe7odXjIzcOP6yLGVqs-46um02ro1mHeNCd6vA%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl%21%21NEt6yMaO-gk%21RH_x4Yy-jTEqPMKiyMGCocKS-X0kXu_C0ArR_wJSIAgx76WXM8Mm5xSMfgunyzA%24> and not anywhere else. Stewart has responded that "an old implementation that received a ToS GAL not at BoS would at best throw an exception or worst be unpredictable".  Neither of these options sounds optimistic to me.



I also do not favor investing into a technique that would guarantee that packets with GAL in the middle of the stack only pass thru new LSRs that know how to handle them .



However, it is quite possible to do the following IMHO:

  1.  Retain the existing definitions of GAL just at BoS and ACH that immediately follows the BoS
  2.  Define new ACH types that can carry new ancillary data, and the structures that can be used for this purpose (as you have said, "we can carry everything in the associated channel", including TLVs and Sub-TLVs, if necessary - it will be up to the specific applications to process such structures in ACH, but at least this would not affect MPLS forwarding).
  3.  Allow LERs that (a) can detect presence of GAL at BoS and (b) recognize new ACH types to meddle with the information carried in the ACH while forwarding labeled packets in the usual way
  4.  Also allow usage of TTL to help LERs that recognize new ACH types to meddle with the information carried in the ACH (similar to what has been done in RFC 8169<https://clicktime.symantec.com/3LjkcAVhuwRQJqtrxjrf92G6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3UtLBGnixTrdCEoquSjkP16H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F389RV1YUirVu9q6t88snhkP6H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Furldefense.com%2A2A2Fv3%2A2A2F__https%2A2A3A%2A2A2Fdatatracker.ietf.org%2A2A2Fdoc%2A2A2Fhtml%2A2A2Frfc8169__%2A2A3B%2A2A21%2A2A21NEt6yMaO-gk%2A2A21QiStnftbs7rzJ6JZRtxhV6LZks_wNvQJ-rNe5phnYEW6lEzzVD0vSHtMB4Q7qmg%2A2A24__%2A3BJSUlJSUlJSUlJSUlJSUl%2A21%2A21NEt6yMaO-gk%2A21Uk8p6mR2CzJJFXxJuweTWC-0CDe7odXjIzcOP6yLGVqs-46um02ro1mHvz6RrTE%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl%21%21NEt6yMaO-gk%21RH_x4Yy-jTEqPMKiyMGCocKS-X0kXu_C0ArR_wJSIAgx76WXM8Mm5xSMz23oBcc%24>) even if they cannot detect presence of GAL at BoS due to the depth of the stack.



I cannot say whether this approach is good enough for the specific set of applications. But it looks to me as reasonably safe since it does not require any new forwarding functionality in existing LERs - primum non nocere<https://clicktime.symantec.com/3GKsCwGpjw974kU3D48QDJb6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3QMnW2BUztofokYXW2fRkBn6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F3GdXcZMxHHLvCC23kWNFkFG6H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Furldefense.com%2A2A2Fv3%2A2A2F__https%2A2A3A%2A2A2Fen.wikipedia.org%2A2A2Fwiki%2A2A2FPrimum_non_nocere__%2A2A3B%2A2A21%2A2A21NEt6yMaO-gk%2A2A21QiStnftbs7rzJ6JZRtxhV6LZks_wNvQJ-rNe5phnYEW6lEzzVD0vSHtMI1UZKH0%2A2A24__%2A3BJSUlJSUlJSUlJSUlJSU%2A21%2A21NEt6yMaO-gk%2A21Uk8p6mR2CzJJFXxJuweTWC-0CDe7odXjIzcOP6yLGVqs-46um02ro1mHSI9qHKg%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU%21%21NEt6yMaO-gk%21RH_x4Yy-jTEqPMKiyMGCocKS-X0kXu_C0ArR_wJSIAgx76WXM8Mm5xSMA9liAC0%24>24>.



My 2c,

Sasha



Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>





-----Original Message-----
From: Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>
Sent: Monday, June 21, 2021 1:16 PM
To: Alexander Vainshtein <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>
Cc: mpls@ietf.org<mailto:mpls@ietf.org>; Haoyu Song <hsong@futurewei.com<mailto:hsong@futurewei.com>>; Jeffrey (Zhaohui) Zhang <zzhang=40juniper.net@dmarc.ietf.org<mailto:zzhang=40juniper.net@dmarc.ietf.org>>; Stewart Bryant <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>
Subject: Re: [mpls] [EXTERNAL] Indicators in the stack and ancillary data after the BoS



Sasha,





On 21/06/2021 11:55, Alexander Vainshtein wrote:

> Loa and all,

>

> I fully agree with the proposal "to not tamper with ACH anymore".

>

>  From my POV, this includes (by implication) not tampering also with

> GAL as well.



Would you include adding a copy of the GAL higher up in the stack to make sure that it is within readable depth for any LSR?

>

> As for the question " If the slot immediately after the label stack is

> reserved for the ACH does this mean the no other ancillary data may be

> inserted in this position, e.g. MPLS EH's, given that there is a GAL

> in the stack" the answer, IMHO, is YES.

>

> However, it is quite possible to carry any kind of new information in

> the ACH, similar to the way this has been done in Section 3 of RFC

> 8169

> <https://clicktime.symantec.com/3FFh4tSjBeGN2kf7C3a3Sa76H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8169%23section-3<https://clicktime.symantec.com/3UGQjSTm4XpXjLBxA9zJqcr6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3QzLxrBKpSCaXxZ9WTPFXb46H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F3UR1A1MPDSqDJ5gouUDZ8i86H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Furldefense.com%2A2A2Fv3%2A2A2F__https%2A2A3A%2A2A2Fclicktime.symantec.com%2A2A2F3FFh4tSjBeGN2kf7C3a3Sa76H2%2A2A3Fu%2A2A3Dhttps%2A2A2A3A%2A2A2A2F%2A2A2A2Fdatatracker.ietf.org%2A2A2A2Fdoc%2A2A2A2Fhtml%2A2A2A2Frfc8169%2A2A2A23section-3__%2A2A3BJSUlJSUlJQ%2A2A21%2A2A21NEt6yMaO-gk%2A2A21QiStnftbs7rzJ6JZRtxhV6LZks_wNvQJ-rNe5phnYEW6lEzzVD0vSHtM0KyFNp0%2A2A24__%2A3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ%2A21%2A21NEt6yMaO-gk%2A21Uk8p6mR2CzJJFXxJuweTWC-0CDe7odXjIzcOP6yLGVqs-46um02ro1mHvEw3iqk%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ%21%21NEt6yMaO-gk%21RH_x4Yy-jTEqPMKiyMGCocKS-X0kXu_C0ArR_wJSIAgx76WXM8Mm5xSMMFVywrw%24>> where G-ACH is used for residence time measurement.



Logically this means that we can carry everything in the associated channel. However there can only one ACH per packet, right?



/Loa

>

> Regards,

>

> Sasha

>

> Office: +972-39266302

>

> Cell:      +972-549266302

>

> Email:   Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>

>

> -----Original Message-----

> From: Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>

> Sent: Monday, June 21, 2021 12:40 PM

> To: Haoyu Song <hsong@futurewei.com<mailto:hsong@futurewei.com>>; Jeffrey (Zhaohui) Zhang

> <zzhang=40juniper.net@dmarc.ietf.org<mailto:zzhang=40juniper.net@dmarc.ietf.org>>; Alexander Vainshtein

> <Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>>; Stewart Bryant

> <stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com>>

> Cc: mpls@ietf.org<mailto:mpls@ietf.org>

> Subject: Re: [mpls] [EXTERNAL] Indicators in the stack and ancillary

> data after the BoS

>

> Haoyu, DT

>

> On 17/06/2021 18:56, Haoyu Song wrote:

>

>  > My opinion is to not tamper with ACH anymore because it's designed

> for control channel only and so far for a special scenario. The

> constraints on GAL and format of ACH are hard to adapt to the new use

> case requirements.

>

>  >

>

> I think this is a position that is possible to defend.

>

> One question though.

>

> RFC 5586 specifies "that the ACH appears immediately after the bottom

> of the label stack."

>

> If the slot immediately after the label stack is reserved for the ACH

> does this mean the no other ancillary data maybe inserted in this

> position, e.g. MPLS EH's, given that there is a GAL in the stack?

>

> /Loa

>

>  > Thanks!

>

>  > Haoyu

>

>  >

>

>  > -----Original Message-----

>

>  > From: mpls <mpls-bounces@ietf.org <mailto:mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org%20%3cmailto:mpls-bounces@ietf.org>>>

> On Behalf Of Jeffrey (Zhaohui)

>

>  > Zhang

>

>  > Sent: Thursday, June 17, 2021 8:02 AM

>

>  > To: Loa Andersson <loa@pi.nu <mailto:loa@pi.nu<mailto:loa@pi.nu%20%3cmailto:loa@pi.nu>>>; Alexander

> Vainshtein

>

>  > <Alexander.Vainshtein@rbbn.com

> <mailto:Alexander.Vainshtein@rbbn.com>>; Stewart Bryant

>

>  > <stewart.bryant@gmail.com <mailto:stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com%20%3cmailto:stewart.bryant@gmail.com>>>

>

>  > Cc: mpls@ietf.org<mailto:mpls@ietf.org> <mailto:mpls@ietf.org>

>

>  > Subject: Re: [mpls] [EXTERNAL] Indicators in the stack and

> ancillary

>

>  > data after the BoS

>

>  >

>

>  > Hi Loa,

>

>  >

>

>  >> but I'd like to see the DT address multiple indicators in the

> stack and multiple sets of ancillary data after the BoS.

>

>  >

>

>  > I think the earlier emails of this email thread were talking about

> multiple indicators in the stack; for multiple set of ancillary data

> after the BoS, either the extended ACH or the proposed MPLS/generic

> extension headers or a merge of those proposals should be able to

> handle it. This is alluded to the DataAfterBOS wiki page.

>

>  >

>

>  > Thanks.

>

>  >

>

>  > Jeffrey

>

>  >

>

>  > -----Original Message-----

>

>  > From: Loa Andersson <loa@pi.nu <mailto:loa@pi.nu<mailto:loa@pi.nu%20%3cmailto:loa@pi.nu>>>

>

>  > Sent: Thursday, June 17, 2021 10:46 AM

>

>  > To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net

> <mailto:zzhang@juniper.net>>; Alexander Vainshtein

>

>  > <Alexander.Vainshtein@rbbn.com

> <mailto:Alexander.Vainshtein@rbbn.com>>; Stewart Bryant

>

>  > <stewart.bryant@gmail.com <mailto:stewart.bryant@gmail.com<mailto:stewart.bryant@gmail.com%20%3cmailto:stewart.bryant@gmail.com>>>

>

>  > Cc: mpls@ietf.org<mailto:mpls@ietf.org> <mailto:mpls@ietf.org>

>

>  > Subject: Re: [mpls] [EXTERNAL] Indicators in the stack and

> ancillary

>

>  > data after the BoS

>

>  >

>

>  > [External Email. Be cautious of content]

>

>  >

>

>  >

>

>  > DT,

>

>  >

>

>  > Responded to Jeffrey's mail, but it is intended to address the

> entire discussion.

>

>  >

>

>  > There seem to be enough issues to sort out around the GAL/ACH pair,

> and I was worried about a set of other indicators and the data that

> they might want to put "after the BoS". So far I have seen no real

> effort to address the interference's this might lead to.

>

>  >

>

>  > Further inline

>

>  >

>

>  >

>

>  > On 17/06/2021 16:15, Jeffrey (Zhaohui) Zhang wrote:

>

>  >> Hi,

>

>  >>

>

>  >> It's not clear how we could put a GAL not at a BoS:

>

>  >>

>

>  >>

>

>  >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>

>  >>

>

>  >>      |                              ACH

> |

>

>  >>

>

>  >>

>

>  >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>

>  >>

>

>  >>      |                         ACH TLV Header

> |

>

>  >>

>

>  >>

>

>  >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>

>  >>

>

>  >>      |

> ~

>

>  >>

>

>  >>      ~                     zero or more ACH TLVs

> ~

>

>  >>

>

>  >>      ~

> |

>

>  >>

>

>  >>

>

>  >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>

>  >>

>

>  >>      |

> ~

>

>  >>

>

>  >>      ~                        G-ACh Message

> ~

>

>  >>

>

>  >>      ~

> |

>

>  >>

>

>  >>

>

>  >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>

>  >>

>

>  >>                         Figure 2: G-ACh Packet Payload

>

>  >>

>

>  >> If the GAL does not have S-bit set, wouldn't a transit LSR treat

> any

>

>  >> 4-ocet field (i.e. those in the above Figure) after that GAL as a

>

>  >> label+TOS+S+TTL? If that 4-octet field has the S-bit set, the

> transit

>

>  >> LSR will think the label stack ends there even though that's just

>

>  >> part of the ACH.

>

>  >>

>

>  >> Or are you saying that a GAL not at the BoS will not have the ACH

>

>  >> following it?

>

>  >

>

>  > Well, as far as I understand a GAL which does not have the NoS-bit

> set will have other labels after itself. The BoS-bit will be found

> deeper down stack and the ACH will immediately fo9llow the BoS.

>

>  >

>

>  > Yes there are issues here, but I'd like to see the DT address

> multiple indicators in the stack and multiple sets of ancillary data

> after the BoS.

>

>  >

>

>  > I think we need to nail down the relevant questiuons first, and

> start working on solutions after that.

>

>  >

>

>  > /Loa

>

>  >>

>

>  >> Jeffrey

>

>  >>

>

>  >> *From:*mpls <mpls-bounces@ietf.org <mailto:mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org%20%3cmailto:mpls-bounces@ietf.org>>>

> *On Behalf Of *Alexander

>

>  >> Vainshtein

>

>  >> *Sent:* Thursday, June 17, 2021 5:07 AM

>

>  >> *To:* Stewart Bryant <stewart.bryant@gmail.com

> <mailto:stewart.bryant@gmail.com>>

>

>  >> *Cc:* mpls@ietf.org<mailto:mpls@ietf.org> <mailto:mpls@ietf.org>

>

>  >> *Subject:* Re: [mpls] [EXTERNAL] Indicators in the stack and

>

>  >> ancillary data after the BoS

>

>  >>

>

>  >> *[External Email. Be cautious of content]*

>

>  >>

>

>  >> Stewart,

>

>  >>

>

>  >> I fully agree with your statement that "an old implementation that

>

>  >> received a ToS GAL not at BoS would at best throw an exception or

>

>  >> worst be unpredictable".

>

>  >>

>

>  >> Regarding your statement "it is OK to have multiple GALs and GALs

> not

>

>  >> at BoS IFF the creator of the LSP ensured that all LSRs on the

> LSP,

>

>  >> including ECMP and FRR paths that found the GAL at ToS were known

> to

>

>  >> be able to process it correctly":

>

>  >>

>

>  >>   1. I fully agree with this statement as a general restriction  2.

>

>  >> Quite a lot of things have to be done in order to make this

>

>  >>      restriction work including at least:

>

>  >>

>

>  >>       1. The definition of correct processing of GAL at ToS but

> not at

>

>  >>          BoS must be provided

>

>  >>       2. Advertisement of ability to process GAL not at BoS

> correctly in

>

>  >>          IGP and BGP must be defined

>

>  >>       3. Ability to set up network-wide paths that only cross

> nodes that

>

>  >>          process GAL correctly must be provided for different

> techniques

>

>  >>          (RSVP-TE, SR-TE, FlexAlgo. BGP-LU etc.)

>

>  >>

>

>  >> It is still possible that, after all this work, we shall find out

>

>  >> that the benefits of supporting GAL at ToS but not BoS will be

> only

>

>  >> available in the networks where all the nodes support the new

>

>  >> functionality because presence of non-supporting nodes imposes too

>

>  >> many restrictions on connectivity and/or resilience.

>

>  >>

>

>  >> Regards,

>

>  >>

>

>  >> Sasha

>

>  >>

>

>  >> Office: +972-39266302

>

>  >>

>

>  >> Cell:      +972-549266302

>

>  >>

>

>  >> Email: Alexander.Vainshtein@rbbn.com<mailto:Alexander.Vainshtein@rbbn.com>

> <mailto:Alexander.Vainshtein@rbbn.com>

>

>  >> <mailto:Alexander.Vainshtein@rbbn.com

> <mailto:Alexander.Vainshtein@rbbn.com>>

>

>  >>

>

>  >> *From:*Stewart Bryant <stewart.bryant@gmail.com

>

>  >> <mailto:stewart.bryant@gmail.com

> <mailto:stewart.bryant@gmail.com>>>

>

>  >> *Sent:* Thursday, June 17, 2021 10:36 AM

>

>  >> *To:* Alexander Vainshtein <Alexander.Vainshtein@rbbn.com

>

>  >> <mailto:Alexander.Vainshtein@rbbn.com

> <mailto:Alexander.Vainshtein@rbbn.com>>>

>

>  >> *Cc:* Stewart Bryant <stewart.bryant@gmail.com

>

>  >> <mailto:stewart.bryant@gmail.com

> <mailto:stewart.bryant@gmail.com>>>; gregory.mirsky@ztetx.com<mailto:gregory.mirsky@ztetx.com>

> <mailto:gregory.mirsky@ztetx.com>

>

>  >> <mailto:gregory.mirsky@ztetx.com

> <mailto:gregory.mirsky@ztetx.com>>;

> mpls@ietf.org<mailto:mpls@ietf.org> <mailto:mpls@ietf.org>

>

>  >> <mailto:mpls@ietf.org <mailto:mpls@ietf.org<mailto:mpls@ietf.org%20%3cmailto:mpls@ietf.org>>>

>

>  >> *Subject:* Re: [mpls] [EXTERNAL] Indicators in the stack and

>

>  >> ancillary data after the BoS

>

>  >>

>

>  >>      On 17 Jun 2021, at 07:45, Alexander Vainshtein

>

>  >>      <Alexander.Vainshtein@rbbn.com

>

>  >>      <mailto:Alexander.Vainshtein@rbbn.com

> <mailto:Alexander.Vainshtein@rbbn.com>>> wrote:

>

>  >>

>

>  >>      While that might be the case, I think that the Open DT may

> give it a

>

>  >>      try and investigate how the existing systems will handle GAL

> being

>

>  >>      not the BoS label.

>

>  >>

>

>  >>      */[[Sasha]] Great minds think alike! One useful step could be

>

>  >>      collecting the known actual behavior of popular

> implementations in

>

>  >>      this case, say, by running a survey among the vendors - what

> do you

>

>  >>      think?/*

>

>  >>

>

>  >> That is actually a considerable amount of work that will take a while.

>

>  >>

>

>  >> It seems to me that an old implementation that received a ToS GAL

> not

>

>  >> at BoS would at best throw an exception or worst be unpredictable.

>

>  >>

>

>  >> The original assumed processing model is to take the context of

> the

>

>  >> PW label or PW+FAT label, discover the GAL and then process the

> GAL

>

>  >> in the context of the PW label.

>

>  >>

>

>  >> When we extended GAL to apply to LSPs we again had the model that

> the

>

>  >> GAL operated in the context of the LSP label that preceded it for

>

>  >> context. It was still BoS.

>

>  >>

>

>  >> Putting the GAL further up the stack is a new behaviour.

>

>  >>

>

>  >> If it arrives at an LSR that knows the new semantic all is good.

>

>  >>

>

>  >> If it arrives at an LSR that does not know the new semantic then

>

>  >>

>

>  >> a) An error has occurred either in setting up the LSP, or in forwarding.

>

>  >>

>

>  >> b) The behaviour at the receiving node is unpredictable, but in

> any

>

>  >> well written implementation should just result in the packet being

>

>  >> dropped and counted as with any other Mal-formed packet.

>

>  >>

>

>  >> So I would think that it is OK to have multiple GALs and GALs not

> at

>

>  >> BoS IFF the creator of the LSP ensured that all LSRs on the LSP,

>

>  >> including ECMP and FRR paths that found the GAL at ToS were known

> to

>

>  >> be able to process it correctly.

>

>  >>

>

>  >> A GAL not at BoS and not at ToS should not be inspected or

> processed

>

>  >> by any LSR that did not know what it was doing, and to attempt to

>

>  >> precess it would be a violation of the normal MPLS processing model.

>

>  >>

>

>  >> - Stewart

>

>  >>

>

>  >>

>

>  >> Notice: This e-mail together with any attachments may contain

>

>  >> information of Ribbon Communications Inc. and its Affiliates that

> is

>

>  >> confidential and/or proprietary for the sole use of the intended

>

>  >> recipient. Any review, disclosure, reliance or distribution by

> others

>

>  >> or forwarding without express permission is strictly prohibited.

> If

>

>  >> you are not the intended recipient, please notify the sender

>

>  >> immediately and then delete all copies, including any attachments.

>

>  >>

>

>  >>

>

>  >> Juniper Business Use Only

>

>  >>

>

>  >>

>

>  >> _______________________________________________

>

>  >> mpls mailing list

>

>  >> mpls@ietf.org<mailto:mpls@ietf.org> <mailto:mpls@ietf.org>

>

>  >>

> https://clicktime.symantec.com/32ELHVPxdZe1NeGCU5oipbG6H2?u=https%3A%<https://clicktime.symantec.com/3AgFeqrtXP4t1gnnks7D75x6H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3LbDZkybzjLKby6DAk88iUh6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F3G18FNxso3yysVeGE2oYas86H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Furldefense.com%2A2A2Fv3%2A2A2F__https%2A2A3A%2A2A2Fclicktime.symantec.com%2A2A2F32ELHVPxdZe1NeGCU5oipbG6H2%2A2A3Fu%2A2A3Dhttps%2A2A2A3A%2A2A2A25__%2A2A3BJSU%2A2A21%2A2A21NEt6yMaO-gk%2A2A21QiStnftbs7rzJ6JZRtxhV6LZks_wNvQJ-rNe5phnYEW6lEzzVD0vSHtMnORLvEs%2A2A24__%2A3BJSUlJSUlJSUlJSUlJSUlJSU%2A21%2A21NEt6yMaO-gk%2A21Uk8p6mR2CzJJFXxJuweTWC-0CDe7odXjIzcOP6yLGVqs-46um02ro1mHiE0sPVM%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU%21%21NEt6yMaO-gk%21RH_x4Yy-jTEqPMKiyMGCocKS-X0kXu_C0ArR_wJSIAgx76WXM8Mm5xSMg35ivIo%24>

> <https://clicktime.symantec.com/32ELHVPxdZe1NeGCU5oipbG6H2?u=https%3A%

> 25>

>

>  >>

> 2F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252

>

>  >> F%252Furld

>

>  >>

> efense.com%2Fv3%2F__https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2

>

>  >> F

>

>  >>

> mpls__%3B!!NEt6yMaO-gk!RVgTGVbknjgIjv3x-q8ob1JglFKOP6qKkgAcCSPbeBMMj2

>

>  >> A

>

>  >>

> nexFnPevXopeK1a6u%24&amp;data=04%7C01%7Chsong%40futurewei.com%7Ccc49d

>

>  >> e

>

>  >>

> 9585a24092e29708d931a0e327%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0

>

>  >> %

>

>  >>

> 7C637595389337881384%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQ

>

>  >> I

>

>  >>

> joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=5et4Juc3Ij

>

>  >> G

>

>  >> dfux%2FR5MsJnuTYDWL6S4pZ8uz3F6h34Q%3D&amp;reserved=0

>

>  >>

>

>  >

>

>  > --

>

>  >

>

>  > Loa Andersson                        email: loa@pi.nu<mailto:loa@pi.nu>

> <mailto:loa@pi.nu>

>

>  > Senior MPLS Expert loa.pi.nu@gmail.com<mailto:loa.pi.nu@gmail.com> <mailto:loa.pi.nu@gmail.com>

>

>  > Bronze Dragon Consulting             phone: +46 739 81 21 64

>

>  >

>

>  > Juniper Business Use Only

>

>  > _______________________________________________

>

>  > mpls mailing list

>

>  > mpls@ietf.org<mailto:mpls@ietf.org> <mailto:mpls@ietf.org>

>

>  >

> https://clicktime.symantec.com/353Ka7ifLCb9e7KAzjZ4fsf6H2?u=https%3A%2<https://clicktime.symantec.com/3Twd6qr3hcrCv35XXASuzA16H2?u=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fclicktime.symantec.com%2F3RHS3C2UW8kquG4WDQJFwvp6H2%3Fu%3Dhttps%2A3A%2A2F%2A2Furldefense.com%2A2Fv3%2A2F__https%2A3A%2A2Fclicktime.symantec.com%2A2F3R52RdsrwRGTaBhuR2Sd5Qw6H2%2A3Fu%2A3Dhttps%2A2A3A%2A2A2F%2A2A2Furldefense.com%2A2A2Fv3%2A2A2F__https%2A2A3A%2A2A2Fclicktime.symantec.com%2A2A2F353Ka7ifLCb9e7KAzjZ4fsf6H2%2A2A3Fu%2A2A3Dhttps%2A2A2A3A%2A2A2A252__%2A2A3BJSU%2A2A21%2A2A21NEt6yMaO-gk%2A2A21QiStnftbs7rzJ6JZRtxhV6LZks_wNvQJ-rNe5phnYEW6lEzzVD0vSHtMG_cybmA%2A2A24__%2A3BJSUlJSUlJSUlJSUlJSUlJSU%2A21%2A21NEt6yMaO-gk%2A21Uk8p6mR2CzJJFXxJuweTWC-0CDe7odXjIzcOP6yLGVqs-46um02ro1mH2RXrzIw%2A24__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSU%21%21NEt6yMaO-gk%21RH_x4Yy-jTEqPMKiyMGCocKS-X0kXu_C0ArR_wJSIAgx76WXM8Mm5xSMct3koic%24>

> <https://clicktime.symantec.com/353Ka7ifLCb9e7KAzjZ4fsf6H2?u=https%3A%

> 252>

>

>  >

> F%2Fnam11.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%

>

>  >

> 252Fwww.ietf.org%252Fmailman%252Flistinfo%252Fmpls%26data%3D04%257C01%

>

>  >

> 257Chsong%2540futurewei.com%257Ccc49de9585a24092e29708d931a0e327%257C0

>

>  >

> fee8ff2a3b240189c753a1d5591fedc%257C1%257C0%257C637595389337881384%257

>

>  >

> CUnknown%257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I

>

>  >

> k1haWwiLCJXVCI6Mn0%253D%257C1000%26sdata%3DXQlRpwkgODLRxcIjyMYyPMiCF2K

>

>  > DC0Y7GG4O8VGESnw%253D%26reserved%3D0

>

>  >

>

> --

>

> Loa Andersson                        email: loa@pi.nu<mailto:loa@pi.nu>

> <mailto:loa@pi.nu>

>

> Senior MPLS Expert loa.pi.nu@gmail.com<mailto:loa.pi.nu@gmail.com> <mailto:loa.pi.nu@gmail.com>

>

> Bronze Dragon Consulting             phone: +46 739 81 21 64

>

>

> Notice: This e-mail together with any attachments may contain

> information of Ribbon Communications Inc. and its Affiliates that is

> confidential and/or proprietary for the sole use of the intended

> recipient. Any review, disclosure, reliance or distribution by others

> or forwarding without express permission is strictly prohibited. If

> you are not the intended recipient, please notify the sender

> immediately and then delete all copies, including any attachments.



--



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

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.

Notice: This e-mail together with any attachments may contain information of Ribbon Communications Inc. and its Affiliates that is confidential and/or proprietary for the sole use of the intended recipient. Any review, disclosure, reliance or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and then delete all copies, including any attachments.