Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

"Rishabh Parekh (riparekh)" <riparekh@cisco.com> Fri, 05 March 2021 18:24 UTC

Return-Path: <riparekh@cisco.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A13B43A2987 for <bier@ietfa.amsl.com>; Fri, 5 Mar 2021 10:24:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.519
X-Spam-Level:
X-Spam-Status: No, score=-9.519 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=UNfA3Alw; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0RQ/PHsd
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 d1-UL3qgSCwy for <bier@ietfa.amsl.com>; Fri, 5 Mar 2021 10:24:56 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801443A2985 for <bier@ietf.org>; Fri, 5 Mar 2021 10:24:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=84312; q=dns/txt; s=iport; t=1614968696; x=1616178296; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=AQhuPXwosjLE2+AbNz6Int+zVxsF8GaB7AmR8z9RmJw=; b=UNfA3AlwIHqtSsEK62zgUE15rL697Dt0453+tEwFr6XkF8feWOTACqOs fI9VsAA3dK46v/E+I1QcrXEdZOhtHde6ugzB7BWrsHYzuNN3avZmwyQKH pWwcyurQ3o1+XSgHwGe0Sd94ejmOnox5B6m0WT2WrnIKAxxYHhxX9hoKC k=;
IronPort-PHdr: =?us-ascii?q?9a23=3A6IK/QhRLfUr98p3LMYBZGvflgNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNuJ6+9NlOfX9avnXD9I7ZWAtSUEd5pBH1?= =?us-ascii?q?8AhN4NlgMtSMiCFQXgLfHsYiB7eaYKVFJs83yhd0QAHsH4ag7Sv3St4D9UER?= =?us-ascii?q?L6ZkJ5I+3vEdvUiMK6n+m555zUZVBOgzywKbN/JRm7t0PfrM4T1IBjMa02jB?= =?us-ascii?q?DOpyhF?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAQDxdUJg/5BdJa1YCh0BAQEBCQE?= =?us-ascii?q?SAQUFAYF9BgELAYEiMFEHdlo2MQMHhDeBX4FpA4U5iFgDiiaOfYEuFIERA1Q?= =?us-ascii?q?LAQEBDQEBIw8CBAEBgxiBNQIXgWMCJTYHDgIDAQELAQEFAQEBAgEGBHGFYQ2?= =?us-ascii?q?GRAEBAQQaAwYKEwEBOA8CAQgRAQMBASEBBgMCAgIfERQDBggCBAESCBOCVoF?= =?us-ascii?q?+VwMvAQ6iXgKKJXaBMoMEAQEGgUdBgxwNC4ITAwaBOYJ2hAYBAYEMgUaDciY?= =?us-ascii?q?cgUlCgRFDgVl+PoIaQgEBAgEBgScBBwsBIxUWCYJgNIIrgVgBawY+AiEDBDs?= =?us-ascii?q?WAkY1URIJGgMBRpBfgyiHS4xZkDs5WwqCfolAjTqFToM5ilGVYpRdi0SDA5N?= =?us-ascii?q?lAgQCBAUCDgEBBoFbAzAqPXBwFTuCNQEBMlAXAg2NfSIMFoNNhRSFCQE7cwI?= =?us-ascii?q?BNQIGAQkBAQMJfI0bAYEOAQE?=
X-IronPort-AV: E=Sophos;i="5.81,225,1610409600"; d="scan'208,217";a="779699419"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Mar 2021 18:24:54 +0000
Received: from mail.cisco.com (xbe-aln-004.cisco.com [173.36.7.19]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 125IOs92015043 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 5 Mar 2021 18:24:54 GMT
Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-aln-004.cisco.com (173.36.7.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 5 Mar 2021 12:24:54 -0600
Received: from xfe-aln-004.cisco.com (173.37.135.124) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3; Fri, 5 Mar 2021 12:24:54 -0600
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.3 via Frontend Transport; Fri, 5 Mar 2021 12:24:54 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OkL3du+8TQLzJZc8Tm36rYXr20GDdG1y3OjXL5hYeiV8XRPYKccOvWFCfRpCLxPoflj64JrvdxSjiHgEpZuZrBAdBa9RBuX2aOGJW0U5yhDK/EU5ebduEgtb0ei+qn+I2P4z0q3q4lIn75IKP/5fsWAKawUBs3LQck5S8J5mLsgkxurMSOCurvk418UwKmBFVN6DBHHKjGYjaKTs9VNm2j9yzIgJpFjlEj4J6brpNk412112zagq4U/zd4xE7d90gKUGpM+66Jdbh4nMOMFxZrGRH6lNgWZQygSUU1Sw9Rg/oJZswEoIpb2R3/DJ1WJZSRb2WX0nxp1hN4du15LrHg==
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=AQhuPXwosjLE2+AbNz6Int+zVxsF8GaB7AmR8z9RmJw=; b=aN3a9lGJvTqlSTedDUtocZa/L+XkKbpHX1ocb3N2VUBme7KZKiMDaN3jghDZYlLMDynJiMt1eq9A7W0QgQE4xWIMsWBNV8W+xHVKX8nLmT9xwhJN+zlIo1nXHB9C+rV4vxMkakqCiikL64YMcJcrjzOtsfzQ8leoW2nJlZuwT4AQNF0hRDSJrMhQQYBSFlT1Lof5JbiyUApy48D9eWwnFFyoU35zJ8I13yiOarTAP9jedxk1d2k0SNe+oA2NLrfQVFrsmy5/+Zq9/pifC1/c+MaHYLFL9jkLxWDdUsNyM/z0vtOagYzwQEjOAAQiv1dUTYsaoGsc+FloXBMiEo4F2w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AQhuPXwosjLE2+AbNz6Int+zVxsF8GaB7AmR8z9RmJw=; b=0RQ/PHsdEpmRj5UPK7S+NK8Ojkh3n6HFUck7xRluWgBWreI5/uH8MyjBA6EJTKqYIICopLBNNqRFN166rCAlf9q7D62AmKmsA/uz7qKoc0XaBud5YmmnJICTZV1H8NrwULoSsFJCNZcAy/ZGER9HMUfUsJ2Rcx+8lFkx5ucSgeA=
Received: from BYAPR11MB3000.namprd11.prod.outlook.com (2603:10b6:a03:8e::21) by SJ0PR11MB4941.namprd11.prod.outlook.com (2603:10b6:a03:2d2::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17; Fri, 5 Mar 2021 18:24:53 +0000
Received: from BYAPR11MB3000.namprd11.prod.outlook.com ([fe80::ad66:4595:7f01:4a20]) by BYAPR11MB3000.namprd11.prod.outlook.com ([fe80::ad66:4595:7f01:4a20%5]) with mapi id 15.20.3912.025; Fri, 5 Mar 2021 18:24:52 +0000
From: "Rishabh Parekh (riparekh)" <riparekh@cisco.com>
To: duanfanghong <duanfanghong@huawei.com>, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "gjshep@gmail.com" <gjshep@gmail.com>, BIER WG <bier@ietf.org>, "EXT-zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>
Thread-Topic: [Bier] Call For Adoption: draft-zhang-bier-bierin6
Thread-Index: AQHXC5TKt8NALInKcUizaE35nWOSI6pv7hKAgAASLsCAAJu+AIAAcTEggAFCW4CAAEY+gIAA9DqAgABF45CAAXmvAIAAeENg
Date: Fri, 5 Mar 2021 18:24:52 +0000
Message-ID: <BYAPR11MB30007B50CD09AAD35226524ADE969@BYAPR11MB3000.namprd11.prod.outlook.com>
References: <CABFReBodz5ko0wAZ_8vKgreWMLnCE_6O_qhKS_RGUbSAowEwfQ@mail.gmail.com> <81971eb65f8848a693d9863d7e8cd6f0@huawei.com> <MN2PR05MB598120A402A23CCE9C1397F8D4999@MN2PR05MB5981.namprd05.prod.outlook.com> <399a9abe217242f585ce72e95307c789@huawei.com> <MN2PR05MB598109D5B639C2228036335BD4989@MN2PR05MB5981.namprd05.prod.outlook.com> <22dd68c9496c4214b59ff755d60f7b50@huawei.com> <MN2PR05MB598148E3D6F5184FABA9D783D4989@MN2PR05MB5981.namprd05.prod.outlook.com> <7bf39a8df86540b28d26ec4b1455d51f@huawei.com> <MN2PR05MB5981784D2E2CEE26263103A2D4979@MN2PR05MB5981.namprd05.prod.outlook.com> <24f9a7e89cf24e219edf1685b51d1974@huawei.com>
In-Reply-To: <24f9a7e89cf24e219edf1685b51d1974@huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [66.115.176.165]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 84ee940c-be9a-46c4-097e-08d8e003f865
x-ms-traffictypediagnostic: SJ0PR11MB4941:
x-microsoft-antispam-prvs: <SJ0PR11MB49410B5E83D0CCA06A525CE0DE969@SJ0PR11MB4941.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 5S/eNToVS/+yxoAwDbdg+OMQ5viaAHVlpTzdvsgpZio4J/iupmHrv11/OStWRjFMxmOqCx8ZJTmDWwnmBC2jNYpC6aWijv4dQYZOaQAGkOfKH1w4mcsa3FWfkbin1DakQ9d7Eu7xGGyreyBLSV459OvQHCJ4/A7BRd0e30MrKWPfADWvWWXnKwcSXp268LkNLrpJUb+GD7gq25EPKAQyARw9HudFmB+DMY822uvi3i8IyAS/NPq/kMbG3X1ajjFqXeIAXH8ZAWNnhnGtGI4rOeNi69aIOkG2w4FSKFqn+2X+LPl40xIPUVH3xkyQC0cH/TQWivcGEZxviGStUN0tVKEszfnBhklCdcs4J6TDFClIqwgx8NqYtkGjJgngu2/+vxL9fzoceFJKvGlNYG8uc8vzqmJtLGYEbPDNxs8Bd3mYOzyfMNxI1pqgmEAB1ME5rPZb5bK7Iv6xg+hKe+xitfEfJIyJFL8ZPmIKhyMmPIx5rbvBxhxE8hFSGDZwyN8yBj4HhCU6ispGj3oD5znf2+TwA46boaRyE/ywLBRH5JJmWMpmfKAyoq6hVi6kcCRCK4hXbI3KgPHeHYcUrLoCtFjFiTOEJxiEpZbWLFBXoC45BifXgSaN9IGaNEyqvoWFCo6GvZwVwCs6+mzhTM+fIA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB3000.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(366004)(346002)(136003)(396003)(376002)(8936002)(83380400001)(86362001)(66574015)(64756008)(8676002)(2906002)(478600001)(186003)(66556008)(53546011)(316002)(30864003)(33656002)(5660300002)(7696005)(76116006)(6506007)(66476007)(71200400001)(52536014)(66446008)(55016002)(966005)(166002)(9686003)(26005)(66946007)(110136005)(491001)(579004); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?TFFRMFJoWmF6WHZ0eE9WWWRjTkcxSGd5dDhBN3J1Wm0wUDZPL001b0VUUmVG?= =?utf-8?B?YUVkSkw1bWdKKzZ3VEluSHUwbm9rTVlwcEtpMHM0cGs0L1ZLTEZhci9GMXBv?= =?utf-8?B?K2QxRDlSOWtwdkJTdzBJeU03S29acFp2MGQ4YWp5d2ZuYkZ3Tyt4MExCdkJj?= =?utf-8?B?a1l3aUd4WXV4ZkF1VzFvc2VDVndpNUhKQnFuOFc2bkNBeFV2aFRtZGZXaytX?= =?utf-8?B?VlMxMVpKL3dDbTcrRS9BdXZ0eEFFODN3dmxyWXJPQW5xS2dDdGtqY0M1cFFY?= =?utf-8?B?UWVsR3pRUWlFSGlCU21idUQrQ0RscjJRQWorTHl3ZHdGVEZmZ2J0cjFxRDUw?= =?utf-8?B?SXRBeTcrY3NTdVpOaGdmTDFCbzI1UjI5M0p3aWRxR0NqalF2Qk9rb2FmTytr?= =?utf-8?B?Q2VmNDYveXNyVkFlRlZRMXJUb3M1T1dUUzNqVXY2WGpGWVpWZDNrdXNrRzBJ?= =?utf-8?B?NUd4SFB2S0R0NnR2VWlaMDdxNWhCbm0wYmRuNWtzS05JWE9jc0RjU2hPQWZO?= =?utf-8?B?SFpkaWFVZ3Z1NEUxU3pQMC8vT1pCVWNiMUIrcjkxd2FIMnMxRitJR3FIVm9M?= =?utf-8?B?dEZvUUZvTzRkNU5hZE9xZXUrZHVIWUU0WnFZL3FJY0w0T3llSlhiMEpKV1I5?= =?utf-8?B?cmxsTkF4U2JjNUFGbEhoRjZxblhvV0NEVmM4THBUZkFnbTlRcFB6OUhCNk9G?= =?utf-8?B?S1JKT3pjWFlzaWFOMXM3UENqSys0R2lIZFpBalc5b0NiSnM5TExRdXdvYzdn?= =?utf-8?B?Q0ZwN2Y0L3lkNGRmK3JIY3c5ODVGeEpVRllPcVl5N3NUamVBYUJZN0FzU2R2?= =?utf-8?B?TEtJOEFLd2RaZktJMGVicW82dEFuTk5Zb1RpM0p2R0lFdHI0djRRdTBoNVJT?= =?utf-8?B?b3QyTE5XV0c0Q2tXMzJPM2NWQkI1ekRkM3pGeUhSS1N0STVGMEkzM0Nhcnls?= =?utf-8?B?WkxHYm01N0pmOFpSQ2d4b2dta25ZaWh2c2Mza3dmNFQ4WlpFTzdLQ0diaGxt?= =?utf-8?B?Y0xoQmx6cFovL3ZhczZlQWNXTGpkMFFQaUI0MEpsaTlVQWVXWStUMkxsMXp4?= =?utf-8?B?dnRGK2dxVVpvWmFCRTJLekhwaGVuMjl5UlJtV1pjUDRDSkRrUzhQYi92cWFm?= =?utf-8?B?MldrY24vbCtDZWlHTGEyaFZZQ1JPSmYzaUczQWdxUTJueWJISFZZS0hRYzIz?= =?utf-8?B?a3h1bHlSSTdCSkEwYXdiakVEcWdaaUk4TFlST29pV2lKYkgvZmFxZWliQXJx?= =?utf-8?B?NzZ6WDBJR0JZMStFMHNBd2h2bFdZQ2VwQk9VeWVGd3NjdHhVY2ttTGFXM0Ux?= =?utf-8?B?bEYvc0ZsRTNpU0lJaTQzTUFJZU9wSzhxM0RUMmFWMUhNQTJwSGMrMXVkaTRy?= =?utf-8?B?My9PZk5LUVdjYzRQRFVPa1FqU0pvb1FsbDd5UVZVbC9Bbld5anV3VE9zRXc0?= =?utf-8?B?S0podUZsa0FRQVl3Rmd6bS83eWkxTmp2SitiaTRFZ3BuaXVQcGt2YkozUk5x?= =?utf-8?B?L25TOUt3SmVOc1pjd0RzaWtjeVdTanZmR3BZWXFJeVBIMHhaVjdueEtDVWdM?= =?utf-8?B?ZWFRT2lGN2hLK1dERGxURVhPNGExdk5vM3B1MklhSGh0dDdKVDhqcEJPSUZw?= =?utf-8?B?SUZDZDIxSVdieThRbDVaREMwM3c1cXF6V2FHZURFcjQrTnpaVzZxRHQ2NlpP?= =?utf-8?B?K3haZzROU0dwM2pOT0pyTU11Qml3SFg2NEVyck1kcEQvaGJuL2RIc0loaXNG?= =?utf-8?Q?bcUGwwJqjVb6VUZ896iMQw3u5qqkQdsufRK6SuV?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB30007B50CD09AAD35226524ADE969BYAPR11MB3000namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB3000.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 84ee940c-be9a-46c4-097e-08d8e003f865
X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2021 18:24:52.9160 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: nEQq3EcyBdrTKsBVVNlDe6vzVPyJvEPm7HqZSjgC99GS+RVGYvXqgXGTgOmCwxHiLgqVH0qM2BCnncFJkUaTIg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR11MB4941
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.19, xbe-aln-004.cisco.com
X-Outbound-Node: rcdn-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/5SODFC8vKlNicDM1O11xxdA6O6A>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6
X-BeenThere: bier@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bier>, <mailto:bier-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier/>
List-Post: <mailto:bier@ietf.org>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bier>, <mailto:bier-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Mar 2021 18:25:00 -0000

Fanghong,

In that SPRING thread, when considering the SID compression schemes, an evaluation metric was proposed to consider if a compression scheme is able to support a multicast address as the last segment (after uncompressing) of a segment list. My comment that encoding a multicast address in the segment list does not conform to SRv6 data plane (therefore that evaluation metric is not really valid and rather we should consider the ability to support a Replication SID as defined in draft-ietf-spring-replication-segment).

Clearly that is a totally different context (about segment list). Here in this BIER thread the “multicast” locator is used to designate a group of nodes because a single replicated packed reaches that group (of BFERs). Moreover, this locator is NOT used to make any forwarding decision – just the FUNC and possible ARG portion is used to derive the service context. IMO, I don’t think this is a violation of SRv6 data plane.

-Rishabh

From: duanfanghong <duanfanghong@huawei.com>
Sent: Friday, March 05, 2021 3:12 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>et>; gjshep@gmail.com; BIER WG <bier@ietf.org>rg>; EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Rishabh Parekh (riparekh) <riparekh@cisco.com>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Jeffrey,

Zzh4> To be exact, a multicast address with the LOC:FUNC:ARG semantics.
That’s a false use of SRv6 LOC:FUNC:ARG semantics.
Please find “FIB” and “FIB lookup” in RFC8986.
When a multicast address is used, it is no longer a “FIB lookup” and the SRv6-capability carved in a router is no longer available.

This is really outside the scope of current SRv6, and should be discussed in SPRING working group (or maybe with PIM working group jointly).

Note, besides this SRv6 misuse, there are still overhead concerns in both of the two opinions.

Thank you.

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Thursday, March 4, 2021 9:38 PM
To: duanfanghong <duanfanghong@huawei.com<mailto:duanfanghong@huawei.com>>; gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; EXT-zhang.zheng@zte.com.cn<mailto:EXT-zhang.zheng@zte.com.cn> <zhang.zheng@zte.com.cn<mailto:zhang.zheng@zte.com.cn>>; Rishabh Parekh (riparekh) <riparekh@cisco.com<mailto:riparekh@cisco.com>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh4> below.

From: duanfanghong <duanfanghong@huawei.com<mailto:duanfanghong@huawei.com>>
Sent: Thursday, March 4, 2021 3:30 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; EXT-zhang.zheng@zte.com.cn<mailto:EXT-zhang.zheng@zte.com.cn> <zhang.zheng@zte.com.cn<mailto:zhang.zheng@zte.com.cn>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

[External Email. Be cautious of content]

Hi Jeffrey,

Zzh3> If the LOC part is from the multicast address space (https://tools.ietf.org/html/rfc4291#section-2.7<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4291*section-2.7__;Iw!!NEt6yMaO-gk!XuRKefVwgXHpwRWQ8vfv5SIRfJYRqTUe3hCpEay8Bp3Y7a2hpKmVhexs-LUAcH5W$>)$>), then it is a “multicast locator”, and the FUNCT:ARG part can be used for service delimiting, just like how unicast is done for VPNs.

So I understand the “multicast locator” you are saying is using the multicast address (rfc4291 section-2.7).

Zzh4> To be exact, “multicast locator” is the LOC part of a multicast address, and the ‘LOC:FUNC:ARG’ concept is introduced in
SPRING working group have just discussed about this:
https://mailarchive.ietf.org/arch/msg/spring/QadqCj31BgJCLicfUONQEviLno8/<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/spring/QadqCj31BgJCLicfUONQEviLno8/__;!!NEt6yMaO-gk!XuRKefVwgXHpwRWQ8vfv5SIRfJYRqTUe3hCpEay8Bp3Y7a2hpKmVhexs-O6puE97$>
“If so, it really does not conform to SRv6 data plane.”

Zzh4> I am copying Rishabh, who made that comment. I am pretty sure the two are different things.

I think this is a big change and should be discussed in SPRING working group.

Zzh3> I don’t see that it needs to stacked and there is no plan to do so.

Do you also use the “multicast locator” here ?

Zzh4> To be exact, a multicast address with the LOC:FUNC:ARG semantics.

Anyway, it is a bigger change than above, with consenquences we can’t easily imagine.

I don’t think it is reasonable, far more an implementation concern I have already raised about forwarding plane or control plane.

Zzh4> Please see above.
Zzh4> Jeffrey

Thank you.


From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Thursday, March 4, 2021 3:54 AM
To: duanfanghong <duanfanghong@huawei.com<mailto:duanfanghong@huawei.com>>; gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; EXT-zhang.zheng@zte.com.cn<mailto:EXT-zhang.zheng@zte.com.cn> <zhang.zheng@zte.com.cn<mailto:zhang.zheng@zte.com.cn>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh3> below.

From: duanfanghong <duanfanghong@huawei.com<mailto:duanfanghong@huawei.com>>
Sent: Wednesday, March 3, 2021 8:45 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; EXT-zhang.zheng@zte.com.cn<mailto:EXT-zhang.zheng@zte.com.cn> <zhang.zheng@zte.com.cn<mailto:zhang.zheng@zte.com.cn>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

[External Email. Be cautious of content]

Hi Jeffrey

Overhead of encapsulation is a concern but we can talk about it later. Please see my comments  with ‘Dfh>’ below.

From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Wednesday, March 3, 2021 9:20 AM
To: duanfanghong <duanfanghong@huawei.com<mailto:duanfanghong@huawei.com>>; gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; EXT-zhang.zheng@zte.com.cn<mailto:EXT-zhang.zheng@zte.com.cn> <zhang.zheng@zte.com.cn<mailto:zhang.zheng@zte.com.cn>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh2> below.

From: duanfanghong <duanfanghong@huawei.com<mailto:duanfanghong@huawei.com>>
Sent: Tuesday, March 2, 2021 6:46 AM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; EXT-zhang.zheng@zte.com.cn<mailto:EXT-zhang.zheng@zte.com.cn> <zhang.zheng@zte.com.cn<mailto:zhang.zheng@zte.com.cn>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

[External Email. Be cautious of content]

Hi Jeffrey and Sandy,

o In option 1, do you mean that, an entire IPv6 header is added between BIER header and the customer multicast packet with a BIER Proto value 6 used?

  Consider non-BFR case like this:
  A(bfr) ---- B(nonbfr) ---- C(nonbfr) ---- D(nonbfr) ---- E(bfr)
  You need an IPv6 Header + BIER Header + IPv6 Header + customer multicast packet encapsulation ?

Zzh2> This was discussed in the last round.
Zzh2> If both IPv6 based fragmentation and tunneling are needed, then indeed two IPv6 headers are used in the cleanly layered architecture.
Zzh2> I pointed out that when IPv6 is used for everything everywhere, then you don’t get to complain about the additional overhead. For comparison, with BIERv6, you’re using the IPv6 header even between directly connected neighbors where a simple l2 header is enough; with BIERv6, if FRR is used in the network, my understanding is you’ll also have two IPv6 headers – one pushed by the BFIR and the other pushed by the PLR.
Zzh2> If one really cares about reducing the overhead, then doing fragmentation/ESP without requiring IPv6 but in a layer independent way is a better solution and that still achieves clean layering.

  Here are some further questions about the inner IPv6 header : 1) what does "multicast locator"  mean? 2) what is the source address of the inner IPv6 address?

Zzh2> A multicast locator is similar to unicast locator but the difference is that multiple nodes can receive traffic addressed to that <locator + func/arg>.
Dfh> Still don’t understand “similar to unicast locator”, and “multiple nodes can receive traffic addressed to that <locator + func/arg>”.
Is it something like “Replication SID” in <draft-ietf-pim-sr-p2mp-policy>?
Or can you please give an example of a multicast locator showing the locator and func/arg part?

Zz3> It’s different from the “replication sid”. Per RFC 8986:

   This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG,
   where a locator (LOC) is encoded in the L most significant bits of
   the SID, followed by F bits of function (FUNCT) and A bits of
   arguments (ARG).  L, the locator length, is flexible, and an operator
   is free to use the locator length of their choice.  F and A may be
   any value as long as L+F+A <= 128.  When L+F+A is less than 128, then
   the remaining bits of the SID MUST be zero.

Zzh3> If the LOC part is from the multicast address space (https://tools.ietf.org/html/rfc4291#section-2.7<https://urldefense.com/v3/__https:/tools.ietf.org/html/rfc4291*section-2.7__;Iw!!NEt6yMaO-gk!XuRKefVwgXHpwRWQ8vfv5SIRfJYRqTUe3hCpEay8Bp3Y7a2hpKmVhexs-LUAcH5W$>)$>), then it is a “multicast locator”, and the FUNCT:ARG part can be used for service delimiting, just like how unicast is done for VPNs. Obviously, we don’t need to setup multicast trees for those addresses on the transit nodes (because BIER is doing the distribution), but the BFERs have corresponding FIB entries with END.DT4/6/2M forwarding behaviors.

Zzh2> The inner address is the BFIR’s address, since it is the node that imposes that inner IPv6 header.

o In option 2, do you mean that, an IPv6 address is added between the BIER header and the customer multicast packet with a BIER Proto value TBD used?

Zzh2> Yes.

  So an IPv6 address is floating in a place outside of any IPv6 header? I don't think it's reasonable.

Zzh2> Why not? We only need the IPv6 address for service delimiting and don’t need anything else provided by a full IPv6 header. In fact, only the func/arg part is needed so a 32-bit value is practically enough; though for theoretical flexibility provided by variable length of func/arg bits, the entire IPv6 address is used.
Dfh> So I understand the “IPv6 address” is used outside of any IPv6 header, making “IPv6 address” like an MPLS Label.
Could more IPv6 addresses be directed stacked just like MPLS Label stack ?
Zzh3> I don’t see that it needs to stacked and there is no plan to do so. For example, for EVPN BUM with MPLS forwarding plane, a label stack (of two) are used to identify the bridge domain and source Ethernet Segment together, but with SRv6, they are identified with FUNC+ARG in a single SID.
Zzh3> Thanks.
Zzh3> Jeffrey

Zzh2> Jeffrey

Thank you


From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net]
Sent: Tuesday, March 2, 2021 10:32 AM
To: duanfanghong <duanfanghong@huawei.com<mailto:duanfanghong@huawei.com>>; gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>
Subject: RE: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Hi Fanghong,

Please see zzh> below.

From: BIER <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>> On Behalf Of duanfanghong
Sent: Monday, March 1, 2021 8:23 PM
To: gjshep@gmail.com<mailto:gjshep@gmail.com>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>
Subject: Re: [Bier] Call For Adoption: draft-zhang-bier-bierin6

[External Email. Be cautious of content]

Hi,

I see this document proposes 2 options for MVPN/EVPN.
One is using the destination address to carry the ID of an MVPN/EVPN, but this means that every BFR have to be aware of the MVPN/EVPN instance, introducing state of MVPN/EVPN service and forwarding overhead in transit BFR nodes.

Zzh> This is not true. In this option, IPv6 is payload and is only exposed at the BFER. We have talked this in the last round of discussion.

The other is to use an IPv6 address after a BIER header and before the customer IP packet, however it proposes a new Proto value and new process in forwarding plane.

Zzh> BIERv6, with its companion MVPN/EVPN solution, also requires new process in forwarding plane.

I think both of the options have obvious defects,

Zzh> Please see above.
Zzh> Thanks.
Zzh> Jeffrey

and thus I do not support the adoption.

Thanks !
Fanghong Duan


From: BIER [mailto:bier-bounces@ietf.org] On Behalf Of Greg Shepherd
Sent: Friday, February 26, 2021 12:37 AM
To: BIER WG <bier@ietf.org<mailto:bier@ietf.org>>
Subject: [Bier] Call For Adoption: draft-zhang-bier-bierin6

Thank you all for the active discussion that brought us to consensus. This draft now addresses all of the points of discussion for the solution.

https://datatracker.ietf.org/doc/draft-zhang-bier-bierin6/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-zhang-bier-bierin6/__;!!NEt6yMaO-gk!Wz3exwJN85TEXwRgTI9gEwvjszwONVImICqBRh9GKk0mHtpLuzDK9Nf4DnO7hYbt$>

Please reply to this thread with your support/opposition of WG adoption of the draft.

Thanks,
Shep
(Chairs)


Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only


Juniper Business Use Only