Hello Joe, > Thanks for your detailed comments. All are queued up for the next revision.
You're welcome.
A few answers below. I removed all items we agreed.
>> First of all, I need to say that I found the
>> draft-ietf-intarea-tunnels-02 I-D extremely useful
>> and wish I found it before.
>>
>> We exchanged a few private emails with Joe last week and I promised to
>> send detailed
>> comments on the list. Here they are... Sorry if this is a bit long.
> ...
>> I also clarified the case of encapsulation header size that is deducted.
> It's worth noting throughout that MTU is defined as the size of the payload.
Yes but there are two notions of payloads depending on the point of view.
Figure 10 can be useful:
inner packet payload => iD
tunnel link packet's payload => iH+iD
>> ** Path MTU definition: I think it's worth clarifying that we focus on
>> the tunnel PMTU in this I-D.
>> I also explain that the encapsulation header size has already been
>> subtracted from the
>> Tunnel PMTU.
>>
>> OLD:
>> o Path MTU (PMTU): the largest message that can transit a path.
>> Typically, this is the minimum of the link MTUs of the links of
>> the path.
>>
>> NEW:
>> o Path MTU: the largest message that can transit a path.
>> Typically, this is the minimum of the link MTUs of the links of
>> the path.
>>
>> o Tunnel Path MTU (TunnelPMTU): the largest Tunnel Transit Packet
>> (or fragment)
>> that can transit inside the tunnel's path. The encapsulation
>> header size is already
>> subtracted from TunnelPMTU and this TunnelPMTU is not visible
>> from outside the
>> tunnel, unlike the Tunnel MTU.
>
> This definition is what the tunnel MTU is intended to convey.
I don't understand. If we re-use example of 4.1, Tunnel MTU=1460 - TOptSz
while tunnel path MTU=1240 - TOptSz. The first one is visible to source,
the second one is not, and the difference is due to reassembly at egress.
> I think we do need another term for the path MTU between the egress and
> ingress but NOT inside the tunnel. I prefer to just call that the PMTU
> between the ingress and egress, though.
Okay, this is the regular IP vision of PMTU. If we need it, we can define it.
>> ** In tunnel MTU definition:
>> Say explicitly that the encapsulation header size has already been
>> subtracted from
>> the Tunnel MTU, since encapsulation headers are considered as
>> "headers from lower
>> protocols" and therefore excluded.
>>
>> OLD:
>> o Tunnel MTU (TMTU): the largest message that can transit a tunnel.
>> Typically, this is limited by the egress reassembly MTU.
>>
>> NEW:
>> o Tunnel MTU (TunnelMTU): the largest message that can transit a
>> tunnel.
>> The encapsulation header size is already subtracted from TunnelMTU.
>> Typically, the TunnelMTU is limited by the EgressRMTU.
> This should be clarified as the MTU that can transit *inside* a tunnel.
yes, it's simple and consistent with the tunnel=link viewpoint.
>> ** Still section 4.1: we cannot say that 1500 is the minimum
>> EgressRMTU as
>> we need to remove the encapsulation header size before as detailed above.
>> I also tried to explain why... Not easy! Do you have a better explanation?
>
> It's because IPv6 uses the term MTU in terms of the link payload, not as
> the network payload.
You're right, RFC2460 uses "link MTU". I never paid attention to this.
> Throughout this doc, we similarly refer to the tunnel as a link, so link
> MTU is the correct notion.
Yes.
Regards,
Vincent
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Int-area mailing list [email protected] https://www.ietf.org/mailman/listinfo/int-area
