Re: [Bier] Questions on draft-eckert-bier-te-arch-01

[Eric C Rosen <[e-mail]>]

On 10/16/2015 3:41 PM, Toerless Eckert wrote:
> We could easily avoid the single "shared leaf bit" by having a forwarding
> plane feature "you're a leaf BFER, every BIER-TE packet you receive
> needs to be punted". But thats a new forwarding plane feature, the
> "shared leaf bit" is just a bit allocation trick, so it keeps the forwarding
> plane simpler/cleaner.

I don't really follow this.  Presumably, if a BFR is a leaf BFER in a 
particular sub-domain, it must know that it is a leaf BFER in that 
sub-domain.  Otherwise it wouldn't punt the packet when it sees the 
"shared leaf bit".

If the BFR knows that it is a leaf BFER in a particular sub-domain, then 
when it gets a packet whose top label is the MPLS label it has assigned 
to that sub-domain, it can just punt the packet.  Recognizing that a 
particular MPLS label means "this packet is for me" doesn't seem like a 
new forwarding plane feature.

On the issue of adding new BFERs, suppose you have an existing flow, one 
of whose BFERs is BFR-1.  Now you need to add another BFER to that flow, 
say BFR-2.  Unfortunately, BFR-2 can only be reached using BFR-1 as a 
transit BFR.  So to add BFR-2 as a leaf, you have to turn BFR-1 into a 
non-leaf, which means assigning it a BFR-id, assigning a bit position to 
the link connecting BFR-1 and BFR-2, and modifying the flow's BitString 
appropriately.  I know that the magic central controller is going to 
figure all this out ;-), but can it disseminate the new bit position 
assignments without disrupting the flow that is already in progress? 
After all, you don't want to see a glitch in the TV show you're watching 
every someone else decides to tune in ;-)

One more issue.  The discussion of SI in the -02 revision of the draft 
still doesn't seem right to me.  In BIER-TE, the BitString in a packet 
has to represent the tree over which the packet will flow.  The only way 
I can think of using SI is to divide the tree into n sub=trees, where 
the links and BFERs for each sub-tree all have BFR-ids that fall into 
the same set.  Then the BFIR could make n copies of the packet, unicast 
each one to the root of the corresponding sub-tree, and allow BIER-TE to 
proceed from there.  Is that what you are actually thinking?