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

[Toerless Eckert <[e-mail]>]

"current status". 

Maybe folks should ask themselves: 
Whats the worst case that could happen when we stick to "current status" ?

IMHO, we can do whatever we want with future work in a backward compatible
fashion and would at most have wasted 7 bits of BAR field. Thats not bad
enough to delay these 2.5++ year old drafts any further IMHO.  Best case, we
will have more efficient encoding for future work than future/additional {sub-}sub-TLVs
if we'd shrunk/cut the field now. 

Cheers
   Toerless


On Mon, Feb 19, 2018 at 04:51:01PM -0500, 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier


-- 
---
[e-mail]