Re: [Bier] I-D Action: draft-ietf-bier-use-cases-01.txt

[Caitlin Bestler <[e-mail]>]

I know these comments may be a bit late, but I've had a nagging doubt 
about these
uses-cases for awhile. Those doubts didn't formulate into a specific 
form until just
recently, however.

The key problem I have is this: Bier requires new dataplane forwarding 
chips. The
subset targeting is done in every multicast packet.

I would expect that BIER use cases would all be examples where there was 
a need
for dynamically selected multicast targets, and for the bitmap solution 
to compare
favorably to extending MLD to dynamically create forwarding rules on an 
as-needed
basis.

Basically, imagine an alternate solution where the sender makes a 
request to an MLD
snooper for  a multicast channel that will reach an enumerated set of 
targets, and
is allocated a multicast group for that purpose.

Such a solution would require only co-operation between MRouters and MLD 
Snoopers.
The L2 forwarding tables would be unchanged. No "BIER Header" would be 
required
on a per packet basis.

When the targeted group is too dynamic for the MRouter/MLD snooper setup 
time then
BIER would be a better solution. But I'm not seeing that in any of these 
use-cases.

I described a storage cluster application that would benefit from BIER 
in my proposal
for Transactional Subset Multicasting.
(https://tools.ietf.org/html/draft-bestler-transactional-multicast-00)
(http://storagetarget.com/2015/08/13/transactional-subset-multicasting/)

That dealt with a data source that needs to multicast a chunk (variable 
sized, but typically
100s of KB to MBs) to multiple destinations. Each chunk transfer is 
potetially to a different
set of storage targets.

But that problem can be solved by pre-population of the potential 
combinations of destinations
and/or a custom control-plane proxy that extended MLD snooping. The BIER 
solution is simpler,
but not sufficiently simpler to justify changing how every multicast 
packet is forwarded.

For all of the use cases cited here the duration of a specific target 
set seems to be even longer.

There may be HPC applications which meet the requirements of true 
datagram multicasting.
It would be nice to hear from some HPC architects about what their 
specific requirements are.

Whether it is the use-case draft or the applicability draft I would 
expect more of a detail trade-off
between new methods of configuring current multicast forwarding tables 
versus fundamentally new
multicast forwarding technology. If the current solution is irrevocably 
limited then prove it, don't
just cite some use cases where this might be nice.