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

[Antoni Przygienda <[e-mail]>]

> -----Original Message-----
> From: Eric C Rosen [mailto:[e-mail]]
> Sent: Monday, October 12, 2015 12:17 PM
> To: Caitlin Bestler; Antoni Przygienda; [e-mail]
> Subject: Re: [Bier] Questions on draft-eckert-bier-te-arch-01
> 
> 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.

 [Tony saiz:]  I would whole-heartedly agree here. Sub-domains are really here to 
separate bigger-grain concepts like services or different router sets running BIER, 
think source/destination ports in a sense. 
Orthogonally, SI gives a transparent solution to the fact that we can't realistically 
carry 32KB receiver bitmasks in each packet, in a sense equivalent to IP 
fragmentation solving  the problem of limited media MTU. 

--- tony