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

[Toerless Eckert <[e-mail]>]

If we want to maintain that "easy" way how flow overlay signaling
works, then IMHO we'd also need to rely on SI for BIER-TE,
or else we'd need to enhance the proposed signaling extensions
for eg: IGPs to better support sub-domains.

Even in BIER it seems in a larger networks that require BIER 
with multiple SI, the operator likely would want to allocate BFR-IDs
so that he doesn't create unnecessary duplicates

[ Eg: 10 edge areas with 200 BFR each. If you allocate a separate SI
  per area, each area will see one copy for each BIER packet. 
  Allocate BFR-ids randomnly -> up to 10 packets into an area]

When you come to think of this, you likely will start allocarting
BFR-id across larger networks keeping SI in mind, eg: in buckets of
256 or whatever the bitstring size is. And in each bucket you want
to keep some headroom for growths (additional BFER added to area
later).

The main difference for BIER-TE is that we'd need more unused headroom
in the BFR-id space thats not allocated to BFER because we need it
in TE for forwarding to intermediate links. Not sure percentage:
20%..30% of bits in bitstring ?

I for once could easily see how i could use the BIER BFR-id also for
BIER-te if my allocation scheme was keeping enough headroom,
eg: plan for initially 51%, longer term not more than 70% of
bits in SI for BFR-id, keep the rest for BIER-TE cases. 

If thats felt to not be appropriate by customer then he likely
would need to simply duplicate the BFR-id allocation: one
BFR-id in sub-domain 0 for BIER with the target of a very high
filling of bits for every SI, and another subdomain for BIER-TE
where the BFR-id in that subdomain are allocated with enough
headroom for the transit hops.

Makes sense ?

--
Toerless

On Mon, Oct 12, 2015 at 03:17:02PM -0400, Eric C Rosen wrote:
> 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.
> 
> _______________________________________________
> BIER mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bier

-- 
---
Toerless Eckert, [e-mail]