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

From: Alia Atlas <[email-masked]>
Date: Mon, 19 Feb 2018 16:51:01 -0500

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

---

From: Toerless Eckert <[email-masked]>
Date: Tue, 20 Feb 2018 00:00:41 +0100

"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 these 2.5++ year old drafts any further IMHO.  Best case, we
will have more efficient encoding for future work than future/additional {sub-}sub-TLVs
if we'd shrunk/cut the field now. 

Cheers
   Toerless

> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

-- 
---
[email-masked]

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 19 Feb 2018 16:03:29 -0800

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 <[email-masked]> 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.
> 
> Let me be clear on what I see the options are from the discussion.  Then I'll elaborate
> 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 
> I see no current reason for a change and I certainly see absolutely no reason for
> I do want to be clear about what the WG wants to do on this issue.  Therefore, here is
> my following request.
> 
> 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
> 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
> IF you have a clear technical objection to why the Current Status is not acceptable,
> 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
>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 19 Feb 2018 19:34:34 -0500

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 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?

I do not hear you making a technical argument.

Regards,
Alia

On Mon, Feb 19, 2018 at 7:03 PM, IJsbrand Wijnands <[email-masked]> 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.
>
> draft-ietf-bier-ospf-extensions-12, I have been following the
> discussion on the mailing list with interest.
>
> 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
>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 19 Feb 2018 16:57:38 -0800

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!

Hope this clarifies,

Thx,

Ice.

---

From: Alia Atlas <[email-masked]>
Date: Mon, 19 Feb 2018 20:05:25 -0500

Ice,

On Mon, Feb 19, 2018 at 7:57 PM, IJsbrand Wijnands <[email-masked]> wrote:

> 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.
>

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

> draft-ietf-bier-ospf-extensions-12, I have been following the discussion
> on the mailing list with interest.
>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 19 Feb 2018 17:15:29 -0800

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 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?

There is no reason for an individual BIER OSPF and BIER ISIS registry. The point is to align with what ever ISIS and OSPF are using to identify the algorithm.

> The routing layer is separate from the BIER layer.  The BAR is for the BIER layer.

The underlay is separate from the BIER layer, and each underlay can carry BIER specific information that is needed for for BIER to make the selection.

Thx,

Ice.

---

From: Alia Atlas <[email-masked]>
Date: Mon, 19 Feb 2018 20:58:11 -0500

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, of course, respect where you have technical expertise, my response -
particularly from a process perspective - is "that's nice".

Regards,
Alia

On Mon, Feb 19, 2018 at 8:15 PM, IJsbrand Wijnands <[email-masked]> wrote:

> There is no reason for an individual BIER OSPF and BIER ISIS registry. The
> point is to align with what ever ISIS and OSPF are using to identify the
> algorithm.
>
> The underlay is separate from the BIER layer, and each underlay can carry
> BIER specific information that is needed for for BIER to make the selection.
>
> Thx,
>
> Ice.
>
>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 19 Feb 2018 21:08:35 -0500

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 <[email-masked]> wrote:

> 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.
>
>> There is no reason for an individual BIER OSPF and BIER ISIS registry.
>> The point is to align with what ever ISIS and OSPF are using to identify
>> the algorithm.
>>

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Tue, 20 Feb 2018 02:09:20 +0000

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 <[email-masked]> on behalf of Alia Atlas <[email-masked]>
Date: Tuesday, February 20, 2018 at 12:05 PM
To: "(Ice) IJsbrand Wijnands" <[email-masked]>
Cc: BIER WG <[email-masked]>, "[email-masked] list" <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> wrote:
Alia,

Regards,
Alia

Hope this clarifies,

Thx,

Ice.

Regards,
Alia

On Mon, Feb 19, 2018 at 7:03 PM, IJsbrand Wijnands <[email-masked]<mailto:[email-masked]>> wrote:
Hi Alia,

Thx,

Ice.

On 19 Feb 2018, at 13:51, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:

Given

  a) option D exists

Regards,
Alia

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 19 Feb 2018 18:19:32 -0800

My reaction to AD's options:

> as is usual for managing code-points, please say so.  No more

+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.

> 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) <
[email-masked]> wrote:

>    - 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 <[email-masked]> on behalf of Alia Atlas <
> [email-masked]>
> *Date: *Tuesday, February 20, 2018 at 12:05 PM
> *To: *"(Ice) IJsbrand Wijnands" <[email-masked]>
> *Cc: *BIER WG <[email-masked]>, "[email-masked] list" <[email-masked]>
> *Subject: *Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions
> and draft-ietf-bier-ospf-extensions
>
>
>
> Ice,
>
>
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 20 Feb 2018 02:32:07 +0000

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.

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.

So Option E seems best to me.

   Les

From: BIER [mailto:[email-masked]] On Behalf Of Tony Przygienda
Sent: Monday, February 19, 2018 6:20 PM
To: Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]>
Cc: BIER WG <[email-masked]>; IJsbrand Wijnands <[email-masked]>; [email-masked] list <[email-masked]>
Subject: Re: [Bier] [Isis-wg] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

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.

+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) <[email-masked]<mailto:[email-masked]>> wrote:
All,

Andrew

From: Isis-wg <[email-masked]<mailto:[email-masked]>> on behalf of Alia Atlas <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 20, 2018 at 12:05 PM
To: "(Ice) IJsbrand Wijnands" <[email-masked]<mailto:[email-masked]>>
Cc: BIER WG <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]> list" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Isis-wg] [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

Ice,

Regards,
Alia

Hope this clarifies,

Thx,

Ice.

Regards,
Alia

Thx,

Ice.

Given

  a) option D exists

Regards,
Alia

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 20 Feb 2018 02:37:08 +0000

I would go with Option B:

This gives best architecture cleanness/flexibility:

-          BIER-specific algorithms that are not tied to anything else, via the BAR value.

-          Anything that is not tied to BIER, via the sub-type. For example, if Flexible Algorithm is needed, the FA number could be specified in the sub-type.

I can provide the text for this option if we end up with going with this option.

Jeffrey

From: BIER [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: Monday, February 19, 2018 4:51 PM
To: BIER WG <[email-masked]>; [email-masked] list <[email-masked]>
Subject: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

Given

  a) option D exists

Regards,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Mon, 19 Feb 2018 22:11:47 -0500

Les,

On Mon, Feb 19, 2018 at 9:32 PM, Les Ginsberg (ginsberg) <[email-masked]
> wrote:

> I am very sympathetic to doing “as little as possible” given we are
> talking about documents which are going through final reviews.
>
> 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.

That was not part of my listed options.

Regards,
Alia

>
>    Les
>
>
>
> *From:* BIER [mailto:[email-masked]] *On Behalf Of *Tony Przygienda
> *Sent:* Monday, February 19, 2018 6:20 PM
> *To:* Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]>
> *Cc:* BIER WG <[email-masked]>; IJsbrand Wijnands <[email-masked]>;
> [email-masked] list <[email-masked]>
> *Subject:* Re: [Bier] [Isis-wg] BAR field length in draft-ietf-bier-isis-extensions
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>
>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 19 Feb 2018 22:25:31 -0500

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 <[email-masked]> wrote:

> Les,
>
> On Mon, Feb 19, 2018 at 9:32 PM, Les Ginsberg (ginsberg) <
> [email-masked]> wrote:
>
>> 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.
>>
>> *Subject:* Re: [Bier] [Isis-wg] BAR field length in
>> draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
>>
>>
>>
>> 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
>> 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
>> *Subject: *Re: [Isis-wg] [Bier] BAR field length in
>> draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions
>>
>>
>>
>> Ice,
>>
>>
>>
>> work for an IGP that isn't link-state?   What about the ideas around
>> using BIER with caches?  Are there issues there?
>> 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
>> 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
>> https://www.iana.org/assignments/igp-parameters/igp-
>> parameters.xhtml#igp-algorithm-types
>>
>> Thx,
>>
>> Ice.
>>
>> 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
>> 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
>> 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
>> 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

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 19 Feb 2018 20:32:59 -0800

Alia,

> I am quite disappointed in the level of discourse; the BIER-WG has traditionally worked very

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 enough to list all the options.

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. 

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.

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.

Thx,

Ice.

> On Mon, Feb 19, 2018 at 9:32 PM, Les Ginsberg (ginsberg) <[email-masked]> wrote:
> 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.
> 
> 
> 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.
> 
> 
> On Mon, Feb 19, 2018 at 6:09 PM, Dolganow, Andrew (Nokia - SG/Singapore) <[email-masked]> wrote:
> 
> All,
> 
>  
> 
> 	• 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)
>  
> 
> 	• 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
>  
>

---

From: IJsbrand Wijnands <[email-masked]>
Date: Mon, 19 Feb 2018 20:36:43 -0800

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.

> 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, of course, respect where you have technical expertise, my response - particularly from a process perspective - is "that's nice".
> 
> Regards,
> Alia
>

---

From: Alia Atlas <[email-masked]>
Date: Mon, 19 Feb 2018 23:47:17 -0500

Ice,

> I don’t think its necessary to try and discredit people like this for

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

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

> • 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)
> • 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
> needs expressed by others, we meet the requirements from those who
> wanted to change the Current status
>
>
> 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

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 19 Feb 2018 20:50:27 -0800

> discussion over the BIER architecture in the future. I know, not your
And would you care to explain in plain technical terms HOW the option B)
will cause problems specifically?  Allocating a BAR type will put the
sub-type (or whatever we call it) under full disposition of the allocator
of the value who can use it as it fits the problem they are out to solve.
You need under your BAR value an IGP registry, go ahead, you want some
flex-algo, feel free, you need some indication of e.g. hash value to
tie-break multiple possible computations, works for you ...  Same can be
achieved with sub-TLVs but as I explained in less backwards compatible
fashion. IETF must have been doing something very wrong in the last 20
years to have registries in place so resolving this mysterious unseen
problems could benefit us all ...

It seems to me like putting BIER BAR type under a clear, well managed
registry is actually the way to close this most interesting 6 months where
no'one had a particular idea where things were supposed to be steered until
things came to head and we finally talk openly about the probably
well-meant intentions (while still being very thin on truly technical
arguments of those intentions I observe) ...

---

From: Senthil Dhanaraj <[email-masked]>
Date: Tue, 20 Feb 2018 04:53:44 +0000

+1 to Option-B
Seems future proof to me.

Thanks,
Senthil

From: BIER [mailto:[email-masked]] On Behalf Of Alia Atlas
Sent: 20 February 2018 03:21
To: BIER WG <[email-masked]>; [email-masked] list <[email-masked]>
Subject: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

Given

  a) option D exists

Regards,
Alia

---

From: Alia Atlas <[email-masked]>
Date: Tue, 20 Feb 2018 00:15:20 -0500

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 the list providing
exact text so we have the details?

For those favoring the current status without an IANA registry, are you
able to handle one being imposed during IESG Review?  It is an obvious
concern to raise.  Are you just prolonging or postponing the discussion?

Regards,
Aka

On Feb 19, 2018 11:53 PM, "Senthil Dhanaraj" <[email-masked]>
wrote:

> *From:* BIER [mailto:[email-masked]] *On Behalf Of *Alia Atlas
> *Sent:* 20 February 2018 03:21
> *To:* BIER WG <[email-masked]>; [email-masked] list <[email-masked]>
> *Subject:* [Bier] BAR field length in draft-ietf-bier-isis-extensions and
> draft-ietf-bier-ospf-extensions
>
>
>

---

From: Senthil Dhanaraj <[email-masked]>
Date: Tue, 20 Feb 2018 05:33:45 +0000

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 for last SI.

I do understand/agree there would be backward/interop issue with older bier-igp drafts if we make a change (say option-B) now for BAR.
Peter Psenak / Ice – Comments ?

Thanks,
Senthil

From: Alia Atlas [mailto:[email-masked]]
Sent: 20 February 2018 10:45
To: Senthil Dhanaraj <[email-masked]>
Cc: BIER WG <[email-masked]>; [email-masked] list <[email-masked]>
Subject: RE: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

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 the list providing exact text so we have the details?

For those favoring the current status without an IANA registry, are you able to handle one being imposed during IESG Review?  It is an obvious concern to raise.  Are you just prolonging or postponing the discussion?

Regards,
Aka

On Feb 19, 2018 11:53 PM, "Senthil Dhanaraj" <[email-masked]<mailto:[email-masked]>> wrote:
+1 to Option-B
Seems future proof to me.

Thanks,
Senthil

From: BIER [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Alia Atlas
Sent: 20 February 2018 03:21
To: BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> list <[email-masked]<mailto:[email-masked]>>
Subject: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

Given

  a) option D exists

Regards,
Alia

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Tue, 20 Feb 2018 09:10:20 +0000

Alia,

As per below i am not aware of a commercial deployment.

Some  implementation assume ability to use BIER specific algorithm. So if we keep 8 bits only, the IANA registry needs to allow that.  The registry being suggested as an option on the list will not allow BIER specific option ( and does not even support experimental bits at all) That would create a functional conflict unless the registry we use is BIER specific. But, as I pointed out, this option does not satisfy others.

Extending field as per Option B would require implementation change but can be accommodated but technically satisfies everyone’s needs I believe.

Andrew

Sent from my iPhone

On Feb 20, 2018, at 4:34 PM, Senthil Dhanaraj <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Senthil

From: Alia Atlas [mailto:[email-masked]]
Sent: 20 February 2018 10:45
To: Senthil Dhanaraj <[email-masked]<mailto:[email-masked]>>
Cc: BIER WG <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> list <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

Regards,
Aka

Thanks,
Senthil

Given

  a) option D exists

Regards,
Alia

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 20 Feb 2018 07:37:24 -0800

all the implementations I am aware off can adjust to Option A) with BAR
registry without problems, neither do I see a problem with option B) given
we are talking only 0/0 being in IGP RFC @ this point in time. thanks. tony

On Mon, Feb 19, 2018 at 9:15 PM, Alia Atlas <[email-masked]> wrote:

>> *Subject:* [Bier] BAR field length in draft-ietf-bier-isis-extensions

---

From: Alia Atlas <[email-masked]>
Date: Tue, 20 Feb 2018 12:02:33 -0500

Thanks for the feedback.

There is one additional aspect here that I think needs further
clarification and discussion.

In the current proposed charter, the first work-item says "Operation of
BIER in
non-congruent topologies, i.e. topologies where not all routers are BIER
capable
can also be addressed."

The newly posted individual draft-zzhang-bier-algorithm-00 suggests having
an algorithm
which is doing an SPF after removing from the topology any non-BIER capable
routers.  This is an example of a BIER-specific constraint.

The individual flex-algo drafts also support adding constraints (similar to
the familiar
constraints from RSVP-TE).

I believe that the need for BIER-specific constraints is one factor driving
the requirement
for a BAR that is specified by the BIER WG.

>From an architectural view, the idea of having the IGP/routing layer have
to understand
BIER specifics seems an undesirable coupling.

Could someone walk me through how this would be supported in each of the
different options?

For Option D, where there is a sub-TLV and that sub-TLV can supply the
additional non-BIER
constraints, I understand it.

For Option B - which some folks are preferring, I do not see understand how
it would work.
For Option A, I do not understand how it would work.

Obviously, this is going far out on a design limb - where flex-algo does
not yet have any IETF
support or adoption, but since it is clear that people's perspectives are
being strongly influenced
by what that might morph into, I think this is important for the whole WG
to understand.

Regards,
Alia

On Tue, Feb 20, 2018 at 10:37 AM, Tony Przygienda <[email-masked]>
wrote:

>>> 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.
>>>
>>>
>>>

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 20 Feb 2018 09:18:33 -0800

> BIER specifics seems an undesirable coupling.

very much so, in stark terms one could say that IGP is BIER signalling
while the fact that we use SPF to perform BIER nexthop calculations is a
convenient first artifact. The architecture RFC does not separate that
clearly IMO but is rather an "example" of practical BIER architecture
embodiment ;-) I do absolutely prefer it that way from practical
standpoint, abstract architectures with all degrees of flexibility written
first are hard to understand and slow to build. BIER delivered on a real
problem but after this first delivery needs the flexibility to spread its
wings into fields where IGP unicast may not be enough IMO and in any case,
IGP unicast computation coupling to BIER specific elements is unnecessary
and undesirable unless one believes e'thing is better off centralized. It
would be _highly_ unfortunate and immense waste of resources if we ended up
building another signalling just so we can perform non unicast IGP
computations.

> For Option B - which some folks are preferring, I do not see understand
> how it would work.
>

BAR = 0 SPF, subtype can be FlexAlgo, any other IGP metric or constraint or
even an IGP registry value, this is a unicast computation
BAR = 1 SPF without BIER routers, subtype can be FlexAlgo, any other IGP
metric or constraint specification, this is a unicast computation
BAR = X (some unicast computation type)  same as 0/1

BAR = Y (multicast specific computation that IGP cnanot perform), subtype
can be anything

What is important to observe that SPF with additional constraints is as
efficient as SPF without those constraints (as long we're talking certain
convex properties AFAIR but I don't want to bore anyone with math, most of
the stuff we use today like max. BW, min. delay has this property).

> For Option A, I do not understand how it would work.

replace subtype with a sub-TLV so it's basically option D). I explained in
my +1/+2 my reasoning why option B) is more preferrable if you are
concerned about backwards compatibility but it's nothing architecturally
important. IGPs were muddling for years without clear distinction between
mandatory/optional TLVs are IDR has and we lived to tell the tale ;-) ...

> by what that might morph into, I think this is important for the whole WG
 AFAIU we have BIER RFCs that form a solid foundation to deliver now.
Things to be done in the future can obviously morph into many directions
and claim to cover any problem presented to them without much risk ...

thanks

--- tony

---

From: Peter Psenak <[email-masked]>
Date: Tue, 20 Feb 2018 18:27:53 +0100

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.

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.

The encoding of the BAR though must be done in a way that it easily 
supports both (1) and (2).

my 2c,
Peter

On 19/02/18 22:51 , Alia Atlas wrote:
> 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.
>
> 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
> 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.
>
> 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.
>
> 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
>
>
>

---

From: Alia Atlas <[email-masked]>
Date: Tue, 20 Feb 2018 12:35:56 -0500

Hi Peter,

Thanks very much for the feedback.

On Tue, Feb 20, 2018 at 12:27 PM, Peter Psenak <[email-masked]> wrote:

> 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.

> 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,

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 20 Feb 2018 09:41:45 -0800

> domain and BIER can simply use these paths instead of computing its own.

+1

Things like BAR 0/1 are clearly unicast computations (SPFs basically given
we're on link-state), many other BARs may be. We have to fully provide for
extended metrics and future constraints like FlexAlgo to make sure that
advanced unicast computations are possible on top of any BIER-specific
computation. This will be choice for many for years to come & the workhorse
of BIER for now.  BIER without IGPs lending its topology
distribution/signalling & first computation help would have not be an easy
thing to introduce.  All kudos to people who had the practical wisdom to go
down that path.

> own topology related computations, independent of IGPs. If they do, I'm not

Discussions came up, not only about specific computations but also about
things where IGP is just signalling and something else completely is doing
computation and it only needs to have all nodes signal that they are using
this off-line computation. Do please read the bier-algorithm draft for
first cases discussed with people seriously interested in deployments.
Yes, we could tell them that IGP is not a viable signalling then and ask
them e.g. to use PCEP to install BIFTs into routers (and some may like this
total control) but that limits the appeal of BIER significantly since we
now do not provide several very important architectural pieces (topology
distribution and simple signalling) or rather would make both inseparable
for no technical beneficial reason I can discern ...

> supports both (1) and (2).

+1

thanks Peter

--- tony

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 20 Feb 2018 09:44:07 -0800

Tony,

> From an architectural view, the idea of having the IGP/routing layer have to understand
> very much so, in stark terms one could say that IGP is BIER signalling while the fact that we use SPF to perform BIER nexthop calculations is a convenient first artifact. The architecture RFC does not separate that clearly IMO but is rather an "example" of practical BIER architecture embodiment ;-) I do absolutely prefer it that way from practical standpoint, abstract architectures with all degrees of flexibility written first are hard to understand and slow to build. BIER delivered on a real problem but after this first delivery needs the flexibility to spread its wings into fields where IGP unicast may not be enough IMO and in any case, IGP unicast computation coupling to BIER specific elements is unnecessary and undesirable unless one believes e'thing is better off centralized. It would be _highly_ unfortunate and immense waste of resources if we ended up building another signalling just so we can perform non unicast IGP computations. 
> 
> Could someone walk me through how this would be supported in each of the different options?
> 
> For Option D, where there is a sub-TLV and that sub-TLV can supply the additional non-BIER
> For Option B - which some folks are preferring, I do not see understand how it would work.
> 
> BAR = 0 SPF, subtype can be FlexAlgo, any other IGP metric or constraint or even an IGP registry value, this is a unicast computation 
> BAR = 1 SPF without BIER routers, subtype can be FlexAlgo, any other IGP metric or constraint specification, this is a unicast computation 
> BAR = Y (multicast specific computation that IGP cnanot perform), subtype can be anything 
> 
> What is important to observe that SPF with additional constraints is as efficient as SPF without those constraints (as long we're talking certain convex properties AFAIR but I don't want to bore anyone with math, most of the stuff we use today like max. BW, min. delay has this property).

My first observation is that what is documented here as “BIER Algorithm Registry” is not an Algorithm, but a constraint. Suppose you want to build a topology with {BIER-ONLY, LOWEST-DELAY, BW}. From an architecture POV, any combination should be allowed. Would you propose to create BAR values to capture every possible combination? I don’t think that scales very well. Constraints would be better served with a BitMask IMO.

Thx,

Ice.

> replace subtype with a sub-TLV so it's basically option D). I explained in my +1/+2 my reasoning why option B) is more preferrable if you are concerned about backwards compatibility but it's nothing architecturally important. IGPs were muddling for years without clear distinction between mandatory/optional TLVs are IDR has and we lived to tell the tale ;-) ...
>  
> 
> Obviously, this is going far out on a design limb - where flex-algo does not yet have any IETF
> support or adoption, but since it is clear that people's perspectives are being strongly influenced
> by what that might morph into, I think this is important for the whole WG to understand.
> 
> 
>  AFAIU we have BIER RFCs that form a solid foundation to deliver now.  Things to be done in the future can obviously morph into many directions and claim to cover any problem presented to them without much risk ... 
> 
> thanks 
> 
> --- tony

---

From: <[email-masked]>
Date: Tue, 20 Feb 2018 17:56:16 +0000

Alia,
We have absolutely concrete requirement to support BEIR over IGP Algorithm (including Flex Algo).  As such Option- E have been  the most viable approach for me. However, based on continues discussions and in my view unsubstantiated/aspiring requirements in regards to define its own algorithm for BEIR future proof flexibility, I have tended to agree to have a right placeholder for IGP Algorithm and Bier Algorithm specified by BIER Info sub-TLV.  It would be interesting to hear other operators use cases to convert aspiring requirements to tangible ones.
As part of small group from members of BIER WG, we did not have  much time to discuss in details interworking option between Bier Algo   and IGP Algo and since of the time pressure related to the Last Call deadline, I opened debate within BIER WG  to extend current BAR field to 16bits  to have enough bits to accommodate any solution that suits the relevant use-cases best in an orthogonal fashion. That is one of the variation of proposed Option-C, just to have a placeholder and then figure out details.

I personally struggle how to achieve deterministic behavior as part of interworking between Bier and IGP algo.  Each of the Algos defines its own set of constraints/computations over a given topology, which leads to dilemma how to reflect via specific code points a desirable  constraint/computation combination.  To get a better grasp of this interworking , I created a flow chart that I can share with the WG in pdf format if it is acceptable.
Below I depicted a few combinations assuming dedicated 1B fields for BAR and FA in Bier info sub-TLV to show the complexity of the problem that we need to solve:
Legend: FA-IGP/Flex Algo; BAR- Bier Algo .
My apology to the folks that already saw it, but I believe it is important to show it.

1.      BIER fully relies on IGP Algo - FA has full control ( constraints/computation) if BAR =0 and FA=X ( where X any value from 0-255)

Solution: BAR=0, FA=0 covered by bier-isis draft, all other use cases such as BAR=0, FA!=0 by new draft.

2.      BIER fully relies on BAR- BAR has full control ( constraints /computation) if BAR = X (where X any value from 1-255) with FA=0.

Solution: BAR!=0, FA=0 Covered by new draft ( example proposed BAR1 as part of bier-algorithm draft should be supported with no issues)

3.      BIER relies on - FA has full constraints control, BAR full computation (Any topology constraints defined by BAR ignored, Any computation defined by FA ignored).

NO SOLUTION:

Interesting to understand which BAR, FA combination can achieve it? ( how to distinguish topology from computation based on value of BAR1 or FA1?)

4.      BIER relies on - BAR has full constraints control, FA full computation. (Any topology constraints defined by FA ignored, Any computation defined by BAR ignored).

NO SOLUTION:

Interesting to understand which BAR, FA combination can achieve it? ( how to distinguish topology from computation based on value of BAR1 or FA1?)

5.      BIER relies on - FA & BAR constraints bundle for overall topology (BAR on top of FA), and BAR has full computation algorithm control (Any computation defined by FA ignored).

NO SOLUTION:

As example, this covers use case for BAR1 over FA for Excluding BIER incapable nodes.  So proposed BAR1 defines the following exclude constraint: to prune any nodes that do not support <SD,MT,BAR,ENC,BSL>, it also defines computation algo: SPF;  so now assume FA1 defines topology constraints as well and SPF as computation algo. So which attribute will trigger to ignore FA computation?.

6.      BIER relies on - FA & BAR constraints bundle for overall topology(BAR on top of FA), and FA has full computation algorithm control (Any computation defined by BAR ignored).
NO SOLUTION:
Similar to the case above, but in this case dilemma is which attribute will define to ignore BAR computation?

I mentioned a few times a bier-algorithm draft that just got released by Jeffrey, the draft solve the issue of EXCLUDING BIER INCAPABLE NODES.  Just for reference, FA  registry as part of Option-E can solve this problem as well with no major compromises.
I also want to point out that from above use cases may be it is not so obvious, but you can derive that BAR is not just complements IGP algorithm it is actually in competition with given underlay that provides underlay functions for BIER.  It is nice when operators have a choice, as long as it can be deterministic.
Scenarios above might be viable or not, as such it is important to define the scope which use cases we are trying to solve.
So back to proposed options.
I personally like Eric proposed option -two independed 1Byte filed one for IGP Algo and another one for BUAM : the "BIER Underlay Algorithm Modifier" registry.  The way the underlay paths are computed for a given BIER sub-domain is determined by the pair of codepoints: <IGP Algorithms codepoint, BIER Underlay Algorithm Modifier codepoint>.
Not sure why it is not in a list of proposed options since I saw a lot of support for it on the WG.
It sort of Option-B but allow more independence between BAR(BUAM) from IGP Algo, which personally attracts me since one cannot screw up another one and at the same time complement each other as part of constraints only.  It might lock thing out for future development but it might bring stability.
But regardless, we need to understand which use cases we are trying to cover and how the proposed option-B will apply.  I would reiterate your request for specific recommendation for the draft from folks that recommend option B.
Thanks
Arkadiy

From: BIER <[email-masked]> on behalf of Alia Atlas <[email-masked]>
Date: Tuesday, February 20, 2018 at 12:03 PM
To: BIER WG <[email-masked]>
Cc: "[email-masked] list" <[email-masked]>
Subject: Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

Thanks for the feedback.

There is one additional aspect here that I think needs further clarification and discussion.

In the current proposed charter, the first work-item says "Operation of BIER in
non-congruent topologies, i.e. topologies where not all routers are BIER capable
can also be addressed."

The newly posted individual draft-zzhang-bier-algorithm-00 suggests having an algorithm
which is doing an SPF after removing from the topology any non-BIER capable
routers.  This is an example of a BIER-specific constraint.

The individual flex-algo drafts also support adding constraints (similar to the familiar
constraints from RSVP-TE).

I believe that the need for BIER-specific constraints is one factor driving the requirement
for a BAR that is specified by the BIER WG.

Regards,
Alia

On Tue, Feb 20, 2018 at 10:37 AM, Tony Przygienda <[email-masked]<mailto:[email-masked]>> wrote:
all the implementations I am aware off can adjust to Option A) with BAR registry without problems, neither do I see a problem with option B) given we are talking only 0/0 being in IGP RFC @ this point in time. thanks. tony

On Mon, Feb 19, 2018 at 9:15 PM, Alia Atlas <[email-masked]<mailto:[email-masked]>> wrote:
I have one additional question for those with implementations or testing them.

Regards,
Aka

Thanks,
Senthil

Given

  a) option D exists

Regards,
Alia

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=JA6g2ZDvIPLQHZqHQByKQq-jvOcxu4cQskARppQFqZc&m=cYIkQCWXJi27_weFtXfbTtRIxqKfBB7CnvKYIxKUb40&s=To9sNa0hNd54cgx-5K9J1xzffDoDHgUVMvuHsZvJnLY&e=>

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 20 Feb 2018 10:00:19 -0800

>
> BAR = 0 SPF, subtype can be FlexAlgo, any other IGP metric or constraint
> or even an IGP registry value, this is a unicast computation
> My first observation is that what is documented here as “BIER Algorithm
> Registry” is not an Algorithm, but a constraint. Suppose you want to build
> a topology with {BIER-ONLY, LOWEST-DELAY, BW}. From an architecture POV,
> any combination should be allowed. Would you propose to create BAR values
> to capture every possible combination? I don’t think that scales very well.
> Constraints would be better served with a BitMask IMO.
>
>
Ice, I assume we talk the unicast computation case. Let's discuss that in
architectural terms that easily map down to the case on hand IMO:

When faced with a combinatorial problem that you mention (often caused by
coupling of many things to each other) a good approach is layering (or
think about it as indirection), i.e. the layers become decoupled and can be
developed/progressed independently. Problem with decoupling is that it
often is inefficient (indirections).

Now, what BAR registry would give us is a "layering of constraints" if you
want, i.e.  BAR=1 (since this is a very tanglible example, another one
would be max. degree of fanout or things like max-label-depth e.g.)  would
take care of the BIER specific constraints without IGP knowing about it in
architectural terms.  On top of that IGP applies its constraints (BW,
delay, whatever) but it's really not  BIER problem, we are just happy
riders on coattails of the hard IGP work ;-)

To address the "efficienty" constraint one has to be very deeply steeped
into IGP SPF computations but the result is that an implementation can
easily incorporate constraints of all layers into a single computation (SPF
practically speaking) unless they lead to NP complete combinations (so
.e.g. having something that is max-bw @ guaranteed delay is far from
simple) ...

So let's say we put the IGP signalling under a new cool IGP  (eeeh, I'm
building one ;-)  and we do not want to shake their whole IGP standard
saying "hey, you know, we have this BIER Stuff you must encode on your IGP
elements (beside us being a subTLV) and put in your registries to do the
right thing", if we have BAR we can just tell them, ok, encoding wise, jsut
give us your SPF-on-steroids registry and we use that as subtype,
underneath that we plug in BAR in our encoding, i.e. we just use them as
signalling channel while constraining the SPF. We're done.  Obviously the
SPF has to be modified to respect the union of all constraints but the
alternative is worse, i.e. I have to be running multiple passes prunning
things (which are practically far less desirable since we are loosing very
cool stuff like LFA which I'm sure we could solve as well but get for free
if we just prune the SPF @ runtime)

I do hope that parses and I  make sense. I tried to be as terse as I
managed and I know I am bad at that ...

Now, whether you believe that IGP signalling must be used for IGP dictated
unicast computations only and IGP must be aware of BIER elements in its
registries/encoding is a matter of taste to a degree (architecture of
protocols is as much craft as art) but as to technial advantages of that I
see none while I see unnecessary coupling ...

--- tony

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 20 Feb 2018 10:25:28 -0800

Tony,

> Now, what BAR registry would give us is a "layering of constraints" if you want, i.e.  BAR=1 (since this is a very tanglible example, another one would be max. degree of fanout or things like max-label-depth e.g.)  would take care of the BIER specific constraints without IGP knowing about it in architectural terms.  On top of that IGP applies its constraints (BW, delay, whatever) but it's really not  BIER problem, we are just happy riders on coattails of the hard IGP work ;-) 

If you want to build a table for BIER, you need to have a way to associate/signal the different constraints that need to be used. In my mind, this is not coming from the IGP, but needs to be signalled in the context BIER. Like how you signal BIER-ONLY as algorithm. Or, statically configured as part of the Sub-Domain. Obviously what is required here is a architecture draft that explains how this all should work.

> 
> To address the "efficienty" constraint one has to be very deeply steeped into IGP SPF computations but the result is that an implementation can easily incorporate constraints of all layers into a single computation (SPF practically speaking) unless they lead to NP complete combinations (so .e.g. having something that is max-bw @ guaranteed delay is far from simple) ... 
> 
> So let's say we put the IGP signalling under a new cool IGP  (eeeh, I'm building one ;-)  and we do not want to shake their whole IGP standard saying "hey, you know, we have this BIER Stuff you must encode on your IGP elements (beside us being a subTLV) and put in your registries to do the right thing", if we have BAR we can just tell them, ok, encoding wise, jsut give us your SPF-on-steroids registry and we use that as subtype, underneath that we plug in BAR in our encoding, i.e. we just use them as signalling channel while constraining the SPF. We're done.  Obviously the SPF has to be modified to respect the union of all constraints but the alternative is worse, i.e. I have to be running multiple passes prunning things (which are practically far less desirable since we are loosing very cool stuff like LFA which I'm sure we could solve as well but get for free if we just prune the SPF @ runtime) 
> 
> I do hope that parses and I  make sense. I tried to be as terse as I managed and I know I am bad at that … 

You lost me, sorry…

Thx,

Ice.

> 
> Now, whether you believe that IGP signalling must be used for IGP dictated unicast computations only and IGP must be aware of BIER elements in its registries/encoding is a matter of taste to a degree (architecture of protocols is as much craft as art) but as to technial advantages of that I see none while I see unnecessary coupling ...
> 
> --- tony 
>

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 20 Feb 2018 10:31:31 -0800

On Tue, Feb 20, 2018 at 10:25 AM, IJsbrand Wijnands <[email-masked]> wrote:

> Tony,
>
> > Now, what BAR registry would give us is a "layering of constraints" if
> you want, i.e.  BAR=1 (since this is a very tanglible example, another one
> If you want to build a table for BIER, you need to have a way to
> associate/signal the different constraints that need to be used. In my
> mind, this is not coming from the IGP, but needs to be signalled in the
> context BIER. Like how you signal BIER-ONLY as algorithm. Or, statically
> configured as part of the Sub-Domain. Obviously what is required here is a
> architecture draft that explains how this all should work.
>

yes, staticially configured BIER computaton constraints could work but then
routers cannot detect mismatch. A very heavy disadvantage ...

Architecture is something we can talk in London if you see value in that,
sure. For the record, I however vastly prefered the direction (mainly)
you/Eric gave from start on which was "enough architecture to get important
first application done", hence I was never pushing some some grand
cathedral building scheme. Maybe after this is in place we should have this
in London, it's the call of the day one core group that carried the banner
where there was nothing but first hill to take ;-)

My suggestion is, let us work out either option B) or Eric's proposal as
flexible and orthogonal scheme to ground the IGPs and then fall out the
rest over it ...  As you observed, I'm big believer in maybe overbuilding a
tad in flexibility or size in control plane to have architectural wiggle
room while in forwarding path one has to be extremely frugal to get the
silicon @ cost ...

> managed and I know I am bad at that …
>
> You lost me, sorry…
>

sorry, email is limited ... Not sure how to deal with that ...

--- tony

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 20 Feb 2018 18:36:02 +0000

Hi Alia, 
I support Peter's position on the draft. While I believe at 8 bit space is more than enough to support  variations of the BIER algorithm for the foreseeable future, I think reaching consensus is more critical than the precise encoding. 

Thanks,
Acee

On 2/20/18, 12:28 PM, "Isis-wg on behalf of Peter Psenak (ppsenak)" <[email-masked] on behalf of [email-masked]> wrote:

    Hi Alia,

    
    
    my 2c,
    Peter

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 20 Feb 2018 10:38:14 -0800

> ...
>
> It sort of Option-B but allow more independence between BAR(BUAM) from IGP
> Algo, which personally attracts me since one cannot screw up another one
> and at the same time complement each other as part of constraints only.  It
> might lock thing out for future development but it might bring stability.
>
> But regardless, we need to understand which use cases we are trying to
> cover and how the proposed option-B will apply.  I would reiterate your
> request for specific recommendation for the draft from folks that recommend
> option B.
>
>
Arkadiy, such a text was extended as strawman in consensus building process
and I include it here on your request. Observe that this represents no
consensus, just further input into building consensus on this list from my
personal side so you have more "meat" to see what we're talking about ...

--- tony

---

From: Alia Atlas <[email-masked]>
Date: Tue, 20 Feb 2018 13:39:23 -0500

Hi Acee,

Thanks for your feedback.  I appreciate and agree with the perspective.

Regards,
Alia

On Tue, Feb 20, 2018 at 1:36 PM, Acee Lindem (acee) <[email-masked]> wrote:

> Hi Alia,
> I support Peter's position on the draft. While I believe at 8 bit space is
> more than enough to support  variations of the BIER algorithm for the
> foreseeable future, I think reaching consensus is more critical than the
> precise encoding.
>
> Thanks,
> Acee
>
> On 2/20/18, 12:28 PM, "Isis-wg on behalf of Peter Psenak (ppsenak)" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     Hi Alia,
>
>     >     from the BAR type.   We can debate over the registration policy
> for
>     > the BAR type.
>     >
>     >    c) I do not see strong consensus for change to one particular
> other
>     > option
>     >
>     > IF you prefer or can accept the current status, but think there
> should
>     > be an IANA registry

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 20 Feb 2018 10:40:21 -0800

+1 obviously ...

On Tue, Feb 20, 2018 at 10:39 AM, Alia Atlas <[email-masked]> wrote:

>> I support Peter's position on the draft. While I believe at 8 bit space
>> is more than enough to support  variations of the BIER algorithm for the

---

From: Eric C Rosen <[email-masked]>
Date: Tue, 20 Feb 2018 14:43:01 -0500

On 2/20/2018 12:56 PM, [email-masked] wrote:
>
> I personally like Eric proposed option -two independed 1Byte filed one 
> for IGP Algo and another one for BUAM : the "BIER Underlay Algorithm 
> Modifier" registry.  The way the underlay paths are computed for a 
> given BIER sub-domain is determined by the pair of codepoints: <IGP 
> Algorithms codepoint, BIER Underlay Algorithm Modifier codepoint>.
>
> It sort of Option-B but allow more independence between BAR(BUAM) from 
> IGP Algo
>

I'm also wondering what's wrong with this proposal as a way of moving 
forward.  The only real change I'd make to it is that the first 
one-octet field would either be a codepoint from the IGP Algorithms 
registry or a Flex-Algo codepoint.  Since the former are in the range 
1-127 and the latter in the range 128-254, no ambiguity is possible.

With regard to the question of why it makes sense to use an IGP 
Algorithms codepoint, I think the argument is the following.  Per the 
architecture, BIER relies on a routing underlay to tell it the next hop 
for a given BFER.  Per the architecture, the routing underlay may use 
the exact same decision procedure applied to the exact same topology as 
can be applied for unicast routing.  One way of identifying a unicast 
routing decision procedure  is with codepoints from the IGP Algorithms 
registry and/or Flex-Algo codepoints.  Thus it makes sense for the IGP 
signaling to use these codepoints as a way of providing the BIER layer 
information about the routing underlay.

With regard to the question of why it makes sense to have a second 
one-octet BIER-specific field, I think the argument is the following.  
The architecture does not require BIER to use a routing underlay that 
applies a decision procedure that is useful for or even applicable to 
unicast packets.   In such a case, there might not be a way to identify 
the decision procedure with a codepoint from the IGP Algorithms registry 
or even with a Flex-Algo codepoint.   So it's useful to have a codepoint 
that does not have to hold values from the IGP Algorithms registry and 
does not need to have Flex-Algo codepoints.

There is also some worry that there may in the future be a lot of 
arguments about populating IGP Algorithms registry, and it would be good 
to have a way to extend BIER by allocating codepoints that help identify 
the routing underlay, but that might not be useful for unicast applications.

To some extent, this is all a tempest in a teapot, because the 
extensible TLV structure can be used, as Alia points out, to work around 
any codepoint problems.  Of course, continually adding TLVs to modify 
the interpretation of other TLVs can becomes a problem in itself.

I think the most compelling argument for adding the second codepoint 
field is that it provide more options for exploring the issues that 
might arise as production deployments begin.

I don't believe that any field containing a codepoint should ever be 
created without an association to a registry.  That makes squatting and 
future codepoint clash inevitable.
Thus I think the current documents, which have a one-octet field that is 
not associated with a registry at all, are not really acceptable.  So I 
don't see any way to move forward now other than with a compromise like 
the one I suggested.  This is not exactly Alia's option B, because the 
second codepoint is not properly thought of as a sub-type of the other.

---

From: Peter Psenak <[email-masked]>
Date: Tue, 20 Feb 2018 21:03:39 +0100

Hi Alia,

On 20/02/18 18:35 , Alia Atlas wrote:
> On Tue, Feb 20, 2018 at 12:27 PM, Peter Psenak <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi Alia,
>
>     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.
>
>
> 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

>              from the BAR type.   We can debate over the registration
>         policy for
>         the BAR type.
>
>             c) I do not see strong consensus for change to one
>         particular other
>         option
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/bier>
>
>
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 20 Feb 2018 23:05:01 +0000

When I said I prefer Option B earlier, I was actually referring to something similar to what was discussed below between Eric and Arkadiy, though with some differences.

Whether we call it Option F or whatever, I have the following text prepared for everyone to review and comment. Ironically, I started with the OSPF spec J

2.1.  BIER Sub-TLV

   0                   1                   2                   3

   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |              Type             |             Length            |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   | Sub-domain-ID |     MT-ID     |              BFR-id           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |    BART       |     BARM      |            Reserved           |

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   |                      Sub-TLVs (variable)                      |

   +-                                                             -+

   |                                                               |

BART: A single-octet specifying the Bier AlgoRiThm used to calculate underlay

      paths to reach BFERs. Values are allocated from the BIER Algorithm Registry.

     Value 0 indicates the basic Shortest Path First algorithm using IGP metric.

BARM: A single-octet specifying the BIER AlgoRithm Modififer that can be used

      to either modify, enhance or replace calculation of underlay paths to

      reach BFERs as defined by the BART value.

In this document version, both the BART and BARM octets MUST be zero. If an

implementation based on this document receives a non-zero BART or BARM octet,

it MUST treat it as an error and ignore the received BIER sub-TLV.

BART and BARM are independent of each other, and the BARM value identify

an IGP Algorithm (either those 0~128 values registered in the “IGP Algorithm Type”

registry, or a number that identifies a Flexible Algorithm [<reference here>],

which is also considered as an IGP Algorithm.

Future specifications may specify BART values that change the

interpretation of the BARM octet. Those specifications must handle backwards

compatibility issues (or simply declare that backwards compatibility is not

required - the deployment will then require the operator to make sure that all

routers in the subdomain conform to the same specification).

[note that will not be added to the spec: if someone wants define a BART value

in the future that changes the meaning of BARM, he would need

to write a spec to explicitly state that and get the spec approved. W/o that,

the BARM field is always interpreted as an IGP Algorithm]

4.  IANA Considerations

  IANA is requested to set up a registry called "BIER Algorithm Registry".

  The registration policies for this registry are

   * "Standards Action" ([RFC5226] and [RFC7120]) for values 0-240

   * "Experimental Use" for values 240-255

   The initial values in the BIER Algorithm Registry are:

   0: Shortest Path First (SPF) algorithm based on IGP link metric

   1-255: Unassigned

Comments?

Jeffrey

From: BIER [mailto:[email-masked]] On Behalf Of Eric C Rosen
Sent: Tuesday, February 20, 2018 2:43 PM
To: [email-masked] <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

On 2/20/2018 12:56 PM, [email-masked]<mailto:[email-masked]> wrote:

I personally like Eric proposed option -two independed 1Byte filed one for IGP Algo and another one for BUAM : the "BIER Underlay Algorithm Modifier" registry.  The way the underlay paths are computed for a given BIER sub-domain is determined by the pair of codepoints: <IGP Algorithms codepoint, BIER Underlay Algorithm Modifier codepoint>.
Not sure why it is not in a list of proposed options since I saw a lot of support for it on the WG.
It sort of Option-B but allow more independence between BAR(BUAM) from IGP Algo

I'm also wondering what's wrong with this proposal as a way of moving forward.  The only real change I'd make to it is that the first one-octet field would either be a codepoint from the IGP Algorithms registry or a Flex-Algo codepoint.  Since the former are in the range 1-127 and the latter in the range 128-254, no ambiguity is possible.

With regard to the question of why it makes sense to use an IGP Algorithms codepoint, I think the argument is the following.  Per the architecture, BIER relies on a routing underlay to tell it the next hop for a given BFER.  Per the architecture, the routing underlay may use the exact same decision procedure applied to the exact same topology as can be applied for unicast routing.  One way of identifying a unicast routing decision procedure  is with codepoints from the IGP Algorithms registry and/or Flex-Algo codepoints.  Thus it makes sense for the IGP signaling to use these codepoints as a way of providing the BIER layer information about the routing underlay.

With regard to the question of why it makes sense to have a second one-octet BIER-specific field, I think the argument is the following.  The architecture does not require BIER to use a routing underlay that applies a decision procedure that is useful for or even applicable to unicast packets.   In such a case, there might not be a way to identify the decision procedure with a codepoint from the IGP Algorithms registry or even with a Flex-Algo codepoint.   So it's useful to have a codepoint that does not have to hold values from the IGP Algorithms registry and does not need to have Flex-Algo codepoints.

There is also some worry that there may in the future be a lot of arguments about populating IGP Algorithms registry, and it would be good to have a way to extend BIER by allocating codepoints that help identify the routing underlay, but that might not be useful for unicast applications.

To some extent, this is all a tempest in a teapot, because the extensible TLV structure can be used, as Alia points out, to work around any codepoint problems.  Of course, continually adding TLVs to modify the interpretation of other TLVs can becomes a problem in itself.

I think the most compelling argument for adding the second codepoint field is that it provide more options for exploring the issues that might arise as production deployments begin.

I don't believe that any field containing a codepoint should ever be created without an association to a registry.  That makes squatting and future codepoint clash inevitable.
Thus I think the current documents, which have a one-octet field that is not associated with a registry at all, are not really acceptable.  So I don't see any way to move forward now other than with a compromise like the one I suggested.  This is not exactly Alia's option B, because the second codepoint is not properly thought of as a sub-type of the other.

---

From: IJsbrand Wijnands <[email-masked]>
Date: Tue, 20 Feb 2018 16:19:27 -0800

Hi Jeffrey,

> When I said I prefer Option B earlier, I was actually referring to something similar to what was discussed below between Eric and Arkadiy, though with some differences.

ICE: Yes, I think this proposal has merit and a possible consensus for those who prefer to align with IGP and those who like to have BIER specific algorithms.

> Whether we call it Option F or whatever, I have the following text prepared for everyone to review and comment. Ironically, I started with the OSPF spec J

ICE: In write up below its more clear on what BARM is, maybe change the name to make it more explicit this is the IGP Algorithm registry. Maybe call it BIER IGP AlgoriThm (BIAT)?

> which is also considered as an IGP Algorithm.

ICE: Ok, I like that. Both values are independent of each other. This means the developments for both BIER Algorithm and IGP Algorithm can move forward without blocking each other.

> interpretation of the BARM octet. Those specifications must handle backwards

ICE: This creates a potential dependency which I think we should avoid. I think there are possible use-cases where the combination of the two values could be valuable. But since we don’t yet know what that is, lets not speculate on it. Let keep both values as equal importance without interdependency.

>    0: Shortest Path First (SPF) algorithm based on IGP link metric

ICE: We should probably create a registry for BIAT, and make clear in the draft the values are identical to the IGP Algorithm registry. In an ideal world we would like to point to it, but that might get the draft stuck. Or, if there are other ideas on how to deal with that, would be good to know...

> Comments?

I think this is good, making the two values of equal importance makes sure nobody is blocked on each other and we can move on.

Thanks Jeffrey,

Ice.

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 20 Feb 2018 16:39:31 -0800

> ICE: This creates a potential dependency which I think we should avoid. I
> think there are possible use-cases where the combination of the two values
> could be valuable. But since we don’t yet know what that is, lets not
> speculate on it. Let keep both values as equal importance without
> interdependency.
>

And I happen to think that if this proposal has any merit this is precisely
the paragraph we have to keep to make sure that not every possible BART
value is being slaved to IGP Registry Algorithm a.k.a as BARM then ...
Without this section we would be mandating that BARM is always an IGP
algorithm or FA so basically it would mandate IGP Algorithm registry as the
only option to perform a calculation making BART possibly pretty much
useless ... Having a registry being mapped 1:1 into  another registry known
as identity makes them both them the same thing by another name.

So, to get anywhere close to consensus let's get bit less creative maybe
and stick to the four letters of the alphabet that the AD extended as a
wide playing field and the WG seems to converge around ... Or otherwise
stick to option F) unmodified and see who's interested in it unless you
insist on creating an option G) ...

thanks

--- tony

---

From: Xiejingrong <[email-masked]>
Date: Wed, 21 Feb 2018 09:39:27 +0000

I vote for D. The reason is the following:
(1) 8 bit is enough currently.
(2) 16 bits is not enough, considering parameters for a algorithm. For example, IMO, I need one or more IP address(es) as parameters of a Algorithm.
(3) Do Unicast Algorithms natually fit to BIER? I am not sure. considering the following:
(3.1) BIER with non-MPLS encapsulation may not be able to run over a Label-Switch-Path, but Unicast can.
(3.2) Thinking a Unicast Algorithm named "over a RSVP-TE tunnel (shortcut tunnel)".
(4) Even if some unicast algorithms can be supported by BIER, do they need to be reviewed by BIER before vendors implement ?
(4.1) There is 0 and 1 algorithm defined in SR, should they be supported by BIER now ? or after being reviewed and sure and assigned a BAR value by BIER-WG ?
(4.2) If a new Unicast Algorithm is created, should it be supported by BIER right now ?

My suggestions:
(1) BAR field in OSPF/ISIS draft is BIER specific. Current 8 bit is enough.
(2) Unicast Algorithms should be reviewed by BIER WG and assigned a BAR value before it is used.
(3) We can apply for a value named "BIER Reserved" in IGP Algorithm registery, to be sure it is not used for any Unicast Algorithm, and then we can do a 1:1 map from Unicast Algorithm to BIER BAR, if the unicast algorithm is reviewed by BIER WG.

--------------------------------------------------
XieJingrong
发件人：Alia Atlas
收件人：BIER WG,[email-masked] list,
时间：2018-02-20 05:51:36
主 题：[Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

Given

  a) option D exists

Regards,
Alia

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Wed, 21 Feb 2018 13:15:40 +0000

Inline.

And I happen to think that if this proposal has any merit this is precisely the paragraph we have to keep to make sure that not every possible BART value is being slaved to IGP

Ice: No, BART is not being slaved here. If BARM is 0, BART is all yours.

Registry Algorithm a.k.a as BARM then ... Without this section we would be mandating that BARM is always an IGP algorithm or FA so basically it would mandate IGP

Ice: Yes, BARM will be the IGP algorithm. That is to accommodate the people on the list who are of the opinion that aligning with IGP is important.

Algorithm registry as the only option to perform a calculation making BART possibly pretty much useless ... Having a registry being mapped 1:1 into  another registry known

Ice: I don't understand why you are saying this. If BARM is 0, BART is all yours. Its unfortunate that a large part of the discussion is dominated by perceived functionality in the form of BIER Algorithm, while there is no architecture draft that describes how it should work and no discussion has happen in any IETF meeting, which leaves us all guessing. I think Alia asked a very good question on the list regarding "constraints". It is not at all clear if BART is a Algorithm or a Constraint. I think from your response you're saying its both, which seems wrong IMO.. To me Alia's question is still open, but that that may be because I could not decipher the rest of your response.

So, to get anywhere close to consensus let's get bit less creative maybe and stick to the four letters of the alphabet that the AD extended as a wide playing field and the WG seems to converge around ... Or otherwise stick to option F) unmodified and see who's
interested in it unless you insist on creating an option G) ...

Ice: Jeffrey brought option F to the list in order to discuss it, that is what we are doing, and that is how you can converge on a solution and reach consensus. That is better compared to a vote on an option and everybody walks away with a different interpretation of it.

Thx,

Ice.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 21 Feb 2018 13:20:24 +0000

Hi Ice,

From: IJsbrand Wijnands (iwijnand) [mailto:[email-masked]]
Sent: Wednesday, February 21, 2018 8:16 AM
To: Tony Przygienda <[email-masked]>
Cc: IJsbrand Wijnands <[email-masked]>; Jeffrey (Zhaohui) Zhang <[email-masked]>; [email-masked] <[email-masked]>; [email-masked]; [email-masked]; Eric Rosen <[email-masked]>
Subject: Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

Inline.

Zzh> BART is BIER’s no matter what BARM is; not only when BARM is 0.

Jeffrey

Thx,

Ice.

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Wed, 21 Feb 2018 13:28:38 +0000

Jeffrey,

Ice: Yes, sorry, I agree, BART is always BIER and BARM is always IGP.

THx,

Ice.

Jeffrey

Thx,

Ice.

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Wed, 21 Feb 2018 13:39:41 +0000

Ice: What I meant to clarify is that BART is not slaved to BARM (IGP) and v.s., if BART is used, BARM will just be 0.

Thx,

Ice.

THx,

Ice.

Jeffrey

Thx,

Ice.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 21 Feb 2018 14:17:47 +0000

To make it absolutely clear using an example: even with <BART 1, BARM 200> it is still that the two fields are independent of each other.
This particular combination means “apply BART 1” to “Flexible-Algo 200”, where “Flexible-Algo 200” could be “exclude red links”, while “BART 1” could be “skip BIER incapable routers”.

This is a very practical and concrete example showing the advantage of having two separate fields. Other ways could be used to achieve the same result, but they’re more cumbersome.

Jeffrey

From: BIER [mailto:[email-masked]] On Behalf Of IJsbrand Wijnands (iwijnand)
Sent: Wednesday, February 21, 2018 8:40 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]; [email-masked]; IJsbrand Wijnands <[email-masked]>; [email-masked] <[email-masked]>; Eric Rosen <[email-masked]>
Subject: Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

Thx,

Ice.

THx,

Ice.

Jeffrey

Thx,

Ice.

---

From: "IJsbrand Wijnands (iwijnand)" <[email-masked]>
Date: Wed, 21 Feb 2018 14:32:40 +0000

Jeffrey,

I agree.

But, which combinations are supported must be documented in an IETF draft. We don't assume any combinations to just work without being specified.

Thx,

Ice.

Jeffrey

From: BIER [mailto:[email-masked]] On Behalf Of IJsbrand Wijnands (iwijnand)
Sent: Wednesday, February 21, 2018 8:40 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; IJsbrand Wijnands <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>; Eric Rosen <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

Thx,

Ice.

THx,

Ice.

Jeffrey

Thx,

Ice.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 21 Feb 2018 09:44:33 -0500

First, I greatly appreciate the rapid education I have gotten on why the
different aspects of this are important.

Let us explore some details on the plan for an 8-bit BART and an 8-bit BARM
that are independent.  Jeffrey,
I really appreciate your bringing this option to the list.  It simplifies
the option B idea of subtypes away and there
seems to be a good amount of interest in it.

My concern is that we specify adequately how the codepoints in BART and
BARM interact.

One of the challenges with doing so has been, IMHO, a bit of terminology
where we are describing these as
algorithms but in fact these are tuples consisting of a set of constraints
and a base algorithm.

BART is the BIER layer's constraints (BC) and algorithm (BA).  Let us
describe this as BART =  (BC, BA).

BARM is the Routing layer's constraints (RC) and algorithm (RA).  Let us
describe this as BARM = (RC, RA).

Let me give some concrete examples.

Consider a case of BART=4 which is known to mean (prune non-BIER routers,
use SPF).
BARM = 200, which is known to mean (prune links with BW <10G, use SPF)

It is desirable to have an outcome that is (prune non-BIER routers and
links with BW < 10G, use SPF).

This can work algorithmically because the constraints are the types that
we've seen before for RSVP-TE.

What I think we need to make the independent 8-bit BART plus 8-bit BARM
work is a clear specification
of the interaction. I think that is:

Start with the topology Topology.
1) Apply the constraints represented by the BART  BC(Topology)
2) Apply the constraints represented by the BARM  RC(BC(Topology))
3) Select the algorithm A as follows:  use BA or if BA is "empty", use RA.
    Run A on RC(BC(Topology)) to get the next-hops and information for the
BIFT.

Key points on the algorithm aspect are:
a) BIER is the higher layer, so it is assumed to know better which
algorithm should be used.
b) It is possible for BA to be "empty"  (as the BARM=0 case discussed) so
that the algorithm
    falls through to whatever is RA.

With that, the BART can be exactly the IGP Algorithms registry.
All the IGP Algorithms are available.   For the 2 currently defined, the
constraints are empty.

For the BARM, all the necessary constraints can be applied first.

To define a code-point for BARM, the following information is necessary:
   i) Constraints
   ii) Can constraints be additive  (default yes unless specified otherwise)
   iii) What is the algorithm - or is it "empty"

I am bringing forth this description now because I am concerned that the
interaction between
BARM and BART is not adequately defined to be published - but I see the
strong interest in
this as the solution and, from my understanding of the problem, agree.

Please comment ASAP.

Jeffrey & Les, is this something that you can turn into clear text for the
drafts?

Regards,
Alia

On Wed, Feb 21, 2018 at 9:17 AM, Jeffrey (Zhaohui) Zhang <[email-masked]

> To make it absolutely clear using an example: even with <BART 1, BARM 200>
> it is still that the two fields are independent of each other.
>
> This particular combination means “apply BART 1” to “Flexible-Algo 200”,
> where “Flexible-Algo 200” could be “exclude red links”, while “BART 1”
> could be “skip BIER incapable routers”.
>
>
>
> This is a very practical and concrete example showing the advantage of
> having two separate fields. Other ways could be used to achieve the same
> result, but they’re more cumbersome.
>
>
>
> Jeffrey
>
>
>
> *From:* BIER [mailto:[email-masked]] *On Behalf Of *IJsbrand
> Wijnands (iwijnand)
> *Sent:* Wednesday, February 21, 2018 8:40 AM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> *Cc:* [email-masked]; [email-masked]; IJsbrand Wijnands <[email-masked]>;
> [email-masked] <[email-masked]>;
> Eric Rosen <[email-masked]>
> *Subject:* Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions
> Ice: What I meant to clarify is that BART is not slaved to BARM (IGP) and
> v.s., if BART is used, BARM will just be 0.
>
>
>
> Thx,
>
>
>
> Ice.
>
>
>
>
>
> THx,
>
>
>
> Ice.
>
>
>
>
>
> Jeffrey
>
>
>
> Registry Algorithm a.k.a as BARM then ... Without this section we would be
> mandating that BARM is always an IGP algorithm or FA so basically it would
> mandate IGP
>
>
>
> Ice: Yes, BARM will be the IGP algorithm. That is to accommodate the
> people on the list who are of the opinion that aligning with IGP is
> important.
>
>
>
> Algorithm registry as the only option to perform a calculation making BART
> possibly pretty much useless ... Having a registry being mapped 1:1 into
> another registry known
>
>
>
> Ice: I don't understand why you are saying this. If BARM is 0, BART is all
> yours. Its unfortunate that a large part of the discussion is dominated by
> perceived functionality in the form of BIER Algorithm, while there is no
> architecture draft that describes how it should work and no discussion has
> happen in any IETF meeting, which leaves us all guessing. I think Alia
> asked a very good question on the list regarding "constraints". It is not
> at all clear if BART is a Algorithm or a Constraint. I think from your
> response you're saying its both, which seems wrong IMO.. To me Alia's
> question is still open, but that that may be because I could not decipher
> the rest of your response.
>
>
>
> stick to option F) unmodified and see who's
>
> Ice: Jeffrey brought option F to the list in order to discuss it, that is
> what we are doing, and that is how you can converge on a solution and reach
> consensus. That is better compared to a vote on an option and everybody
> walks away with a different interpretation of it.
>
>
>
> Thx,
>
>
>
> Ice.
>
>

---

From: Alia Atlas <[email-masked]>
Date: Wed, 21 Feb 2018 10:09:05 -0500

Hi Jeffrey,

Yes, I was rushing & may have mangled the terminology in the final bit.

The routing layer 8-bit field can be from the IGP Algorithm registry.

Thanks for catching it & for your willingness to write this up more clearly!

Regards,
Aka

On Feb 21, 2018 10:05 AM, "Jeffrey (Zhaohui) Zhang" <[email-masked]>
wrote:

> Hi Alia,
>
>
>
> Thanks for articulating it very clearly, and bring out the issue of having
> a clear specification on the interaction.
>
>
>
> I need one clarification from you though – is it possible that the you
> actually meant BART when you said BARM, and vice versa, in the following?
>
>
>
> ------------------
>
> -------------
> I’ll try to work with Les on the text to specify the interaction.
>
>
>
> Jeffrey
>
>
>
> *From:* Alia Atlas [mailto:[email-masked]]
> *Sent:* Wednesday, February 21, 2018 9:45 AM
> *Cc:* IJsbrand Wijnands (iwijnand) <[email-masked]>;
> [email-masked]; IJsbrand Wijnands <[email-masked]>; [email-masked]; Eric
> Rosen <[email-masked]>
> Let us explore some details on the plan for an 8-bit BART and an 8-bit
> BARM that are independent.  Jeffrey,
>
> On Wed, Feb 21, 2018 at 9:17 AM, Jeffrey (Zhaohui) Zhang <
> [email-masked]> wrote:
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=-s4yYMmN1jlRwgyk02_2IFamu-k7K7di1WiwKt-AoeE&s=pJHykwbjl-mkz5oRRkXE6hjOs0tsiC1ucjQtr6-F-4k&e=>
>
>
>

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 21 Feb 2018 15:05:05 +0000

Hi Alia,

Thanks for articulating it very clearly, and bring out the issue of having a clear specification on the interaction.

I need one clarification from you though – is it possible that the you actually meant BART when you said BARM, and vice versa, in the following?

------------------
With that, the BART can be exactly the IGP Algorithms registry.
All the IGP Algorithms are available.   For the 2 currently defined, the constraints are empty.

Jeffrey

From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, February 21, 2018 9:45 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: IJsbrand Wijnands (iwijnand) <[email-masked]>; [email-masked] <[email-masked]>; [email-masked]; IJsbrand Wijnands <[email-masked]>; [email-masked]; Eric Rosen <[email-masked]>
Subject: Re: [Bier] BAR field length in draft-ietf-bier-isis-extensions and draft-ietf-bier-ospf-extensions

First, I greatly appreciate the rapid education I have gotten on why the different aspects of this are important.

Let us explore some details on the plan for an 8-bit BART and an 8-bit BARM that are independent.  Jeffrey,
I really appreciate your bringing this option to the list.  It simplifies the option B idea of subtypes away and there
seems to be a good amount of interest in it.

My concern is that we specify adequately how the codepoints in BART and BARM interact.

One of the challenges with doing so has been, IMHO, a bit of terminology where we are describing these as
algorithms but in fact these are tuples consisting of a set of constraints and a base algorithm.

BART is the BIER layer's constraints (BC) and algorithm (BA).  Let us describe this as BART =  (BC, BA).

BARM is the Routing layer's constraints (RC) and algorithm (RA).  Let us describe this as BARM = (RC, RA).

Consider a case of BART=4 which is known to mean (prune non-BIER routers, use SPF).
BARM = 200, which is known to mean (prune links with BW <10G, use SPF)

It is desirable to have an outcome that is (prune non-BIER routers and links with BW < 10G, use SPF).

This can work algorithmically because the constraints are the types that we've seen before for RSVP-TE.

What I think we need to make the independent 8-bit BART plus 8-bit BARM work is a clear specification
of the interaction. I think that is:

    Run A on RC(BC(Topology)) to get the next-hops and information for the BIFT.

Key points on the algorithm aspect are:
a) BIER is the higher layer, so it is assumed to know better which algorithm should be used.
b) It is possible for BA to be "empty"  (as the BARM=0 case discussed) so that the algorithm
    falls through to whatever is RA.

With that, the BART can be exactly the IGP Algorithms registry.
All the IGP Algorithms are available.   For the 2 currently defined, the constraints are empty.

I am bringing forth this description now because I am concerned that the interaction between
BARM and BART is not adequately defined to be published - but I see the strong interest in
this as the solution and, from my understanding of the problem, agree.

Please comment ASAP.

Jeffrey & Les, is this something that you can turn into clear text for the drafts?

Regards,
Alia

On Wed, Feb 21, 2018 at 9:17 AM, Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
To make it absolutely clear using an example: even with <BART 1, BARM 200> it is still that the two fields are independent of each other.
This particular combination means “apply BART 1” to “Flexible-Algo 200”, where “Flexible-Algo 200” could be “exclude red links”, while “BART 1” could be “skip BIER incapable routers”.

Jeffrey

From: BIER [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of IJsbrand Wijnands (iwijnand)

Thx,

Ice.

THx,

Ice.

Jeffrey

Thx,

Ice.

_______________________________________________
BIER mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bier<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bier&d=DwMFaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=f7wsLGcfzAWDNS6XNTBZwj_OLAOsZZqdrR2IDAzeZqE&m=-s4yYMmN1jlRwgyk02_2IFamu-k7K7di1WiwKt-AoeE&s=pJHykwbjl-mkz5oRRkXE6hjOs0tsiC1ucjQtr6-F-4k&e=>

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 21 Feb 2018 09:43:13 -0800

First, I concur with Alia's writeup fully and yes, this is definitely
providing a "higher ground" and clean architecture what those 16 bits are
aiming to achieve if they really should serve their purpose in the oncoming
years. Beside providing a nice orthogonal framework to think about those
issues it gives BIER the possibility to use the underlying IGP as any
combination of (signalling, computation algorithm, constraints)  so to
speak while we can substitute/add the algorithm and/or constraint part with
BIER information/algorithm as needed in each use case. Efficient
implementation is a different topic, at minimum we understand it for things
like SPF quite well from other technologies. The only thing BIER will never
try to do is topology distribution when using IGP of course  ;-)   If we
took all this fire to the forge here to emerge with that framework as
consensus, it may have been very well worth it IMO.

Second, I concur with Jeffrey terminology-wise that the BART is the BIER
algorithm/constraint side normally when we talk about it & BARM the "IGP
computation side". We could do BAT & RAT for BIER & ROUTING but I fear that
the 2nd acronym is too unfortunate then and we don't capture the constraint
part either. So (BC,BA) and (RC,RA) will work fine as well IMO.

I see that in a sense as option F) with clear architectural framework and
am waiting for the writeup now to nit what's necessary ...

thanks

--- tony

On Wed, Feb 21, 2018 at 7:05 AM, Jeffrey (Zhaohui) Zhang <[email-masked]