Re: [Bier] PIM/BIER: Where and how to do structure-encoded multicast distribution tree forwarding work ?

[Toerless Eckert <[e-mail]>]

Dear PIM-WG, BIER-WG and msr6 community:

I am writing this in response to <[e-mail]>
on BIER WG form TonyP, which i think is jumping the gun on something i wish we had more time to have technical
and process discussions about, and alas, this could not happen at IETF117 for reasons
explained further below.

Ultimately, IMHO, the question is how we best should do what i consider should be a single next-gen
stateless multicast forwarding given the structure of our existing working groups PIM/BIER and
how they may require us to split up work in the middle.

Let me try to explain the core technical issue:

We are working since early 2023 on P4/Tofino validation code for our concepts
of how to do stateless IP Multicast forwarding in a scalable, high-speed, low-cost fashion
applicable to hopefully a broad set of vendor hardware (hence validation on Tofino - lowest
common denominator - may not even do everything we want, but useful to gauge the feasibility
on better hardware). Our initial proposal presented for IETF discussions since end of 2021
evolved from draft-xu-msr6-rbs to draft-eckert-bier-rbs, with also variations
in draft-eckert-msr6-rbs. 

Note that there also is a vendor NPU prototype of the original version described in draft-xu-msr6,
which was validatet with a high-speed NPU on a research WAN in China. We recently had the research report
translated, see here:

https://github.com/network2030/publications/blob/main/CENI_Carrier_Grade_Minimalist_Multicast_Networking_Test_Report.pdf

In short, the forwarding method is to perform scalable, high-speed source routed, stateless multicast
by encoding the multicast tree in a source routing header as an easy to parse
compact structure.

This is of course next-gen work based on experience with BIER and especially BIER-TE (RFC9262),
both of which use what i call "network wide flat bitstrings" and their scaling and implementation costs/challenges.
In these "RBS" encoding structures as we call them, per-tree-node bitstrings are used to indicate next hops in the tree,
so for exampe each router only needs to parse a single (short) bitstring for its next-hops, and ignore the rest of the
encoded structure.

However, we also had started to work on scalability simulations and comparison
of different approaches. One, not finalized, but likely conclusion is that a solution
best should have both the option to address next-hops via either a bitstring or
a sequence of next-hop identifiers. Take for example the two RFC9262 Section 2.2 examples
and think that the first example might be best encoded with next-hop bitstrings,and example 2
with next-hop identifiers. In general: the more sparse the tree, the more likely per-next-hop
identifiers may be better, the denser the tree in a particular area of the network, the
more likely bitstrings as next-hops are better.

When i talked about the general problem, TonyP said on the mike at BIER-WG IETF116, 
that a solution using bitstrings could go into BIER, a solution with identifier would need to
go to a different WG, such as SPRING (where PIM WG seems to be doing multicast work with
SPRING architecture).

Hence we have the potential problem between our current IETF WGs  that we may
not work in a single WG on a solution with two options, even if we would technically agree
we need both and they would just be a variation in an otherwise common encoding mechanism.

I would find such an outcome technically quite difficult and wish we would be able to
make the scope of the solution tackled by a single working group (current or future) broad
enough that all useful technical options are on the table for it.

We did plan to present and disucss this at IETF117 in PIM-WG because of exactly this
described issue, and i had also sent an email about exactly this before IETF117 to the PIM WG,
PIM chairs, and also in private email to the BIER WG chairs.

Unfortunately, the PIM WG chairs overlooked the slot ask, and when this was discovered, the
PIM WG agenda for IETF117 was already full. Likewise, the BIER chairs did not reply to my email at all,
and i had a slot conflict so i could not go to BIER-WG meeting this time. Note that also several
other active participants on the topic could not come, for cost of getting to USA and/or for USA failing
to issue visas to them.

So, i think the list here should be used to discuss,
and/or IETF in Prague would, we hope, be a much better place to have a more complete showing of the
community and in-person discussion.

Cheers
   Toerless

P.S.: There are already other proposals with a single tree encoding supporting both
next-hop bitstring and next-hop identifier encoding of tree sructures, such as
draft-chen-pim-adaptive-te, which is AFAIK a variation of what was earlier presented at 
the IETF114 msr6 BOF, but i am not aware whether this line of proposals had similar
vendor and whitebox NPU/PoC validation or simulation of comparison of scaling aspects
as what we are doing for our proposals to feel solid about our conclusions.