I am very sympathetic to doing “as little as possible” given we are talking 
about documents which are going through final reviews.
At the same time, I think defining the authoritative source for algorithm 
values is important.

I therefore agree w Ice – let’s keep the current 8 bit algorithm value – but 
make it clear that the identifiers come from the IGP Registry.

Andrew – I do not think there is agreement on what the function of a “BAR 
sub-type” is. Therefore I am not comfortable in adding it to the drafts.
Certainly this may prove to be useful, but let’s add it when we know how it 
will be used and how to assign values to it. That requires more discussion than 
can reasonably be had in the current context.

Tony / Alia – the argument that 256 algorithm values is not enough for all use 
cases (BIER specific and IGP specific and Babel specific…) – or even that 128 
is not enough (if we allow the Flex-Algo proposal to reserve half of the space) 
– simply does not ring true to me.
If I waited for  you to buy  me a beer when we reached 10 algorithms I likely 
will go thirsty for a very long time.

So Option E seems best to me.


From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of Tony Przygienda
Sent: Monday, February 19, 2018 6:20 PM
To: Dolganow, Andrew (Nokia - SG/Singapore) <andrew.dolga...@nokia.com>
Cc: BIER WG <b...@ietf.org>; IJsbrand Wijnands <i...@cisco.com>; 
isis-wg@ietf.org list <isis-wg@ietf.org>
Subject: Re: [Bier] [Isis-wg] BAR field length in 
draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

My reaction to AD's options:
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 

+1 to this option, i.e. current status with IANA BIER BAR registry.

I think we have a clear and current case which is anchored already in the 
architecture RFC as section 6.9

The draft https://tools.ietf.org/html/draft-zzhang-bier-algorithm-00 goes into 
more detail in this respect and I hope the draft being adopted and at least a 
single BAR value being assigned to deal with brownfield deployments today where 
not all routers support BIER.  This clearly necessitates a BIER BAR registry.

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.

+2 for Option B). Albeit we can meet future use cases with BAR subtype being a 
sub-TLV a bar type/bar subtype 16 bits field (subtype with or without registry 
and of course we can name those things differently) all sub-TLVs in IGPs are 
traditionally “optional”, i.e. adding sub-TLVs later _may_ cause backwards 
compatibility problems.  Defining the subtype today will allow us to specify 
that only type/subtype 0/0 is well defined & any unknown type/subtype 
combination must be avoided. The subtype will allow for BAR 0 or future BAR 
types to understand that subtype is in a sense a “mandatory sub-TLV” and the 
routers sending out such subtype must be avoided, even if the type itself is 
known.  Several possibilities come to mind immediately such as using Unicast 
IGP Algorithm Registry as subtype for certain BAR values or accommodate 
interesting, future work like Flex Algo into BIER right after IGP RFCs are 
available which IMO would present a very beneficial future direction for BIER 
technology cleanly governed by a BIER BAR registry.
PS: I think we should control the urges of workgroup participants to explore 
the number of letters in the roman alphabet that we can use to introduce their 
preferred solutions if we want to get to some kind of consensus on this thread.
PPS: Option E has been discussed in the last 16-bit thread to the point of 
logical conclusion of a "all routing protocols under the sun algorithm 
registry" and found to  be a rathole I thought ...

On Mon, Feb 19, 2018 at 6:09 PM, Dolganow, Andrew (Nokia - SG/Singapore) 
<andrew.dolga...@nokia.com<mailto:andrew.dolga...@nokia.com>> wrote:

As we discussed here (as a WG) and in this topic:

  *   We need to have ability to define way for independent BIER computation 
algorithms (for BIER specific computations or other use cases, some of which 
Alia highlighted in her email below)
  *   We want to have extensibility to use other non-BIER specific algorithms 
(as others brought up)

The original draft can be argued not to provide both of those capabilities, and 
thus Option A below (marked as Current status) really just defers the issue. I 
find Option E that Ice added also counterproductive as it eliminates the top 
use case above. Thus we really left with options B, C, D as a compromise. From 
those, Option B seems to me the best:

  *   It meets the requirements above
  *   It allows a clean implementation (as opposed to Option C which is a bit 
more kludgy). Thanks to a sub-TLV defining what BAR field carries – a 
BIER-specific algorithm defined in BIER specific registry (a registry that 
should be BIER specific, regardless of IGP used), or something else to meet 
needs expressed by others, we meet the requirements from those who wanted to 
change the Current status

Option C/D are acceptable alternatives; however, Option B seems technically 
cleanest, most flexible, and meeting all requirements.


From: Isis-wg <isis-wg-boun...@ietf.org<mailto:isis-wg-boun...@ietf.org>> on 
behalf of Alia Atlas <akat...@gmail.com<mailto:akat...@gmail.com>>
Date: Tuesday, February 20, 2018 at 12:05 PM
To: "(Ice) IJsbrand Wijnands" <i...@cisco.com<mailto:i...@cisco.com>>
Cc: BIER WG <b...@ietf.org<mailto:b...@ietf.org>>, 
"isis-wg@ietf.org<mailto:isis-wg@ietf.org> list" 
Subject: Re: [Isis-wg] [Bier] BAR field length in 
draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions


On Mon, Feb 19, 2018 at 7:57 PM, IJsbrand Wijnands 
<i...@cisco.com<mailto:i...@cisco.com>> wrote:

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

I know that there are individual drafts draft-ppsenak-ospf-sr-flex-algo-00  and 
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?

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

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,




On Mon, Feb 19, 2018 at 7:03 PM, IJsbrand Wijnands 
<i...@cisco.com<mailto:i...@cisco.com>> 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 

Option E: Change BAR into “IGP Algorithm” registry as documented in 



On 19 Feb 2018, at 13:51, Alia Atlas 
<akat...@gmail.com<mailto:akat...@gmail.com>> 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 
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 
   from the BAR type.   We can debate over the registration policy for the BAR 

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.


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

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

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.


BIER mailing list



BIER mailing list

Isis-wg mailing list

Reply via email to