Re: [babel] Adding two babel milestones

David Schinazi <dschinazi.ietf@gmail.com> Thu, 27 May 2021 15:36 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 A41423A138D for <babel@ietfa.amsl.com>; Thu, 27 May 2021 08:36:26 -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 gWIGTNR3aufv for <babel@ietfa.amsl.com>; Thu, 27 May 2021 08:36:22 -0700 (PDT)
Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (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 A42CB3A138A for <babel@ietf.org>; Thu, 27 May 2021 08:36:22 -0700 (PDT)
Received: by mail-pj1-x1034.google.com with SMTP id f8so707592pjh.0 for <babel@ietf.org>; Thu, 27 May 2021 08:36:22 -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=H/T8DMoVj2ekgphEYjv8BjpItm1DVAi8rNtbUiIM74o=; b=hIxzTLBzvATVmGdldTjejZ86bEkpVsAziV3DdaGZTamaFD0+bM2Fc0YsrM1/1lrg6H MtTbJ7rgBtyj5bLD8Ve83M4z/OpC91h7qsigO6ICQJocna0LMshe2VH9J3tLAF0MLcpR s3Bc+f0m6QptJJpoOF/Qc+0noHQBj0LssNQOQx1p8lxQCYUx6mcfDHQtAZCm56n1gEhn tcXYVu2XklkQ96RrOQRsnwhuPfb8jp7F0zPz+KOyvKt7VLh5RlynKyKRUZBWAW43oT8B L48L+yMVZFP0HG/+30/5XUTu+4Ehpx8tmpc63+g84s0CUD9WVSV7QG3wIIJok95z+b87 ODqQ==
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=H/T8DMoVj2ekgphEYjv8BjpItm1DVAi8rNtbUiIM74o=; b=ZsBGGLG/cIVd6RrUC8DLodlN8F62X1BY+e6tabV6TZGBl7YfMsaVwnV2Mxqmnaefhe bGPno107vz3zl4nw9FJY0q+ltPYRpuQ1kK4qTPUYOEdYb/hBqFBFkTbi8H4z7hD2PEBx 1ZIu4f5RDFq2Y00utCaqNJ11ppyX32a6nrSetz4fEvksL3b+LdO5XAlEj0vbixU14n0j JpAjb6pw+uf6pgFq+7Ge9J/wcug6Q3rYSTHVD3YCYTmygoq/IDkPPIjlc9V9KywLNII8 fQNmMd2tZeUoDRbcyNWxyTTUF8FpXm/UmiAvTKRdNgcBe/3oUc9o52xjBMqsWHsu/BJe 4vIw==
X-Gm-Message-State: AOAM531fcV9xazeJ4hg9hYgfx0JhM8rm3jEJLs2RGwI8d4cR8XkA58A/ FUGrru/oC6vjHN1Jnqw6T0jSMcvEJ5ajxl8pWc4=
X-Google-Smtp-Source: ABdhPJzSxbrX6xjksPR9hSDOTcLkOcgfkIev571Q2U1ubxGtGgd1hyPSDPtgqr0K8/EUkJdnBKWF9Rv1ZNg+Y803oBw=
X-Received: by 2002:a17:90b:3905:: with SMTP id ob5mr9972822pjb.94.1622129781644; Thu, 27 May 2021 08:36:21 -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> <CAPDSy+5kA4N32ZOjKbn7r4bs1VjDhxAj-SdBeTk2UFNUyV0cYw@mail.gmail.com> <CAF4+nEHQOUu6fk9xj71FXjwTV8tMG9ZFqZeKC=5pDjkKStdPWA@mail.gmail.com>
In-Reply-To: <CAF4+nEHQOUu6fk9xj71FXjwTV8tMG9ZFqZeKC=5pDjkKStdPWA@mail.gmail.com>
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Thu, 27 May 2021 08:36:10 -0700
Message-ID: <CAPDSy+7rnxrZDkfUzRGsyaj+RUFxBEyDubETrzx5huFSb3eUxw@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="0000000000006a201505c3518505"
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/utkvq40vkl-wYyLg6WUF-ru_asA>
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: Thu, 27 May 2021 15:36:27 -0000

On Thu, May 27, 2021 at 6:54 AM Donald Eastlake <d3e3e3@gmail.com> wrote:

> Hi David,
>
> On Wed, May 26, 2021 at 2:41 PM David Schinazi <dschinazi.ietf@gmail.com>
> wrote:
> >
> > 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.
>
> 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.

Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  2386 Panoramic Circle, Apopka, FL 32703 USA
>  d3e3e3@gmail.com
>
> > 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
>