Subject: Re: [Bier] End-to-end BIER

From: Toerless Eckert <[email-masked]>
Date: Wed, 4 Nov 2015 15:39:48 -0800

Inline.

On Thu, Oct 29, 2015 at 01:15:43PM -0400, Eric C Rosen wrote:
> [Caitlin] Each bit position would represent and end-station rather than
> a BFER. The application would map a destination IP address to a bit
> position (or bit-positions for BIER-TE).
> 
> This is really just a control plane issue.

True. Is there any control plane proposal where a BFER could be
a host (eg: not running IGP) ? Or a BFR an L2 switch (running STP
vs. IGP) ?

> [Caitlin] allowing the actual BFER to use multicast Layer 2 delivery is 
> more direct. There is no need for BFERs to inform BFIRs that multicast 
> delivery will be used. It makes no difference to the other BFRs. You can 
> even make a case that this is already allowed under the "no harm no 
> foul" rule.
> 
> This seems a bit more problematic to me, as the LAN might attach to 
> multiple transit BFRs.  Consider a topology like:
> 
>         |----BFR-B---Endpoint-1
> BFR-A---|      |
>         |----Endpoint-2
[...]

Sure, but this is not a problem specific to "end-to-end BIER". It would
apply to existing BIER as well if we wanted to use L2 multicasting
to directly send to more than one BFR.

Assuming we had an L2 BIER control plane, use of L2 multicasting
would become quite uninteresting because all L2-switches topologies
wouldn't need it anymore. Only passive multiaccess L2 subnet. Which
today really only means wireless (i think...). In a DC which i think
is the topology Caitlin is interested in, it looks to me the ask
is really BIER for L2 switches, but L2-hop-to-l2-hop BIER (L2)
unicast would be perfect (no L2 multicast needed).

> Another problematic scenario:
[...]
> The various proposals for MLD/IGMP/PIM overlays address problems like 
> this, but the solutions are not at the BIER layer, so I don't think they 
> apply directly to the case of end-to-end BIER.

Which specific proposal for example do you think would help ?

Cheers
    Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 4 Nov 2015 15:58:37 -0800

FWIW:

I think it would be lovely if we had a BIER-API definition in some
appropriate BIER RFC. Would make it so much easier to talk with
app-developers about BIER and see how it compares to the APIs/service
for ASM/SSM.

IMHO, the most basic API is really just something like this: 

   write(bier_domain, list-of-bfer-ip-addr, data, len)

Aka: no exposure/need to bother about bitmasks and other  BIER
forwarding or control plane details. And no IP multicast group
addresses to worry about.

This API could be used today on BFIR/BFER. And it wouldn't need to
change for an end-to-end BIER where as Eric said we may just have
some other variants of control plane under the hood.

Toerless

On Wed, Oct 28, 2015 at 01:26:11PM -0700, Caitlin Bestler wrote:
> There is a broad use-case for BIER that has not been properly 
> highlighted: explicit application use of bitmaps
> to push multicast messages.
> 
> Applications specify the subset of a cluster (BIER sub-domain) that is 
> to receive a message on a per packet basis.
> Sender-determine, or pushed, targeting is natural for many cluster 
> applications, especially storage clusters.
> Requiring the sender to tell the receivers that they need to join a 
> specific group adds latency to any transaction.
> When the determination is truly listener based, or the delivery lasts 
> long enough, this overhead is insignificant.
> But for transactional messages, such as transferring chunks within a 
> storage cluster, the extra latency is a killer.
> 
> No real changes are required to support this model. At most a few MAY 
> clauses would be added.
> 
> Each bit position would represent and end-station rather than a BFER. 
> The application would map a destination
> IP address to a bit position (or bit-positions for BIER-TE). But such an 
> implementation would already be allowed
> by simply considering the IP stack on each end station to be its own BFER.
> 
> It would also be desirable to use Layer 2 multicasting for the final 
> delivery hop. The current pseudo-code implies
> unicast delivery. Allowing mutlicast L2 delivery only requires adding 
> one clause to the forwarding pseudo-code.
> We must allow treating an existing L2 multicast address as though it 
> were an anonymous virtual BFER that delivered
> to a known set of endpoints. An implementation could create a virtual 
> BFER under the current wording, but I believe
> it would have to allocate a bit position for each virtual group, and 
> then explicitly advertise it. Just allowing the actual
> BFER to use multicast Layer 2 delivery is more direct. There is no need 
> for BFERs to inform BFIRs that multicast delivery
> will be used. It makes no difference to the other BFRs. You can even 
> make a case that this is already allowed under the
> "no harm no foul" rule.
> 
> 
> 
> 
> _______________________________________________
> BIER mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bier

---

From: Caitlin Bestler <[email-masked]>
Date: Wed, 4 Nov 2015 16:28:00 -0800

>     write(bier_domain, list-of-bfer-ip-addr, data, len)
The API should allow this, but it should also allow create a BIERpath 
like this:

     bp = make_bier_path (bier_domain,list-of-bfer-ip-addr)
     send_to_bp (bp,data,len)

As well as the usual 'send_to_bpv' for vectorized content.

Eventually you would release the 'bierpath'.

The bierpath would be totally opaque. It might be an integer handle or 
an allocated struct.

This would be optimal for sending a message that had to be broken up 
into multiple datagrams
in that it avoids the overhead of translating the IP addresses to 
bit-numbers for each UDP datagram.

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 4 Nov 2015 16:47:40 -0800

> into multiple datagrams in that it avoids the overhead of translating the
> IP addresses to bit-numbers for each UDP datagram.

Sure. I wasn't taking into account any API mods necessary to optimize local
computational requirements or the like. Just the basic BIER paradigm.

I would also not introduce any new/unclear tem like path. It's just
a set of bfer (bfer-set or the like). And thats how i'd compare it
with ASM/SSM: receiver-sets vs. group-addreses is what the app-developer
is dealing with.

Cheers
    Toerless

-- 
---
Toerless Eckert, [email-masked]

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 4 Nov 2015 17:06:57 -0800

> app-developers about BIER and see how it compares to the APIs/service

+ (1E99 * 10)