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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A52041205F0; Tue, 20 Feb 2018 09:19:17 -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 OKgMZOZ-a2Hq; Tue, 20 Feb 2018 09:19:16 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C73E41241F8; Tue, 20 Feb 2018 09:19:15 -0800 (PST)
Received: by with SMTP id w77so16548931wrc.6; Tue, 20 Feb 2018 09:19:15 -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=xHsug94WEICEBX7LhMl8tGPUGJCL/LfJU8pZCP+jWeA=; b=IDVTw6XvwEqun9YYxlD5s/7/wi68W5qAiCbtXr4OmTKHT9FMniSPNQdsYberwe1fWY eCx9HbxDAUfFE/uBLM6Gtknxa7fqLmUChOiR+SyHZ7og+pEzAAfQf2vhLkd086QwQn3T MJ68td2C4to0eyYUbs2Wlur8p4hjH5iB5aSGDZbjFV9EmlkJAmZZYh//xBOFRHfiBqpU C9OxIxEDuo9M/VnPzoDFual83ES8Uq0J3D15nb8ugOvPUeOSuaLVHMs0UdMhqAj6OacO ytfVSf2cmxXOiMgeVe+1vevxN0CWu/JSvDPFAeGFdWDUO1RQvNG+r5PxHatEURhqBLII HgXg==
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=xHsug94WEICEBX7LhMl8tGPUGJCL/LfJU8pZCP+jWeA=; b=E07XRrQlETlzaMMpl+HkID2cVyEOis7eJiCbFfmsspCAz/ZHgrrgHILagCSEqViod/ fXW6Is5YKQKW71iehvb1iRG2/HL8TaK6a+Ciq9pOYgddmtIwaKI4+ptp5ErhN//3IIAG B8aqKFeB7e3T/ev6aqKJ8PBRLILZvCYTqk/vjWBM2Wpv0ns2T9GSZSJU3VEZcn+3mxXD C3LzPO8qCRlQAec/Z9nvyRh6++YLP2VbSFshrbFIH46//FAcmV2DCR535cCAZkBWgumC uPvSNlhS8Bxf2BvBkO4Pi2I0hlN1XDlX99d1tKkpX2SI+/jA8G4heGAjafMRWLA6dea+ Mb8g==
X-Gm-Message-State: APf1xPA185o5LHn0FCTgYhHkYL7qpNgGGkuW8shF6jNQpFp5hsv/WSOD gcCunSUPPZf7SIFalMj/RLK0OCB1dxESQ9LwSUY=
X-Google-Smtp-Source: AH8x227B2C2pqprYjRetYRWoGBU0uxv0VmVfzPxDLyscJiELVg1ArHQ8mUCVj9/PMIxoaosf2sYXts5Y7s/3GAeqfpY=
X-Received: by with SMTP id l6mr1195054ede.250.1519147154197; Tue, 20 Feb 2018 09:19:14 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 20 Feb 2018 09:18:33 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: Tony Przygienda <>
Date: Tue, 20 Feb 2018 09:18:33 -0800
Message-ID: <>
To: Alia Atlas <>
Cc: BIER WG <>, " list" <>
Content-Type: multipart/alternative; boundary="f403045c7fa87cd1b10565a802fb"
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:19:18 -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

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

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


--- tony