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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A227512DA07; Tue, 20 Feb 2018 09:42:33 -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 X1rrVUVwWKOs; Tue, 20 Feb 2018 09:42:27 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c0c::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5819C126CC7; Tue, 20 Feb 2018 09:42:27 -0800 (PST)
Received: by with SMTP id m5so16769233wrg.1; Tue, 20 Feb 2018 09:42:27 -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=Pc1h5YEXJfUUwWm8FOP3LbkMLh0nbZllVdfP/IAJ2Fw=; b=AG2L8pXn3rb1EUCescVbzSHj0jgIs6BM3dKnVdxlmigd07WeVunmdpy0EHxrn0LFqW jlKIt/TXT6M6+rEqnBmRLBiHcb/Fax7MlPgeugpIPDJ5i/2f7FLA/r38KxflOMgkYB2v dZEhTybN23kc2detKWUrG1xsntanEJUrPlLaw5BGkHeh7NvBYzj1zbJM+TB2X8m4kIXF QjXncqt6ffOfdmiRbIsudojxH0oddYoF//+6OKTEtPz0HZVt/EyOlwmbrs9yDJykvt+G CDIN8ZnPSXN+5ANrmjMrTsE5UxYMtdktm9HVgKn/kxFokUR4DOdP3de7o3OtqF0yMIqg zMbg==
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=Pc1h5YEXJfUUwWm8FOP3LbkMLh0nbZllVdfP/IAJ2Fw=; b=g13vnmytAUK02QYiPazJtZNvYY/aEmn0j7MdAL3lnXev89t323Y21xmM1iYFJjCRDa euq2uF5ghlIOMNzwp21sSG5R8LlF4oS3xQfPx5HJecVr0bpA9KcwFGD+UmBLWcfQGuzy jzSwecuqYOk7Q2RfecOh9vgxuG1kpQWUGWgFxI31aPgrPkeRMUprmFZShDConZqFIQqR XR+lPYahqt9IHyt07D5LjacxMU/1QMLCvRegMUi3PEdp5AIKN4BOepwoluwvYYAtL3TX ra++ZQbi3mn0RcC1B5wk4xWCeHBuE/kCHuGfMoYxUr7Jk8HOV0AdvuYycLjUknBvc7bD 3qwg==
X-Gm-Message-State: APf1xPBc7U3hmETOWuasfgef0/GSY/SX9YBHqbec8+AmxgQCWUI90ax6 JCVOQx0CYaFqiod2Lew5lOGmg0U26ZcDq4VBFo8=
X-Google-Smtp-Source: AH8x225NdS5NdgoqeNgGr59yjBqRXPsL9K+9nzw9L7sfQo1vig4YZaVIqMffKT1iceQj7zE90i6jSKfrM/lKPp5clXU=
X-Received: by with SMTP id 34mr1254407edz.227.1519148545807; Tue, 20 Feb 2018 09:42:25 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 20 Feb 2018 09:41:45 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Tony Przygienda <>
Date: Tue, 20 Feb 2018 09:41:45 -0800
Message-ID: <>
To: Peter Psenak <>
Cc: Alia Atlas <>, BIER WG <>, " list" <>
Content-Type: multipart/alternative; boundary="f403045c2a986f1cd50565a8556e"
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:42:34 -0000

On Tue, Feb 20, 2018 at 9:27 AM, Peter Psenak <> wrote:

> Hi Alia,
> 1. I see a benefit in having the BIER a way to map to any of the IGP
> algorithms. Simply because IGPs already provide paths to all nodes in the
> domain and BIER can simply use these paths instead of computing its own.


Things like BAR 0/1 are clearly unicast computations (SPFs basically given
we're on link-state), many other BARs may be. We have to fully provide for
extended metrics and future constraints like FlexAlgo to make sure that
advanced unicast computations are possible on top of any BIER-specific
computation. This will be choice for many for years to come & the workhorse
of BIER for now.  BIER without IGPs lending its topology
distribution/signalling & first computation help would have not be an easy
thing to introduce.  All kudos to people who had the practical wisdom to go
down that path.

> 2. Not sure if people plan to deploy the BIER in a model where it does its
> own topology related computations, independent of IGPs. If they do, I'm not
> objecting that.

Discussions came up, not only about specific computations but also about
things where IGP is just signalling and something else completely is doing
computation and it only needs to have all nodes signal that they are using
this off-line computation. Do please read the bier-algorithm draft for
first cases discussed with people seriously interested in deployments.
Yes, we could tell them that IGP is not a viable signalling then and ask
them e.g. to use PCEP to install BIFTs into routers (and some may like this
total control) but that limits the appeal of BIER significantly since we
now do not provide several very important architectural pieces (topology
distribution and simple signalling) or rather would make both inseparable
for no technical beneficial reason I can discern ...

> The encoding of the BAR though must be done in a way that it easily
> supports both (1) and (2).


thanks Peter

--- tony

> my 2c,
> Peter
> On 19/02/18 22:51 , Alia Atlas wrote:
>> As the Sponsoring AD for draft-ietf-bier-isis-extensions-07 and
>> draft-ietf-bier-ospf-extensions-12, I have been following the discussion
>> on the mailing list with interest.
>> I have not seen clear consensus for any change.
>> Let me be clear on what I see the options are from the discussion.  Then
>> I'll elaborate
>> a bit on how you can express your perspective most usefully.
>> 1) Current Status:  Bier Algorithm (BAR) field is 8 bits.  Currently,
>> only value 0 is specified.  The drafts do not have an IANA registry -
>> with the expectation that one will be created when the first additional
>> use is clear.  It is possible that there will be objections from the
>> IESG to progressing without an IANA registry.  Given the lack of clarity
>> for future use-cases and after discussion, I decided not to force one
>> after my AD review - but I will not push back against having a BIER IANA
>> registry if raised by others.
>> 2) Option B:  Add a BAR sub-type of 8 bits.  This would modify the
>> current TLVs.
>>     Define an IANA registry for the BAR type.  The meaning of the BAR
>> sub-type derives
>>     from the BAR type.   We can debate over the registration policy for
>> the BAR type.
>> 3) Option C: Change the BAR field to be 16 bits and define an IANA
>> registry.  Part of the range can be FCFS with Expert Review, part can be
>> Specification Required, and part can be IETF Consensus.
>> 4) Option D: At some point in the future, if there is an actual
>> understood and documented need, a BAR sub-type could be added a
>> sub-TLV.  The length of the BAR sub-type could be determined when the
>> sub-TLV is defined.
>> Given
>>    a) option D exists
>>    b) there is currently only one defined value for BAR
>>    c) I do not see strong consensus for change to one particular other
>> option
>> I see no current reason for a change and I certainly see absolutely no
>> reason for
>> a delay in progressing the documents.
>> I do want to be clear about what the WG wants to do on this issue.
>> Therefore, here is
>> my following request.
>> Please send your feedback to the mailing list as follows:
>> IF you prefer or can accept the current status, please say so.  No more
>> justification
>> or reasoning is required. I just don't want the bulk of folks who are
>> content to be
>> overlooked by those suggesting change.
>> IF you prefer or can accept the current status, but think there should
>> be an IANA registry
>> as is usual for managing code-points, please say so.  No more
>> justification is needed.
>> IF you prefer Option B, C, and/or D, please say so with your
>> explanation.  More technical depth than "'we might need it" would be
>> helpful; the availability of sub-TLVs already
>> provides future proofing.
>> IF you have a clear technical objection to why the Current Status is not
>> acceptable,
>> please express that - with clear details.
>> IF you feel that additional code-points should be allocated in a BAR
>> IANA Registry or
>> have thoughts on the appropriate policy, please say so with your
>> explanation for what
>> those should be.
>> Unless I see clear and strong consensus for something other than the
>> Current Status,
>> that will remain.
>> IF there is clear and strong consensus for Option B, C, or D, or adding
>> an IANA registry with particular values, then it will be possible to
>> have a change up through this Weds night - with a 1 week WGLC on that
>> particular technical change.
>> My priority is to have the base BIER specifications published as
>> Proposed Standards so that more BIER implementations and deployment can
>> be done.  I would like the WG to wrap up the core work (as expressed in
>> the proposed recharter) so that you all can look
>> at how to use it.
>> Given this topic was raised last Weds and given that there are no
>> technical objections raised to the documents as are, there isn't much
>> time - so please just respond to this email ASAP.  My deadline for a
>> decision is 6pm EST on Weds.
>> Regards,
>> Alia
>> _______________________________________________
>> BIER mailing list
> _______________________________________________
> Isis-wg mailing list