Re: [babel] Adding two babel milestones

Donald Eastlake <d3e3e3@gmail.com> Tue, 01 June 2021 20:15 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 CF2923A25F5 for <babel@ietfa.amsl.com>; Tue, 1 Jun 2021 13:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level:
X-Spam-Status: No, score=-1.849 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] 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 Yxtvd2qF4jNv for <babel@ietfa.amsl.com>; Tue, 1 Jun 2021 13:15:39 -0700 (PDT)
Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (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 09D203A25F4 for <babel@ietf.org>; Tue, 1 Jun 2021 13:15:38 -0700 (PDT)
Received: by mail-io1-xd33.google.com with SMTP id r4so45827iol.6 for <babel@ietf.org>; Tue, 01 Jun 2021 13:15:38 -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=kEevcqNPACN9hsN1axSxvsgUBV654fQN68TC6nroxGg=; b=bfTjqdKkwdLj5fiucyJwfS8zoZx1TevEHZpQ0dLdDjc3HdJmPFJ3XMVN9alrDrCBGf tpwNhdJx7cg2kZS5cSkYbwUcvao0/rYPUotedskiYU3vUZZdfRlKfmVBrkvRFtSD8VtP Wb/NsYTSxS10GsK5hBV2YP9mNT1gP43WRBF8RrW5RVaO/EwYJBnva9Nlm5YMShODWbRc RrIb3DFnFtCvXYayR5fZBioy/k82lB1dejVb1T2J1AD+i/SKCBCFqijV92gpPy9y1oMd uSzk/q4dNX2Xp4cubI/fiTu4UMqPJVZMDTV1MxnrGNqmc9rHPJRNpwR9cAj/eLeQWwOt 2oSw==
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=kEevcqNPACN9hsN1axSxvsgUBV654fQN68TC6nroxGg=; b=BS2CN9q1xcsbmjSxJDm1+YQIhY220wewhgjYBPYWEhPvJQOlaX9hhAeGn9uAAPzwEe 2N9wPmFr7maSBUqv6t/cqiicO0fRX61xN33phHd7hVlgh3zc1+ETNgFYe0Wn7GcFgTdk +p3JTpmOWGt2OOav62qJYlxTAx0/5TyvdMiLVKhT2EpRKAxE/0azrGtzb1d5yDPDbAmx CrzKbFrOJiuVHzGNJVWvtVm2ujoWriRJXn1EP08xs53A+9eWxHahbHFRzXPk937Uo7cq +1CeK+f4Ty20GAJRqm7V7A2NreVJ2xBrmFkLvVrPMzPuAoAcFqL1EAThbuC6+F9RFEgn hzOQ==
X-Gm-Message-State: AOAM533b/ysqTewZcLK2wg1KtHQkFaZVvm4S7osLShVlZXSsyF6Pf7pD gNO8NTzXlDWe7CZkG0dPcumQ+9Qtcg07PyKgQkU=
X-Google-Smtp-Source: ABdhPJzPhGSpDAz1lCCWFBJDhgh0eZB+E2E/4ov2R1+wsbcM8QqGkqNMXcezM32MhFCFNHljuiOfnv9lvAD0JB82QxY=
X-Received: by 2002:a5d:8190:: with SMTP id u16mr18178703ion.158.1622578536130; Tue, 01 Jun 2021 13:15:36 -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> <CAPDSy+7rnxrZDkfUzRGsyaj+RUFxBEyDubETrzx5huFSb3eUxw@mail.gmail.com>
In-Reply-To: <CAPDSy+7rnxrZDkfUzRGsyaj+RUFxBEyDubETrzx5huFSb3eUxw@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Tue, 1 Jun 2021 16:15:25 -0400
Message-ID: <CAF4+nEFw3rp3VG5h3Y7WzyjpD22fEnw81pT2tAQvd6uCP=djtg@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: Babel at IETF <babel@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/babel/FGzIT62rwOM8TjXdHxplCBCNeY8>
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: Tue, 01 Jun 2021 20:15:42 -0000

Hi David,

On Thu, May 27, 2021 at 11:36 AM David Schinazi
<dschinazi.ietf@gmail.com> wrote:
>
> 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:
>> >>
>> >> ...
>>
>> ...
>>
>> >> ...
>> >>
>>
>> ...
>>
>> >> 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?

Well, to the tenant your network looks like a link so you unavoidably
have the "link-local" tenant multicast. For example, for each of
possibly many connections to islands of a tenant you might have a
bridge and behind that an IP router so you would have BPDUs, LLDPDUs,
VLAN registration messages, LAGPDUs, etc., and then maybe ARP/ND/RA
and IS-IS Hellos and LSPs and SNPs etc. And there could be other
discovery services running... (And actually, TRILL fits exactly
between bridging and routing so a bridged LAN looks like a link to
TRILL but a TRILL campus looks like a link to IP routing, so you could
have TRILL "link-local" multicast packets in addition to bridging and
IP routing multicast packets.)

As to what you might consider "real" applications, I think it is
somewhat of a chicken and egg problem. Since non-link-local multicast
isn't supported that much, applications tend to avoid it which
decreases the incentive to implement it, and so on.

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

I've only added the IPv4 via IPv6 milestone.

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

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