Re: [Bier] DISCUSS? SI vs. sub-domains - draft-ietf-bier-architecture-02

[Caitlin Bestler <[e-mail]>]

On 10/13/15 10:37 AM, Toerless Eckert wrote:
> > Is this the full answer for your use-case, DC ? Not quite i think.
>     Would be good to discuss more, but i don't see you coming to Yokohama ?
>
>     Eg: AFAIK, DCs have huge (>> 2^16) VMs. Each user/application will
>     most likely have much less than 2^16  receivers. Creating per-app
>     sub-domains sounds like the obvious starting point. SIs would come
>     into the process automatically, as soon as an applicatin requires more
>     than Bitstringlength possible receivers. BUT:
>
>     1. AFAIK, we have not defined for BIER any automated schemes to assign unique
>     BFR-id to receivers. Doing it once for eg: the physcial topology - manually
>     is a well known process for operators (like allocation of loopback addresses).
>     Doing this repeatedly for multiple apps IMHO requires an automated
>     scheme. This would be a good (potentially DC centric) signaling
>     problem to look into.

Yes, a typical intra-DC application will map a VLAN or VXLAN to a Bier 
Domain.
The membership in this virtual cluster may be for the duration of a job, or
indefinite. But the VLANs/VXLANs will probably be set up by cluster 
management
rather than by hand

Further, the desired forwarding path for a given virtual cluster is 
intended to
be very short. It might be longer if you are forced to allocate nodes in 
a large
number of racks, but that is not what the scheduler will be trying to do.

That also means you are unlikely to see BIER in datacenters until it is 
implemented
in commodity forwarding chips that are deployed in edge servers. 2-hops with
old fashioned multicast groups will beat 4 hops with BIER.

We rejected emulating what we wanted switches to do in edge switches for our
storage cluster because you can't make the latencies required when you 
add extra
physical hops to your path.