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

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

Toerless, Neale,

Thanks for your interesting responses.  I am still inclined to say that 
this proposal needs more baking before it is ready for WG adoption.

> [Toerless] The author who wrote this (me) wanted to explain that the
>  BFIR-ID is not required for BIER-TE forwarding itself (it is
> required for BIER forwarding if i am not mistaken), and incorrectly
> wrote "does not support".

I don't think the BFIR-id is needed for BIER forwarding, it's only
needed if the multicast flow layer at the BFERs needs to do some sort of
RPF check. I don't think BIER and BIER-TE are different in this respect.

> [Neale] The intent was to reduce the number of bit-positions needed
> in the network by not requiring the BFIR to have one. The draft
> should therefore instead state that the BFIR-ID MAY not be set in
> the packet, and if not, then there are the consequences that you
> have identified.

> [Toerless] Neale mentioned also that not assigning a BFIR-ID can
> help to save bitspace, which is true in BIER, but if we only use
> BIER-TE forwarding, it would not even cost bits.

Right, 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] I could not find BFER-ID term being used anyplace other
> than draft-ietf-bier-isis-extensions-00.xml, so i would not venture
> to guess what its semantics is - any pointer i overlooked ?

A BFER-id is just the BFR-id of a BFER. Similarly, a BFIR-id is just
the BFR-id of a BFIR.

With regard to the issue of not having enough bits to represent the
entire multicast distribution tree ...

> [Neale] Since the data is not distributed throughout the domain, it
> does not need to be unique within the domain.

By "it", do you mean the bit position that represents a particular link?
Or do you mean the BFIR-id?  Note that BFR-ids are already unique only
relative to a sub-domain.

> [Neale] So, one might also consider applying the same BFIR-id to a

Same BFR-id?

> group of BFERs that belong to the topology. If that bit-position is
> then set in the packet, then it is received by all BFERs that the
> packet reaches, and that is determined by which other bits are set in
> the BitString. Since in TE BIER a packet cannot reach BFER if the
> BitString does not describe a path to it.

> [Toerless] Section 4.3 explain how Leaf BFER effectively require no
> bit (sorry typo: 4.3:s/BFIR/BFER/, done for -02). Eg: just one bit
> per link to leafs, and one shared (local decap) bit for all leafs in
> the network.

I didn't really understand this.  How does a node know whether it is a 
leaf (a BFER) for a particular packet?  Doesn't this mean that every BFR 
through which a packet passes is going to have to figure out whether it 
is supposed to be a BFER for that packet?  I'd like to see the details 
of how that would work.  BTW, however it works, it will probably require 
knowing the BFIR-id, unless that can be inferred from the sub-domain 
that is implicitly identified by the BIER-MPLS label.  (Consider, e.g., 
a case where a given flow is traveling on two different TE trees, 
perhaps from different BFIRs, but a given transit node is on both trees.)

> [Toerless] The most simple logic is to segment your network into
> non-overlapping areas, assign an SI to each area, and effectively
> unicast a copy from the BFIR to the desired entry points in each of
> the areas. Unicasting eg: via Routed Adjacencies.

Assuming we replace "SI" with "sub-domain", is this the same as Neale's
suggestion:

> [Neale] perhaps one could consider one or more uni-directional
> BIER-TE sub-domains rooted at each BFIR. Each individually signalled
> sub-domain comprises a sub-set of the BFERs (and the links to
> traverse to them) that the BFIR needs to address. Flows can then map
> onto one or more of these sub-domains. This scheme keeps the number
> of sub-domains scaling with network size (as with SPF-BIER sets),
> rather than number of flows.

So each sub-domain would be a sub-tree of the tree from a given BFIR.
You unicast-tunnel a packet to the root of a sub-domain, and then let 
BIER distribute the packet down the sub-tree. The number of sub-domains 
is then proportional to the number of BFIRs (which is still a lot of
sub-domains), and each transit node would have to determine for each
packet whether it needs to consume that packet or just pass it along.
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?

It seems like there are a lot of details to be added, and some of them
might be dependent upon the multicast flow layer.

> [Toerless] Am i missing references, or where the numbers of the
> drafts references too old, even for the time when i ran the xml2rfc?

The references are to the old individual documents rather than to the WG
documents.

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

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.

Eric