Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt

[Joe Touch <[e-mail]>]

HI, Fred,

AOK - I can add that. The point is that *IF* you get multiple answers
(regardless of how), you use the min.

And the ingress needs to determine that value before sending for sure
and there's always the possibility of PMTUD doing odd things if ICMPs
are blackholed here - but partial delivery in that case isn't unique to
tunnels.

I'll mention it, though.

joe


On 5/16/2017 4:31 PM, Templin, Fred L wrote:
> Joe,
>
>> -----Original Message-----
>> From: Joe Touch [mailto:[e-mail]]
>> Sent: Tuesday, May 16, 2017 4:17 PM
>> To: Templin, Fred L <[e-mail]>
>> Cc: [e-mail]
>> Subject: Re: [Int-area] I-D Action: draft-ietf-intarea-tunnels-05.txt
>>
>> Fred,
>>
>> Regarding the following point:
>>
>>
>> On 3/28/2017 9:36 AM, Templin, Fred L wrote:
>>> 19) Section 4.3.3, third paragraph, I thought it was said earlier
>>>     that all ingress/egress pairs must support the same MTU. I
>>>     thought we agreed earlier on that that multi-MTU subnets
>>>     don't work. So, I think it should say that all ingress pairs
>>>     MUST support a uniform MTU.
>> The cited section allows for ingress/egress pairs that don't support the
>> same MTU, but then says that the MTU used for that set is the minimum of
>> those MTUs.
>>
>> There's no way (short of configuration management) to ensure that
>> ingress/egress pairs MUST support the same MTU, but no real value to
>> requiring that - AFAICT, we just use the min across that set (which is
>> what that section says to do).
> What I am trying to get at is the need for an ingress to determine the
> minimum before it sends a packet that may be too big for one of the
> multipoint link egresses. On IPv6 links, this could be through receipt
> of an MTU option in a Router Advertisement message. Other ways
> are possible (e.g., static configuration) but there needs to be some
> way for all ingresses to determine the minimum.
>
> Thanks - Fred
>
>> So yes, we do not *use* different MTUs per-destination, but we don't
>> need to require it AFAICT.
>>
>> Joe