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

Bob Hinden <bob.hinden@gmail.com> Sun, 09 August 2020 23:42 UTC

Return-Path: <bob.hinden@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A983A0C8B; Sun, 9 Aug 2020 16:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, 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 Q0dX9Sm-xn0n; Sun, 9 Aug 2020 16:42:29 -0700 (PDT)
Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (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 CAE5A3A0C8F; Sun, 9 Aug 2020 16:42:26 -0700 (PDT)
Received: by mail-wr1-x429.google.com with SMTP id a15so6508397wrh.10; Sun, 09 Aug 2020 16:42:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=52DhmgHq41BxJJuyeRib0sr4N64oL9GbqmdtsChO/V4=; b=FUlFUMOVgytlmarkp48hYhi7EtFkz9BtDbZnHOpOxN0rNqiS8fJTiR2yUGvgGVPorO LpNhxpXb4p2mhpvTFZ7wdUCmh7BnRYmJ2pIED98w6WqddgW6I/t/prl+3n9flZlPSTTb 5LTIULQhCriLAGU3dfV+JLsVAlLEIfOuLwqpP79jkLSc17n4BSFjVfZiKzSr8AvPebl9 l26u6vvrZMT2NtIF+BkeEFyY3u/kPx9t8DNtBg0mKXeK/4aay6i0Hrrz/dS86eK60C7a Hwj63UUaiplHkvZ0sKSs9Rv8uLyB5jn2KwJCK8zqWVIJqprwDy4a6QZ2FZkUfnY5+UB4 M2ng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=52DhmgHq41BxJJuyeRib0sr4N64oL9GbqmdtsChO/V4=; b=nOWic4pBsNyHn8dqiR5Ki377KYMFuPmacWjSNFlwH8fUZftcvso9QAm1ppHgYbDNv5 Si2KoLNjgBIDy7SB2xw6kPsh+ziGpM7U5nOoPTZbhjeR7UGs/c4GkArtcNkqusY2fO31 CAmZkFAjWphiGZHYZdvcEiWInz2dCW6V+aL0Z0R2EH0MQLgnYH3UUy7k3SOMMcR9KBST ThMHv/LgxGAIx5et6JTr4a4S3XLDCyNwWF86C13NK1aF/lUkLvHKAhny03B8zrh4bhwP 84I6fFQonL+2WAXeu6fxUhhN86FhfpmwYry14MZZrrDb3GIXoaDXlX5wGe7HYTIl9gyK 6kFw==
X-Gm-Message-State: AOAM53383dx78zAOzWg1edJ+wTvtaevFmnI+2S4OTumZ1G7iKgxbQ/14 UhKUJngWoLEALkqYE873dB4=
X-Google-Smtp-Source: ABdhPJwPOiSJkr1/50ZBpbZxmaEnO80+Q8IAVg97FFPTAfFDn4G42TtPHwWybc+aAVEPwaP17FT1zQ==
X-Received: by 2002:adf:ed0f:: with SMTP id a15mr22289967wro.341.1597016545155; Sun, 09 Aug 2020 16:42:25 -0700 (PDT)
Received: from ?IPv6:2601:647:5a00:ef0b:1072:f6de:c5f8:6a90? ([2601:647:5a00:ef0b:1072:f6de:c5f8:6a90]) by smtp.gmail.com with ESMTPSA id x4sm17236277wru.81.2020.08.09.16.42.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 09 Aug 2020 16:42:24 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <0A2FD466-6DB0-4378-88B7-AB99D32C2180@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_EA594DD6-FD3F-4FC0-9A9E-575A655EB4B8"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\))
Date: Sun, 9 Aug 2020 16:42:18 -0700
In-Reply-To: <B50732C5-4BBA-49E4-A169-74677C91B88B@cisco.com>
Cc: Bob Hinden <bob.hinden@gmail.com>, Ted Lemon <mellon@fugue.com>, "v6ops@ietf.org" <v6ops@ietf.org>, IPv6 List <ipv6@ietf.org>, Philip Homburg <pch-v6ops-9@u-1.phicoh.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
References: <m1k4nX7-0000ICC@stereo.hq.phicoh.net> <1D1A68AE-4C75-4DF0-8C7C-3500DB67C8FB@fugue.com> <4B1A43D0-45B1-4C73-8B09-089D4EC1FFF7@cisco.com> <17A8FA06-3776-450A-B549-958157AD5784@gmail.com> <B50732C5-4BBA-49E4-A169-74677C91B88B@cisco.com>
X-Mailer: Apple Mail (2.3445.104.15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/v6ops/6oaFBjmLX2Pg42JtMPDAA9Wz1jQ>
Subject: Re: [v6ops] draft-ietf-6man-grand : saving lookups
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Aug 2020 23:42:43 -0000


> On Aug 9, 2020, at 2:23 PM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
> 
> By memory this was around 300/s Bob.

Do you have a reference?  Also, answers to my other questions?

> 
> This might look innocuous on a wire but on Wireless the broadcast is expensive, because it is sent at the lowest speed in all directions.
> 
> This clogs the medium, maybe 5 to 10% of it; for no value at all but to offer the stick to beat us; well would have If we had let all that over the wire.
> 
> It is expensive too when a fabric spans multiple remote sites.
> 

I thought we learned long ago to not create large distributed broadcast/multicast domains.

Bob



> Dismissing the problem, looking elsewhere is just not the way to go.
> 
> Regards,
> 
> Pascal
> 
>> Le 9 août 2020 à 21:13, Bob Hinden <bob.hinden@gmail.com> a écrit :
>> 
>> Pascal,
>> 
>>> On Aug 9, 2020, at 11:56 AM, Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org> wrote:
>>> 
>>> We have some Ted;
>>> 
>>> In large meetings we measured way above 100 ND multicast messages per second on the wire, for 90 minutes in a row.
>> 
>> What does “way above 100” mean?   101, 1000, 10000, ?
>> 
>> 100 per second doesn’t seem excessive to me.  What percentage of overall messages was that?  How many nodes on the link?
>> 
>> Bob
>> 
>> 
>>> 
>>> This was on the wire because we use proprietary tech to dampen the wireless side, things like ND proxy but based on snooping for the lack of a better information.
>>> 
>>> I asked for the figures at the last 2 in person IETF meetings but never got them. First time I asked too late, there needs to be due process to guarantee anonymity. Not sure if they were captured in Singapore and if so where they are.
>>> 
>>> Take care,
>>> 
>>> Pascal
>>> 
>>>>> Le 9 août 2020 à 18:04, Ted Lemon <mellon@fugue.com> a écrit :
>>>> 
>>>> Do we have data that indicates that this would be an improvement?
>>>> 
>>>>> On Aug 9, 2020, at 11:47, Philip Homburg <pch-v6ops-9@u-1.phicoh.com> wrote:
>>>>> 
>>>>> 
>>>>>> 
>>>>>> So what I'm after is the host behavior of "not onlink" for the
>>>>>> lookup phase, the router behavior of onlink for the redirect phase,
>>>>>> and the L bit set iff the link is P2P or a transit. E.g., in a
>>>>>> distributed fabric, all addresses "reside on-link and can be reached
>>>>>> directly without going through a router" and yet we want to avoid
>>>>>> broadcast lookups.
>>>>> 
>>>>> Suppose we have a no-multicast bit, that tells a host to send traffic to
>>>>> its default router when it doesn't have a neighbor in the NC cache.
>>>>> 
>>>>> It is not clear to me how the semantics would be different from clearing the
>>>>> L-bit, but if you think there are considerable differences, why no write
>>>>> a draft that describes the use of such a bit.
>>>>> 
>>>>> 
>>>>> --------------------------------------------------------------------
>>>>> IETF IPv6 working group mailing list
>>>>> ipv6@ietf.org
>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>> --------------------------------------------------------------------
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>