Subject: [babel] Adding two babel milestones

From: Donald Eastlake <[email-masked]>
Date: Mon, 24 May 2021 22:57:23 -0400

Hi,

Currently we have completed all the established milestones for the WG. It
seems to me that we should have some future milestones.

In the slides from the last Babel WG meeting at
https://datatracker.ietf.org/meeting/110/materials/slides-110-babel-agenda-and-status-03
that were presented at the last IETF meeting, I suggested three additional
milestones. The last one related to Babel for 802.11 mesh was controversial
but there did not appear to be any objections to the other two.

So, I plan to add the following two milestones (I believe new milestones
need to be OKed by our AD):

  June 2021   IESG submission of IPv4 via IPv6.
  Sept 2021   WG adoption of a Babel multicast draft.

Perhaps the Babel WG meeting at the July IETF meeting (July 26-30) should
focus on multicast.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 25 May 2021 17:03:15 +0200

Hi Donald,

> So, I plan to add the following two milestones (I believe new milestones need
> to be OKed by our AD):
> 

Donald, I'd like to expand the introduction to this document before it is
submitted to the IESG -- no content changes, just wording.  Is it possible
to do that without restarting last call?

>   Sept 2021   WG adoption of a Babel multicast draft.

What do you envision?  Babeld works with PIM-SM (that's what the
"reflect-kernel-metric" option is for), but I'm not seeing a lot of
interest.  I'm not following the DNSSD/mDNS community closely, but I'm
under the impression that they're focusing on multicast-to-unicast proxies
instead of site-local multicast (draft-cheshire-mdnsext-hybrid).

There's also Sandy's BIER for Babel work, but I fear it may have been
abandoned.

> Perhaps the Babel WG meeting at the July IETF meeting (July 26-30)
> should focus on multicast.

My personal plans are to finish merging HMAC and v4-via-v6 into babeld
mainline, and then to get back to working on network-layer mobility:

  https://www.irif.fr/~jch/software/sroamd.git

-- Juliusz

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 25 May 2021 14:24:45 -0400

Hi Juliusz,

> to do that without restarting last call?

Probably. The Introduction does not seem to be controversial. I
suggested a change to the Introduction here
https://mailarchive.ietf.org/arch/msg/babel/5HEAHOesxnerhhq9rZcy92hjfwI/
and there were no complaints. You could propose a different change to
the Introduction as a resolution to my comment. Since all this is
getting posted to the WG mailing list, if no one speaks up in 7 or 8
days and there are no technical changes to the protocol, I don't think
we would need a new WG Last Call.

> What do you envision?

Multicast is mentioned in the Babel WG Charter as something optional
to work on. This is just my personal opinion but a routing system that
doesn't handle both unicast and multicast seems incomplete to me.

> Babeld works with PIM-SM (that's what the
> interest.

Is this discussed in any of the Babel RFCs or drafts? Seems like
something somewhere in the IETF Babel documentation should talk about
at least a way to do multicast.

Thanks,
Donald

> I'm not following the DNSSD/mDNS community closely, but I'm

---

From: David Schinazi <[email-masked]>
Date: Tue, 25 May 2021 17:23:56 -0700

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'm supportive of Juliusz making editorial changes before
submitting to the IESG, I'm sure the IESG review will lead
to editorial changes anyway, and so will IETF last call.

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 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 :-)

David

On Tue, May 25, 2021 at 11:25 AM Donald Eastlake <[email-masked]> wrote:

> _______________________________________________
> babel mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/babel
>

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 26 May 2021 00:02:15 -0400

Hi David,

> 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 editorial changes anyway, and so will IETF last call.

OK.

> willing to do the work for this to happen.

I don't see why a milestone can't be aspirational.

> non-link-local multicast whereas unicast is general-purpose :-)

What makes one use "general" and another "special"?

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?

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.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: David Schinazi <[email-masked]>
Date: Wed, 26 May 2021 11:41:35 -0700

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

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

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

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

> link local multicast but that doesn't mean it is the best way to do

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.

David

Thanks,

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 27 May 2021 09:53:52 -0400

Hi David,

OK.

>> ...

No consensus call has been made.

> it, whereas "special-purpose" is for a single application.

See below for a couple of applications.

> hear each other's Babel Hellos and IHUs.

Ahhh, so you meant a Babel link.

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

Another application is streaming media. IP-TV in access networks
pretty much always uses multicast.

Thanks,
Donald

---

From: David Schinazi <[email-masked]>
Date: Thu, 27 May 2021 08:36:10 -0700

> systems that handle unicast and multicast and build such distribution

In this example, what's the application? What application data are the
multicast packets arriving from a tenant carrying?

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

Thanks,

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Thu, 27 May 2021 18:20:24 +0200

David Schinazi <[email-masked]> writes:

> 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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 28 May 2021 14:00:19 +0200

> (although the chances of them switching to Babel are slim).

I think it could be a lot of fun if done in collaboration with someone
actually doing large-scale video distribution.  Not so sure about
implementing multicast in isolation and hoping it gets adopted.

-- Juliusz

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 28 May 2021 14:36:42 +0200

> implementing multicast in isolation and hoping it gets adopted.

Totally agreed; hence the "nice to have" classification :)

-Toke