Re: [Int-area] Comments on draft-van-beijnum-multi-mtu-02

[Dave Thaler <dthaler at windows.microsoft.com>]

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:iljitsch at muada.com]
> Sent: Tuesday, March 11, 2008 12:34 PM
> To: Dave Thaler
> Cc: int-area at lists.ietf.org
> Subject: Re: Comments on draft-van-beijnum-multi-mtu-02
>
> On 10 mrt 2008, at 23:17, Dave Thaler wrote:
>
> > 1) Section 3.2 should motivate better why Path MTU Discovery doesn't
> > already solve this problem.  Certainly one issue is that the router
> > has to communicate a value larger than the link MTU in the IP-over-
> > foo document, no question about that.  But once that is done, why do
> > you need the ND probing mechanism as opposed to PMTU discovery?
>
> RFC 1191 PMTUD requires that hosts receive ICMP too big messages. In
> order to be able to generate those, a router (I guess a switch could
> also do it) must first successfully receive a packet, then determine
> that it is too big to be forwarded and then it can return the too big
> message.

Right.  RFC 2461 states:
"If the bridges do not generate ICMP
Packet Too Big messages, communicating nodes will
be unable to use Path MTU to dynamically determine
the appropriate MTU on a per-neighbor basis.  In
such cases, routers use the MTU option to specify
the maximum MTU value that is supported by all
segments."

Note the specific clause that suggests that bridges can generate ICMP
too big messages.

> On a link with variable MTUs the second step is not possible without
> additional communication of per-destination MTUs, and even then
> "invisible" layer 2 devices can get in the way. These layer 2 devices
> can't do step 1 because of hardware limitations.

I don't know what you mean about "can't do step 1".  Can you elaborate?

[...]

-Dave
_______________________________________________
Int-area mailing list
Int-area at ietf.org
https://www.ietf.org/mailman/listinfo/int-area