Re: [Softwires] Genart last call review of draft-ietf-softwire-mesh-multicast-22

[Brian E Carpenter <[e-mail]>]

On 2018-09-17 19:01, Ole Troan wrote:
>> No, it isn't, but as far as I can see, any tunnel spec needs to state how this applies. If the tunnel keeps no packet state, how is it going to perform PMTUD? If the answer is that the tunnel end points need to be configured in some way, that needs to be stated too.
>>
>> Sorry to go on, but when I review a draft, I like to feel that if I had to, I could code it, and in this case I just don't know how I would code the AFBR with respect to PMTUD and/or including a fragment header.
> 
> Typically tunnels are either configured with a fixed MTU, or do path MTU discovery like any other host on the Internet.
> E.g. for a point to point tunnel it can dynamically set the MTU on a tunnel interface based on received PMTUD messages (or PLMTUD probing).
> For point to multi-point tunnels it maintains a PMTUD cache.
> There’s no magic for tunnels here, just like Joe says.

No, of course not. But the implementor has to do something, and I don't see
how this can be an interoperable specification without some guidance
for the AFBR implementor.

Since there is implementation experience, it shouldn't be hard to provide
such guidance.

    Brian