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:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C4CA124319; Tue, 20 Feb 2018 10:32:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 kirzAMQcmBq4; Tue, 20 Feb 2018 10:32:14 -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 B3E6D126D0C; Tue, 20 Feb 2018 10:32:13 -0800 (PST)
Received: by with SMTP id 34so17140682wre.13; Tue, 20 Feb 2018 10:32:13 -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=bMTHqb/HkR4YOIcA1H7phOe2vm/pdjNWoWNTSqs1iVI=; b=AkFisqZ58CK/z6lSg0WMiKi7tR7ot0WN2K8Oq/PL2t3AOWkZJQBLFgqVrKUkYHAr1h 5nUvFAIFrAVEpnmYC/qglFIktq8P4RNbarFQ9+qBHz0gK8nErOKFjGjepNBuHm8bkXFf cMlbXs1wjtBCERg/EoeY2yVph3kDxdoo9WudJoBGh4eGHayCfEr81HBF4eEgduu6O5Wc P7dWi7jjK+hkSbyGNMBGA5HkCmj3VyEJV8rmBOy3CnkuNlSRZ4k+FGa9BoUIMyyVUOXO OW6uiaMcsNsN1+Mp0xyIiElepMNyCoug5c4gIpFmrUdq6VqEgblUqDj7gCsaMtukKlT7 4Iag==
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=bMTHqb/HkR4YOIcA1H7phOe2vm/pdjNWoWNTSqs1iVI=; b=W54UXTl3hjtS1vZuZlMRXTNOIhvG+3C34AFL/N+7qBsRqfSVJSwWlg3Cv2+dguZai/ Mpj9m2Fz3MCS/h0YZ0NFU8zDQJLvTT1U1k23hxw6mA+XvHslhqVzjc4S+TdzGtMybfO3 aYM/tVwA7qOE8Gin9YxRlwbCTWfe6wh8W+rjOgITparNojPW0KuqLWlHBPn2UuiGUKLp hv25RDoEw4ioSwcnhi5j7sUu44qq908hegReXfpyhNmjwUctyDkikF/k64Y9GRg26NxO LKWPNH3kwMhSnn/NetRUCYy4dHpXleJNVEb+1up51oMjJUMtRbca6o7VtUEZmDckL+f9 K3fA==
X-Gm-Message-State: APf1xPAet7ZItXxGmJq3A//8ehHVDZWyUivp690n4l0b498E/BwE8obM 4T71demjRFN/muIzdfD7HWCL0/OpuJuSAVXsIOo=
X-Google-Smtp-Source: AH8x2265DqXaF6F3qhSJd14q8pET56IRUSHUoMz0m+U/lBCyJRcekrCIN0h4KdbCBv+fEIpHN6+Gx2e+zakddGAxj8I=
X-Received: by with SMTP id 61mr1472290edh.16.1519151532309; Tue, 20 Feb 2018 10:32:12 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 20 Feb 2018 10:31:31 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
From: Tony Przygienda <>
Date: Tue, 20 Feb 2018 10:31:31 -0800
Message-ID: <>
To: IJsbrand Wijnands <>
Cc: Alia Atlas <>, BIER WG <>, " list" <>
Content-Type: multipart/alternative; boundary="94eb2c0da4127181b60565a90720"
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:32:16 -0000

On Tue, Feb 20, 2018 at 10:25 AM, IJsbrand Wijnands <> wrote:

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

yes, staticially configured BIER computaton constraints could work but then
routers cannot detect mismatch. A very heavy disadvantage ...

Architecture is something we can talk in London if you see value in that,
sure. For the record, I however vastly prefered the direction (mainly)
you/Eric gave from start on which was "enough architecture to get important
first application done", hence I was never pushing some some grand
cathedral building scheme. Maybe after this is in place we should have this
in London, it's the call of the day one core group that carried the banner
where there was nothing but first hill to take ;-)

My suggestion is, let us work out either option B) or Eric's proposal as
flexible and orthogonal scheme to ground the IGPs and then fall out the
rest over it ...  As you observed, I'm big believer in maybe overbuilding a
tad in flexibility or size in control plane to have architectural wiggle
room while in forwarding path one has to be extremely frugal to get the
silicon @ cost ...

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

sorry, email is limited ... Not sure how to deal with that ...

--- tony