Re: [Bier] draft-ietf-bier-ipv6-requirements-09

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Mon, 23 November 2020 01:07 UTC

Return-Path: <zzhang@juniper.net>
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 38F093A10E1; Sun, 22 Nov 2020 17:07:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Level:
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=kLxyeeek; dkim=pass (1024-bit key) header.d=juniper.net header.b=IWWn7FxA
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 6Z4aaBxXpGAZ; Sun, 22 Nov 2020 17:06:56 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 D3F2C3A10E0; Sun, 22 Nov 2020 17:06:55 -0800 (PST)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0AN10ua3015644; Sun, 22 Nov 2020 17:06:54 -0800
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=ujamxpnEmc+fGBkMSvDj8qeVk/XIb5xVo4K5i+fyHrw=; b=kLxyeeekkzx6rGtAdSTIPOnuGk80Ai23nacT2ql7f4jGldBHUAOjeUwgNum0BkJCzZhI nFbCbimbjOuhotY1cT1zYLxGquOF9URodh7iHXvsq8kObk6WKgyetbugcSIbzUqBNpom KZOE1mqGilkwub4mt1Pfjo6PZsw6Bs+XwHUI0ivziOYnWbvRorqXJW0ZS6++XYL/XtlB NVzGRPfoPUfXR6bHTqdwhz8l9HMMvnwbJgFaqvJmw0m1iBeFyGMCjtP6gJOwQ8MOa4Df 3xrgriCCkAJaHSzymlNyPV2iQNfXu4NvTz8WyH/B5fnfkHOiHiKTvjg345AF0iSywQjR UQ==
Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2176.outbound.protection.outlook.com [104.47.58.176]) by mx0b-00273201.pphosted.com with ESMTP id 34y2w2hcxm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 22 Nov 2020 17:06:53 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F/biwLOypi3dMMvUTfVUvnT10mfgzVsCxHSxkh12KfbpnSNW+KrK0YF7SYXMhtKFRR3srUWTxp8O/fJrRilqHNqV5pinC1blOMSOrNur6nVQX3LZd0DQB7bAVsecSdpUqznyBpeEG0+FNhLyccr1sZWSpcT88Fy35YQoKvxbnW4/JMPSNrN2jzKHTc/nWlhGY+MrujdZePUxI6PhNo4P36ylbVeMpBxKPYNARM7/OMGuYrZgWKlI9C+7ECbMqNawiiu6TYDINw340qQQL1k84jxIZyrzEWTw3sYdkVLgMkzhzX0XrDS094WnKfMWB+r9+1bidzHHS5e5O3HbD4MRrA==
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=ujamxpnEmc+fGBkMSvDj8qeVk/XIb5xVo4K5i+fyHrw=; b=SvmQqJ2I/W1bFNjXUvc9BJwYxrtYakteGZVjYtYw6URLwMKRzITRGXP0ynuQqdC67Y0oFGePTFYgPNe+8JPzhJmhDU3dUGg9dtYvoA3/UhVmyvJYbl4nBq/EpBw5flZ5xtNGMzKpxD1xvzv+yrinVUEY4ke8j4Ol5JhZCJMXtj5o7ntbeHjhBGC853BlaO7MVvUDyinlQWGNoZBqxVmjq9FWu0LWA0/ccKlNUfitTem0jx+t0BgdHxZRNzR3aMhki3yYC7iIF0OiOPz+b3Pm4+G9YTibaIfN+gs8cVfE83bXLt1QtCywAzucH/jpXGmL9n9b13x8jTol0MPKPg8Bqg==
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=ujamxpnEmc+fGBkMSvDj8qeVk/XIb5xVo4K5i+fyHrw=; b=IWWn7FxAum/wzA8yDC52+H+ajQJZu1o+v4AmSfIWbdd4eiRcbJgmZYLGHhjYskFHdF3EUIgX5q4U0u3wRMsa4qvnv25xt2nRkdsQNsUmRhIcZ7Yn4tmVYMZcpVRiJ3STM7OFkcGXle/wP73MXFnOR6PZx1E+qoJrYaYGRku0uIU=
Received: from MN2PR05MB5981.namprd05.prod.outlook.com (2603:10b6:208:c3::15) by MN2PR05MB6494.namprd05.prod.outlook.com (2603:10b6:208:d9::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.14; Mon, 23 Nov 2020 01:06:45 +0000
Received: from MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::2cd5:f786:c003:42c6]) by MN2PR05MB5981.namprd05.prod.outlook.com ([fe80::2cd5:f786:c003:42c6%7]) with mapi id 15.20.3589.021; Mon, 23 Nov 2020 01:06:45 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: Gyan Mishra <hayabusagsm@gmail.com>
CC: Alvaro Retana <aretana.ietf@gmail.com>, BIER WG <bier@ietf.org>, "EXT-zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>, Tony Przygienda <tonysietf@gmail.com>, draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org>, "gjshep@gmail.com" <gjshep@gmail.com>
Thread-Topic: draft-ietf-bier-ipv6-requirements-09
Thread-Index: AQHWvb2JExcoEqV7rUqj331ceyYvFKnPtYOAgAG+jICAAXl8gIAAeTEAgADDhlCAAFMHgIAAEEPggAAhIgCAADmO8A==
Date: Mon, 23 Nov 2020 01:06:45 +0000
Message-ID: <MN2PR05MB5981AEC2E508A34919BBCE6AD4FC0@MN2PR05MB5981.namprd05.prod.outlook.com>
References: <CABNhwV0aZRqXP2wAweEktsibTYpHqHhDB9OTPkO+1JmyOb7-gA@mail.gmail.com> <CABFReBoFMZwcPrROMB=RbE60TsP4uajUERbE7MVTQD9AjwJ4ag@mail.gmail.com> <CABNhwV3zOqmSetuB92M=8pFFgGmEyq3KvVWat87WfDoBH4j3bg@mail.gmail.com> <MN2PR05MB598132918AFF529C955B15D3D4FE0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV2KOCHCAnFG0P-9V9g4rsz4e=aZ1WEcNSR6bTLW9OCO_A@mail.gmail.com> <MN2PR05MB5981922D4BDC641F5CF3CD20D4FD0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV1NXz8NrEvP3GYLz2PKkGNOU__D7XOOZ6_tbM03xPcNSg@mail.gmail.com> <MN2PR05MB5981824AF7424761E656D36ED4FD0@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV2nzBK7YDqBHrAt_3zAZiA7VDJmw-R=wOqTet6QS=Rg0g@mail.gmail.com>
In-Reply-To: <CABNhwV2nzBK7YDqBHrAt_3zAZiA7VDJmw-R=wOqTet6QS=Rg0g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.5.0.60
dlp-reaction: no-action
msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=6f02ed89-f654-41a9-a910-3c2bd9a02cd8; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; 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_SetDate=2020-11-23T00:44:56Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [71.248.165.31]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 2b85d113-bac5-4206-01dd-08d88f4c0be6
x-ms-traffictypediagnostic: MN2PR05MB6494:
x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr
x-microsoft-antispam-prvs: <MN2PR05MB64946A0378E94ED686B4101ED4FC0@MN2PR05MB6494.namprd05.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: NqnutePPIxTmNcSslof13k5pS+r0awUf4MwSYFxq5LyEVSFjg9e+I8uqUScP7rscXHnJunbYzsnwSDCNSAft5iIXe02VldflWltksFfYjJakdQxSY2UiM7Ia9Evbj5BdyB4LeKKph8LuxcCs8nwg5FfJeNb4iVc3trlmwWcjI8Xv9yNRV7zchonEhTW3IAghewz46XdwLZF1zMJiRQRdyp1o0dMb37m9GFK07l6SrQBVENjeOMYfjedk9e8S17D2zNTUb7YPBcAFExJ656AZODqikDuOpFUpd38kg7BSOFDFT8fIy20L6AaXAinlVuRUAMYLKrISD4LLy9jB45bCyY/qZtcBdhdXIrFPT/1J37C/Ms9MoglUvoh/OPGBGcqu0EYTaknR0+xfYY6G8NTCnA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB5981.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(396003)(376002)(136003)(346002)(39860400002)(166002)(83380400001)(2906002)(9686003)(71200400001)(33656002)(55016002)(26005)(86362001)(30864003)(66574015)(53546011)(9326002)(186003)(6506007)(8936002)(966005)(5660300002)(52536014)(6916009)(66946007)(54906003)(66556008)(64756008)(316002)(7696005)(66446008)(76116006)(4326008)(8676002)(66576008)(478600001)(66476007)(99936003)(579004)(559001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: pFBpsoV9F4u6cVnq2pmGH52Ca5xjb9YlWKmqn9ZvQLJMzgrS8e+JV+EEqsFSkELPwFPVoLIoYrDkvI+rZTJTl5lCsW0tGf1PK7YDxhA+7d4GaBmmdHmWrhSsHbtGhZ27ZzuVMO55Vdfi31flkF1QWlnKJKWaspoTBo4eG10B/5xX8RdF2izWQ1A/T96gKL3utmQD1IYwmvG21ohKHuSkK4nlDKutSEkTsJSCqkTCyE9VnFiff8aDdsm1Jh78SboPY4MzbK7lSDWBNCbCRAgR6IG19ZD9C1pmdgpZktq2KXfXylGsaOHUPue3xg4L4bKkwBBiVmvgnjrR+D87NbdQOcZdSj8p098RDvE4bE4F0mAIMUZM18Kc+1CWXbSW8HHB4begL0BpqJbTQvO4ZjPEq88vGkahR33imGVwHESvEdsp5HP7Hx+AFEb1NFIF6npvAUt9KWethU1QVhfkU+SVmqW7sZN5ksTllGeuKltDzgoxZclQGzZT1yeVJXgvmic68RiLHJUUgp4CgryjeAlEvtilQEOUMaC5ykkvmoW5dP14FpKNIWOekltKHTbQlyayHgMvOe4Li+l/lBXCf/seUGqWNGg5X6EyAIsEDzBQQoC09sKAXSijIF+BxivIlcpHBvsdTkdD+woT+HDjGjZa5ZKolDRBNlSdkNrmFsJPQovLALKk+k4y2qsOApEG0/+C36NycbN7Mz7A51NvbheBdEe82sQYx42S9F/JHItbi/uotuV5/hspdKO3gKNFZcCql7lkj97/lSiJFwo58+7FfS2xMNJ+HuoYiMSrBsuZfJcgmxYu/bcudqNqprcwcdaT9iN0s9cz/C/BEWkp+cP2wsKP6VtS53ixaQMWLNdjWiX71h26CvhNws8ET15JujUcWJSyn3HPEVsmOCEiL0P4Gw==
x-ms-exchange-transport-forked: True
Content-Type: multipart/related; boundary="_005_MN2PR05MB5981AEC2E508A34919BBCE6AD4FC0MN2PR05MB5981namp_"; type="multipart/alternative"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB5981.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2b85d113-bac5-4206-01dd-08d88f4c0be6
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 01:06:45.1165 (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: wUo49OxPLhT7RbXa8jB75fdvWl/1NBq6lLdIcmUE9uxgIvyuD8wfHGqSzkRqXnttdgDPLvydjpPWgGCjwrAHUg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6494
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-22_16:2020-11-20, 2020-11-22 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 lowpriorityscore=0 suspectscore=0 clxscore=1015 malwarescore=0 spamscore=0 phishscore=0 mlxlogscore=999 adultscore=0 impostorscore=0 bulkscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2011230003
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/BTD7IQgOPLkkKwhUX5kklr3Ow8U>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09
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: Mon, 23 Nov 2020 01:07:03 -0000

Hi Gyan,

Yes I believe we’ve reached consensus.

Please see zzh5> below about some details.

From: Gyan Mishra <hayabusagsm@gmail.com>
Sent: Sunday, November 22, 2020 4:19 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>
Cc: Alvaro Retana <aretana.ietf@gmail.com>om>; BIER WG <bier@ietf.org>rg>; EXT-zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>cn>; Tony Przygienda <tonysietf@gmail.com>om>; draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org>rg>; gjshep@gmail.com
Subject: Re: draft-ietf-bier-ipv6-requirements-09

[External Email. Be cautious of content]

Hi Jeffrey

This has been a very informative exchange and extremely helpful for all of us to get onto the same page from a basic understanding POV.

Much appreciated all your help and feedback helping clarify my confusion.

I am answering in-line but now connecting the dots how is in today’s RFC 8296 Non MPLS BIER Ethernet going to transport IPv6?

From your answers below it cannot work as we need two IANA code point one for IPv6 next header type and ICMPv6.

Zzh5> The existing model/concept works except that we need to two code points if IPv6 tunneling is used for either getting over non-BFRs or for FRR. One may deem non-BFR as a short-term scenario but FRR will be here for the long run.

And it is for this reason BIERin6 even with optional IPv6 encapsulation removed, does in fact even for L2, BIERin6 introduces something new being the two code points for IPV6 environment and thus must be standards track.

Zzh5> “even for L2” is not exactly right. It is when IPv6 tunneling is needed (for non-BFR or for FRR – and that is different from the optional IPv6 encapsulation between directly connected BFRs) where the two new code points are needed.

Do you agree with my overall assessment?

Zzh5> Yes but minus the above minor detail. More zzh5> below.


In-line Gyan3>

On Sun, Nov 22, 2020 at 3:12 PM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> wrote:
Hi Gyan,

So now the focal question about BIERin6 is should it be an informational document (if the optional IPv6 encapsulation between directly connected BFRs is removed).

The short answer is no. Please see zzh4> below.

From: Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>
Sent: Sunday, November 22, 2020 1:22 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Cc: Alvaro Retana <aretana.ietf@gmail.com<mailto:aretana.ietf@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>>; Tony Przygienda <tonysietf@gmail.com<mailto:tonysietf@gmail.com>>; draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org<mailto:draft-ietf-bier-ipv6-requirements@ietf.org>>; gjshep@gmail.com<mailto:gjshep@gmail.com>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

[External Email. Be cautious of content]

Hi Jeffrey

Please see in-line below

On Sun, Nov 22, 2020 at 8:56 AM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> wrote:
Hi Gyan,

Please see zzh3> below.

From: Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>
Sent: Saturday, November 21, 2020 8:45 PM
To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Cc: Alvaro Retana <aretana.ietf@gmail.com<mailto:aretana.ietf@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>>; Tony Przygienda <tonysietf@gmail.com<mailto:tonysietf@gmail.com>>; draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org<mailto:draft-ietf-bier-ipv6-requirements@ietf.org>>; gjshep@gmail.com<mailto:gjshep@gmail.com>
Subject: Re: draft-ietf-bier-ipv6-requirements-09

[External Email. Be cautious of content]



On Sat, Nov 21, 2020 at 1:45 PM Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>> wrote:
About the following:


I would not think we are ready to adopt any non MPLS BIER in IPV6 environment solution if we still do not have the requirements set as to the gap that is being filed and problem being solved that cannot be done today with non MPLS BIER Ethernet.

GS - Agree.

    Gyan> Agreed.  So to reiterate once we complete the requirements draft and then if both fit the Bill of the requirements draft, we can ask for Adoption of both drafts at once.


Now it’s clear what the chair was requesting for the requirements draft. Quote from Greg’s reply to the other email:
Gyan>Agreed
Zzh2> The real questions are: 1) why do we need IPv6 encapsulation (BFIR->BFER or between adjacent BFRs) 2) Even if you do, where do you put the BIER header. 1) is a requirement question, and 2) is a solution question.
GS - ^^^This. Thanks Jeffrey.
 …
     Gyan> Given what Greg and Tony stated as far as the requirements draft as what is missing related to the “why” we need any IPv6 environment solution I think “any” means any which include BIERin6.  We may need some clarification from the chairs on this.
 Zzh2> My understanding is the question is “why we need IPv6 encapsulation” (especially BFIR->BFER). BIERin6 does not
require BFIR->BFER encapsulation, but it works nicely with that.
GS - ^^^And this. As I said before, the WG had NO issues with BIERin6. The reqs draft came about as a means to document the WGs direction in this space in the light of BIERv6.


So the requirements draft will discuss why IPv6 encapsulation is needed. As I mentioned in my previous email, even if there is a requirement for IPv6 encapsulation, BIERin6 works nicely with it, and works better with a clean layering architecture.
 Gyan>Understood.  As I stated explicitly in the response to Greg above.  What are your thoughts on what I stated that BIERin6 solution- if you remove the L2 links concept as that is Non MPLS BIER Ethernet RFC 8296 (BIERin6 L2) which already exists today and would be used for Green field IPv6 environments, so imagine then the BIERin6 solution without the L2 do you agree that this solution as well as BIERv6 solutions in an IPV6 environment is strictly only for transitional brown field deployments to tunnel unicast over “non BFR capable” routers?
Zzh3> Having trouble zooming in on exactly you’re saying, but let me clarify that *BIERin6* works for *all* situations – and it is a *long term* solution:

   Gyan2>Understand and agreed long term and everything stated below all situations, however you are missing my critical point that BIERin6 includes an “existing solution of RFC 8296 Non MPLS BIER Ethernet 0xAB37”.  So that already exists and to my original point and question from Greg why do we need IPV6 encapsulation if we already have a solution for BIER over L2 links which is RFC 8296 Non MPLS BIER Ethernet 0xAB37. Because BIERin6 used an existing solution is makes NOT a new solution for IPV6 environments.  We end up in the circular argument.

Zzh4> Now I understand what you’re talking about.
   Gyan3> Glad we are in sync!

Zzh4> Greg’s question “why do we need IPv6 encapsulation” is really for the BIERv6 solution, in particular for the BFIR->BFER case. Obviously, when tunneling is needed (e.g. to get around non-BFRs, or for FRR), IPv6 encapsulation is needed as long as the tunnel is IPv6 (w/o using GRE/UDP/similar), for both BIERin6 and BIERv6.
 Gyan> Agreed.  That is why I was thinking temporary but I think having in operators toolbox of options is extremely helpful even in future where all hardware is upgraded BFR capable their maybe a need to use IPV6 encapsulation and not L2.  So I am in agreement we can definitely define reasons for why we need IPV6 encapsulation for future end state and not just interim transitional solution.
Zzh4> BIERin6 *optionally* uses IPv6 encapsulation even between directly connected BFRs. The draft itself already explains the scenario:

   The IPv6 encapsulation could be used even between two directly
   connected BFRs in the following two cases:

   o  An operator mandates all traffic to be carried in IPv6.

   o  A BFR does not have BIER support in its "fast forwarding path" and
      relies on "slow/software forwarding path", e.g. in environments
      like [RFC7368] where high throughput multicast forwarding
      performance is not critical.

    Gyan> Good point.  So not only non directly connected “non BFRs” but directly connected “non BFRs” but important point that operator mandates traffic carried in IPv6.  That justification could definitely answer at least one of the “why” reasons for IPV6 encapsulation as we build the list.
Zzh4> Notice that the above is really no different from the case where tunneling is used between non-directly connected BFRs.

   Gyan3> Good point Agreed

Zzh5> Notice that for the requirements draft, when you talk about IPv6 encapsulation, there is a need to distinguish between BFIR->BFER multi-hop IPv6 encapsulation (as currently used in BIERv6) and hop-by-hop encapsulation. We can discuss that separately.
Zzh4> If the WG pushes back the above optional feature in BIERin6 until it’s been formally concluded in the requirements draft, while I think it is a bit unreasonable, we can remove the above for now and so that we can focus on the main point – existing solution can be used as is for IPv6.
 Gyan> This thread is really helpful in getting both of is completely and fully synced up.  And as we get synced up I don’t think we want to remove the optimal feature.  Let’s wait for this thread to play out but so far I am thinking we keep optional in place.
Let’s try it another way to help explain what I am trying to convey.

Questions below.

Can BIERin6 work today in IPv6 environment?

Zzh4> Yes.

How would it work?

Zzh4> The draft already said it:
Zzh4> 1. BIER header follows L2 header between directly connected BFRs; optionally a one-hop IPv6 tunnel can be used, and then the BIER header follows the IPv6 header which follows the L2 header
Zzh4> 2. BIER header follows a tunnel header if tunneling is used (either IPv6 or some other tunnel)

Does that solution already exist?

Zzh4> Yes

What is that solution?

Zzh4> Existing non-MPLS BIER solution, but we do need two new code points for IPv6 environment.

Can that solution be used for Greenfield deployments today?

Zzh4> Yes

Can that solution be used for Greenfield deployments in an IPV6 environment?

Zzh4> Yes

In the future once the BIERin6 optional feature using IPV6 encapsulation is developed would that ever be utilized once all routers are BFR capable?

Zzh4> It could be – up to the operator and depending on the deployment situation.

Here is the crux of the questioning.

What is the difference between BIERin6 L2 solution and RFC 8296 Non MPLS BIER Ethernet encapsulation 0xAB37?

Zzh4> No difference, except that similar to Ethertype 0xAB37 we need an IP “next header” type assigned when IPv6 tunneling is needed; and we need another code point for ICMP6 (see IANA consideration section of BIERin6).

Are they both one and the same?

Zzh4> See above.

If you removed the IPv6 encapsulation optional feature from  BIERin6, what are you left with?

Zzh4> Existing solution, which is the beauty of BIERin6. Also please note that the optional feature is applying the typically multi-hop tunneling to one-hop tunneling; BIER on top of IPv6 tunneling is not special.
 Gyan3> Understood.  Similar proven layering techniques
Is what you are left with basically the existing solution defined in RFC 8296 Non MPLS BIER Ethernet 0xAB37?

Zzh4> Yes

If that is true then what is the purpose or benefit or need for BIERin6 draft if we already have that L2 encapsulation solution defined in RFC 8296 as “Non MPLS BIER Ethernet 0xAB37”?

Zzh4> To be exact, it is not “L2 encapsulation solution”. Existing solution does use both L2 encapsulation, and when necessary tunnel encapsulation.
Zzh4> First we need to assign an IP “next header” type for BIER (and an ICMP6 code point). Secondly, with the multi-year saga on BIER solution in IPv6 network, *it is clear how important for us to document how existing solution nicely work in an IPv6 network*. As Greg mentioned, BIERin6 did not move quickly because the optional feature was not considered by all as critical, but now with the confusion/contention introduced with BIERv6, it’s critical that we move quickly with BIERin6, even if we need to remove the optional feature temporarily if you demand that feature to be formally justified in the requirements draft first.

Gyan3> Agreed with everything stated. So that is the gap and the two new code point allocations is what net new that gets added in the BIERin6 draft even if the optional IPv6 encapsulation was excluded

Zzh5> To be exact, the optional IPv6 encapsulation is for between directly connected BFRs. Even when we exclude that one, If there are non-BFR or FRR situation, then IPv6 encapsulation and two new code points are needed (unless you use GRE/UDP/MPLS/other tunnels), but that IPv6 encapsulation is nothing different from any other types of tunnels.
Zzh3> 1. BIER directly over L2 links
Zzh3> 2. BIER over *any* tunnels for whatever reasons (e.g. FRR):
Zzh3>      2a. non-IPv6 tunnels
Zzh3>      2b. IPv6 based tunnels
Zzh3>             2b1. with UDP/GRE/whatever
Zzh3>             2b2. Direct IPv6 encapsulation without UDP/GRE/whatever
Zzh3>             2b3. With SRv6
Zzh3>             2b4. Without SRv6
Zzh3>             2b5. Whatever you can think of

Zzh3>  This *not* a transitional solution. It works for greenfield, brownfield, forever-field. Whatever you throw at it. A greenfield IPv6 environment still means IPv6 over L2 links and BIER can still be over L2 links directly (and it is better that way – I’ve alluded to that here and there and can discuss that separately further).
   Gyan2>Completely agree that because BIERin6 is using an existing L2 solution layering already defined in RFC 8296 Non MPLS BIER Ethernet 0xAB37 that BIERin6 draft is not introducing anything new if you exclude the IPV6 encapsulation optional feature I would agree that then BIERin6 should really be an informational draft of how BIERin6 can be used specifically in IPv6 environments using L2 links BFR to BFR.

Zzh4> It can’t be informational, for the reasons that I stated above.
   Gyan3>Agreed and understand we need the two codepoints allocated for L2 BIER to work in an IPv6 environment even if we excluded the optional IPV6 encapsulation.

Zzh5> To be exact, replace “L2 BIER” with “BIER over L2/tunnel” (which is an existing solution/model/concept), and add “between directly connected BFRs” after “optional IPv6 encapsulation”.
Zzh5> Jeffrey
Zzh3>  As stated in the requirements draft, it is an *independent* model
Gyan> Agreed using existing copyrighted technology defined in RFC 8296 so if you removed the IPV6 encapsulation optional feature we should downgrade BIERin6 to informational as it is not introducing anything new.
Or do you think that although we already have the RFC 8286 Non MPLS BIER Ethernet solution for IPV6 environments the goal is to have additional alternatives for operators for IPV6 environments that are L2 ethernet and /or other non Ethernet link layer which would be a remaining gap as to why an IPV6 encapsulation is needed.  I guess I  am somewhat answering that why question partially but let’s say a carrier packet switched network that used GMPLS / MPLS-TP but a new architecture non MPLS based that lives in an IPV6 environment- SRv6 a candidate but prove how L2 would not work and these two proposed solutions fill the gap.

Zzh3> It is a bit hard to parse what you’re saying. As I said in my previous email, whatever the additional requirements draft discussion/work lead to (whether an IPv6 encapsulation is needed), it is *irrelevant* to the BIERin6 solution, because BIERin6 is an independent model and can work *with or without* IPv6 encapsulation nicely, because it makes use of time-proved architecture of clean layering.

   Gyan2> Understood.  Yes it makes use of time proven architecture so then my question is what is the purpose of BIERin6 draft as technically it is not introducing anything new that requires it to be standards track.

Zzh4> Please see above.
Zzh3> If that discussion/work concludes that BIERv6 is warranted, it can be adopted at that time, but *there is no reason to delay the BIERin6* work.
Gyan2>I believe BIERin6 if you remove the IPv6 encapsulation optional feature then BIERin6 draft can be adopted as informational.
Zzh4> It can’t be informational for the reasons stated above.
As I stated if BIERv6 and BIERin6 are really slated to be temporary until all brown field non BFR capable routers are upgraded then we don’t need to answer the questions as this is a temporary stop gap measure.

Zzh3> I am sorry but it is *wrong* to say that BIERin6 is slated to be temporary. It is a solution that works now and for long term. If you’re specifically referring to the *optional* feature of using IPv6 encapsulation even between directly connected BFRs in the BIERin6, I want to point out that, that is a small *optional* feature that *could* be removed for now just so that we can reduce the noise level at this time so that we can focus on the fundamentals.

   Gyan2>yes please remove and make BIERin6 informational as it is not introducing anything new  and we can move to adopt as informational.

Zzh4> Please see above why it can’t be informational.
Zzh3> I am not sure if others will agree that BIERv6 was slated to be temporary either 😊

Gyan2>I am not necessarily stating that BIERv6 is optional as we have to answer the million $$ question as why IPV6 encapsulation is needed that cannot be provided today with existing L2 solution. What made be even go down that road of “temporary solution” is the question as to why BIERin6 has the L2 solution added to the solution,  almost as if the plan if you stepped back a bit and looked at the big picture was to make the IPv6 encapsulation optional or we would not have added L2 to the BIERin6 draft in the first place.

Zzh4> Please see earlier responses.
Zzh4> Thanks!
Zzh4> Jeffrey
As such, we believe BIERin6 is already ready for adoption – though we’ll put out a revision to evaluate against the requirements draft. It is not reasonable or fair to delay the adoption of this one any further until the requirements draft justifies the other solution.
 Gyan> Agreed.  Let’s have WG and chairs and AD chime in.
Zzh3> Ah ha. Good and relieved to see “agreed” wording here. Thank you 😊
Zzh3> Jeffrey
Thanks.
Jeffrey

From: Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>>
Sent: Friday, November 20, 2020 3:00 PM
To: gjshep@gmail.com<mailto:gjshep@gmail.com>
Cc: Alvaro Retana <aretana.ietf@gmail.com<mailto:aretana.ietf@gmail.com>>; BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>; Tony Przygienda <tonysietf@gmail.com<mailto:tonysietf@gmail.com>>; draft-ietf-bier-ipv6-requirements <draft-ietf-bier-ipv6-requirements@ietf.org<mailto:draft-ietf-bier-ipv6-requirements@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: draft-ietf-bier-ipv6-requirements-09

[External Email. Be cautious of content]


Hi Greg

In-line

Thank you again both you and Tony and Alvaro for all your guidance to help right the ship!!

I will by “first round” when we meet in person — some day!!👍😁- maybe even second and third - or the night is on me if we can get this behind us. 😀

Thanks
On Thu, Nov 19, 2020 at 12:22 PM Greg Shepherd <gjshep@gmail.com<mailto:gjshep@gmail.com>> wrote:
GS - inline:

On Wed, Nov 18, 2020 at 7:14 AM Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@gmail.com>> wrote:
All

I would like to thank the Greg, Tony and Alvaro on their pointers and guidance this morning to help move the ball forward with the requirements draft.

Thank you for your help.

     Gyan> Welcome

What I heard from Greg which rang out loud and clear and I mentioned to the requirements authors that today we have BIER MPLS where the BIER header is encoded into MPLS label stack layer 2 1/2 and we also have non MPLS BIER Ethernet ether type 0xAB37.

GS - No, the BIER header is NOT 'encoded' in MPLS. MPLS encapsulates the BIER packet. Yes, the outer label included BIER specific information (Set-ID) with the intent of streamlining the forwarding process but without creating a dependency. We mirrored the format for Eth encap to ensure a single header format for the BIER architecture standard. It's important to mention there that the process to get to this point involved a 3-day design-team meeting where we worked hard, transparently and together and managed to conclude with a solution which resolved any conflict, satisfied everyone's concerns, and resulted in a clean, consistent message from a Working Group that was working under the 'experimental' banner. We moved from 'experimental' to standards track by listening to all the reasons we were started out as 'experimental' in the first place - ie This is the forwarding plane and will require new HW so the work from the WG must justify a new forwarding model and produce clear standards to follow.

   Gyan> Thank you for clarification on BIER MPLS and important history on the BIER encapsulation types and how they came about and the evolution from Experimental to Standards Track.  I can see the simplicity single header format beauty behind the BIER architecture.

So why do we need non MPLS BIER encapsulation in an IPV6 environment as that IPv6 environment can be supported by non MPLS BIER Ethernet.  The case and point here is that eventually just as ATM and Frame Relay now live in the technology graveyard so will at some point in time as SRv6 matures will become the end all be all “core transport” mechanism for all operators.

GS - This is an opinion and not a technical argument. BTW, it is MY opinion that the largest early adopters for BIER will be financial networks, and more specifically financial trading floors. These networks are dedicated, high-speed, multipoint networks that will never adopt SRv6. Remember the IETF is to create standards that work best for everyone, not just to solve our individual network issues or vision.

    Gyan> Understood.

So that being said we need a another encapsulation method to carry BIER , and per RFC 8296 that gap is filled with Non MPLS BIER Ethernet encapsulation today which will work for future SRv6 transport once MPLS goes by the wayside.

GS - Just for clarity, RFC8296 works today regardless of any perceived transport wars. That's because a proper layered architecture avoids layer dependencies.

     Gyan> Understood.  The BIER encapsulations types MPLS and Non MPLS defined in RFC 8296 works well with the RFC 8279 BIER 3 layer architecture, underlay, BIER layer, overlay which are independent of each other.  Makes sense.

At the beginning of the presentation Greg corrected me and stated that that after the BIERin6 independent model draft was published, that the requirement draft came about to build a set of requirements as to the “why” we need BIER to work in a non MPLS BIER in an IPv6 environment when we already have the BIER Ethernet encapsulation that fits the bill and works.

GS - Not exactly... Let me clarify:
  BIERin6 first published in Oct 2017. I think the primary interest at the time was Homenet. The WG had no issues with the solution, but then neither had many members stepping up to help. Our AD's (and through extension the IAB) ingrained in us the need to remain diligent in the publication of our standards and only progress work that remained consistent with our existing work and showed community support. The first was true, the second was a little slight at the time.

  April 2018 - the BIER Encap (misnomer) draft was published. It was pointed out from the beginning that there is a stark difference between encap and encode and that the WG has already published standards for encode. So the question was asked, why do you need a new encoding and encap. The answer given at the time was that there was a need to address non-BIER routers in the network and that this solution would be transitional. The WG pushed back that ANY transition mechanisms MUST NOT require HW changes. We also heard things like:
"integrated into IPv6" - not true, it's merely BIER information encoded into extension headers. Operationally this is identical to BIERin6 encap, except that the former would require new HW, something our AD's made clear needs to be justified before progressing.
"fast-path" - not true.
I/We continued to ask questions trying to understand what benefits could be implied by encoding the BIER header into an IPv6 extension header rather than to just encap the BIER packet? And ultimately what is to be accomplished with any new encap now that we have RFC8296? The WG decided we needed a problem statement and requirements draft to guide any work in this space.

The reqs draft was heavily weighted by BIEREncode draft authors and showed significant effort to direct the conversation. The WG was largely silent on any support either way. Mike came to me frustrated that nobody is stepping up to help. My reply was that if the WG doesn't show interest in the work, maybe that's your answer. Since then, more authors have been added.

    Gyan> Thank you for the important clarification on history of how things transpired and how the requirements draft came about.  As well as history of BIERin6 and BIERv6.  Makes perfect sense as what triggered the requirements draft was the second solution BIERv6.

Operationally as you stated as well as from the BIER layering perspective 2 out of the 3 layers ar identical as both have underlay and overlay and thus are mirrored on the encapsulation in the layering.
As you mentioned the stark difference comes is the “BIER” layer where with BIERin6 it fits right in the middle of the inner and outer layer “encap” where with BIERv6 the additional encoding of the BIER header was the tricky part for sure.

We leveraged following verbatim the IPv6 specification RFC 8200 to encode the BIER header in the DOH extended header for en route hop by hop BIFT processing very similar to hbh header processing.

So there being the stark difference where BIERin6 was “encap” based and BIERv6 was “encap” + additional “encode” based, thus the pushback as to giving concrete reasoning for having a solution that requires the additional “encode”.  Agreed.

Our answer as you stated has been that BIERv6 solution would be a transitional solution to accommodate “Non BFR” routers and that is still the case.  As stated with the BIERv6 integrated solution , the key problem that has to be solved to make that solution viable is where to put the BIER header.

As “encap” was not an option as that would literally make BIERv6 identical to BIERin6 - thus the MAJOR challenge as to where to put the BIER header as there really is no other place other then in an extension header.  Another option that is still another viable option is picking a different header such as hbh to encode the BIER header.  We chose DOH as it had the options flag value option 3 for en route so at the time it made sense to go with DOH.  With many drafts looking at hbh for performance measurements in-situ hbh processing in the fast path, it is possible that hbh could still be a viable alternative.

One other significant difference between BIERin6 and BIERv6 is that BIERin6 is to some degree a “pseudo” IPV6 environment solution as L2 links direct Non MPLS Ethernet encapsulation can be used to transport BIER packets.  So this is HUGE has far as stark difference and major advantage of BIERin6 over BIERv6.

So with BIERin6 in an IPv6 environment, the IPv6 tunnel encapsulation and decapsulation for HBH BIFT processing only needs to be done in case of “Non BFR” routers present in “transitionary method”.


“Between two BFRs,either a L2 link can be used directly or any tunnel (IPv6 or not) can be used for BIER transport.”



    One example of this model is defined in [I-D.zhang-bier-bierin6<https://urldefense.com/v3/__https:/tools.ietf.org/html/draft-ietf-bier-ipv6-requirements-08*ref-I-D.zhang-bier-bierin6__;Iw!!NEt6yMaO-gk!S_I_ZBufoz35JgFHlOwEI9ATFUpFwT0geRI2SpVviaQmC6aLofgyRk1guGv38Vu_$>]$>],

   where the BIER header and the payload following it are L2 payload

   when feasible (e.g.  when two BFRs are directly connected) or IPv6

   payload when IPv6 transport is needed/desired (e.g. when two BFRs are

   not directly connected).  This is indicated by either a 0xAB37

   Ethertype allocated to BIER or a new IPv6 Next-Header value to be

   allocated by IANA.

This does give BIERin6 significant advantage over BIERv6 that in a IPV6 environment as BIERin6 can leverage existing RFC 8296 encapsulation non MPLS BIER Ethernet solution already in place today

So to state differently how BIERin6 is envisioned as a “pseudo” IPv6 encapsulation solution is that in Green field deployments we would only use L2 to connect BFRs via non MPLS BIER Ethernet ether type Oxab37 which then this would be case and point that you don’t need the BIERin6 solution to accomplish as that exists in RFC 8296.  Was this done on purpose- I think so as why reinvent the wheel so to speak.  Makes sense to me.

BIERin6 using IPv6 encapsulation and decapsualation technique for BIER header transport would only be used in transition where non BFRs exist to tunnel unicast over for backwards compatibility for existing old hardware.  Once all brown field Non BFR routers are upgraded in essence we are back to the original RFC 8296 non MPLS BIER Ethernet solution.

So as we don’t want to reinvent the wheel as we already have a solution for IPV6 environment, these two solutions are transitional “interim” stop gap measures bandaid if you will to get to the end state solution we already have today for IPV6 environments.

So I think it’s fair to state and please let me know if my extrapolation is way off base!

As I stated earlier that in BIERin6 solution makes this crystal clear that we already have a solution for transporting BIER packets in a Non MPLS BIER IPV6 environment using RFC 8296 non MPLS BIER Ethernet ether type 0xab37.

As the big million $$ - why do we need another solution for IPv6 environment-  the answer is and correct me if I am off base = “we don’t”

Both BIERin6 “encap” solution and BIERv6 “encap” + “encode” solution would only be used for brown field transitional sense and never was meant to be a long term - shall we say alternative solution to carry BIER packets.  Point being is we already have a solution so why reinvent the wheel.

As far as IPV6 extended header usage and processing see below:

With graconian routers of the past with extended header processing and on 6man and v6ops there have been many drafts written for best practices to not drop extended headers with fear of dos attack on the control plane but impacting legitimate customer traffic that used extended headers. Modern router processing of extension headers has advanced quite significantly over the past 20 years being able to process hbh as well as doh en route hop by hop at line rate in the forwarding plane fast path.  No new hardware.

So that’s the million $$ question we are trying to solve here with the requirements draft.

GS - Yes, but redefined as per my explanation above.

As for the IPV6 6MAN questions, I was brought on board by Mike McBride as the IPv6 SME as well as multicast SME - but point being member of 6MAN for many years so a go between liaison with 6MAN related to any questions regarding following the IPV6 specification for extension header usage per RFC 8200.  Both solutions drafts had been reviewed by myself and 6MAN and no technical issues were found regarding the solutions.

GS - Thank you.

    Gyan> Welcome

Alvaro mentioned as far as the list of requirements that they were fairly basic but maybe needed some more meat behind it such as the “support various L2 link types” but we did not specify.  In previous versions we stated L2 agnostic and then switched to various but being vague on which L2.  Alvaro also mentioned why OAM should be a requirement.  We may want to add a sentence on justification as to why we picked BIER IPv6 requirements as required versus optional.

We need to add some more meat in the introduction or maybe even a separate section as to what gap is being filled by non MPLS BIER in IPv6 environment using IPv6 encapsulation and encoding the BIER header versus Non MPLS BIER Ethernet.  Also maybe use the requirements section to see if a new requirement that maybe a gap that is not covered by non MPLS BIER Ethernet that can be covered by non MPLS BIER in an IPv6 environment.

At the end of the call when we rolled through the last two drafts and went into overtime I heard the ask for call for adoption for BIERin6 independent model.

GS - Both v6 draft presentations asked for adoption. One of them had technical arguments for doing so. The other was list of grievances.

     Gyan> Understood and duly noted

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

I would not think we are ready to adopt any non MPLS BIER in IPV6 environment solution if we still do not have the requirements set as to the gap that is being filed and problem being solved that cannot be done today with non MPLS BIER Ethernet.

GS - Agree.

    Gyan> Agreed.  So to reiterate once we complete the requirements draft and then if both fit the Bill of the requirements draft, we can ask for Adoption of both drafts at once.

The flip side of the comment above is that if we are ready to adopt and we decided we can skip answering the “why” questions, so then do we need the requirements draft at all if that’s the case as we have made the decision to go with a single solution and are closing the door on any other options.  If the latter then we hang tight on any adoption of any solution and wait till the requirements draft is completed and adopted followed by moving forward with adopting any solutions.

GS - Agree. And my suggestion for new authors on the reqs draft still stands. I'm not demanding, I'm suggesting, based on the document's history. Your presentation of the history of the draft made it clear that there has been little direction, less clarity, and potentially an excessive amount of motivation to justify one solution over the other, leaving us with the mushy reqs draft we have today. Let's get this draft right, then we will have the guidance to address any potential solutions.

    Gyan> Agreed on all points.  I will captain and right the ship and get out of muddy waters to a crystal clear draft that can provide concrete guidance on a solution.   Please see my points above on the transitional aspects of this solution and if in the end state we would use the existing RFC 8296 Non MPLS BIER Ethernet in an IPV6 environment then that provides a lot of clarity to the team as to direction.  So that million $$ question goes away in essence as we have already answered our own question due to transitional nature of this IPV6 environment solution we are developing now with these two “non end state” transitional only solutions.

Thanks,
Greg

Kind Regards

Gyan


--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!S_I_ZBufoz35JgFHlOwEI9ATFUpFwT0geRI2SpVviaQmC6aLofgyRk1guBEzUU8q$>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike <https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**BSilver*Spring,*MD?entry=gmail&source=g__;KyvCoCsrKw!!NEt6yMaO-gk!S_I_ZBufoz35JgFHlOwEI9ATFUpFwT0geRI2SpVviaQmC6aLofgyRk1guKR8EuJa$>
Silver Spring, MD<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**BSilver*Spring,*MD?entry=gmail&source=g__;KyvCoCsrKw!!NEt6yMaO-gk!S_I_ZBufoz35JgFHlOwEI9ATFUpFwT0geRI2SpVviaQmC6aLofgyRk1guKR8EuJa$>

--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!S_I_ZBufoz35JgFHlOwEI9ATFUpFwT0geRI2SpVviaQmC6aLofgyRk1guBEzUU8q$>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*0D*0A*Spring,*MD?entry=gmail&source=g__;KysrJSUrJSUrKw!!NEt6yMaO-gk!STxhGXVn_7l3akd-22ekvXgHaktg0upH7_YQ2V4lW3xymg0-tSVfW5z4OhjypH0r$>
Silver Spring, MD<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!STxhGXVn_7l3akd-22ekvXgHaktg0upH7_YQ2V4lW3xymg0-tSVfW5z4OtK_wvtD$>



Juniper Business Use Only
--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!STxhGXVn_7l3akd-22ekvXgHaktg0upH7_YQ2V4lW3xymg0-tSVfW5z4Oj4pKcqJ$>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*0D*0A*Spring,*MD?entry=gmail&source=g__;KysrJSUrJSUrKw!!NEt6yMaO-gk!U4fWui9a6AMmox_9HVOLuabWQsSUE43xFjGNG7ozUqEhzJuXaluJlznN0z_yUTbt$>
Silver Spring, MD<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!U4fWui9a6AMmox_9HVOLuabWQsSUE43xFjGNG7ozUqEhzJuXaluJlznN02rdMzHa$>



Juniper Business Use Only
--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!U4fWui9a6AMmox_9HVOLuabWQsSUE43xFjGNG7ozUqEhzJuXaluJlznN03dja8EJ$>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*0D*0A*Spring,*MD?entry=gmail&source=g__;KysrJSUrJSUrKw!!NEt6yMaO-gk!VCcJaZ8dtXUa9f6ssLdDxnziiSu3Yr8ckb108w5pho5p919JLUS76hRQuWI6UOan$>
Silver Spring, MD<https://urldefense.com/v3/__https:/www.google.com/maps/search/13101*Columbia*Pike**A0D*0A*Silver*Spring,*MD?entry=gmail&source=g__;KysrJSUrKys!!NEt6yMaO-gk!VCcJaZ8dtXUa9f6ssLdDxnziiSu3Yr8ckb108w5pho5p919JLUS76hRQuXLf1KCq$>



Juniper Business Use Only
--

[Image removed by sender.]<https://urldefense.com/v3/__http:/www.verizon.com/__;!!NEt6yMaO-gk!VCcJaZ8dtXUa9f6ssLdDxnziiSu3Yr8ckb108w5pho5p919JLUS76hRQufRfSwY9$>

Gyan Mishra

Network Solutions Architect

M 301 502-1347
13101 Columbia Pike
Silver Spring, MD



Juniper Business Use Only