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

--===============3946662932619910238==
Content-Type: multipart/alternative; boundary="001a113e37c43fbfd80565a83e7d"

--001a113e37c43fbfd80565a83e7d
Content-Type: text/plain; charset="UTF-8"

Hi Peter,

Thanks very much for the feedback.

On Tue, Feb 20, 2018 at 12:27 PM, Peter Psenak <[email protected]> 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
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/bier
>>
>>
>

--001a113e37c43fbfd80565a83e7d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Peter,<div><br></div><div>Thanks very much for the feed=
back.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue=
, Feb 20, 2018 at 12:27 PM, Peter Psenak <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:[email protected]" target=3D"_blank">[email protected]</a>&gt;</span>=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex">Hi Alia,<br>
<br>
1. I see a benefit in having the BIER a way to map to any of the IGP algori=
thms. Simply because IGPs already provide paths to all nodes in the domain =
and BIER can simply use these paths instead of computing its own.<br></bloc=
kquote><div><br></div><div>Makes sense.=C2=A0=C2=A0</div><div>=C2=A0</div><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">
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&#39;m=
 not objecting that.<br></blockquote><div><br></div><div>That is what I&#39=
;m hearing as a requirement.=C2=A0</div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex">
The encoding of the BAR though must be done in a way that it easily support=
s both (1) and (2).<br></blockquote><div><br></div><div>There&#39;s the rub=
 :-)=C2=A0 The challenge seems to be when there are BIER-specific constrain=
ts and also other more generic constraints.=C2=A0</div><div><br></div><div>=
Regards,</div><div>Alia=C2=A0</div><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">
my 2c,<br>
Peter<div><div class=3D"h5"><br>
<br>
<br>
<br>
On 19/02/18 22:51 , Alia Atlas wrote:<br>
</div></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div><div class=3D"h5">
As the Sponsoring AD for draft-ietf-bier-isis-extension<wbr>s-07 and<br>
draft-ietf-bier-ospf-extension<wbr>s-12, I have been following the discussi=
on<br>
on the mailing list with interest.<br>
<br>
I have not seen clear consensus for any change.<br>
<br>
Let me be clear on what I see the options are from the discussion.=C2=A0 Th=
en<br>
I&#39;ll elaborate<br>
a bit on how you can express your perspective most usefully.<br>
<br>
1) Current Status:=C2=A0 Bier Algorithm (BAR) field is 8 bits.=C2=A0 Curren=
tly,<br>
only value 0 is specified.=C2=A0 The drafts do not have an IANA registry -<=
br>
with the expectation that one will be created when the first additional<br>
use is clear.=C2=A0 It is possible that there will be objections from the<b=
r>
IESG to progressing without an IANA registry.=C2=A0 Given the lack of clari=
ty<br>
for future use-cases and after discussion, I decided not to force one<br>
after my AD review - but I will not push back against having a BIER IANA<br=
>
registry if raised by others.<br>
<br>
2) Option B:=C2=A0 Add a BAR sub-type of 8 bits.=C2=A0 This would modify th=
e<br>
current TLVs.<br>
=C2=A0 =C2=A0 Define an IANA registry for the BAR type.=C2=A0 The meaning o=
f the BAR<br>
sub-type derives<br>
=C2=A0 =C2=A0 from the BAR type.=C2=A0 =C2=A0We can debate over the registr=
ation policy for<br>
the BAR type.<br>
<br>
3) Option C: Change the BAR field to be 16 bits and define an IANA<br>
registry.=C2=A0 Part of the range can be FCFS with Expert Review, part can =
be<br>
Specification Required, and part can be IETF Consensus.<br>
<br>
4) Option D: At some point in the future, if there is an actual<br>
understood and documented need, a BAR sub-type could be added a<br>
sub-TLV.=C2=A0 The length of the BAR sub-type could be determined when the<=
br>
sub-TLV is defined.<br>
<br>
Given<br>
<br>
=C2=A0 =C2=A0a) option D exists<br>
=C2=A0 =C2=A0b) there is currently only one defined value for BAR<br>
=C2=A0 =C2=A0c) I do not see strong consensus for change to one particular =
other<br>
option<br>
<br>
I see no current reason for a change and I certainly see absolutely no<br>
reason for<br>
a delay in progressing the documents.<br>
<br>
I do want to be clear about what the WG wants to do on this issue.<br>
Therefore, here is<br>
my following request.<br>
<br>
Please send your feedback to the mailing list as follows:<br>
<br>
IF you prefer or can accept the current status, please say so.=C2=A0 No mor=
e<br>
justification<br>
or reasoning is required. I just don&#39;t want the bulk of folks who are<b=
r>
content to be<br>
overlooked by those suggesting change.<br>
<br>
IF you prefer or can accept the current status, but think there should<br>
be an IANA registry<br>
as is usual for managing code-points, please say so.=C2=A0 No more<br>
justification is needed.<br>
<br>
IF you prefer Option B, C, and/or D, please say so with your<br>
explanation.=C2=A0 More technical depth than &quot;&#39;we might need it&qu=
ot; would be<br>
helpful; the availability of sub-TLVs already<br>
provides future proofing.<br>
<br>
IF you have a clear technical objection to why the Current Status is not<br=
>
acceptable,<br>
please express that - with clear details.<br>
<br>
IF you feel that additional code-points should be allocated in a BAR<br>
IANA Registry or<br>
have thoughts on the appropriate policy, please say so with your<br>
explanation for what<br>
those should be.<br>
<br>
Unless I see clear and strong consensus for something other than the<br>
Current Status,<br>
that will remain.<br>
<br>
IF there is clear and strong consensus for Option B, C, or D, or adding<br>
an IANA registry with particular values, then it will be possible to<br>
have a change up through this Weds night - with a 1 week WGLC on that<br>
particular technical change.<br>
<br>
My priority is to have the base BIER specifications published as<br>
Proposed Standards so that more BIER implementations and deployment can<br>
be done.=C2=A0 I would like the WG to wrap up the core work (as expressed i=
n<br>
the proposed recharter) so that you all can look<br>
at how to use it.<br>
<br>
Given this topic was raised last Weds and given that there are no<br>
technical objections raised to the documents as are, there isn&#39;t much<b=
r>
time - so please just respond to this email ASAP.=C2=A0 My deadline for a<b=
r>
decision is 6pm EST on Weds.<br>
<br>
Regards,<br>
Alia<br>
<br>
<br>
<br></div></div><span class=3D"">
______________________________<wbr>_________________<br>
BIER mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/bier" rel=3D"noreferrer" t=
arget=3D"_blank">https://www.ietf.org/mailman/l<wbr>istinfo/bier</a><br>
<br>
</span></blockquote>
<br>
</blockquote></div><br></div></div>

--001a113e37c43fbfd80565a83e7d--


--===============3946662932619910238==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg

--===============3946662932619910238==--