[Bier] DISCUSS? SI vs. sub-domains - draft-ietf-bier-architecture-02 (was: Re: Questions on draft-eckert-bier-te-arch-01)

[Toerless Eckert <[e-mail]>]

On Mon, Oct 12, 2015 at 02:21:05PM -0700, Caitlin Bestler wrote:
> This is more of an issue of document clarity than a request for an 
> architecture change.
> 
> My areas of expertise are at the application layer, host stacks, NICs 
> and L2 switching. Viewed through those perspectives
> there is virtually nothing in the architecture document that explains 
> why a sub-domain exists and what the implications of
> using a sub-domain vs. the use of an SI-subset are. Section 6.1's 
> discussion of adolescences alludes to a few specifics, but
> does not present an explanation.

Caitlin, 

Q1: I think you are referring to the BIER arch, not just BIER-TE arch,
so i changed the mail thread subject. Maybe the BIER arch authorw will
comment on your call for more clarity. If you are asking for specific clarity
in BIER-TE, pls. let me know.

Q2: "adolescences" ? I do not understand.

To answer your content question, SI vs sub-domain.

-> An application using BIER does not want/need to be bothered with
   bits in a bitstring. It simply creates BIER sockets(), optionally
   specifies a sub-domain (other than 0), and the list of BFER
   BFR-prefixes (IP addresses of receivers) that this socket should send copies
   to. Sends packets. Andds/removes BFR-prefixes over time if receiver
   set is changing.  Done. (*)

   How does this magic work ? The most important piece is SIs. SIs
   allow to have a 16 bit space of BFR-ids that are through routing
   underlay (eg: IGP) mapped to BFR-prefixes. 

   Why then SI and sub-domains ?
   
   Well, network operator will start (IMHO) assigning SI to BFER based
   on physical network topology.  As explained in prior emails for large
   networks, i think this would not be randomn, but based on geography -
   split up network into regions, assign BFERs in one region BFR-ids with 
   same SI (as much as possible).

   Now some app sends out humunguous amount of data and always
   has eg: < 256 receivers, but  they're all in a different region.
   Bummer: 20 regions, 10 receivers each, but sender needs to send
   out 10 copies anyhow because of SI allocation. So network operator
   creates another virtual BIER network... oops: sub-domain. In this
   subdomain only the potential BFER for this app/user are mapped
   to BFR-id, and e voila, the app uses this sub-domain, and the
   traffic in the network is again as efficient as we'd like - only
   one  packet sent to reach all receivers.

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

   2. I do not know how many BIFT routers in the future would support.
   Its definitely important to find solutions that minimize the
   number of required BIFT. Each BIFT is in-network state, and one of
   BIERs claim to fame is to reduce state. Of course, even if you
   had a lot of state with BIER its still better than MPLS/PIM because
   its not dynamically changing with membership, but we should try
   to propose (SI,sub-domain) solutions that are as efficient as possible.

   So,... i don't know enough about your DC targets: Number of overall
   network-wide possible receivers, number of different app-instances
   (eg: with different subset of possible receivers),...

-> Hope this gives an idea why today i think the framework of (SI,subdomain)
   is necessary (can't get rid of either without making apps more difficult),
   but also sufficient (can't think of additionally useful concepts to scale BIER
   receivers AND create the option for optimized replication).

Cheers
    Toerless