On 19 Sep 2019 15:11, Ted Lemon <mel...@fugue.com> wrote:

Yes, of course. We can never change a standards track protocol. That would be wrong. :)

What I’m trying to understand is how bad a problem this is.


That's what I'm still trying to understand.

The reason for the 64k limit is clear (due to the design choice of relying on UDP fragmentation).

What's still unclear to me is why the packet contains all the nodes' TLV's. 

That is whether the limit is per node or per network.

It's not clear to me if that's an implementation issue (requesting four node TLV status requests in one packet, and ditto replies) or a standards issue (all node TLV's must be transmitted when the network TLV changes).

Regards,
RayH

> On Sep 19, 2019, at 04:56, Juliusz Chroboczek <j...@irif.fr> wrote:
>
> 
>>
>> This still doesn’t address the problem that the HNCP packet needs to be
>> fragmented.  Fragmented Multicast doesn’t scale well.
>
> HNCP doesn't fragment multicast, it only uses fragmentation for (link-local)
> unicast.  This is way less severe than what you incorrectly claim.
>
> At any rate, the right time to discuss that was 2015, not now.  HNCP is
> a standards track protocol, and there's nobody left who's willing and
> competent to work on a new revision.
>
> -- Juliusz

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet


_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to