Re: [Bier] Consensus call on adoption of RBS Work Into BIER WG

[Toerless Eckert <[e-mail]>]

Thank you, Tony

I very much appreciate the interest in the technology, but i would like to remind that authors
did not ask for WG adoption at this point in time but that the presentation given instead  tried
to explain how the are focussing on working through a range of technical options and challenges,
including those raised by Ice, through prototyping and simulation (re. comparing scalability),
and i fear that adoption now might lead to make premature choices.

While it might be possible to delay some choices also after adoption to a WG, i think there are a couple
of fundamental issues where it is unclear to me where/how they would best be captured, and
which WG would best be able to do them or how, so a broader discussion of scope and how to
organize work in the IETF would be useful.

For example:

a) Initial thinking from us authors indicates that there likely will be at least two different
type of tree encoding  approaches that would best suit two type of use-cases:

- The "RBS" style approach where every node has a representation of "local next-hop addresses"
  (bitstring or other) might best be suited to "native deployment" and "larger trees" - and
  we're investigating this, especially optimizations for larger trees (such as what was already
  mentioned but not prototyped first time around, e.g.: "edge-broadcasting" - for e.g.: IPTV).

- Another approach which would use "global-next-hop-addresses" might be best for smaller trees
  in overlay deployments, e.g.: where not every node will support the new forwarding. (One may
  think of this in term of established IETF terminology as a tree of SIDs).

b) When we look beyond the current choices of BIER-WG re. encapsulation with "flat bitstrings",
it would be useful for IETF to revisit what is seen by network operators of networks with 
different base unicast architectures (IPv6 vs. MPLS for example), what they do prefer operationally.

For example, i tried a first round of this in the different encap mechanisms of RBS
via draft-eckert-bier-rbs and drafgt-eckert-msr6-rbs, and maybe these type of options are also
good to get reviewed in other groups, such as 6MAN/SPRING/PIM to get broader feedback.
(some time and other challenges to get that done in the past).

Aka, long story short: I'd rather like to gain more insight into several points before i even had a good
overall plan what i think would best have to be done. And the discussions in the BIER-WG in IETF116 and
on the floow where extremely helpful to get to that point, but WG adoption of some part might not be right now.

Last but not least: While a lot of the thinking described avbove also derives from the work on
BIER-TE, and the scale limitations encountered in using its "flat-bitstrings" (for underlay/overlay uses),
i think BIER-TE is still a great today-useable technology, and i would also like to spend cycles help
close the gap on work we've done for it (control-plane, YANG, ...), which further limits the speed
wich which i think it would be possible to make sound decisions on the long-term evolution today
(and BIER-TE is also being worked on by Univ. Tuebingen too ...). Aka: contributor cycle contention ;-)

Cheers
    Toerless

On Fri, Apr 14, 2023 at 10:32:24PM +0200, Tony Przygienda wrote:
> During the last IETF meeting we ended up in an interesting consensus
> discussion based on the Toerless “RBS Update” presentation.
> 
> After the presentation a show of hands was run (after AD indicated
> readiness to extend the charter to work along the lines of the use case
> this work addresses)
> 
> “Who would contribute to Work on RBS in BIER WG”
> 
> 8 out of 15 hands went  up so it looked like enough people were interested
> in working out the details/viability of the solution.
> 
> After quick discussion with AD we doubled up with another quick verbal poll
> since the “no hand up” meaning wasn’t clear here.
> 
> “Who is objecting RBS adoption as a working group item into BIER WG ?”
> 
> And here, rather confusingly and as far as I could read the room, up to 5
> hands went up in the room, mostly from people who seemed to be associated
> with the cluster of original proponents/contributors to RBS work.
> 
> So, we’re taking per usual IETF procedures the call to the list to see who
> voices support/objection to adopt RBS work into the BIER WG charter in some
> form or fashion.
> 
> Please refrain from “counter mails” as in +1/-1 and state specific
> technical objections/merits of the work and its applicability
> 
> thanks
> 
> -- tony

-- 
---
[e-mail]