+1 to Option-B
Seems future proof to me.


From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of Alia Atlas
Sent: 20 February 2018 03:21
To: BIER WG <b...@ietf.org>; isis-wg@ietf.org list <isis-wg@ietf.org>
Subject: [Bier] BAR field length in draft-ietf-bier-isis-extensions and 

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.


Isis-wg mailing list

Reply via email to