On 23-Aug-21 12:26, Michael Richardson wrote: > > Brian E Carpenter <[email protected]> wrote: > >> Brian E Carpenter <[email protected]> wrote: > >> > (1) Flooding (M_FLOOD) messages. These are UDP multicasts, so in > effect > >> > all nodes must agree on the same maximum size. To send messages above > >> > the present limit, the maximum flood message size would have to be > >> > increased everywhere in the autonomic network. That is trivial if > > we > >> > allow operator configuration, but since an AN should be > self-creating, > >> > we want to avoid operator configuration. Therefore, we need GRASP > > to be > >> > able to self-configure this. > >> > >> For the flooded messages over UDP, it seems unwise to ever assume we > can > >> reliably get more than 1280 through. In production, this goes over > IPsec ESP tunnels. > > > Why would that break IPv6 fragmentation? We can assume a well-defined > > MTU within an autonomic network, I think. These are all link-local > > addressed packets, so there is no PMTUD problem. > > But, it's not over link-local. > It's over a mesh of point to point IPsec ESP tunnels.
Sure, but the VRF has to emulate LL multicast to ff02::13, and there must be a well-defined MTU for that emulation, regardless of the mesh. > Choices are: > 1) fragment before encrypt. Reassemble after decrypt. Please. > 2) encrypt and then fragment the ESP. > Depends upon ESP assembly buffer being big enough. Please not. Brian > > Both tend to work, up to some ill-defined limit which is not always 64K. > (1) is likely easier to fix if it's broken, since re-assembly happens in the > control plane CPU, rather than, possibly, in some IPsec hardware. > > -- > Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
