Re: [babel] Adding two babel milestones

Donald Eastlake <> Tue, 01 June 2021 20:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CF2923A25F5 for <>; Tue, 1 Jun 2021 13:15:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.849
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Yxtvd2qF4jNv for <>; Tue, 1 Jun 2021 13:15:39 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 09D203A25F4 for <>; Tue, 1 Jun 2021 13:15:38 -0700 (PDT)
Received: by with SMTP id r4so45827iol.6 for <>; Tue, 01 Jun 2021 13:15:38 -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=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;; 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: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Donald Eastlake <>
Date: Tue, 01 Jun 2021 16:15:25 -0400
Message-ID: <>
To: David Schinazi <>
Cc: 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: Tue, 01 Jun 2021 20:15:42 -0000

Hi David,

On Thu, May 27, 2021 at 11:36 AM David Schinazi
<> wrote:
> On Thu, May 27, 2021 at 6:54 AM Donald Eastlake <> wrote:
>> Hi David,
>> On Wed, May 26, 2021 at 2:41 PM David Schinazi <> wrote:
>> >
>> > On Tue, May 25, 2021 at 9:02 PM Donald Eastlake <> 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.

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

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