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

all the implementations I am aware off can adjust to Option A) with BAR
registry without problems, neither do I see a problem with option B) given
we are talking only 0/0 being in IGP RFC @ this point in time. thanks. tony

On Mon, Feb 19, 2018 at 9:15 PM, Alia Atlas <akatlas@gmail.com> wrote:

> I have one additional question for those with implementations or testing
> them.
>
> What is the impact of going with your preferred option in terms of
> interoperability?  It may be early enough that changes can happen, but more
> feedback is needed.
>
> For those favoring Option B, could you send email to the list providing
> exact text so we have the details?
>
> For those favoring the current status without an IANA registry, are you
> able to handle one being imposed during IESG Review?  It is an obvious
> concern to raise.  Are you just prolonging or postponing the discussion?
>
> Regards,
> Aka
>
>
>
> On Feb 19, 2018 11:53 PM, "Senthil Dhanaraj" <senthil.dhanaraj@huawei.com>
> wrote:
>
>> +1 to Option-B
>>
>> Seems future proof to me.
>>
>>
>>
>> Thanks,
>>
>> Senthil
>>
>>
>>
>>
>>
>>
>>
>> *From:* BIER [mailto:bier-bounces@ietf.org] *On Behalf Of *Alia Atlas
>> *Sent:* 20 February 2018 03:21
>> *To:* BIER WG <bier@ietf.org>; isis-wg@ietf.org list <isis-wg@ietf.org>
>> *Subject:* [Bier] BAR field length in draft-ietf-bier-isis-extensions
>> and draft-ietf-bier-ospf-extensions
>>
>>
>>
>> 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
> BIER@ietf.org
> https://www.ietf.org/mailman/listinfo/bier
>
>