Re: [babel] Adding two babel milestones

Donald Eastlake <d3e3e3@gmail.com> Thu, 27 May 2021 13:54 UTC

Return-Path: <d3e3e3@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 EAC523A0D02 for <babel@ietfa.amsl.com>; Thu, 27 May 2021 06:54:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 sjYQZsMX4OX5 for <babel@ietfa.amsl.com>; Thu, 27 May 2021 06:54:05 -0700 (PDT)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 2D21C3A0D01 for <babel@ietf.org>; Thu, 27 May 2021 06:54:05 -0700 (PDT)
Received: by mail-il1-x12d.google.com with SMTP id k4so316701ili.4 for <babel@ietf.org>; Thu, 27 May 2021 06:54:05 -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=y7SkeLiYCnXmc99iQjxXVQiVFUPt3L3bXUzYc/CvY70=; b=aoyQcyAEbLaqYR79VAagpRiTuuaPRUPucTJ3zWwyNB/qfcqWnD+LhsEpjDcM5Nb9MF b7s1NuRKRNcZYyiULVgRDEdlJxi4Y4i1lkLQkPXaBq58oA4fT5ZjuwZZBJLEvupmrJ0B 8BEo2lCcpglggXmugG26XpLajbVcII4mvccQ0z1phRJzeXA1flHgvjoZ8ODqyVj7MuRY /rFtDmXharbsp81ZVjN/TS5OquQla5aJtJIH/af1R+vf0hIePeOGxSk8geU5lQVFKVPJ UbIVfXijSy5fuTXn9NSSu8+HG6a7PnHDmrr/RWNY6yfOo7OSz+4G/sMrrY+d0Dz/PRtY L62A==
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=y7SkeLiYCnXmc99iQjxXVQiVFUPt3L3bXUzYc/CvY70=; b=NePQ95uwhd7+3vz/RNtlgQl/X0YlZnaXzU0IrAEod2+f+lRMr8tXsZfkHdpRMbQ9le AyyNSery3YHv7/Zf2yh4HxmjswxZd8yMwRlwD9RJMmgaxUskPud+Dn7iKkcpogVxrdBX zKuap8PDYHOEC4KvmkZ4hpmZJg4mIEkuVi5DVGEgehLd4ffyl7Aa6CDJtv9Xc48PBDel 46eAnuH2k6f1qlXOqhcAy9Iol+ghUdSF28JpRXsRrGBVx3xt/QVbb0ivmTpPOpM9q6BV CttoAH0rkq0ppvKXOLvxmNJe/K47AtcSey6mnhAOQhfF8zHVWHvZBWyAKYzVlFJ9PTH0 /W8w==
X-Gm-Message-State: AOAM533mMrG/WRyuu1QSc0/fLDpysbWb3zuJsKaDyX/HvnI8Nyic/Vxq 9F/P81IOIf5AP+ui9UIqFLT2SJm6fG9pqzgPnAo=
X-Google-Smtp-Source: ABdhPJyCEkzuYGQ6Ilr0OdrS8hEq3PKRfOCCT2Cji0wqgLykCqLeEqOnigkxV7JqkqhKKyFclwfQN9K6Q5pntO0V4xA=
X-Received: by 2002:a92:6b05:: with SMTP id g5mr3093665ilc.40.1622123643536; Thu, 27 May 2021 06:54:03 -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>
In-Reply-To: <CAPDSy+5kA4N32ZOjKbn7r4bs1VjDhxAj-SdBeTk2UFNUyV0cYw@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Thu, 27 May 2021 09:53:52 -0400
Message-ID: <CAF4+nEHQOUu6fk9xj71FXjwTV8tMG9ZFqZeKC=5pDjkKStdPWA@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: Juliusz Chroboczek <jch@irif.fr>, Babel at IETF <babel@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/9ZU_iuR4PTAChnAAYV96azpQGCU>
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 13:54:10 -0000

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.

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


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