I didn't mean to suggest that you can't support higher MTUs, but the latest version definitely addresses my DISCUSS. Thanks.
On Thu, Apr 22, 2021 at 3:13 AM Carles Gomez Montenegro < [email protected]> wrote: > Hi Martin, > > Thank you very much for your feedback, and apologies for the late response. > > We just published an updated version of the draft (revision -10). > > Regarding your Discuss point, after discussion among the authors and with > the WG, we aim to address the issue by stating now that: > > “As per the present specification, the MTU size for IPv6 mesh over BLE > links is 1280 octets.” > > (Initially we thought that it might be a good idea to keep the flexibility > offered by the IPSP in this regard, but we finally realized that it was > not such a good idea.) > > Should you have further comments, please let us know. > > Thanks, > > Carles (on behalf of all the authors) > > > > > Martin Duke has entered the following ballot position for > > draft-ietf-6lo-blemesh-09: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-6lo-blemesh/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > I found this paragraph in Section 3.1 to be hand-wavy: > > > > "Note that this specification allows using different MTUs in different > > links. If an implementation requires use of the same MTU on every > > one of its links, and a new node with a smaller MTU is added to the > > network, a renegotiation of one or more links can occur. In the > > worst case, the renegotiations could cascade network-wide. In that > > case, implementers need to assess the impact of such phenomenon." > > > > What are the consequences of link "renegotiation"? If every MTU downgrade > > results in a storm of messages, that's a bad property. Is the use case > > where > > the MTU must be the same on all links an important one? If not, simply > > requiring hosts to handle this case seems way cleaner. > > >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
