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

[Toerless Eckert <[e-mail]>]

Inline

On Thu, Oct 29, 2015 at 01:52:06PM -0400, Eric C Rosen wrote:
> 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".

Right.

> 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.

Sure.

Then i use an encap other than MPLS and i have to figure out how to
achieve the desired behavior there. All not rocket science, but all
dependencies against additional definitions in those docs ??

All the ways described in the arch doc how you can use the BIFT adjacency
entries to achieve beneficial outcomes are just that: "can". If there are
other ways to achieve the same thing preferred in some secenarios, that's
great. I just thought as an architect its a nice scheme and requires
nothing new in the forwading plane (local_decap is already needed anyhow).

One other thought: if there was a case in which we would have to waste more
than one bit in a bitstring for leaf-BFER, then i'd be a lot more
interested to instead rely on encap like MPLS or the like to save me the
bit. But one bit looked ok.

> 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 ;-)

Nah, BIER-TE is like watching sports in a bar ;-)

Three phase commit.  The numbers are phases.
The operations within each phase can be parallel:

1. Set up new bit to punt (local_decap) for BFR-1 in its BIFT.
   Add bit for link to BFR-2 on BIFT in BFR-1.
   Add shared-bit to punt to BIFT in BFR-2.

2. Update bitstrings on all BFIR that intended to reach BFR-1 via shared
   bit to now use the new bit for BFR-1. If the bitstrings have the
   shared bit set to also reach othre BFER then keep shared bit, else reset.

3. Remove punt adjacency for shared bit on BFR-1 BIFT.

Now BFR-2 is operable, aka: the bit toward it can be used in bitstrings. 

Can you do it with the shared punt semantic being in the label ? Probably
yes, but i hope (for the value of the shared bit idea) that the way
i describe is simpler because the controller only has to do this three
phase commit with BIFT entries and BIFR bitstrings in mind, but nothing
else. 

> 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?

Thats not only what i am thinking, but even more so what i thought
i had written in the -02 draft.

Wanted to use the afternoon to morp the new -02 text example
into an animated graph for tomorrow, hope that will help to clear it up even more.

Cheers
    toerless