Re: [v6ops] draft-ietf-6man-grand : saving lookups

"Templin (US), Fred L" <> Mon, 17 August 2020 14:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA0F93A0C51; Mon, 17 Aug 2020 07:09:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 oN9rCSfCTQ0M; Mon, 17 Aug 2020 07:09:15 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DDE283A0C06; Mon, 17 Aug 2020 07:09:14 -0700 (PDT)
Received: from localhost (localhost []) by (8.15.2/8.15.2/DOWNSTREAM_MBSOUT) with SMTP id 07HE99hd012936; Mon, 17 Aug 2020 10:09:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=boeing-s1912; t=1597673352; bh=PJqw0ZGXpKy3FtRTLy1qGcmCkI1FDuHwT9ee3tXQ8gA=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=U/3CpZIV/h8T19HTpDEOBq4wYcgUKmTzY+cI8O4d3dYsBgsX0XdjYx3TLQ3ARM4ND 77Md8RGctCuUlcx9geKnoit2rN/NsivVjwmAgndr4RIHV96SCilYwTa5b8IipxrHHh e7qFnIMvUL2ki3ZhpSWHRMeEmzd3MYUhC8JinIUjdnqlHq6Rypj7RgeMw8arl4sUcE QzYDA0M/ItI6nBAkkw2wqyngC5qWOebSb2nPYAwiM+5s7cMS6ruhIjeYxyUwrZPnih b3UXUJj5mx0MWGPlIXeM3LSlpQfXzDtqHxzIgg9CMKjfnSxUWar5xGOPfjvHs8Yx8Z XyYEwxbUNkKGw==
Received: from ( []) by (8.15.2/8.15.2/8.15.2/UPSTREAM_MBSOUT) with ESMTPS id 07HE8xFS011478 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Mon, 17 Aug 2020 10:08:59 -0400
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.1.2044.4; Mon, 17 Aug 2020 07:08:58 -0700
Received: from ([fe80::1522:f068:5766:53b5]) by ([fe80::1522:f068:5766:53b5%2]) with mapi id 15.01.2044.004; Mon, 17 Aug 2020 07:08:58 -0700
From: "Templin (US), Fred L" <>
To: "Pascal Thubert (pthubert)" <>
CC: IPv6 List <>, "" <>
Thread-Topic: [v6ops] draft-ietf-6man-grand : saving lookups
Thread-Index: AdZv/nPAXPbo98BsTRy+/vxuNZBYcwAAtAeAAR1NU+AACiuXIA==
Date: Mon, 17 Aug 2020 14:08:58 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-snts-smtp: BD2B5F8BF2651EE2BBA6037B768CC0BAE2F8F4F43D09A65CD8DF8349172060C92000:8
Content-Type: multipart/alternative; boundary="_000_258750d2b12c423291bf4a3e3ab715f6boeingcom_"
MIME-Version: 1.0
X-TM-AS-GCONF: 11111111
X-TM-AS-SMTP: 1.0 Y2x0LW1ic291dC0wMS5tYnMuYm9laW5nLm5ldA== RnJlZC5MLlRlbXBsaW5AYm9laW5nLmNvbQ==
x-imss-email-tag-status: notag
x-imss-email-tag-ndr: notndr
x-imss-email-tag-format1: unknown
x-imss-email-tag-format2: html
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--34.209-10.0-31-10
X-imss-scan-details: No--34.209-10.0-31-10;No--34.209-4.5-31-10;No--34.209-5 .0-31-10;No--34.209-10.0-31-10
X-TM-AS-Result-Xfilter: Match text exemption rules:No; Match text exemption rules:No
X-TMASE-Version: IMSS-
X-TMASE-Result: 10--34.209200-10.000000
X-TMASE-MatchedRID: HsnSQcO8htG8wYz+pTajLS1gNysqkMBhBaTsDKw4uJuQ1SnerYd+EK1Z GUKR0YgsjJSanf+vxwkkwlcMmOSp1GurLpElz3nxHw/GFrdAalYOZPFR5w4TsXNzTI/PdquKTLZ B6U/YaPr0i0LZ2ZefXUiO7+wNDdeY1j/C5GjH2oQFWQZRPMLZnOuW4IfKKEcuHC7hAz/oKnK8xE 2H2EuMWfyQXCBzKijhouaXE/reSZlbE5AQ4+sUylfIICmtvJUnV5Q91MZHczTiHyvyXeXh5j7sh OThrdN/RjNrjV0arFI5Jk7hr3RRUHoITrrQQ8uraShJSffb/QNYnYaRn+84cJRpgJ74o180Y4iW rUKNKlDAXwY9kbw5co4makWSIXbDHotHLBURPSsQHhXrWiYmrgfcn38EnaBHR+GtoiXVeDGL5MC c+du22KnTSb+60o4B7/+9swuISRVLbeMXCgjtvX7W5bdwgnW8o5RUoF1j1rgItCy6ZX/lL4IWSp rjdsebHCP6WbPscS8wfkn2bVbTjx8jFCsOZzQil+soBKtnVK3f8QWOo2ap2VuG9y1leuU7YUuZn 9VXZWG5jfwdoC7OjmhkSwpykoqVBRkDpXylQ1n3JpeE+GdRnSwwtxRkxyN3i+m1DDPm2yIg/CIf leX9D0RgqQYN6l+rMEqnbgFcVMNtOn7eKaRF5CTjJYmyRq1BbnvOXMlJIJSeAiCmPx4NwMFrpUb b72MUVMHZ5C2ljqBW8GflmYLXF11FkXVL+ky7OMB0shqXhHo5eTR52brcsSTK0gz5rL6T7NOiX6 ymIZZEDj8cpfbyrvRBH9fjnEsZ
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <>
Subject: Re: [v6ops] draft-ietf-6man-grand : saving lookups
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 Aug 2020 14:09:17 -0000

Hi Pascal,

See below for inlines:

From: Pascal Thubert (pthubert) []
Sent: Monday, August 17, 2020 2:39 AM
To: Templin (US), Fred L <>
Cc: IPv6 List <>rg>;
Subject: [EXTERNAL] RE: [v6ops] draft-ietf-6man-grand : saving lookups
Hello Fred:

100% agree. If the size of the multicast table is roughly that of the routing table, it looks particularly inefficient to maintain a multicast table for the sole purpose of DAD and lookup. We take great care in hiding that simple truth under the carpet by saying that’s a L2 problem. But it does not seem that L2 has taken the bait, has it.

It depends on the L2. If the L2 is a physical media like a fabric of Ethernet switches then
penetration down to L2 may not be happening. But, if the L2 is a virtual topology that
is manifested by encapsulation (e.g., and overlay) then the point may be moot.

As another case of what you’re describing,  fabrics are optimized to use a routing protocol (e.g., BGP with eVPN) and broadcast is the last resort, but there is no multicast in between. Sadly it is still there, because the fabric is lacking a clear view of what’s there.

Note also that the routing protocol is better suited to announce reachability than to perform DAD.

This is where some help from the host would be needed in place of the useless IGMP games. The host can help the fabric by providing accurate information on the addresses it is effectively using, a sense of duration, a sense of order in movements, and a proof of ownership. This information should be enough to differentiate a case of multihoming / anycast with a movement.

You seem to be assuming that the end system is a host that does SLAAC. I am assuming
an end system model that does link-local-only with unique LLAs where no SLAAC nor
DAD are necessary.

Thanks – Fred

All the best


On Aug 11, 2020, at 12:48 PM, Templin (US), Fred L <<>> wrote:
That is more or less the principle for NBMA, yes. But take a conservatively-sized NBMA
link with 1M nodes on the link but only 2-3 of them need to receive the multicast then
serially unicasting seems pretty efficient and does not disturb the vast majority of
nodes that don’t care.