Re: [6lo] Martin Duke's Discuss on draft-ietf-6lo-blemesh-09: (with DISCUSS)

[Martin Duke <[e-mail]>]

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 <
[e-mail]> 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.
>
>
>