Re: [babel] Adding two babel milestones

[Toke Høiland-Jørgensen <[e-mail]>]

David Schinazi <[e-mail]> writes:

> 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:
>> >>
>> >> Hi David,
>> >>
>> >> On Tue, May 25, 2021 at 8:24 PM David Schinazi <
>> [e-mail]> wrote:
>> >> >
>> >> > Adding "IESG submission of IPv4 via IPv6" as a
>> >> > milestone is fine by me, because we're about to do that
>> >> > anyway. I've never found milestones to be useful, so
>> >> > I'm not sure there's any benefit in doing this as opposed
>> >> > to just submitting the draft for publication.
>> >>
>> >> I think milestones give an idea of what the WG has accomplished or may
>> >> accomplish in the future. They sort of supplement the Charter. But I'm
>> >> willing to admit that the "IESG submission of IPv4 via IPv6" doesn't
>> >> add that much. On the other hand, it's mostly the Chairs doing the
>> >> work to modify/track the set of milestones.
>> >
>> > To clarify, I don't object to the chairs creating a
>> > "IESG submission of IPv4 via IPv6" milestone.
>>
>> OK.
>>
>> >> ...
>> >>
>> >> > Regarding the "WG adoption of a Babel multicast draft"
>> >> > milestone, I would personally like to see such a draft
>> >> > written and discussed at a WG meeting before a
>> >> > milestone is added. That would ensure that we have folks
>> >> > willing to do the work for this to happen.
>> >>
>> >> I don't see why a milestone can't be aspirational.
>> >
>> > Does the aspiration reflect WG consensus? My understanding
>> > is that we're a very implementation-driven WG, and I'd prefer to
>> > have aspirations reflect what implementers aspire to build.
>> > Alternatively, hearing from someone who runs a Babel network
>> > telling us that they have a need for multicast would also be great.
>>
>> No consensus call has been made.
>>
>> >> > I disagree with Donald's statement that "a routing system that
>> >> > doesn't handle both unicast and multicast seems incomplete",
>> >> > because I have yet to find a general-purpose use-case for
>> >> > non-link-local multicast whereas unicast is general-purpose :-)
>> >>
>> >> What makes one use "general" and another "special"?
>> >
>> > I'd say "general-purpose" means there are several applications using
>> > it, whereas "special-purpose" is for a single application.
>>
>> See below for a couple of applications.
>>
>> >> What is a "link"? Say you have a network of Babel routers. Some
>> >> communicate by radio where the transmission on one of its radios by a
>> >> router may be received by zero, one, or more other routers. Some
>> >> communicate by wire/Ethernet but some of those connections are bridged
>> >> so those inter-router connections are more stable but can be
>> >> bi-lateral or multilateral. What exactly is a link in this network?
>> >
>> > My personal definition is: two devices are on the same link if they can
>> > hear each other's Babel Hellos and IHUs.
>>
>> Ahhh, so you meant a Babel link.
>>
>> >> 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?
>
> 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.

In my view, having multicast support in Babel would be quite cool just
for this use case. I know people who do this with spanning tree today
(although the chances of them switching to Babel are slim).

However, it would very much be an aspirational "nice to have" thing for
my part at least. As in, I sadly don't think I can commit many cycles to
actually working on adding such support... :(

-Toke