Re: [babel] Adding two babel milestones

David Schinazi <dschinazi.ietf@gmail.com> Wed, 26 May 2021 18:41 UTC

Return-Path: <dschinazi.ietf@gmail.com>
X-Original-To: babel@ietfa.amsl.com
Delivered-To: babel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9691B3A07BA for <babel@ietfa.amsl.com>; Wed, 26 May 2021 11:41:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.096
X-Spam-Level:
X-Spam-Status: No, score=-1.096 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_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQkXlAvGjjaB for <babel@ietfa.amsl.com>; Wed, 26 May 2021 11:41:47 -0700 (PDT)
Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8983F3A07B6 for <babel@ietf.org>; Wed, 26 May 2021 11:41:47 -0700 (PDT)
Received: by mail-pf1-x42d.google.com with SMTP id f22so1653078pfn.0 for <babel@ietf.org>; Wed, 26 May 2021 11:41:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2e5dSuxiDhLvZLBlfxMCZNEI3nmt9JTGyl+hM6xKSpU=; b=jNyZHZM1rUXAQcoXy21JZWRZ7kqkkmCATuK+9mrcJ+9vVjlcJukxoyVxnk41LeKQgQ UvjEhM1G5zwvnD/Bz/0izouJzZ5qTQMtr4WjkGHpgW+ucmaEai6/ufUc67XYn3jPKb35 2pfPNK1DdONDHFcgUQE4RTw/MmR5pK6MsMXkWauWCQ6+kmvt/zkJCti2UhD53dQhIRsn K1xE8azDqOPnSOSB5HJitqMiue0pWkANARDpgbxnPlh9Ddd6TdXAKgIg4V2NFpXaBxRO 8atnveuCnEuVUkIZZo/uSewoFT62xDIvqQz6DTxL+UVB/5hPhDT4PWXMv+tMKqAgRtpO tWzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2e5dSuxiDhLvZLBlfxMCZNEI3nmt9JTGyl+hM6xKSpU=; b=GFXeEGcGP7g5xDDYM41FJNcguLQBELpgarPlTFsHoZjbOCULbciwyCNauHtFqO9VPI 5/9O73Y5sJgBDj6wQtlFz0rdgLRweNiBqrNORcIA7STgXBGqHJcTXpyLcDDsG83PSDzV jqwPKS/CbX/OnG4M1R1IcA5uRiVxKwyhx5rvy4EisQubZ0Fkq2M/VhU1RppwFmPexdHz QNzCTDypOUEmW6q5kzUaCLQHFK1Rex4ryPVPNv916k4RIIQiazwURqiRpdDuy8NzHiCC ZGT2YSZo2TxAvHt1Mnn0id1+2Z7xv2BTdnOWhe9qmw9j+AMYYj766odmTg/eIzakjEwx wT+Q==
X-Gm-Message-State: AOAM533cdX9zIUwpxemthKr3QKidOW+3Z3RzAG8P6VFzXXEgB2BqMA3o RLOu7iPNuOizsWIPlxv823gpacGDRi9aG886xMU=
X-Google-Smtp-Source: ABdhPJw+vixLkT20kpdpCTF0Oao8PvZMrTgfbZD6wZUeGUSrn2TFj00l0yWxFi3W9Ja8XQkT83c6Rgk8fwQaxz+bgWU=
X-Received: by 2002:a63:7206:: with SMTP id n6mr8166979pgc.206.1622054506343; Wed, 26 May 2021 11:41:46 -0700 (PDT)
MIME-Version: 1.0
References: <CAF4+nEFuQ8zvaxKTkBTqb3q_gQWTMYJDF+GQTz-A1OPPkrj1Ag@mail.gmail.com> <87v976voss.wl-jch@irif.fr> <CAF4+nEG0rJ7ykAuoUS8VoC2XvEk5VvmHiykmGMyvyPP1OcQhJQ@mail.gmail.com> <CAPDSy+61k62heXUc4SVutKKkOVoYFj+SOyWRuE-2dybaFo62xA@mail.gmail.com> <CAF4+nEEeXhuTsDR-YFBXhGUwvfFaiLmjb0+V8LZm7Ns-7y31fA@mail.gmail.com>
In-Reply-To: <CAF4+nEEeXhuTsDR-YFBXhGUwvfFaiLmjb0+V8LZm7Ns-7y31fA@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Wed, 26 May 2021 11:41:35 -0700
Message-ID: <CAPDSy+5kA4N32ZOjKbn7r4bs1VjDhxAj-SdBeTk2UFNUyV0cYw@mail.gmail.com>
To: Donald Eastlake <d3e3e3@gmail.com>
Cc: Juliusz Chroboczek <jch@irif.fr>, Babel at IETF <babel@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a8319705c33ffe80"
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/rJnlpInW8LxP6tVOBi6jHnwi7SQ>
Subject: Re: [babel] Adding two babel milestones
X-BeenThere: babel@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "A list for discussion of the Babel Routing Protocol." <babel.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/babel>, <mailto:babel-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/babel/>
List-Post: <mailto:babel@ietf.org>
List-Help: <mailto:babel-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/babel>, <mailto:babel-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 May 2021 18:41:52 -0000

On Tue, May 25, 2021 at 9:02 PM Donald Eastlake <d3e3e3@gmail.com> wrote:

> Hi David,
>
> On Tue, May 25, 2021 at 8:24 PM David Schinazi <dschinazi.ietf@gmail.com>
> 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.

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

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


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

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.

David


Thanks,
> Donald
> =============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e3e3@gmail.com
>
> > David
> >
> > On Tue, May 25, 2021 at 11:25 AM Donald Eastlake <d3e3e3@gmail.com>
> wrote:
> >>
> >> Hi Juliusz,
> >>
> >> On Tue, May 25, 2021 at 11:03 AM Juliusz Chroboczek <jch@irif.fr>
> 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
> >>
> 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.
> >>
> >> > >   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
> >>  d3e3e3@gmail.com
> >>
> >> > 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
> >>
> >> _______________________________________________
> >> babel mailing list
> >> babel@ietf.org
> >> https://www.ietf.org/mailman/listinfo/babel
>