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

["Pascal Thubert (pthubert)" <[e-mail]>]

By memory this was around 300/s Bob.

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. 

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