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

[Bob Hinden <[e-mail]>]

> On Aug 9, 2020, at 2:23 PM, Pascal Thubert (pthubert) <[e-mail]> 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 <[e-mail]> a écrit :
>> 
>> Pascal,
>> 
>>> On Aug 9, 2020, at 11:56 AM, Pascal Thubert (pthubert) <pthubert=[e-mail]> 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 <[e-mail]> a écrit :
>>>> 
>>>> Do we have data that indicates that this would be an improvement?
>>>> 
>>>>> On Aug 9, 2020, at 11:47, Philip Homburg <[e-mail]> 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
>>>>> [e-mail]
>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>> --------------------------------------------------------------------
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>