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

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

>> [Eric] in BIER-TE forwarding the BFIR-id doesn't require a bit in the
>> BitString, so eliminating the BFIR-id doesn't really seem to provide
>> much value.

> [Toerless] 16 bit header saved.

I think that would count as "not much value" ;-)  FWIW, originally the 
MPLS encapsulation made the BFIR-id an optional field, but then you need 
a flag bit to say whether it is present, and it just seemed simpler to 
always include it.

> [Toerless] If BFR is leaf BFER, then controller only assigns bit to the
> links leading up to the leaf BFER, not the BFER itself.

> For all non-leaf BFER, controller assigns an individual bit.

Got it, I didn't attend properly to the fact that non-leaf BFERs have 
their own bits.

Maybe I should have said "almost got it" ;-)  Under what conditions will 
a leaf node receive a packet that it doesn't need to consume?  That is, 
what is the significance of failing to set the local_decaps bit?

Doesn't this scheme make it difficult to add a new BFER for an existing 
flow, or to change a non-leaf node from being a non-BFER to being a BFER 
for an existing flow?

> [Toerless] Lets run a simple example: 5 country network. 1000 BFER, each country
> 200 BFER, 3 routers in each country connecting to core. Call them
> them sub-domain BFIR if you want. Controller allocates
> one sub-domain per country. Fills up 256 bitstring with in-country
> BFER and in-country links Aka: lets say all relevant links between
> sub-domain BFIR and BFER are < 56.
>
> Lets look at BFIR service lookup for some IPTV (S,G) on ANY BFIR
> across the whole network: OIF list of 5 replications, each replication
> has unicast/MPLS label of one sub-domain BFIR follows by that BFIRs
> label for the subdomain of interest, followed by the BIER bitstring for
> the "in-country bits".
>
> Scales with number of BFER + number of relevant replication
> transit hops.  In above example, maybe 20% of BFER ???
>
> If you'd try to run this example with BIER instead of BIER-TE and
> did random BFR-ID == SI allocation, you may end up sending more copies
> across a lot of links. Eg: when you end up with BFR-ID with 2 different
> SI in a country. So the logic of allocating BFR-ID or sub-domains
> is really necessary/beneficial almost as much in BIER as in BIER-TE
> in these type of examples.

In non-TE BIER, you could also set up each country as a separate BIER 
sub-domain (or even a completely separate BIER domain, if we had 
inter-domain signaling of some sort).  Something like that might be 
needed anyway for inter-AS BIER.

>> Part of the BFER processing would be to figure out for each packet (a)
>> am I supposed to receive this packet and (b) did I receive it from the
>> sub-domain over which I'm expecting it?
>
> Hmmm... no, can't parse that. knowing which sub-domain a packet is
> for is like BIER via the label when MPLS encap is done (otherwise it
> wouldhave to be in the BIER header). Punting to higher layer is
> just based on having a bit with local decap and as explained above,
> the controller can intelligently assign this shared for leaf BFERs.

Think about an application like MVPN extranet, where one (S,G) flow is 
traveling through one sub-domain, another (S,G) flow is traveling 
through another sub-domain, and you have to make sure that each flow 
gets punted to the proper VRF.  If a given BFER for that flow is in both 
sub-domains, you'd need to know the sub-domain in order to dispatch to 
the proper VRF.  But I guess this could happen in non-TE BIER as well if 
different VPNs are using different sub-domains.

>>> [Toerless] rings require also only one bit per node (local decap),
>>> and a single shared bit for the ring (Section 4.6) (or even for
>>> multiple rings).
>>
>> [Eric] I don't quite understand from section 4.6 why a given packet will not
>> revolve around the ring forever, as the "ring bit" only seems to get
>> reset when the packet leaves the ring.  Also, if the "ring bit" gets
>> reset when a packet leaves the ring, how do you use one bit for multiple
>> rings?  Perhaps I've misunderstood something.
>
> [Toerless]  "On BFR2, the adjacency also points to the
>     clockwise neighbor BFR1, but without DNR set.  "

> DNR bit is part of the adjacency in the BIFT, so only
> the copies sent across the ring adjacencies will have it set, and then
> we do not set DNR towards the end of the ring before it would loop.

Doesn't this assume that all the BIER-TE packets enter the ring at a 
single ingress?  If packets can enter the ring at multiple points, what 
is the meaning of "end of the ring"?

> [Toerless] Multiple rings is just an example. DNR allows you to save bits
> in bitstring whenever you are fine all BIER-TE traffic is flooded
> across that sub-topology. Just set up in the BIFTs appropriate
> adjacencies to flood (loop free) across the topology.

I see how this would work for a sub-topology that is itself a tree 
(single ingress).  But if the non-leaf nodes in the sub-topology are 
also BFERs, you'd still need bits for them.