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

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Thu, 26 November 2020 15:24 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 DF96B3A138C for <bier@ietfa.amsl.com>; Thu, 26 Nov 2020 07:24:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=yQrm/TjQ; dkim=pass (1024-bit key) header.d=juniper.net header.b=WiTf1r1O
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 AGRe_dLYMPb7 for <bier@ietfa.amsl.com>; Thu, 26 Nov 2020 07:24:48 -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 51BE93A138B for <bier@ietf.org>; Thu, 26 Nov 2020 07:24:48 -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 0AQFD6UH016380; Thu, 26 Nov 2020 07:24:46 -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=b8tFYh3AEwjlTsylKQSRs8x6m6fZKavUuQ9CoSnd+aY=; b=yQrm/TjQ60UID3Varqmw32tXOc3hBqCSezNFjZ+i+y65Htu+cK1MRHgPL31KPs3gPPF5 J4WHJWVJFsUwnvhKNB2EhhTx3nMhfjww/X3khNobaeFtn/hdjONEankg57kOvWCW98Hn Es1GQ48R+XFX7HyY2rBLRZlZC0QAGB0CBEz9Fbs2xx88Fidr8l7EDW9OiW0nsF6qY4wh uuVWsXh3au142Z+zYcsOPSbeZf4tc4l6D+ynq2a1C9jkKofqs1zkJ1KCJ+zJuC8Nunyl 424AN3AWL+hOY/1PYfKDEfyucLB0oWQPbMa71M3YXR/T2fzHDr6fLUUTLOExH3Xgg/uP hw==
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp2054.outbound.protection.outlook.com [104.47.38.54]) by mx0b-00273201.pphosted.com with ESMTP id 34y2w2s65b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Nov 2020 07:24:46 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iqcAZHMXtjvXC+hYWvt7TJluPvOBpQNq0muU13xIepPYXXkZ9jv7rxUdKRm2CvJ9CBTkKgR8htcDySqoE2AaUNp1Zj7l1aldCoOBhI/FBb2wpmwdjD6uf7n3idjNnS7+r+SCbOQZ4HGswkIFind9OaylBXoBDrfRzrAK7H5CnInh7pYkgWUYJ8Hy08Rp1Fo6gpUKDsWhnfzGXzmPju2HbUpOhQb/yXgH0FuSVf5/YclyA8TP3vWx/K5BsHHJbP/jd6Qlw4lBkqlsQXxhezrNtHsI3bSHEnn/yIcWVptAEErzLoFbgqcks+MkUkRN1GfJkWRn43TR3Ot+ERyguiKt2w==
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=b8tFYh3AEwjlTsylKQSRs8x6m6fZKavUuQ9CoSnd+aY=; b=FldN+eRWEm1OShHpM9n5TOJe5bpQtdkhgckx+YnZTEp1E+xKkuqocUGDAW3rH0tDLGjGedlBuqNWgRG20nqZ0bh6f/cvkJyknFyLdgZp3IayD7hClroN0eN/CDSd4/k6lFJxdRT5HFdGZjxNNtUpEGvkRNgomTGCAKG/cGBmIXddeHbNWK/NOkAiAAP2meTpz9QY9JWP7QzW9jflNIwDvpu4323qZJNUVxEjBdD7L6kEospnzjtTyg7vBQNiWolEMa1HIcPGul3VbP7Hq3kmr9D39waJJTtcIANGuO5SVtKvHI30DV9R0r0i6od2pZDH5gllpbajkLm6FUQ2sYuj8A==
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=b8tFYh3AEwjlTsylKQSRs8x6m6fZKavUuQ9CoSnd+aY=; b=WiTf1r1OUYHp6IR56NmYNmwprqqyrj8s5XxtCj6UpkPlg4/+jthN2O+TYDNhldjznk5d4/gVjkxHr+OyW6tYJFA0fdCnanCeeCYJ3hG5foTgTNbc86WAKu+Hfq4yb09nA5sdBYc3XOQnOCuCjbzFFofI+asD2gktn/2p4MFXjFA=
Received: from MN2PR05MB5981.namprd05.prod.outlook.com (2603:10b6:208:c3::15) by MN2PR05MB6590.namprd05.prod.outlook.com (2603:10b6:208:e0::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.9; Thu, 26 Nov 2020 15:24:44 +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; Thu, 26 Nov 2020 15:24:44 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, 'Tony Przygienda' <tonysietf@gmail.com>, 'Greg Shepherd' <gjshep@gmail.com>
CC: 'BIER WG' <bier@ietf.org>
Thread-Topic: [Bier] draft-ietf-bier-ipv6-requirements-09
Thread-Index: AQHWvb2JExcoEqV7rUqj331ceyYvFKnOBeRggABwJQCAAL5B0IAAhhQAgADIHQCACe1ZAIAAInhw
Date: Thu, 26 Nov 2020 15:24:43 +0000
Message-ID: <MN2PR05MB59815B822B853C19A60251DED4F90@MN2PR05MB5981.namprd05.prod.outlook.com>
References: <CABNhwV0aZRqXP2wAweEktsibTYpHqHhDB9OTPkO+1JmyOb7-gA@mail.gmail.com> <MN2PR05MB5981CEBAA6AB7329350293EED4E10@MN2PR05MB5981.namprd05.prod.outlook.com> <CABNhwV26CqDs8vwT=mcPQMVGVTFLVEOgVYtaYZyuyNiBFMYGcw@mail.gmail.com> <MN2PR05MB5981CB5AB50C0641A54DDCDAD4E00@MN2PR05MB5981.namprd05.prod.outlook.com> <CABFReBqJ5HVUBzbNv-LjYsCqjdvtNvXtdOjCscGftkBrVtbEmA@mail.gmail.com> <CA+wi2hMTxELaf6MQv2ocdp7nxeOusW_dv6hUZ6O2uRZa=ob6Qg@mail.gmail.com> <02fd01d6c3f5$a8f23de0$fad6b9a0$@olddog.co.uk>
In-Reply-To: <02fd01d6c3f5$a8f23de0$fad6b9a0$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
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=35d016e3-1fba-498e-bfc6-7b9bdcfdafd2; 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-26T15:14:53Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4;
authentication-results: olddog.co.uk; dkim=none (message not signed) header.d=none;olddog.co.uk; 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: 065f89f7-ae37-40e2-da96-08d8921f66e0
x-ms-traffictypediagnostic: MN2PR05MB6590:
x-microsoft-antispam-prvs: <MN2PR05MB6590707FDDED7196DE6C0C2DD4F90@MN2PR05MB6590.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VtWJfDs/In+M7jXnG0VjjLhNyNe7Vw3lU6ZGtHaORhPnFhY4Ns6rG+n8eVbwmAXU6GEdeTI8IYlkqOCc+x3mEtcisDjj9Kxs1q0MfrxY36S0wyv+Aga7F+40XNpuoxExEW8YWWbduGK/NFTIsxFSr6ZGlxY7lAYh+6br/cakccvG1gely+uLhN5uii+NEyyPlYnn0GmriugQBcd7JIjrDSgrlRlpExOC6uvS5r4GH6Ya6Bh8ZUrdRdvxBuAG+60h5y1ctyYUIigGELo0V7JSClUs0fnihEnB1/1U9dCEQdGZP6SJN1G49P7iL3VB+kt1DHxKjQ/pbD6HF5xMlw9J6A==
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)(136003)(39860400002)(376002)(396003)(346002)(6506007)(7696005)(86362001)(8936002)(83380400001)(110136005)(66574015)(71200400001)(316002)(76116006)(55016002)(9326002)(66446008)(33656002)(9686003)(66476007)(2906002)(186003)(5660300002)(26005)(478600001)(64756008)(53546011)(4326008)(66556008)(66946007)(52536014)(8676002); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?QnVJczkzWjlYR0dGYjUxSHJyWkQzQjVyQWNrTFBxVldySXl5dERFekp2ZDM5?= =?utf-8?B?OGovblNxSzVsMzdISHg4RnZKcEdza0lDN3o5Y1QyWEpoTmdiUWJDdnBkOHox?= =?utf-8?B?Tkd0R0NPeCtReWNCaUdMaDNXdWZSUDVpVm5EdTRVanpLREVFRUZUWGp0a1Fk?= =?utf-8?B?M1liVkdSOVZXRXJzV0tWWGhWcHlhTmRJVWJ1NmRMUDZWQ3I0UDg3K0RnNXh0?= =?utf-8?B?ZE1iRlhzSW1lREdmcVZNUnFUZGQ5aFQ1K21KMVVqRi94M1lWOStOWTYxck5P?= =?utf-8?B?NmJKak04UGxyZFcyaXp5NjBCSVFkTE9kSkFINUhycmw0T1MrMWRMeDlqbUhj?= =?utf-8?B?bUlDM0xOdUVrZDJwR3pPem9RaDhpcVBSbWJVTGtqZzZTTEdZM3V3TURMa3kz?= =?utf-8?B?MW4vRi9jcE5oL2ljYk9DaVFiNFN2RFJ2TGFjZjgrTEZrUlRyMnJsUEwxcjRS?= =?utf-8?B?TGZrV0dEcTBTQUlOWGdLWHBrTFJkODdXODBtNTJsQnRYVjdmbnIralM0cURx?= =?utf-8?B?elhxOFNKTk8yaHhkak5rNGtCTkk2RUFZTXdJWjZVSDBIajd4YlQ1ZmdwYWp4?= =?utf-8?B?Q1M4QzhUSDhzVC9teUxhNUZrUWFMb21XUkRKdU9RQm02QjM5cGgvSkpwKytR?= =?utf-8?B?WlJacXZiTzlLRUgrZThob0NKUmJuY21WMDUvRE9VZ2toSDZFVjNBMVVialNK?= =?utf-8?B?T0pLUXViTUYxRytjckM2dTIxWkpQRXQ4ZkRxV24zckw1dDVIVlBPS01MbTdB?= =?utf-8?B?NDFmdWpBcTBsQ014czJDRk4yWHFOMjdXVDBUQWtRK3hnNmtDNVF2SGEvcDJS?= =?utf-8?B?RHh3Ym1VaGJURTk4SVVMeWFxMzZ0UkhHVWJnMlJhTjJzTEwzNFVjZ25rU2hi?= =?utf-8?B?NmNWWDN6YnR4aEpKcHZrY2JuMFM5c3gzMVBqNnE2TjEzSDVKYTdSeWxYM09H?= =?utf-8?B?eHc1M0oyMCtHbWQ5UW1JRlVVM2NTNkxZQzhYS3VoMHBkdngzU1RwVVNLc1VK?= =?utf-8?B?QStJWkZ5SzdVQlEyT3JrZWlrZ3gvWXo5ZVY3SGV3QTBwcmcxL1pPVkk3M1ZI?= =?utf-8?B?SDZoWWllZnBSU3JEanJqc1dlNG1FOE9EQWY5b2RNbUx5VmE5WTQ5cU1XS2Jo?= =?utf-8?B?TVdFQ3M5UCtiVEFiYjEraUszMEt4VnY3QzBUc0tPS2VCdHVMYmk0akx2K1J6?= =?utf-8?B?L24xOHBsbml3RnBpYkVrdjVqN0pvVGpHUGNTSWdIWDZGR01PSkE5cXdFQS85?= =?utf-8?B?YXpleFF5QmM2UnlRWUcwNVJOalJrQS9yNWFoc3dudXRYMFh2ZHl0Y204eFlv?= =?utf-8?Q?DUNC1MjnCjEtg=3D?=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR05MB59815B822B853C19A60251DED4F90MN2PR05MB5981namp_"
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: 065f89f7-ae37-40e2-da96-08d8921f66e0
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2020 15:24:43.9259 (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: QEDbpF5RxYoEcA4X7wjM48vv/DBPaxcc4TxF/1l90NcqldKnlYZAog6lHA5Y3rmZK6Pe57kd8VOa84tG79i/HQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6590
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-11-26_06:2020-11-26, 2020-11-26 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 lowpriorityscore=0 suspectscore=0 clxscore=1011 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-2011260093
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/gXr8uxHs4baz2Viat6Epn9cqC6E>
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: Thu, 26 Nov 2020 15:24:51 -0000

Hi Adrian,

Looks like I don’t have a life – making arguments for this life and death situation on Thanksgiving day 😊

Anyway, about the ECMP topic, not sure if the following addresses your questions/comments.

At BIER layer itself, BIER packet has an entry field used for hashing to decide which ECMP path to the next BFR it will take. This is used by any BFR.

If BFR1 determines that for to reach BFR2 it is going to use tunnel1 (vs. tunnel2 or another L2 link), and tunnel1 is an IPv6 tunnel, then with BIERin6 an IPv6 header is put on by BFR1, with the BIER header following the IPv6 header, and the BIER header’s entropy field copied into IPv6 header’s flow label field. That flow label field is then used by the routers along the tunnel to do ECMP.

Jeffrey

From: BIER <bier-bounces@ietf.org> On Behalf Of Adrian Farrel
Sent: Thursday, November 26, 2020 8:12 AM
To: 'Tony Przygienda' <tonysietf@gmail.com>om>; 'Greg Shepherd' <gjshep@gmail.com>
Cc: 'BIER WG' <bier@ietf.org>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

[External Email. Be cautious of content]

I’ve been reading up on this thread and the three related drafts.

I don’t dip into BIER often (I’m not a multicast person, and I have a life), but this seemed to be a fairly weighty topic which has been bubbling away for a while, and the volume of the discussion suggested that this is a really important question (it sounded like a life and death decision judging by some of the emails!).

I think Tony captured some really key points in his email below. I particularly like his observation that BIER is working at the neck of the hourglass: that demands caution and good judgement; it also requires everyone to step back and do the right thing regardless of their investment (emotional or financial) in their preferred solution.

It seems to me (again, from the outside, and apologies if this is re-opening age-old discussions) that most of this is just protocol engineering. We have long experience at making any protocol do anything we want. If a particular solution lacks some capability, it can always be added with an extra TLV. That makes comparisons of solutions (also known as beauty contests) somewhat pointless: if you judge A better than B because B lacks some feature, then we just add the feature to B, and the cycle starts again.

That means that, while the requirements work is highly valuable for working out what the solution should deliver, it is not so helpful in determining which solution the WG should pursue. We are left, IMHO, with some of the edge requirements about transiting non-BIER nodes. These are nodes that can happily process “normal” IPv6 packets, but don’t know what to do with a BIER encapsulation. That looks like Section 3.1.3 of the requirements draft.

Embedded in that requirement is discussion of what an IPv6 router that is a transit might do with a packet. On the whole, routers just route on the fields in the v6 header itself, but they may look deeper in order to perform ECMP functions etc. For example, they may look for the transport payload to hash on ports etc. To achieve this, a router must be able to step over any additional headers (RH, DOH, etc.) to find the payload or must know not to even try. In general, a router that doesn’t understand a header will step over it if it can, but will probably give up the hunt for hashable fields.

At this point I ran aground ☹ 8926 doesn’t have anything to say about ECMP in a BIER network (with or without BIER-capable routers). But 8279 has a nice fat section on ECMP, but this seems to describe how ECMP works when processing the BIER encapsulation for equal cost paths between BIER routers, not for how the “underlay” (the IPv6 network in this case) might handle equal cost paths in its own routing.

Any clues as to how ECMP is expected to work in the context of the v6 requirements? Anything that should be added to 3.1.3 or a new section?

Thanks,
Adrian


From: BIER <bier-bounces@ietf.org<mailto:bier-bounces@ietf.org>> On Behalf Of Tony Przygienda
Sent: 20 November 2020 05:36
To: Greg Shepherd <gjshep@gmail.com<mailto:gjshep@gmail.com>>
Cc: BIER WG <bier@ietf.org<mailto:bier@ietf.org>>; Gyan Mishra <hayabusagsm@gmail.com<mailto:hayabusagsm@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>>; Alvaro Retana <aretana.ietf@gmail.com<mailto:aretana.ietf@gmail.com>>; Jeffrey (Zhaohui) Zhang <zzhang@juniper.net<mailto:zzhang@juniper.net>>
Subject: Re: [Bier] draft-ietf-bier-ipv6-requirements-09

Well, I’m glad that the work on requirements draft, albeit as product found wanting in AD’s assessment, has led to clarification of the crucial questions that e'one seems to agree need to be asked.

It surprised me then mildly that my co-chair had to explicitly lay out the semantics of what was a clear direction spelled out during the meeting but that’s all well to get e’one better in sync I guess. Needless to say I am sharing his assessment and questions put to the room entirely.
Some things that I think need explicit spelling out IMO after the last few meetings (since I’m not sure e’one in the process internalized that) is that WG is not here to tell people they cannot work on something whatever the perception seems to be, IETF doesn’t work that way. People go sideways and build stuff based on what we publish/develop in open source and for their customers in all kind of ways which may be neither fitting into an architecture, consensus or interest of a WG all the time. And that’s wonderful and more power to them, RFCs are free to download and they are just RFCs, they are not stone tablets brought from the mountain. However, and that's a big however, _if_ a work is looking for WG adoption and ultimately RFC status, the IETF process kicks in and the process has been here and well debugged over 30 years and that’s why Internet was built IME. The process is unusual in the way that it resists pretty well pressure based on non-technical claims, exceedingly poor architectural choices, chair shopping, padding of communication channels with “I participated only once to send a +1 to a list”, ad-hominem attacks and similar shenanigans that have been all tried over and over again. In the same vein the process tends to weigh based on reputation of “who said what in which context”'; such reputation being built on community service and sound work over many years. And sometimes hard calls are made based on rough consensus called by people that are here to steer stuff and nudge it along the way. Sure, it’s easy to standardize and build “something”, it’s very hard to keep it going operationally @ Internet scale for 20 years and lots of those lessons are unfortunately scar tissue not easily transferred except at level of RFC1925. Last point to emphasize is that BIER is not the average set of RFCs, we have been handed the permission to go into the hourglass of the Internet, something that happens every 15 years or so. The stuff we deliver is as fundamental as MPLS or IP forwarding plane and as PS has to meet toughest architectural standards to prevent a melt-down of non-orthogonal, under’spec’ed solutions leading to poor operational properties @ scale and non-interoperable solutions which long-term serves no'one well that relies on IP technology to support high quality infrastructure @ scale.



Juniper Business Use Only