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 01:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC897126D85; Mon, 19 Feb 2018 17:05:30 -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 sA_hN7X9T6AI; Mon, 19 Feb 2018 17:05:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4003:c0f::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CA6591241FC; Mon, 19 Feb 2018 17:05:27 -0800 (PST)
Received: by with SMTP id 95so8554761ote.5; Mon, 19 Feb 2018 17:05: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=1u59JiGxZn0J4WI0c5Cl6pY7oSqrNwwebVs/QlOrUY0=; b=mU7/Cakf0NXn3GSt/8FsD+B8tcAIxT2OuZsLcB06T133v7s/hnAnffz9Qjy2ZYQpNh ePh9YitiuV7FHmyLtfv3uQwLkfYtezaCpFrvC+ZDOqwoGTINBakMhH30gnbLyFB7+6W1 JPcRsPixxcBRtNJebahyNIHuZj55Npd5yWB8OZ8VAYPFyN9fx4dUnY3ZPV/I6Ey6iWn7 kbtMRrYWS4WBFWClSuC5ttZ/pQ5XGMpyh/5NkvwWb999Z1b7Sli8lCo2f+O3ug6zHfcF q3HjYLaLYx7JfTptrIE1JF1JdW7j1hpKRFfMPDLZaCWBmohZPKJIby7KzUH8kIVXO628 yc8w==
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=1u59JiGxZn0J4WI0c5Cl6pY7oSqrNwwebVs/QlOrUY0=; b=RxaL2mHg3TNNAUfE0uvNzR98X7AX4MkB/8utW9vvin8KvPMjc40j6lJRPFEY6VJUQw P8XSWpKq7wPaE7JCiBuT+n2w+myiDjXgYwbgtinSQQ1fnVrGPd/sCvBGDTdcdAbKQSEw K5uNdqQmWqdZVlV2xsu9nf7BYk4vinZcgR2Zeo8kRvkDnAbPPZtcn5NwUQmA/DcPqKQp mSQ5VPPn2xgb74I3bJyGub13/oeMRvR+8/85H0XNUwo4BvwjAQDt/QJ8kkMkWTbVVXrF 9R7Qno9EFVJSjq8hP9zpEmbbsh8k+flkfQW8GilAf9CgIAb8iFk8MAoyvGx+PvL7Nk8u Yr1A==
X-Gm-Message-State: APf1xPDJ6rZbQtroQfVE5dsAsilBpCaDDrO5VcJBqumlo2Yl84DBO4mu BuOXkBmUn5DBuze6SXhtD1pU3QjhMe1x1idOGYk=
X-Google-Smtp-Source: AH8x224GrFsd0c2QFWujaVenmRSjImIoGmXovaM3HYLTXhSUskoELe77t5K/R+WaAK/x4Gn/v1hv6xK3s1nw0C6HBDU=
X-Received: by with SMTP id 69mr7577294oti.258.1519088726673; Mon, 19 Feb 2018 17:05:26 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 19 Feb 2018 17:05:25 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
From: Alia Atlas <>
Date: Mon, 19 Feb 2018 20:05:25 -0500
Message-ID: <>
To: IJsbrand Wijnands <>
Cc: BIER WG <>, " list" <>
Content-Type: multipart/related; boundary="001a113e37c4efbef805659a67a4"
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 01:05:31 -0000


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

> Alia,
> 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
> unicast?
> IANA registries are not price prohibitive.  Why would we tie BIER to the
> link-state IGP registry?
> We are talking about what needs to be advertised in OSPF and ISIS in order
> to select the BIER underlay. We are not discussing Babel or any other
> candidate underlay technologies for BIER. Moreover, we are not limiting any
> new innovation with BIER regarding the underlay. This discussion is
> strictly related to the drafts in the title.
> I do not hear you making a technical argument.
> This is an architectural argument!

An architectural argument can't also limit itself to the drafts in the

If it sounded like the IANA registry was suggested as separate for BIER
OSPF  and BIER ISIS, then your attempt to reframe the conversation might be
reasonable.  Let me clarify - I see no current reason for an OSPF BAR
registry and an ISIS BAR registry; it would just be a BAR registry.  Perhaps
that clarification is a good reason to get the IANA registry included in
the next update?

The routing layer is separate from the BIER layer.  The BAR is for the BIER


> Hope this clarifies,
> Thx,
> Ice.
> Regards,
> Alia
> 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
> <PastedGraphic-6.png>