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

[Carles Gomez Montenegro <[e-mail]>]

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.