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

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

Hello Bob

The data was not published. This is why I asked for a measurement during the IETF meetings.

I do not know the ratio of traffic ND represents and you should know that it is meaningless on wireless if you do not account for relative PHY speed and loss of spectrum reuse and MUMIMO. I do not know the number of users, that was an excessively large room, bigger than our usual plenary though by far not a stadium.

What’s more interesting is that this group does not have such numbers. Shouldn’t we ?

For your last comment, we may consider doing protocols so that people can do what they want as opposed to ask them to bend their deployments to match inappropriate designs. 

This lack of consideration makes the bed of newIP-like endeavors, uncontrolled middlebox operations and proprietary tricks in switches and routers. But maybe a maintenance group is not the place to upgrade the protocol. Maybe we need an IPv6 working group again.

Just look at how BESS is doing DAD today. Then think SAVI. And we are in 2020. 

Regards,

Pascal

> Le 10 août 2020 à 01:42, Bob Hinden <[e-mail]> a écrit :
> 
> 
> 
>> 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
>>>> --------------------------------------------------------------------
>>> 
>