Re: [babel] Adding two babel milestones

Donald Eastlake <> Wed, 26 May 2021 04:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D0FE23A1E81 for <>; Tue, 25 May 2021 21:02:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FM50xXr__cCp for <>; Tue, 25 May 2021 21:02:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9B8CF3A1E80 for <>; Tue, 25 May 2021 21:02:27 -0700 (PDT)
Received: by with SMTP id b81so12126239iof.2 for <>; Tue, 25 May 2021 21:02:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CKVXm4z6DiE661ZUT0vQwFTCEOI/5mnp0iJllKCMf54=; b=e/eQHqg1Oc3HGj7n/f1rcA8plUi/GV4hTnMsHR0pHpNOeoVyrnNNbMkI6+cD3P7MCI s7vWQip0v5B2DztFFd7iEe7pXN0NYZlzDyodfAF9oygNehQ6ch/nCl1GJSa+JUIlTa0c OW8zTJNdgUau1ow2PLVglD8P0yI5usPhhAAKOLaxUM0ZvAjzzjuVOPco7XlYJKX1duzG k48DcG4T3VyUp9CSUAmEjJWl73YeEDl6K9d6J1oaFX89tH7nNnzRR4SkbABi+fBEIB9B UAgXFNYAjw1w064zqNdW2Wy8LQflVOv+EXx1S2+PaHr9LlhlatbVli/KUurYTXGU21p5 6yng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CKVXm4z6DiE661ZUT0vQwFTCEOI/5mnp0iJllKCMf54=; b=Wj8iKPXxtwOu4dCXnxXQG1sxggwbWHMBLTDXVzAjSgYGp+ycG/2dmnhWUYKo/6Dyi0 nS55KzsJFRAmEurLka/g9wdPfLUFVAba0v+2t6iwpb8qkixa1UWERZwuH0k4yxvJkUYd Ky6M4xx/gwV/siqzq3xRN64PysRNdyeBuUfxq+Wka9VhCwzC7xmbAiNEDYHeaHjJ3qsn Fa39F104zBo3tvz3N0lr/W5H0oIROBXlPtCAbE1Y1dRYY4bQ9cyo1OpWqAlPUeV1slZ5 GeLiyp4vHW/TJvEMYQOolY8zPNPHTWY6F03u/NxCeYJYu73iEIBMzGDtUcPFBo1fzb1p Ng4A==
X-Gm-Message-State: AOAM531JNcpkZsc4kqkBRydRPrHWFGv28h03uQFH+wfJKTvvgjHRVRa4 Mz/EF6EH/lVHosTdlJOp/kpfMxmp4r5il+aWA0E=
X-Google-Smtp-Source: ABdhPJzESJziJKhQTpfKLCkZ8wnExVqFjELWpZADHkSqLV3OqYf2OJODKTMKvLR2r7HdnKjH1UeBabvJIT+oO7bJZDA=
X-Received: by 2002:a5d:8d87:: with SMTP id b7mr20664038ioj.46.1622001746238; Tue, 25 May 2021 21:02:26 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Donald Eastlake <>
Date: Wed, 26 May 2021 00:02:15 -0400
Message-ID: <>
To: David Schinazi <>
Cc: Juliusz Chroboczek <>, Babel at IETF <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [babel] Adding two babel milestones
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 May 2021 04:02:32 -0000

Hi David,

On Tue, May 25, 2021 at 8:24 PM David Schinazi <> 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.

> 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 don't see why a milestone can't be aspirational.

> 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"?

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

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA

> David
> On Tue, May 25, 2021 at 11:25 AM Donald Eastlake <> wrote:
>> Hi Juliusz,
>> On Tue, May 25, 2021 at 11:03 AM Juliusz Chroboczek <> wrote:
>> >
>> > Hi Donald,
>> >
>> > > 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.
>> >
>> > 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?
>> Probably. The Introduction does not seem to be controversial. I
>> suggested a change to the Introduction here
>> 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.
>> > >   Sept 2021   WG adoption of a Babel multicast draft.
>> >
>> > 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
>> > "reflect-kernel-metric" option is for), but I'm not seeing a lot of
>> > 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
>> ===============================
>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>  2386 Panoramic Circle, Apopka, FL 32703 USA
>> > 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:
>> >
>> >
>> >
>> > -- Juliusz
>> _______________________________________________
>> babel mailing list