Subject: Re: [Bier] Consensus Decision on the BAR field

From: <[email-masked]>
Date: Thu, 22 Feb 2018 03:49:37 +0000

Support, thank you to all folks who has been engaged to achieve this milestone.
Regards,
Arkadiy

From: BIER <[email-masked]> on behalf of Xiejingrong <[email-masked]>
Date: Wednesday, February 21, 2018 at 9:47 PM
To: "Jeffrey (Zhaohui) Zhang" <[email-masked]>, Alia Atlas <[email-masked]>, BIER WG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Bier] Consensus Decision on the BAR field

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,

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]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[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.

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: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Thu, 22 Feb 2018 09:13:18 +0000

This looks good to me.

Regards

Matthew

From: BIER <[email-masked]> on behalf of "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wednesday, 21 February 2018 at 22:28
To: Alia Atlas <[email-masked]>, BIER WG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[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

To: BIER WG <[email-masked]>

Regards,
Alia