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

Tony Przygienda <> Tue, 20 February 2018 18:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B580126D0C; Tue, 20 Feb 2018 10:01:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GXkzNDBlYjGo; Tue, 20 Feb 2018 10:01:01 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c0c::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 588E9124BAC; Tue, 20 Feb 2018 10:01:01 -0800 (PST)
Received: by with SMTP id z12so10762677wrg.4; Tue, 20 Feb 2018 10:01:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FiptHTO1dXE0efZzn97rbYUq3gQEj8XOQvmxQQ451M4=; b=NjBGsQMj/t0mOMjRu2BQRLsBIex716gYnBd+//D6O9AgJTj37/itG6Omf0C0COBvtY cBONKxcliyhspyEaSZqCmxL9kKfWrW+dyAkJY0QN7qllkdu9KmCgEyIb1Bo+fZTFicT5 boM8tXVEyAPlF8DK3FHBg50dBo9FU4JxLW48QrCMfhKY95zk46IsDTyMtqqgY8I1ACJp UwRmPDkdkZoHli6RL1KiZxSQA0Uf8n5XSWQJvpDhjphNnAFvMN0ug+87ra1rURd50Clf rI0spiHTidmMVbMVJDRPsDguAfF3w6XW5eCcJj/roc8oul+1FeCOgeZx5r4l+nJ3mJrm O/GA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FiptHTO1dXE0efZzn97rbYUq3gQEj8XOQvmxQQ451M4=; b=GhyGcz8XgGDwKahmK+65YhNye68hCvA1VfdXgVmW+pn5NwCRoZNjOGrAk3nZ25zDLW Jb7r0FghMeGZW++87oDljV2jzBZVjEww9J8r347ZGEajyMxMsEdO0FQKAJEjDReeV5wA fjyNAP63robsC+MMXS2NPrn2Hlp8w9Rfq07eVC7L7TbEMvmIeekx5ko5TaQBX59HvyB0 IaSWYWwTHrBZL+cx3MCXekVejx69NdrQMdSA2pr4fU24flD/31HM7P6dyNIsEeKQtr07 UtrfBZxoU84XukO2d/LtVPU11fRn7ptPfLhnMDW7BTUWkQe8Or8eIdusz5SGFdadrPgv 2Z7w==
X-Gm-Message-State: APf1xPB++F9/59ldYHEE9EBn6f2nJbJJKiokMkiMLNfcAr+C6KkUlanq XtKVw+cBngn4DrI9KiX8g7OSXVidHs1fS1CLtIE=
X-Google-Smtp-Source: AH8x2253e4bva118nll1EwpoQnMHJzbtHf4Qc+caNZTZVcd9vZ/HGnQwB7/J2XPHE6qE91T0OgN3wAn6rPqu4fysPpI=
X-Received: by with SMTP id a6mr1405883edn.240.1519149659830; Tue, 20 Feb 2018 10:00:59 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 20 Feb 2018 10:00:19 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Tony Przygienda <>
Date: Tue, 20 Feb 2018 10:00:19 -0800
Message-ID: <>
To: IJsbrand Wijnands <>
Cc: Alia Atlas <>, BIER WG <>, " list" <>
Content-Type: multipart/alternative; boundary="089e082f6a44d5bff80565a897ad"
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:01:03 -0000

> 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.
Ice, I assume we talk the unicast computation case. Let's discuss that in
architectural terms that easily map down to the case on hand IMO:

When faced with a combinatorial problem that you mention (often caused by
coupling of many things to each other) a good approach is layering (or
think about it as indirection), i.e. the layers become decoupled and can be
developed/progressed independently. Problem with decoupling is that it
often is inefficient (indirections).

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 ;-)

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 ...

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