Re: [Isis-wg] [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt

IJsbrand Wijnands <> Thu, 15 February 2018 18:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BC0F126D45; Thu, 15 Feb 2018 10:51:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Status: No, score=-14.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WwWmBi3-LSo7; Thu, 15 Feb 2018 10:51:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E567120727; Thu, 15 Feb 2018 10:50:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=68936; q=dns/txt; s=iport; t=1518720660; x=1519930260; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=fr7yyssd9rCpF8E1Sb3EvDC3Pf9xEMDwL9EypuH0oac=; b=K84WJLh+WynOpqIjr7rEexa30U4cly41MskWrxBz1KF50JzeKhI9fX/y 3eephQlb2TGW+WcW7eAjxTekbDA7zSsoBeWL4oYFmKhUuOMBBsfrXcsvL LwmmF9Ysfbc4ihaaCH9ux0/q8tci4+5/ZMqe3PC72XOgIMnd6BDdgtJxF k=;
X-Files: PastedGraphic-6.png : 43631
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BcAgDh1YVa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMhgRdwKINlixmNUQMDBoE0gReHf4hqh3EDBwECGAEKJjaEPAK?= =?us-ascii?q?DGRUBAgEBAQEBAQJrKIUjAQEBAwEBAQMeSwsFCwsYBQEBASICAgIVAQkFATAGE?= =?us-ascii?q?gEGFYoCAwgFCBCua4InhzsNgTKCEwEBAQEBAQEBAQEBAQEBAQEBAQEBAQ4KBYU?= =?us-ascii?q?DgzaCMCmDBYJrRAEBhQgxgjQFo301CYcbiV+FC5RGjk2GAoMgAgQLAhkBgTw1I?= =?us-ascii?q?4FRTSMVPSoBghs/ghYcggdAN44WAQEB?=
X-IronPort-AV: E=Sophos;i="5.46,517,1511827200"; d="png'150?scan'150,208,217,150";a="2095064"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2018 18:50:57 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w1FIouVT017521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Feb 2018 18:50:57 GMT
Content-Type: multipart/alternative; boundary="Apple-Mail=_A1FDFEF1-C009-412E-AD0B-C51970EA5E32"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: IJsbrand Wijnands <>
In-Reply-To: <>
Date: Thu, 15 Feb 2018 19:50:56 +0100
Cc: Greg Shepherd <>, "" <>, "" <>, Xiejingrong <>, Jeff Tantsura <>, "" <>, Eric C Rosen <>
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
To: Tony Przygienda <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Subject: Re: [Isis-wg] [Bier] WGLC : draft-ietf-bier-isis-extensions-07.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF IS-IS working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Feb 2018 18:51:03 -0000

I think its clear from the discussion there are different opinions on the matter on how to make BIER use the BAR field. The reason for me to support 16 bits is that everybody seemed ok go move forward with an 8bits BAR without a registry, a 16bits BAR does not change anything, its just a bigger field. But at least with 16bits, we can split in Type, Value, and support different use-cases. IMO, pointing to whatever the Unicast underlay is providing is the main use-case, but it allows other ways to do things.

One thing is clear, with just 8bits, it will be very hard to reach an agreement what the registry would look like. If we make it 16bits, we know we can solve multiple use-cases. The main question (I think) is whether we document how a 16bit BAR is carved up now, or we defer that to later. And as I said, since everybody seemed ok with 8bit BAR without a registry, I don’t see why its now different for 16bits. It gives us time to workout exactly how to use it and get input from the WGs.

And, of course, the goal is to create a registry for the 16 bits through a new draft!



> On 15 Feb 2018, at 18:28, Tony Przygienda <> wrote:
> On Thu, Feb 15, 2018 at 9:20 AM, Greg Shepherd <> wrote:
> On Thu, Feb 15, 2018 at 8:53 AM, Tony Przygienda <> wrote:
> On Thu, Feb 15, 2018 at 8:38 AM, Greg Shepherd <> wrote:
> For the record, there is no SR Registry. There is only an IGP Algo Type Registry as defined in draft-ietf-ospr-segment-routing-extensions-24 section 8.5
> So is that a good idea, having multiple drafts in flight with fields expecting to have magic couplings to each other while leaving e'thing "unspecified" to "publish RFCs" while we "decide things later"? 
> That was a pivot, but still; there is no reference, there is no coupling. 
> Tangental: draft-ietf-ospr-segment-routing-extensions-24 has been around for a while, and the IGP Algo registry will be tied to this draft and it's fate. If anyone is expecting to use this registry outside of the scope of this draft, it would be in their best interest to pull the registry description out into a separate draft.
> OK, and I agree that if such a registry is pulled and under a clear charter of mandating multiple technologies within an independent body then a discussion starts to make sense and what the size of that should be given that mandates algorithms over multiple technologies (SR, unicast, mcast, whatever) and implies a "God's eye view" of all the elements of all the technologies (and if a computation touches elements from two technologies they become [optionally] coupled).  We are not talking IGP registry or multicast computation registry or SR registry then but a "wider scope registry". Yes, that is an intriguing thought with its own validity but outside the scope of charter we're under as BIER.  Personally, I consider multiple, if needed loosely coupled registries for each technology a less centralized and hence "more Internet like" solution but I see how opinions on such a thing can diverge ... 
> thanks
> --- tony 
> _______________________________________________
> BIER mailing list