Re: Reopening jumbo frames in IS-IS

[Curtis Villamizar <curtis at faster-light.net>]

In message <023c01c5896a$0ede1020$6501a8c0 at dax>
"Stephen Sprunk" writes:
>  
> > No one in their right mind (note that I this is a qualified "no one")
> > would bridge a PPP link to an ethernet link.  Standards should
> > discourage doing incredibly stupid things rather than try to
> > accomodate people who do them with no good reason for doing so.
>  
> Then a large number of ISPs are out of their minds...  The two main ways to 
> deploy ADSL service are (a) Ethernet bridged to PPPoATM, and (b) PPPoE 
> directly to the host.  I think the latter is also commonly used for DOCSIS.

Agreed.  :-)

These were more the choices of DSLAM vendors and to a less extent the
RBOCs/ILECs who were latecomers.  The traditional ISPs at the time
preferred that the DSLAMs just do IP over PPP on the customer router
or host and IP over PPP or ATM on the backhaul side.  The DSLAM
vendors thought that by matching the ATM parameters to the DSL rate
they could all but eliminate buffering in the DSLAM.

> If bridging POS and Ethernet were safer (i.e. jumbos could be assumed), we'd 
> probably see that become common in ISPs as well.

Has it become that bad already? :-)

Who was it that said the Internet is growing exponentially but the
amount of clue is growing linearly at best so the clue density is
shrinking exponentially?  I think it was Randy Bush in the early 90s.

> > TCP and most other modern protocols handle the end system MTU quite
> > nicely and TCP path MTU discovery is widely implemented and easy
> > enough to enable though I think it is still disabled by default in
> > most implementations.
>  
> Win2k and later have PMTUD on by default, but unfortunately not PMTU black 
> hole detection.  I'm not sure about earlier Windows versions or 
> MacOS/Linux/etc.
>  
> However, there's no current means for MTU detection for hosts on the same 
> subnet.  I can envision a number of ways to fix this for IP traffic, but I 
> don't know enough about IS-IS to know if any of them are applicable.
>  
> S
>  
> Stephen Sprunk      "Those people who think they know everything
> CCIE #3723         are a great annoyance to those of us who do."
> K5SSS                                             --Isaac Asimov 


ISIS sends hellos at full MTU.  If the other end can't handle them,
then no neighbor adjacency comes up.  There is no L2 DF bit and ICMP
would fragment reply as there is in IP so TCP doesn't handle the MTU
mismatch on the same subnet.  Something like that (an L2 DF and ICMP)
would be needed to handle two devices with an MTU mismatch on the same
subnet or some probe packet of the type ISIS uses.  The diagnostic
tool available to today's operator is "ping".  Use the -s option.

Until something changes there is no automatic means to detect and
correct an MTU mismatch on the same subnet.  If running ISIS there is
the means to detect the error but I don't think there is an automatic
correction (no MTU fallback).  I'd have to check the expired draft.

Curtis