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

Alia Atlas <> Tue, 20 February 2018 00:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72CF81241F3; Mon, 19 Feb 2018 16:34:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 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_LOW=-0.7, 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 jBLjI7fV-mJK; Mon, 19 Feb 2018 16:34:36 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 832261204DA; Mon, 19 Feb 2018 16:34:36 -0800 (PST)
Received: by with SMTP id f186so1361580oig.4; Mon, 19 Feb 2018 16:34:36 -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=SBoQejAGUcCKLODprhLpJCT0cUz5+JMF2H5A3mSDiUY=; b=BAZyK0hsG9nudXXttMBz5DZrXRybiJq+bS/vpskM2jZHwGyZ4sAfsflzypyBu0qXO1 HjvAk5fDCHVn25t6IuM4LDLGN/740HKnMFuo/OwEUPOqSQKXDZu/JaqL23oucFsePJJT 2KH6tq7TZxkTCl8A7+dAZPLsBFi6w1ZuORo6yHaS9qaIO+1ICYG7Nr7mDLoq0qs76IBZ 9EPrdJMCC8QH6v4POYmLRjwWrmGA6CTKujsB+rBShwQSbbV6AW1+8XRR00N1lMmDRyH4 milsIzZGwW1J/pqJFq9bsGjkqve1Y5ss/3L2WN7zCEBzOxALRoPngZUfA0miqsDXq9i8 oflw==
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=SBoQejAGUcCKLODprhLpJCT0cUz5+JMF2H5A3mSDiUY=; b=RwtOdPMGeSfoUwOtGR12A6SeZxuJ/4VlLu5kBGhs63pNbJwAsXsa3KdSORVzkwkgap J6EecLysMPKmtdbz7iWXkLLxLXjm/ncNr6GlUCBmQcFJRWvaq1URS99XFSdj0Xm2cB50 0ERp1OBrZn7PrqqhB97UwxPGgbefxkIcDlO0G7Guh/d6VziWFhanaeThnVcz6fFxclXi b4teqjCXt5VGHnfzHjMQ4zQH7bGdPFEJn12lbHT71pIIE8wz4A/iJ1B1IH7/X2+9DURO 72i+JbSx+LTUOnBqS+C8/6Y3nDHwR+Ddf+N0hNdgExOsJoRXlJx4EjsF44cgpNRoNrFq R6EA==
X-Gm-Message-State: APf1xPDFtc0+F0zUyMgsHJy+XLbl+HiG+AA04DW2nJmoqoQaecRfSBof 6tLMs4j3TvN8sPerNxqbiU+Gl3CwEo+ZuE2osyQ=
X-Google-Smtp-Source: AH8x227GpWNWYyXyrjxpaOtA9dGdur5H+alaW5C+GacXJ0Vl0nmOEKU+pVGXh7GQpiKsM2pbdPR2X2x5qW/5Q2HxmoM=
X-Received: by with SMTP id 138mr11231383oia.331.1519086875447; Mon, 19 Feb 2018 16:34:35 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 19 Feb 2018 16:34:34 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Alia Atlas <>
Date: Mon, 19 Feb 2018 19:34:34 -0500
Message-ID: <>
To: IJsbrand Wijnands <>
Cc: BIER WG <>, " list" <>
Content-Type: multipart/related; boundary="001a1137ab2098543b056599f9bc"
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 00:34:39 -0000

Hi Ice,

I appreciate that you have finally decided to discuss this on the BIER
mailing list.

I know that there are individual drafts draft-ppsenak-ospf-sr-flex-algo-00
 and  draft-hegdeppsenak-isis-sr-flex-algo-02.
I see a bit of discussion on the is-is mailing list and at IETF 100, but,
of course, no WG adoption.

I see BIER as a fundamental technology that can be used in different
situations.  For instance, there is not merely
discussion of how Babel and BIER could interact - but actual code (thanks
Sandy!); of course, that is not a WG-adopted
draft yet either, so this is merely a thought experiment example.  How do
the different algorithms
work for an IGP that isn't link-state?   What about the ideas around using
BIER with caches?  Are there issues there?
What about algorithms that make sense for BIER or multicast - but not for

IANA registries are not price prohibitive.  Why would we tie BIER to the
link-state IGP registry?

I do not hear you making a technical argument.


On Mon, Feb 19, 2018 at 7:03 PM, IJsbrand Wijnands <> wrote:

> Hi Alia,
> There is one more option that I think is not fully covered from the choice
> of options related to getting a registry.
> The topic of the discussion is what information we need to pass in the IGP
> in order for BIER to select the correct underlay. What identifies the
> underlay is really what ever information is needed to select the Table
> (MT-ID) and Algorithm. An example of Algorithm work that is going on is
> Flex-Algo. My preferred option is to align with what ever the IGPs are
> using to identify the Algorithm.
> Option E: Change BAR into “IGP Algorithm” registry as documented in
> algorithm-types
> Thx,
> Ice.
> On 19 Feb 2018, at 13: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