Re: [Bier] Feedback on draft-eckert-bier-rbs-00

[Toerless Eckert <[e-mail]>]

Hey Ice

Sorry for the long delay. I was hoping that i could answer the questions
in a draft update, but the productive work that has happened around RBS 
primarily with Michael Menths team has somewhat put other issues than a
draft update in the front burner for the last quarter, so i will
ask for a slot at IETF116 to explain how we're progressing, but that also means its
best to discuss your questions on the list now.

1) mismatch of bitstring length between sender and receiver

Thanks for bringing this up.  A actually had to think about this issue already
some time ago when doing some researchy unicast forwarding scheme
draft-eckert-intarea-functional-addr-internets. And trying to figure out if, and then
what new quality or quantity of a problem this could be.

First of all, i don't think the worst-case network-layer problem of a
mismatched packet is bad with RBS. It can result in some additional packet
copies in the network with a low likelyhood to even reach any destinations.
This is because every copy created will have a smaller remaining RBS address
to proceed. This is RBS's equivalent to BIER/BIER-TE clearing bits in the
bitstring and thus exhausting incorrect copies even before TTL exiry hits.

Secondly, the RBS forwarding plane must recognize incorrect RU-length fields
anyhow, because they can not result in pointing past the RBS header, and an attacker
could always create malicious RBS headers, same as creating malicious MPLS or IPv6
extension headers. If one can parse all the address offsets before replicating one
can probably eliminate almost all wrong copies. But even if this only happens
copy-by-copy, it still seems to me that almost all those wrong copies would die
somewhere along the path.

Now, i had also though about a bitstring-length field in the header, rewrite
hop-by-hop, but IMHO that does not buy anything, because ultimately we need for
the sender that created the RBS header and every RBS router on the tree to agree.
So when we want to indicate length it would need to be for each bitstring in
the RBS address separately, which would be header-size-prohibitive, unless we
end up with variable bitstring length not in bits, but maybe larger quantity, like bytes.
Thats something we investigate anyhow for reasons of possible lowest-common
denominator data center forwarding plane restrictions. See update we want to give @IETF116.

But: I think we can much better and cheaper solve this problem in the control plane
with an approach that is equally applicable for BIER-TE - but thats a somewhat longer writeup,
so give me a bit more time for that.

2) recursive flag

Yes, agreed. We are experimenting with that encoding. If you remember my slides (and the drafts
reference to the github URHL), there is also the optimization for dense trees
to reduce their RBS tree size by indicating on the pre-ultimate hop to replicate to
all leaf neighbors. Typical case would be IPTV of course or similar "dense-trees".
This is what on the china simulation results brings down the total number of copies towards
those dense trees. There are a few options to encode, have not concluded on it.
The BIFT leaf bit might then simply be to distinguish leaf neighbors for the purpose
of such last-hop broadcast from non-leaf neighbors.

Cheers
    Toerless

On Fri, Feb 17, 2023 at 02:09:10PM +0100, IJsbrand Wijnands wrote:
> Hey Toerless,
> 
> Do you have a timeline in mind to address my questions?
> 
> Thx,
> 
> Ice.
> 
> > On 23 Jan 2023, at 18:26, IJsbrand Wijnands <[e-mail]> wrote:
> > 
> > Hey Toerless,
> > 
> > Did you address the issues I raised below?
> > 
> > Thx,
> > 
> > Ice.
> > 
> > Sent from my iPhone
> > 
> >> On 15 Nov 2022, at 11:26, Toerless Eckert <[e-mail]> wrote:
> >> 
> >> Thanks, Ice - also Tony/Greg feedback/mails..
> >> 
> >> want to incooporate feedback into draft updates, hence no quick reply here,
> >> as to other discus here.
> >> 
> >> Cheers
> >>   Toerless
> >> 
> >> 
> >>> On Thu, Nov 10, 2022 at 01:32:51AM +0000, IJsbrand Wijnands wrote:
> >>> Dear Authors,
> >>> 
> >>> Here is some feedback on the RBS encoding. This is based on my understanding of the draft and discussion with Toerless today.
> >>> 
> >>> 1. It seems that when a BIER router is parsing the RecursiveUnit, the length of the BitString is derived from the length of the BIFT Table on the router processing the packet. To me that seems very tricky as the length of the BIFT table might change when interfaces/adjacencies get added and removed. There might always be transient cases where the length of the BitString in the packet might be different from the router’s BIFT Table. If that happens, the complete parsing of the RBS packet goes to sh*t. It would be good to somehow add the length of the BitString inside the RBS header to prevent these cases from happening and be more defensive.
> >>> 
> >>> 2. The BIFT table has a Recursive flag to indicate if a BIER node has downstream receivers. This is also required to correctly parse the RBS header. In my mind this should not be a property of the BIFT table. A bier node might have nodes connected to it, but that doesn’t mean they are part of the tree. The recursive flag should be part of the encoded tree inside the RBS header.
> >>> 
> >>> Thx,
> >>> 
> >>> Ice.
> >>> 
> >> 
> >> -- 
> >> ---
> >> [e-mail]
> > 
> > _______________________________________________
> > BIER mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/bier
>