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 17:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B847F12D955; Tue, 20 Feb 2018 09:44:11 -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 9hESRhlcAgYP; Tue, 20 Feb 2018 09:44:10 -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 CA3DD12D94A; Tue, 20 Feb 2018 09:44:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=69919; q=dns/txt; s=iport; t=1519148649; x=1520358249; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=Xo40vfz2eaT40n/GIoqSOr2t4wshpHXFYzgrvkypU+w=; b=Nze5o74uIlXS8G1dsDdoS7psjwS8OrdNdIHnXBlDdagTOwzMPXqCxszL nM9HWNNN9HsbllTUIyNQ86PcQ4w0qVGMohaPhdTY6KX4chdWYBIw4SUs3 JJ35wcT2m7cwwC0qd15gNOJDlBwiX+EeAVYPmyd0RUDzj4skLmzvQZJF+ E=;
X-Files: PastedGraphic-6.png : 43631
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwBwDyXYxa/5pdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMeMWZwKINnmCxIBoE0gReQbYdvAwcBAhgBCiY2hDwCgmxXFQE?= =?us-ascii?q?CAQEBAQEBAmsohSQBAQMBAQEDHksLBQsLEgsBAQEbBwICAhUBDgEiDgYSAQaKE?= =?us-ascii?q?AUIEK1VgieIeoITAQEBAQEBAQEBAQEBAQEBAQEBAQEBDgoFhQ6CKIEPgjApgwW?= =?us-ascii?q?DMAEBhQgxgjQFk2iQAUwJhx+Oa4w8iAuIEYxAgyECBAsCGQGBPDUjgVFNIxU6K?= =?us-ascii?q?gGCGD6CS4IOIDeNIAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,540,1511827200"; d="png'150?scan'150,208,217,150";a="73406906"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Feb 2018 17:44:08 +0000
Received: from [] ([]) by (8.14.5/8.14.5) with ESMTP id w1KHi7BO027653 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Feb 2018 17:44:08 GMT
Content-Type: multipart/alternative; boundary="Apple-Mail=_5F907A7E-31C8-44DC-9A0A-CCF92A48B514"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: IJsbrand Wijnands <>
In-Reply-To: <>
Date: Tue, 20 Feb 2018 09:44:07 -0800
Cc: Alia Atlas <>, BIER WG <>, " list" <>
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 17:44:12 -0000


> From an architectural view, the idea of having the IGP/routing layer have to understand
> BIER specifics seems an undesirable coupling. 
> very much so, in stark terms one could say that IGP is BIER signalling while the fact that we use SPF to perform BIER nexthop calculations is a convenient first artifact. The architecture RFC does not separate that clearly IMO but is rather an "example" of practical BIER architecture embodiment ;-) I do absolutely prefer it that way from practical standpoint, abstract architectures with all degrees of flexibility written first are hard to understand and slow to build. BIER delivered on a real problem but after this first delivery needs the flexibility to spread its wings into fields where IGP unicast may not be enough IMO and in any case, IGP unicast computation coupling to BIER specific elements is unnecessary and undesirable unless one believes e'thing is better off centralized. It would be _highly_ unfortunate and immense waste of resources if we ended up building another signalling just so we can perform non unicast IGP computations. 
> Could someone walk me through how this would be supported in each of the different options?
> For Option D, where there is a sub-TLV and that sub-TLV can supply the additional non-BIER
> constraints, I understand it. 
> For Option B - which some folks are preferring, I do not see understand how it would work.
> BAR = 0 SPF, subtype can be FlexAlgo, any other IGP metric or constraint or even an IGP registry value, this is a unicast computation 
> BAR = 1 SPF without BIER routers, subtype can be FlexAlgo, any other IGP metric or constraint specification, this is a unicast computation 
> BAR = X (some unicast computation type)  same as 0/1
> BAR = Y (multicast specific computation that IGP cnanot perform), subtype can be anything 
> What is important to observe that SPF with additional constraints is as efficient as SPF without those constraints (as long we're talking certain convex properties AFAIR but I don't want to bore anyone with math, most of the stuff we use today like max. BW, min. delay has this property).

My first observation is that what is documented here as “BIER Algorithm Registry” is not an Algorithm, but a constraint. Suppose you want to build a topology with {BIER-ONLY, LOWEST-DELAY, BW}. From an architecture POV, any combination should be allowed. Would you propose to create BAR values to capture every possible combination? I don’t think that scales very well. Constraints would be better served with a BitMask IMO.



> For Option A, I do not understand how it would work.
> replace subtype with a sub-TLV so it's basically option D). I explained in my +1/+2 my reasoning why option B) is more preferrable if you are concerned about backwards compatibility but it's nothing architecturally important. IGPs were muddling for years without clear distinction between mandatory/optional TLVs are IDR has and we lived to tell the tale ;-) ...
> Obviously, this is going far out on a design limb - where flex-algo does not yet have any IETF
> support or adoption, but since it is clear that people's perspectives are being strongly influenced
> by what that might morph into, I think this is important for the whole WG to understand.
>  AFAIU we have BIER RFCs that form a solid foundation to deliver now.  Things to be done in the future can obviously morph into many directions and claim to cover any problem presented to them without much risk ... 
> thanks 
> --- tony 
> _______________________________________________
> BIER mailing list