Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

IJsbrand Wijnands <> Tue, 20 February 2018 18:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 89E2B12D943; Tue, 20 Feb 2018 10:25:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 NdhvWz2u3cg2; Tue, 20 Feb 2018 10:25:30 -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 0751A126D0C; Tue, 20 Feb 2018 10:25:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2876; q=dns/txt; s=iport; t=1519151130; x=1520360730; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=V9xFBofGU0OyTqJkqzZDkvxoxVDAY9w1VPkcQATz2zo=; b=d27BWn4KZKEGE8Vflfi7C4JKjfXOkHAvzxUKmD+ozEvA1YduvwqLbYby /K9VLgIXhWo8+iEOofynkcfNeQ/rzsypPxXN2M0eR/mprnJJygbIGrsjZ +ezXhTUaEe9cWl1ZxqEH54VUZU1rUplNXnKqPecBbcD0AW0mYHJmK70OS 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AwArZ4xa/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMeMYFWhA+YLEgGgQ0ngReYXwqFOwKCbFgUAQIBAQEBAQECayi?= =?us-ascii?q?FJAEEASNWBQsLEggCHwcCAkkOBoopBQitO4IniHuCEwEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEfgQ+Df4IogQ+CMCkMgnmFI4MXMYI0BZNokE0JlgqMPIgLlFGDIQIECwI?= =?us-ascii?q?ZAYE8NiKBUU0jFWQBghk9gkuCDiCNVwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,540,1511827200"; d="scan'208";a="73455406"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Feb 2018 18:25:29 +0000
Received: from [] ([]) by (8.14.5/8.14.5) with ESMTP id w1KIPSuL009242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Feb 2018 18:25:29 GMT
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: IJsbrand Wijnands <>
In-Reply-To: <>
Date: Tue, 20 Feb 2018 10:25:28 -0800
Cc: Alia Atlas <>, BIER WG <>, " list" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Tony Przygienda <>
X-Mailer: Apple Mail (2.2104)
Archived-At: <>
Subject: Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
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: Tue, 20 Feb 2018 18:25:31 -0000


> Now, what BAR registry would give us is a "layering of constraints" if you want, i.e.  BAR=1 (since this is a very tanglible example, another one would be max. degree of fanout or things like max-label-depth e.g.)  would take care of the BIER specific constraints without IGP knowing about it in architectural terms.  On top of that IGP applies its constraints (BW, delay, whatever) but it's really not  BIER problem, we are just happy riders on coattails of the hard IGP work ;-) 

If you want to build a table for BIER, you need to have a way to associate/signal the different constraints that need to be used. In my mind, this is not coming from the IGP, but needs to be signalled in the context BIER. Like how you signal BIER-ONLY as algorithm. Or, statically configured as part of the Sub-Domain. Obviously what is required here is a architecture draft that explains how this all should work.

> To address the "efficienty" constraint one has to be very deeply steeped into IGP SPF computations but the result is that an implementation can easily incorporate constraints of all layers into a single computation (SPF practically speaking) unless they lead to NP complete combinations (so .e.g. having something that is max-bw @ guaranteed delay is far from simple) ... 
> So let's say we put the IGP signalling under a new cool IGP  (eeeh, I'm building one ;-)  and we do not want to shake their whole IGP standard saying "hey, you know, we have this BIER Stuff you must encode on your IGP elements (beside us being a subTLV) and put in your registries to do the right thing", if we have BAR we can just tell them, ok, encoding wise, jsut give us your SPF-on-steroids registry and we use that as subtype, underneath that we plug in BAR in our encoding, i.e. we just use them as signalling channel while constraining the SPF. We're done.  Obviously the SPF has to be modified to respect the union of all constraints but the alternative is worse, i.e. I have to be running multiple passes prunning things (which are practically far less desirable since we are loosing very cool stuff like LFA which I'm sure we could solve as well but get for free if we just prune the SPF @ runtime) 
> I do hope that parses and I  make sense. I tried to be as terse as I managed and I know I am bad at that … 

You lost me, sorry…



> Now, whether you believe that IGP signalling must be used for IGP dictated unicast computations only and IGP must be aware of BIER elements in its registries/encoding is a matter of taste to a degree (architecture of protocols is as much craft as art) but as to technial advantages of that I see none while I see unnecessary coupling ...
> --- tony