Subject: [Bier] Consensus Decision on the BAR field

From: Alia Atlas <[email-masked]>
Date: Wed, 21 Feb 2018 14:08:37 -0500

As the sponsoring AD for draft-ietf-bier-ospf-bier-extensions-13 and
draft-ietf-bier-isis-extensions-07, I would like to thank everyone what for
what turned into a clarifying and
useful technical discussion.

Here is my perspective and summary of what I saw.

1) There are a few people who are ok with keeping an 8-bit BAR field, but
they have very different ideas of what that field will be used for or what
IANA Registry would be appropriate. Willingness to keep with the current
status of one 8-bit BAR field varied wildly depending on whether the
associated IANA registry met each person's assumptions  (e.g. the
discussion of Option E).

2) There was support for option B - which had a type and sub-type - as a
way of providing flexibility, but there was also concern about the added
complexity of defining sub-types. This didn't seem to represent the correct
relationship.  Jeffrey Zhang suggested an Option F which has two separate
8-bit fields.  I saw significant support for this - and believe that the
reasons given for supporting option B before option F was suggested also
apply to option F.
So, to elaborate more on "Option F", which is similar to "option B" but
without one being a sub-type of another.  In its cleanest form, this has
two 8-bit fields currently termed BARM and BART.  One field - the BARM -
would represent the BIER layer's constraints and algorithm; this will be an
8-bit field with a new IANA Registry that belongs to BIER.  The second
field - the BART - will represent the routing layer's constraints and
algorithm; this will use the IGP Algorithms IANA Registry that was created
from draft-ietf-ospf-segment-routing-extensions (which is in the RFC
Editor's queue).

At this point, I believe that the BIER WG's consensus is to use Option F.

I have a technical concern that the interaction between the two fields
isn't adequately defined.  I sent out a suggested framework for defining
the interaction, but agree that
rushing that detail is not appropriate.  Therefore, I have asked Jeffrey
Zhang and Eric
Rosen to quickly craft sufficient text to describe the understood
interactions (as previously defined) and to cleanly put allocating
additional values in the BART Registry as not available until another draft
defines the correct interactions.  There may be naming changes to the
fields to better clarify in this version - based on the discussion we have
been rapidly having.

I request that the editors for  draft-ietf-bier-ospf-bier-extensions and
draft-ietf-bier-isis-extensions include that text in a new version of their
documents TODAY, after it has been
sent to the list and briefly discussed.  I do not believe that there will
be controversy on
this text.

These documents are on tomorrow (Feb 22)'s IESG telechat for approval as
Proposed
Standards. Given that this will be an extremely late technical change after
WGLC, the
drafts will also come back to the BIER WG for a 1 week WGLC on this
specific technical
change (and any others required to meet IESG review).

This is my view and summary of the discussion.
I do welcome feedback both to the list and privately.

Regards,
Alia

---

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

Hi,

The following text is what Eric and I came up with for OSPF. ISIS would be very similar. I will work with OSPF/ISIS-BIER co-authors to get the docs updated. In the meantime, please review and comment.

Thanks!
Jeffrey

-------------------

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           |

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

   |    BAR        |     IPA       |            Reserved           |

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

   |                      Sub-TLVs (variable)                      |

   +-                                                             -+

   |                                                               |

BAR: Bier AlgoRithm. A single-octet specifying a BIER specific algorithm

      used to calculate underlay

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

IPA: IgP Algorithm. A single-octet specifying an IGP Algorithm

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

      reach BFERs as defined by the BAR value. Values are from the

      IGP Algorithm registry.

BAR and IPA definitions are independent of each other.

The use of non-zero values in either the BAR field or the IPA field is outside

the scope of this document.  If an implementation does not support the use of

non-zero values in these fields, but receives a BIER sub-TLV containing

non-zero values in these fields, it SHOULD treat the advertising router

as incapable of supporting BIER (one way of handling incapable routers is documented in

section 6.9 of RFC 8279 and additional methods may be defined in the future).

4.  IANA Considerations

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

  The registration policies for this registry are

   * "Standards Action" for values 0-127

   * “Specification Required” for values 128-240

   * "Experimental Use" for values 240-254

   The initial values in the BIER Algorithm Registry are:

   0: No BIER specific algorithm is used

   1-254: Unassigned

   255: Reserved

From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, February 21, 2018 2:09 PM
To: BIER WG <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Consensus Decision on the BAR field

As the sponsoring AD for draft-ietf-bier-ospf-bier-extensions-13 and draft-ietf-bier-isis-extensions-07, I would like to thank everyone what for what turned into a clarifying and
useful technical discussion.

1) There are a few people who are ok with keeping an 8-bit BAR field, but they have very different ideas of what that field will be used for or what IANA Registry would be appropriate. Willingness to keep with the current status of one 8-bit BAR field varied wildly depending on whether the associated IANA registry met each person's assumptions  (e.g. the discussion of Option E).

2) There was support for option B - which had a type and sub-type - as a way of providing flexibility, but there was also concern about the added complexity of defining sub-types. This didn't seem to represent the correct relationship.  Jeffrey Zhang suggested an Option F which has two separate 8-bit fields.  I saw significant support for this - and believe that the reasons given for supporting option B before option F was suggested also apply to option F.
So, to elaborate more on "Option F", which is similar to "option B" but without one being a sub-type of another.  In its cleanest form, this has two 8-bit fields currently termed BARM and BART.  One field - the BARM - would represent the BIER layer's constraints and algorithm; this will be an 8-bit field with a new IANA Registry that belongs to BIER.  The second field - the BART - will represent the routing layer's constraints and algorithm; this will use the IGP Algorithms IANA Registry that was created from draft-ietf-ospf-segment-routing-extensions (which is in the RFC Editor's queue).

I have a technical concern that the interaction between the two fields isn't adequately defined.  I sent out a suggested framework for defining the interaction, but agree that
rushing that detail is not appropriate.  Therefore, I have asked Jeffrey Zhang and Eric
Rosen to quickly craft sufficient text to describe the understood interactions (as previously defined) and to cleanly put allocating additional values in the BART Registry as not available until another draft defines the correct interactions.  There may be naming changes to the fields to better clarify in this version - based on the discussion we have been rapidly having.

I request that the editors for  draft-ietf-bier-ospf-bier-extensions and draft-ietf-bier-isis-extensions include that text in a new version of their documents TODAY, after it has been
sent to the list and briefly discussed.  I do not believe that there will be controversy on
this text.

These documents are on tomorrow (Feb 22)'s IESG telechat for approval as Proposed
Standards. Given that this will be an extremely late technical change after WGLC, the
drafts will also come back to the BIER WG for a 1 week WGLC on this specific technical
change (and any others required to meet IESG review).

Regards,
Alia

---

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

Hi Jeffrey,

Looks great!

For IETF London I'll bring you and Eric a BIER beer from my private collection, especially for using the field name "IPA" in the Sub-TLV :-)

Thanks guys,

Ice.

Thanks!
Jeffrey

-------------------

2.1.  BIER Sub-TLV

   0                   1                   2                   3

   |              Type             |             Length            |

   |    BAR        |     IPA       |            Reserved           |

   |                      Sub-TLVs (variable)                      |

   +-                                                             -+

   |                                                               |

      IGP Algorithm registry.

4.  IANA Considerations

   1-254: Unassigned

   255: Reserved

From: Alia Atlas [mailto:[email-masked]]
Sent: Wednesday, February 21, 2018 2:09 PM
To: BIER WG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Consensus Decision on the BAR field

Regards,
Alia

---

From: "Dolganow, Andrew (Nokia - SG/Singapore)" <[email-masked]>
Date: Wed, 21 Feb 2018 23:25:50 +0000

Jeffrey, Eric – thank for putting this together!

Support

Andrew

From: Jeffrey Zhang <[email-masked]>
Date: Thursday, February 22, 2018 at 9:28 AM
To: Alia Atlas <[email-masked]>, BIER WG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: Consensus Decision on the BAR field
Resent-From: <[email-masked]>
Resent-To: Peter Psenak <[email-masked]>, <[email-masked]>, "(Ice) IJsbrand Wijnands" <[email-masked]>, Andrew Dolganow <[email-masked]>, Toni Przygienda <[email-masked]>, Jeffrey Zhang <[email-masked]>, <[email-masked]>
Resent-Date: Thursday, February 22, 2018 at 9:28 AM

Hi,

Thanks!
Jeffrey

-------------------

2.1.  BIER Sub-TLV

   0                   1                   2                   3

   |              Type             |             Length            |

   |    BAR        |     IPA       |            Reserved           |

   |                      Sub-TLVs (variable)                      |

   +-                                                             -+

   |                                                               |

      IGP Algorithm registry.

4.  IANA Considerations

   1-254: Unassigned

   255: Reserved

Regards,
Alia

---

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

BIER, BAR, IPA, … keep it coming!

Why didn’t we name BFIR/BFER as BEIR/BEER J

Jeffrey

From: IJsbrand Wijnands (iwijnand) [mailto:[email-masked]]
Sent: Wednesday, February 21, 2018 6:22 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: Alia Atlas <[email-masked]>; BIER WG <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: Consensus Decision on the BAR field

Hi Jeffrey,

Looks great!

Thanks guys,

Ice.

Thanks!
Jeffrey

-------------------

2.1.  BIER Sub-TLV

   0                   1                   2                   3

   |              Type             |             Length            |

   |    BAR        |     IPA       |            Reserved           |

   |                      Sub-TLVs (variable)                      |

   +-                                                             -+

   |                                                               |

      IGP Algorithm registry.

4.  IANA Considerations

   1-254: Unassigned

   255: Reserved

Regards,
Alia

---

From: Greg Shepherd <[email-masked]>
Date: Wed, 21 Feb 2018 15:37:38 -0800

Thank all of you for not giving up here, and coming together with a spec we
can all agree on. Bonus points for the name changes as well!! Yes, it is
celebration time.

Cheers!,
Greg

On Wed, Feb 21, 2018 at 3:28 PM, Jeffrey (Zhaohui) Zhang <[email-masked]
> wrote:

> *From:* IJsbrand Wijnands (iwijnand) [mailto:[email-masked]]
> *Sent:* Wednesday, February 21, 2018 6:22 PM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>
> *Cc:* Alia Atlas <[email-masked]>; BIER WG <[email-masked]>;
> [email-masked]; draft-ietf-bier-isis-
> [email-masked]
> *Subject:* Re: Consensus Decision on the BAR field
>
>
>
> Hi Jeffrey,
>
> Looks great!
>
>
>
> For IETF London I'll bring you and Eric a BIER beer from my private
> collection, especially for using the field name "IPA" in the Sub-TLV :-)
>
>
>
> Thanks guys,
>
>
>
> Ice.
>
>
>
>
>
> The following text is what Eric and I came up with for OSPF. ISIS would be
> very similar. I will work with OSPF/ISIS-BIER co-authors to get the docs
> updated. In the meantime, please review and comment.
>
>
>
> Thanks!
>
> Jeffrey
>
>
>
> -------------------
>
>
>
> 2.1.  BIER Sub-TLV
>
>
>
>    0                   1                   2                   3
>
> *From:* Alia Atlas [mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, February 21, 2018 2:09 PM
> *To:* BIER WG <[email-masked]>
> *Cc:* [email-masked]; draft-ietf-bier-isis-
> [email-masked]
> *Subject:* Consensus Decision on the BAR field
>
>
>
> draft-ietf-bier-isis-extensions-07, I would like to thank everyone what
> for what turned into a clarifying and
> draft-ietf-bier-isis-extensions include that text in a new version of
> their documents TODAY, after it has been
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier
>
>

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 21 Feb 2018 20:19:29 -0500

Jeffrey/Eric - well done, looks great!
Great to see how efficiently wg resolved the issue and reached consensus, kudos to chairs and AD!

Regards,
Jeff

> On Feb 21, 2018, at 17:28, Jeffrey (Zhaohui) Zhang <[email-masked]> wrote:
> 
> Hi,
>

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 21 Feb 2018 17:38:00 -0800

+1

yes, the IPA is indeed sly ;-)

On Wed, Feb 21, 2018 at 3:37 PM, Greg Shepherd <[email-masked]> wrote:

> Thank all of you for not giving up here, and coming together with a spec
> we can all agree on. Bonus points for the name changes as well!! Yes, it is
> celebration time.
>
> Cheers!,
> Greg
>
> On Wed, Feb 21, 2018 at 3:28 PM, Jeffrey (Zhaohui) Zhang <
> [email-masked]> wrote:
>
>> [email-masked];
>> [email-masked]
>> The following text is what Eric and I came up with for OSPF. ISIS would
>> be very similar. I will work with OSPF/ISIS-BIER co-authors to get the docs
>> *Cc:* [email-masked];
>> [email-masked]

---

From: Xiejingrong <[email-masked]>
Date: Thu, 22 Feb 2018 02:46:48 +0000

Support.
Many Thanks to Jeffrey & Eric.

XieJingrong

From: BIER [mailto:[email-masked]] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Thursday, February 22, 2018 6:28 AM
To: Alia Atlas <[email-masked]>; BIER WG <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Bier] Consensus Decision on the BAR field

Hi,

Thanks!
Jeffrey

-------------------

2.1.  BIER Sub-TLV

   0                   1                   2                   3

   |              Type             |             Length            |

   |    BAR        |     IPA       |            Reserved           |

   |                      Sub-TLVs (variable)                      |

   +-                                                             -+

   |                                                               |

      IGP Algorithm registry.

4.  IANA Considerations

   1-254: Unassigned

   255: Reserved

Regards,
Alia

---

From: Senthil Dhanaraj <[email-masked]>
Date: Thu, 22 Feb 2018 05:47:31 +0000

OK.

1.       However (as Ice already mentioned), any future proposed specifications for non-zero BAR/IPA values need to clearly specify the combinations of BAR & IPA which are supported as we cannot assume any/all combinations to work.  Should we need to add a text to OSPF/ISIS drafts to clearly state this ?

2.       As we add new values to BAR/IPA in future, Is it feasible to update support/non-support for all combinations in each (existing & new) proposals ? Would we create a new registry/specification as a place holder ?

Thanks,
Senthil

Sent: 22 February 2018 03:58

Hi,

Thanks!
Jeffrey

-------------------

2.1.  BIER Sub-TLV

   0                   1                   2                   3

   |              Type             |             Length            |

   |    BAR        |     IPA       |            Reserved           |

   |                      Sub-TLVs (variable)                      |

   +-                                                             -+

   |                                                               |

      IGP Algorithm registry.

4.  IANA Considerations

   1-254: Unassigned

   255: Reserved

Regards,
Alia

---

From: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email-masked]>
Date: Thu, 22 Feb 2018 07:02:00 +0000

+1

Thank you!
Jorge

From: BIER <[email-masked]> on behalf of Jeff Tantsura <[email-masked]>
Date: Thursday, February 22, 2018 at 2:19 AM
To: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, BIER WG <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Bier] Consensus Decision on the BAR field

On Feb 21, 2018, at 17:28, Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Thanks!
Jeffrey

-------------------

2.1.  BIER Sub-TLV

   0                   1                   2                   3

   |              Type             |             Length            |

   |    BAR        |     IPA       |            Reserved           |

   |                      Sub-TLVs (variable)                      |

   +-                                                             -+

   |                                                               |

      IGP Algorithm registry.

4.  IANA Considerations

   1-254: Unassigned

   255: Reserved

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

---

From: Senthil Dhanaraj <[email-masked]>
Date: Thu, 22 Feb 2018 08:37:06 +0000

Another question is,

3.       Today BAR=0, means not-used (from BIER registry) and IPA=0 means SPF (from IGP registry)

In future, when we define a new BIER Algo and intend to use it instead of any other IGP Algo, how do we advertise?  BAR=X and IPA=0 ? But IPA=0 specify IGP SPF as well.

Either we  define a don’t-care value for IPA in IGP registry (or) we specify if BIER=X, then do not care about IPA value ?? – Clumsy -☺

Thanks,
Senthil

From: Senthil Dhanaraj
Sent: 22 February 2018 11:18
To: 'Jeffrey (Zhaohui) Zhang' <[email-masked]>; Alia Atlas <[email-masked]>; BIER WG <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: Consensus Decision on the BAR field

OK.

Thanks,
Senthil

To: Alia Atlas <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>

Hi,

Thanks!
Jeffrey

-------------------

2.1.  BIER Sub-TLV

   0                   1                   2                   3

   |              Type             |             Length            |

   |    BAR        |     IPA       |            Reserved           |

   |                      Sub-TLVs (variable)                      |

   +-                                                             -+

   |                                                               |

      IGP Algorithm registry.

4.  IANA Considerations

   1-254: Unassigned

   255: Reserved

Regards,
Alia

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 22 Feb 2018 13:40:24 +0000

Hi Sethil,

Please see zzh> below.

From: Senthil Dhanaraj [mailto:[email-masked]]
Sent: Thursday, February 22, 2018 3:37 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Alia Atlas <[email-masked]>; BIER WG <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: Consensus Decision on the BAR field

Another question is,

Zzh> Much of those details will be specified in new specifications. I am thinking one spec that (perhaps among other things) defines the general rules about BAR/IPA interaction/compatibility, and more specs as needed that define individual BAR values and their semantics.

Zzh> More below.

Thanks,
Senthil

From: Senthil Dhanaraj
Sent: 22 February 2018 11:18
To: 'Jeffrey (Zhaohui) Zhang' <[email-masked]<mailto:[email-masked]>>; Alia Atlas <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: Consensus Decision on the BAR field

OK.

Zzh> The BAR registry has the following requirements:

Zzh> So, it’s clear that we’ll need specifications, and I trust that the IETF process will ensure that the issues you raised will be addressed in those documents. Specifying what needs to happen in the future in this document may be too restricting or not enough/accurate, so we might as well just leave out the obvious for now?

Zzh> Any new definitions will need to specify the interaction/compatibility with existing values. I don’t think we need a registry for the support/non-support matrix - the registry is only for code points and not for semantics per my understanding, but either way, that is outside the scope of current IGP spec J

Thanks!
Jeffrey

Thanks,
Senthil

Hi,

Thanks!
Jeffrey

-------------------

2.1.  BIER Sub-TLV

   0                   1                   2                   3

   |              Type             |             Length            |

   |    BAR        |     IPA       |            Reserved           |

   |                      Sub-TLVs (variable)                      |

   +-                                                             -+

   |                                                               |

      IGP Algorithm registry.

4.  IANA Considerations

   1-254: Unassigned

   255: Reserved

Regards,
Alia

---

From: "Bidgoli, Hooman (Nokia - CA/Ottawa)" <[email-masked]>
Date: Thu, 22 Feb 2018 15:27:20 +0000

Support

That said same question as ICE and Senthil, can BAR and IPA overlap? Or is BAR only for cases that IPA does not cover? As an example if BIER to be resolved via a multicast only Routing Table etc… BAR will be used?

Regards

Hooman

From: BIER [mailto:[email-masked]] On Behalf Of Senthil Dhanaraj
Sent: Thursday, February 22, 2018 12:48 AM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Alia Atlas <[email-masked]>; BIER WG <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Bier] Consensus Decision on the BAR field

OK.

  1.  As we add new values to BAR/IPA in future, Is it feasible to update support/non-support for all combinations in each (existing & new) proposals ? Would we create a new registry/specification as a place holder ?

Thanks,
Senthil

Hi,

Thanks!
Jeffrey

-------------------

2.1.  BIER Sub-TLV

   0                   1                   2                   3

   |              Type             |             Length            |

   |    BAR        |     IPA       |            Reserved           |

   |                      Sub-TLVs (variable)                      |

   +-                                                             -+

   |                                                               |

      IGP Algorithm registry.

4.  IANA Considerations

   1-254: Unassigned

   255: Reserved

Regards,
Alia

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 22 Feb 2018 15:59:22 +0000

Looks good!

Thanks.
Jeffrey

Sent from my iPhone

On Feb 22, 2018, at 10:27 AM, Bidgoli, Hooman (Nokia - CA/Ottawa) <[email-masked]<mailto:[email-masked]>> wrote:

Support

Regards

Hooman

To: Jeffrey (Zhaohui) Zhang <[email-masked]<mailto:[email-masked]>>; Alia Atlas <[email-masked]<mailto:[email-masked]>>; BIER WG <[email-masked]<mailto:[email-masked]>>

OK.

Thanks,
Senthil

Hi,

Thanks!
Jeffrey

-------------------

2.1.  BIER Sub-TLV

   0                   1                   2                   3

   |              Type             |             Length            |

   |    BAR        |     IPA       |            Reserved           |

   |                      Sub-TLVs (variable)                      |

   +-                                                             -+

   |                                                               |

      IGP Algorithm registry.

4.  IANA Considerations

   1-254: Unassigned

   255: Reserved

Regards,
Alia

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 22 Feb 2018 16:03:35 +0000

All those are good questions and the rules will be specified in future documents.

I have some text/thoughts on that. Will share for discussion once they’re polished a bit further - we’ll work together to get that done.

Thanks!
Jeffrey

Sent from my iPhone

Support

Regards

Hooman

OK.

Thanks,
Senthil

Hi,

Thanks!
Jeffrey

-------------------

2.1.  BIER Sub-TLV

   0                   1                   2                   3

   |              Type             |             Length            |

   |    BAR        |     IPA       |            Reserved           |

   |                      Sub-TLVs (variable)                      |

   +-                                                             -+

   |                                                               |

      IGP Algorithm registry.

4.  IANA Considerations

   1-254: Unassigned

   255: Reserved

Regards,
Alia

---

From: Tony Przygienda <[email-masked]>
Date: Thu, 22 Feb 2018 08:05:50 -0800

<chair>

Please read the decision handed by AD as resolution.  It defines clearly
the conceptual model of what (BA,BC) and (RA,RC) means and expected
interactions.

It was agreed (I think for the best) that IGP drafts are not a good place
to describe that model and resulting interactions in detail. The according
document will/is being worked on with good number of people willing to put
work into it already.

</chair>

<personal>

For completeness sake and to make that fully symmetric and easier to
understand you can imagine that there is/could/will be an "undefined RA/RC"
value in the IGP registry but we'll worry about it when we start to
standardize concrete use cases and a clean value encoding of it.

I expect that use cases or group of use cases will be centering around
drafts/RFCs that will standardize the encoding values in each registry (I
hold it probable that certain BAR/IPA value combination may even have
special BIER TLVs added) but we will get to it when the use cases
solidify/are understood in detail.  If you are interested in current
discussions along different axis please read the flex-algo draft, the
igp-sr drafts and the bar-algo drafts and follow the discussions on the
mailing list closely ...

</personal>

I hope that clarifies it.

--- tony

On Thu, Feb 22, 2018 at 7:27 AM, Bidgoli, Hooman (Nokia - CA/Ottawa) <
[email-masked]> wrote:

> Support
>
>
>
> That said same question as ICE and Senthil, can BAR and IPA overlap? Or is
> BAR only for cases that IPA does not cover? As an example if BIER to be
> resolved via a multicast only Routing Table etc… BAR will be used?
>
>
>
> Regards
>
>
>
> Hooman
>
>
>
> *From:* BIER [mailto:[email-masked]] *On Behalf Of *Senthil
> Dhanaraj
> *Sent:* Thursday, February 22, 2018 12:48 AM
> *To:* Jeffrey (Zhaohui) Zhang <[email-masked]>; Alia Atlas <
> [email-masked]>; BIER WG <[email-masked]>
> *Subject:* Re: [Bier] Consensus Decision on the BAR field
>
>
>
> OK.
>
>
>
>    1. However (as Ice already mentioned), any future proposed
>    specifications for non-zero BAR/IPA values need to clearly specify the
>    combinations of BAR & IPA which are supported as we cannot assume any/all
>    combinations to work.  Should we need to add a text to OSPF/ISIS drafts to
>    clearly state this ?
>
>
>
>    1. As we add new values to BAR/IPA in future, Is it feasible to update
>    support/non-support for all combinations in each (existing & new) proposals
>    ? Would we create a new registry/specification as a place holder ?
>
>
>
> Thanks,
>
> Senthil
>
>
>
> *From:* BIER [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Jeffrey (Zhaohui) Zhang
> *Sent:* 22 February 2018 03:58
> *To:* Alia Atlas <[email-masked]>; BIER WG <[email-masked]>
> *Subject:* Re: [Bier] Consensus Decision on the BAR field
>
>
>
> Hi,
>
>
>

---

From: Senthil Dhanaraj <[email-masked]>
Date: Fri, 23 Feb 2018 04:26:55 +0000

Thanks for the clarifications Jeffrey !

Rgds,
Senthil

From: Jeffrey (Zhaohui) Zhang [mailto:[email-masked]]
Sent: 22 February 2018 19:10
To: Senthil Dhanaraj <[email-masked]>; Alia Atlas <[email-masked]>; BIER WG <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: RE: Consensus Decision on the BAR field

Hi Sethil,

Please see zzh> below.

Another question is,

Zzh> More below.

Thanks,
Senthil

From: Senthil Dhanaraj

OK.

Zzh> Any new definitions will need to specify the interaction/compatibility with existing values. I don’t think we need a registry for the support/non-support matrix - the registry is only for code points and not for semantics per my understanding, but either way, that is outside the scope of current IGP spec ☺

Thanks!
Jeffrey

Thanks,
Senthil

Hi,

Thanks!
Jeffrey

-------------------

2.1.  BIER Sub-TLV

   0                   1                   2                   3

   |              Type             |             Length            |

   |    BAR        |     IPA       |            Reserved           |

   |                      Sub-TLVs (variable)                      |

   +-                                                             -+

   |                                                               |

      IGP Algorithm registry.

4.  IANA Considerations

   1-254: Unassigned

   255: Reserved

Regards,
Alia

---

From: IJsbrand Wijnands <[email-masked]>
Date: Fri, 23 Feb 2018 10:56:48 +0100

Jeffrey,

> Why didn’t we name BFIR/BFER as BEIR/BEER J

I slightly regret we did not name the "Set Identifier" as “Crates" :-)

Thx,

Ice.

---

From: Antoni Przygienda <[email-masked]>
Date: Fri, 23 Feb 2018 16:47:27 +0000

We’ll find new things to define & worry about while we sail the standards oceans now … 

Keep a notebook ;-) 

--- tony

<[email-masked]> spake:

    Jeffrey,

    
    Thx,
    
    Ice.