Hi Alia,
On 20/02/18 18:35 , Alia Atlas wrote:
Hi Peter,
Thanks very much for the feedback.
On Tue, Feb 20, 2018 at 12:27 PM, Peter Psenak <[email protected]
<mailto:[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.
we should be able to say BIER BAR X means (1) or (2), not both.
thanks,
Peter
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] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/bier
<https://www.ietf.org/mailman/listinfo/bier>
_______________________________________________
Isis-wg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/isis-wg
