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

[Alia Atlas <[e-mail]>]

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 limited, given our
experience with different
IGP algorithms.  I would also be stunned if we got to 10 different
algorithms.

b) Having unclear semantics because an algorithm only makes sense for BIER
or only makes
sense for an IGP-specific technology is not good.

c) Adding the complexity to consider how and when to use an algorithm or
similar new feature
that makes sense for a link-state IGP - to then also consider if it can
apply to BIER and if it can
work in non-link-state IGPs - would only make sense if it were balanced by
an equal technical
benefit.

These drafts were WGLCed in June - with no BAR.  In October, I did not just
insist on a IANA
registry for the BAR in the BIER registries - because it was claimed that
would let the documents
progress and not force to an assumption.  I regret that decision - given
the poor efforts to force
a registry merge.

IF you and Ice truly believe that this is the technically correct thing to
do, then you would make
substantive technical arguments instead of this sophistry.

I have given several more chances to allow this WG to discuss whether any
changes are needed
or are desirable. I am pushing for technical discussion.

I am quite disappointed in the level of discourse; the BIER-WG has
traditionally worked very
collegially with substantive technical points.

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>
>>
>>
>>
>> [image: cid:[e-mail]]
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>