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

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

On 10/9/2015 3:49 PM, Caitlin Bestler wrote:
> Is there some reason why you could not replace the SI concept with
> simply have more sub-domains that mapped
> to the same number of routing underlays?

In addition to what Ice and Tony have said, here's one way to think 
about it.

A particular application/service at a particular BFIR would be 
provisioned to send a certain class of flows in a certain sub-domain. 
The set of BFERs to which a given flow is to be sent would generally not 
be provisioned, but would be learned dynamically.

So the application/service tells BIER "here's a packet; send it on this 
sub-domain to this set of BFERs", where the set of BFERs is identified 
as a set of IP addresses (BFR-prefixes).  BIER maps the sub-domain and 
the set of BFR-prefixes to a set of BFR-ids.  If the set of BFR-ids 
cannot fit into a single BitString, the SI method is used to 
automatically create several packets.

This would all become rather more complicated if you had to use multiple 
sub-domains to reach a given set of BFERs, as the application/service 
would now have to know which sub-domain to use for each BFER.

Further, when a packet reaches a BFER, the BFER may need to figure out 
the BFR-prefix corresponding to the BFIR (this is necessary, e.g., for 
the MVPN application).  If the BFIR-id and the BFER-id were not from the 
same sub-domain, this would be difficult to do -- the packet would have 
to carry information allowing one to identify both the source sub-domain 
and the destination sub-domain.  But the architecture doesn't even have 
a notion of "source" and "destination" sub-domains.

Of course, it might be possible to rewrite the architecture to eliminate 
the SIs and replace them with sub-domains.  But since that would only 
make the architecture more complicated, it doesn't seem like a very good 
direction to pursue.