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

[Alia Atlas <[e-mail]>]

Hi Peter,

Thanks very much for the feedback.

On Tue, Feb 20, 2018 at 12:27 PM, Peter Psenak <[e-mail]> wrote:

> Hi Alia,
>
> 1. I see a benefit in having the BIER a way to map to any of the IGP
> algorithms. Simply because IGPs already provide paths to all nodes in the
> domain and BIER can simply use these paths instead of computing its own.
>

Makes sense.


> 2. Not sure if people plan to deploy the BIER in a model where it does its
> own topology related computations, independent of IGPs. If they do, I'm not
> objecting that.
>

That is what I'm hearing as a requirement.

The encoding of the BAR though must be done in a way that it easily
> supports both (1) and (2).
>

There's the rub :-)  The challenge seems to be when there are BIER-specific
constraints and also other more generic constraints.

Regards,
Alia

my 2c,
> Peter
>
>
>
>
> On 19/02/18 22:51 , 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
>>
>>
>