I’m not aware of any commercial (or sort of) deployments.
So I hope it’s early enough for the implementations to adjust - Just like the
consensus we had on the other issue related to allowing 0 as a valid value for
“label-range (now called as “max-si)” which in-fact had a interoperability
issue
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 th
+1 to Option-B
Seems future proof to me.
Thanks,
Senthil
From: BIER [mailto:bier-boun...@ietf.org] On Behalf Of Alia Atlas
Sent: 20 February 2018 03:21
To: BIER WG ; isis-wg@ietf.org list
Subject: [Bier] BAR field length in draft-ietf-bier-isis-extensions and
draft-ietf-bier-ospf-extensions
> Les’s response to Andrew’s comments are spot on. Over the weekend we tried
> to converge over a 16 bit BAR, and how it would look like. We where not
> able to converge on the semantics, especially related to option B and
> the “BAR sub-type”. Its opening an other can of worms and will cause new
>
Dear BIERers,
Andrew just took the words out of my hands, my position is very similar and for
exactly same reasons as described below.
Option B is the technically sound and future proof choice.
Thanks!
Cheers,
Jeff
From: BIER on behalf of "Dolganow, Andrew (Nokia -
SG/Singapore)"
Ice,
On Mon, Feb 19, 2018 at 11:32 PM, IJsbrand Wijnands wrote:
> Alia,
>
> I am quite disappointed in the level of discourse; the BIER-WG has
> traditionally worked very
> collegially with substantive technical points.
>
>
> I don’t think its necessary to try and discredit people like this for
Alia,
> I forgot to add - of course - that I understand you have already stated that
> you don't have any technical objections to the current status.
That is true. Sticking with 8 bits BAR and not yet declare what is means is
better than rushing into 16bit with a registry during LC.
Thx,
Ice.
Alia,
> I am quite disappointed in the level of discourse; the BIER-WG has
> traditionally worked very
> collegially with substantive technical points.
I don’t think its necessary to try and discredit people like this for speaking
up.
If you ask for input from the WG, you should be honest enou
Les,
Let me clarify - rereading your email again where you clearly suggest using
128 values for
flex-algo. (I've been working all evening - except for ducking out for
that 10 minutes to
chase the kids to bed in the middle of that last email.)
a) I found the need for an SR Algorithm field to be
Les,
On Mon, Feb 19, 2018 at 9:32 PM, Les Ginsberg (ginsberg) wrote:
> I am very sympathetic to doing “as little as possible” given we are
> talking about documents which are going through final reviews.
>
> At the same time, I think defining the authoritative source for algorithm
> values is im
I would go with Option B:
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.
This gives best a
I am very sympathetic to doing “as little as possible” given we are talking
about documents which are going through final reviews.
At the same time, I think defining the authoritative source for algorithm
values is important.
I therefore agree w Ice – let’s keep the current 8 bit algorithm value
My reaction to AD's options:
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.
>
>
+1 to this option, i.e. current status with IANA BIER BAR registry.
I think we
All,
As we discussed here (as a WG) and in this topic:
* We need to have ability to define way for independent BIER computation
algorithms (for BIER specific computations or other use cases, some of which
Alia highlighted in her email below)
* We want to have extensibility to use other
Ice,
I forgot to add - of course - that I understand you have already stated
that you don't have any technical objections to the current status.
Regards,
Alia
On Mon, Feb 19, 2018 at 8:58 PM, Alia Atlas wrote:
> Ice,
>
> At this point in the process, it would be necessary to make an
> overwhel
Ice,
At this point in the process, it would be necessary to make an overwhelming
technical argument - that would sway almost the whole
WG to your perspective.
I see you saying that you have a personal preference for having the IGP
Algorithm registry also be used for the BAR registry. While
I do
Alia,
> An architectural argument can't also limit itself to the drafts in the title.
>
> If it sounded like the IANA registry was suggested as separate for BIER OSPF
> and BIER ISIS, then your attempt to reframe the conversation might be
> reasonable. Let me clarify - I see no current reason
Ice,
On Mon, Feb 19, 2018 at 7:57 PM, IJsbrand Wijnands wrote:
> Alia,
>
> I appreciate that you have finally decided to discuss this on the BIER
> mailing list.
>
>
> I know that there are individual drafts draft-ppsenak-ospf-sr-flex-algo-00
> and draft-hegdeppsenak-isis-sr-flex-algo-02.
> I
Alia,
> I appreciate that you have finally decided to discuss this on the BIER
> mailing list.
>
> I know that there are individual drafts draft-ppsenak-ospf-sr-flex-algo-00
> and draft-hegdeppsenak-isis-sr-flex-algo-02.
> I see a bit of discussion on the is-is mailing list and at IETF 100, b
Hi Ice,
I appreciate that you have finally decided to discuss this on the BIER
mailing list.
I know that there are individual drafts draft-ppsenak-ospf-sr-flex-algo-00
and draft-hegdeppsenak-isis-sr-flex-algo-02.
I see a bit of discussion on the is-is mailing list and at IETF 100, but,
of cours
Hi Alia,
There is one more option that I think is not fully covered from the choice of
options related to getting a registry.
The topic of the discussion is what information we need to pass in the IGP in
order for BIER to select the correct underlay. What identifies the underlay is
really what
"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 the
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
Hi Folks,
The newly forming LSR (link-state-routing) WG will be meeting on Wednesday
March 21, 2018 from 9:30 to 12:00.
Please send us (lsr-cha...@ietf.org) any requests for presentation slots.
Currently we have 1 slot request:
- https://datatracker.ietf.org/doc/draft-li-dynamic-flooding/
h
24 matches
Mail list logo
