"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
> b...@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
--
---
t...@cs.fau.de
_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg
