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

[Alia Atlas <[e-mail]>]

Ice,


On Mon, Feb 19, 2018 at 11:32 PM, IJsbrand Wijnands <[e-mail]> 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
> speaking up.
>

I am asking for technical reasoning; what breaks, what is facilitated, and
so on.
I am also evaluating whether the WG is mature enough to handle the proposed
recharter - as
BIER continues to make its way into the industry - or whether stricter
controls are needed.

Please do consider the private side conversations you have had as well.


> If you ask for input from the WG, you should be honest enough to list all
> the options.
>

If I didn't want the WG input, I would have simply said that it is done.
That I have not done so is
because I believe in the IETF Standards Process and it is my current
responsibility to uphold that.

I put options that I see as reasonable on the table - to provide
flexibility.
I hear you and Les speaking up but not explaining why.
I have put up technical objections and concerns that should clearly
articulate why I see a joint
registry as a technically bad and limiting idea.  I have to look at the
broad picture.

What Les and I say is because we think that is architecturally the right
> think to do. If you don’t understand the reasoning or disagree, that is
> fine.
>

You did not give reasoning.  You did not explain how you see the complexity
it introduces between WGs being handled.


> Some problems take time to converge on, clearly in this case there was not
> enough time, but the drafts are pushed through anyway, your call. We got
> informed through a draft that there was no consensus on how to use the BAR
> type 4 weeks ago.
>

Sometimes deadlines are needed to force conversations to happen and into
the open. You knew this when my AD review recommended an IANA registry and
I got pushback.


> 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
> discussion over the BIER architecture in the future. I know, not your
> problem.
>

 I see specific technical problems and complexity introduced by a common
registry.
 I see other suggestions trying to merge.

I am unclear on why you believe I do not care about setting up BIER for
success in the future.  That is precisely what I am spending too much
time working on.

Cough up technical reasons that persuade the WG.  Explain to me exactly
where I am incorrect.

I have not seen technical reasons to justify an extremely late change to
the WG drafts nor consensus to do so.

I KEEP giving you chances and Weds night is the final deadline.

Cheers,
Alia



> Thx,
>
> Ice.
>
>
> Regards,
> Alia
>
> On Mon, Feb 19, 2018 at 10:11 PM, Alia Atlas <[e-mail]> wrote:
> Les,
>
> On Mon, Feb 19, 2018 at 9:32 PM, Les Ginsberg (ginsberg) <
> [e-mail]> 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 important.
>
>
>
> I therefore agree w Ice – let’s keep the current 8 bit algorithm value –
> but make it clear that the identifiers come from the IGP Registry.
>
>
> I do not hear from you or Ice a clear technical reason nor willingness to
> address the concerns that I raised about the impact
> on the use of BIER.
>
> I see no technical reasons being used to recommend combining the BIER BAR
> registry and the IGP Algorithms registry.
>
>
> Andrew – I do not think there is agreement on what the function of a “BAR
> sub-type” is. Therefore I am not comfortable in adding it to the drafts.
>
> Certainly this may prove to be useful, but let’s add it when we know how
> it will be used and how to assign values to it. That requires more
> discussion than can reasonably be had in the current context.
>
>
>
> Tony / Alia – the argument that 256 algorithm values is not enough for all
> use cases (BIER specific and IGP specific and Babel specific…) – or even
> that 128 is not enough (if we allow the Flex-Algo proposal to reserve half
> of the space) – simply does not ring true to me.
>
> If I waited for  you to buy  me a beer when we reached 10 algorithms I
> likely will go thirsty for a very long time.
>
>
> It is fascinating to see that you believe me too busy to keep up on the
> side discussions happening - or perhaps merely too distracted to
> recall the emails discussing acquiring half of the IGP Algorithm space for
> flex-algo.  I do talk to my WG Chairs.
>
> Please engage substantively with technical arguments.  If you have them,
> you are more than capable of representing them
> accurately.
>
>
> So Option E seems best to me.
>
>
> That was not part of my listed options.
>
> Regards,
> Alia
>
>
>
>
>    Les
>
>
>
> From: BIER [mailto:[e-mail]] On Behalf Of Tony Przygienda
> Sent: Monday, February 19, 2018 6:20 PM
> To: Dolganow, Andrew (Nokia - SG/Singapore) <[e-mail]>
> Cc: BIER WG <[e-mail]>; IJsbrand Wijnands <[e-mail]>;
> [e-mail] list <[e-mail]>
> Subject: Re: [Bier] [Isis-wg] BAR field length in draft-ietf-bier-isis-extensions
> and draft-ietf-bier-ospf-extensions
>
>
>
> 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 have a clear and current case which is anchored already in the
> architecture RFC as section 6.9
>
> The draft https://tools.ietf.org/html/draft-zzhang-bier-algorithm-00 goes
> into more detail in this respect and I hope the draft being adopted and at
> least a single BAR value being assigned to deal with brownfield deployments
> today where not all routers support BIER.  This clearly necessitates a BIER
> BAR registry.
>
>
> 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.
>
>
> +2 for Option B). Albeit we can meet future use cases with BAR subtype
> being a sub-TLV a bar type/bar subtype 16 bits field (subtype with or
> without registry and of course we can name those things differently) all
> sub-TLVs in IGPs are traditionally “optional”, i.e. adding sub-TLVs later
> _may_ cause backwards compatibility problems.  Defining the subtype today
> will allow us to specify that only type/subtype 0/0 is well defined & any
> unknown type/subtype combination must be avoided. The subtype will allow
> for BAR 0 or future BAR types to understand that subtype is in a sense a
> “mandatory sub-TLV” and the routers sending out such subtype must be
> avoided, even if the type itself is known.  Several possibilities come to
> mind immediately such as using Unicast IGP Algorithm Registry as subtype
> for certain BAR values or accommodate interesting, future work like Flex
> Algo into BIER right after IGP RFCs are available which IMO would present a
> very beneficial future direction for BIER technology cleanly governed by a
> BIER BAR registry.
>
> PS: I think we should control the urges of workgroup participants to
> explore the number of letters in the roman alphabet that we can use to
> introduce their preferred solutions if we want to get to some kind of
> consensus on this thread.
>
> PPS: Option E has been discussed in the last 16-bit thread to the point of
> logical conclusion of a "all routing protocols under the sun algorithm
> registry" and found to  be a rathole I thought ...
>
>
>
>
>
>
> On Mon, Feb 19, 2018 at 6:09 PM, Dolganow, Andrew (Nokia - SG/Singapore) <
> [e-mail]> wrote:
>
> 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 non-BIER specific algorithms
> (as others brought up)
>
>
> The original draft can be argued not to provide both of those
> capabilities, and thus Option A below (marked as Current status) really
> just defers the issue. I find Option E that Ice added also
> counterproductive as it eliminates the top use case above. Thus we really
> left with options B, C, D as a compromise. From those, Option B seems to me
> the best:
>
> • It meets the requirements above
> • It allows a clean implementation (as opposed to Option C which is a bit
> more kludgy). Thanks to a sub-TLV defining what BAR field carries – a
> BIER-specific algorithm defined in BIER specific registry (a registry that
> should be BIER specific, regardless of IGP used), or something else to meet
> needs expressed by others, we meet the requirements from those who
> wanted to change the Current status
>
>
> Option C/D are acceptable alternatives; however, Option B seems
> technically cleanest, most flexible, and meeting all requirements.
>
>
>
> Andrew
>
>
>
>
>
> From: Isis-wg <[e-mail]> on behalf of Alia Atlas <
> [e-mail]>
> Date: Tuesday, February 20, 2018 at 12:05 PM
> To: "(Ice) IJsbrand Wijnands" <[e-mail]>
> Cc: BIER WG <[e-mail]>, "[e-mail] list" <[e-mail]>
> Subject: Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions
> and draft-ietf-bier-ospf-extensions
>
>
>
> Ice,
>
>
>
> On Mon, Feb 19, 2018 at 7:57 PM, IJsbrand Wijnands <[e-mail]> 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 see a bit of discussion on the is-is mailing list and at IETF 100, but,
> of course, no WG adoption.
>
> I see BIER as a fundamental technology that can be used in different
> situations.  For instance, there is not merely
> discussion of how Babel and BIER could interact - but actual code (thanks
> Sandy!); of course, that is not a WG-adopted
> draft yet either, so this is merely a thought experiment example.  How do
> the different algorithms
> work for an IGP that isn't link-state?   What about the ideas around using
> BIER with caches?  Are there issues there?
> What about algorithms that make sense for BIER or multicast - but not for
> unicast?
>
> IANA registries are not price prohibitive.  Why would we tie BIER to the
> link-state IGP registry?
>
>
>
> We are talking about what needs to be advertised in OSPF and ISIS in order
> to select the BIER underlay. We are not discussing Babel or any other
> candidate underlay technologies for BIER. Moreover, we are not limiting any
> new innovation with BIER regarding the underlay. This discussion is
> strictly related to the drafts in the title.
>
>
>
> I do not hear you making a technical argument.
>
>
>
> This is an architectural argument!
>
>
>
> 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 for an OSPF BAR
> registry and an ISIS BAR registry; it would just be a BAR registry.  Perhaps
>
> that clarification is a good reason to get the IANA registry included in
> the next update?
>
>
>
> The routing layer is separate from the BIER layer.  The BAR is for the
> BIER layer.
>
>
>
> Regards,
>
> Alia
>
>
>
>
>
> Hope this clarifies,
>
>
>
> Thx,
>
>
>
> Ice.
>
>
>
>
> Regards,
> Alia
>
>
> On Mon, Feb 19, 2018 at 7:03 PM, IJsbrand Wijnands <[e-mail]> wrote:
> 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 ever information is needed to select the
> Table (MT-ID) and Algorithm. An example of Algorithm work that is going on
> is Flex-Algo. My preferred option is to align with what ever the IGPs are
> using to identify the Algorithm.
>
> Option E: Change BAR into “IGP Algorithm” registry as documented in
> https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-
> algorithm-types
>
> Thx,
>
> Ice.
>
>
> On 19 Feb 2018, at 13:51, Alia Atlas <[e-mail]> 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
>
>
>
> <PastedGraphic-6.png>
>
>
>
> <image001.png>
>
>
>
>
>
>
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier
>
>
>
>
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg
>
>
>
>
>
>
>