Re: [babel] Adding two babel milestones

[Donald Eastlake <[e-mail]>]

Hi David,

On Thu, May 27, 2021 at 11:36 AM David Schinazi
<[e-mail]> wrote:
>
> On Thu, May 27, 2021 at 6:54 AM Donald Eastlake <[e-mail]> wrote:
>>
>> Hi David,
>>
>> On Wed, May 26, 2021 at 2:41 PM David Schinazi <[e-mail]> wrote:
>> >
>> > On Tue, May 25, 2021 at 9:02 PM Donald Eastlake <[e-mail]> wrote:
>> >>
>> >> ...
>>
>> ...
>>
>> >> ...
>> >>
>>
>> ...
>>
>> >> I tend to think of multicast as being either discovery multicast or
>> >> application multicast. For application multicast, generally you can
>> >> use head end replication and unicast which is less efficient in terms
>> >> of link utilization and generally has higher latency due to multiple
>> >> copies being sent on a link but might be simpler; on the other hand,
>> >> if there are lots of sources and multicast groups, these head ends
>> >> have to all keep track of who to unicast to. For discovery, you can't
>> >> do everything with unicast because, by definition, you want to be able
>> >> to find nodes that you don't know about yet; but you can probably get
>> >> away with unicast + link local multicast for some definition of link.
>> >> So I agree you can find some way to do everything with unicast and
>> >> link local multicast but that doesn't mean it is the best way to do
>> >> everything.
>> >
>> > In my mind, the best way to perform discovery is to combine unicast
>> > and link-local multicast. That's what we use in DNSSD which is AFAIK
>> > the IETF-recommended way to perform service discovery.
>>
>> OK for discovery although I'm not aware of anything that explicitly
>> states that that is an IETF recommendation.
>>
>>  Here are the first two application multicast uses that come to mind:
>>
>> Say you have a provider network with multiple tenants attached.
>> Multicast packets arriving from a tenant need to be sent out to other
>> islands of that tenant connected to your provider network. I don't
>> want to get too bogged down in details of topology and optimizations
>> and stuff but I think that some form of tree distribution is needed to
>> scale. Interconnecting pieces of the same VLAN is similar. 802.1
>> bridging and TRILL routing are examples of complete packet forwarding
>> systems that handle unicast and multicast and build such distribution
>> trees.
>
> In this example, what's the application? What application data are the
> multicast packets arriving from a tenant carrying?

Well, to the tenant your network looks like a link so you unavoidably
have the "link-local" tenant multicast. For example, for each of
possibly many connections to islands of a tenant you might have a
bridge and behind that an IP router so you would have BPDUs, LLDPDUs,
VLAN registration messages, LAGPDUs, etc., and then maybe ARP/ND/RA
and IS-IS Hellos and LSPs and SNPs etc. And there could be other
discovery services running... (And actually, TRILL fits exactly
between bridging and routing so a bridged LAN looks like a link to
TRILL but a TRILL campus looks like a link to IP routing, so you could
have TRILL "link-local" multicast packets in addition to bridging and
IP routing multicast packets.)

As to what you might consider "real" applications, I think it is
somewhat of a chicken and egg problem. Since non-link-local multicast
isn't supported that much, applications tend to avoid it which
decreases the incentive to implement it, and so on.

>> Another application is streaming media. IP-TV in access networks
>> pretty much always uses multicast.
>
>
> Definitely agree with this example, I think it's the main use of non-link-local
> multicast on the Internet today.
>
> All this said, if you really want to add the milestone, I'll back off. I'm just
> commenting that this would be the first milestone we have that wasn't
> backed by support from implementers of Babel.

I've only added the IPv4 via IPv6 milestone.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

>> Thanks,
>> Donald
>> ===============================
>>  Donald E. Eastlake 3rd   [phone] (cell)
>>  2386 Panoramic Circle, Apopka, FL 32703 USA
>>  [e-mail]