Subject: Re: [Isis-wg] Derek's proposal for MTU discovery in IS-IS

From: Derek Yeung <[email-masked]>
Date: Sun, 01 Jul 2001 17:44:32 -0700

Sorry for the late reply.

	Given enough interest, I can send out a draft in a week or so for the MTU TLV 
for IIH.

	Going through the thread, it appear to me the problem this new TLV does not 
solve is the FDDI-Ethernet type bridged network Radia mentioned. IMHO, this network model 
is broken in nature and hopefully it is not wide-spread enough to render the suggestion useless.

	For Henk's comment -

>  In theory there are two more problems that can be detected early
> when the IIH is really padded to mtu-size.
> 1) bit errors or packet corruption that has a higher probability to
>    occur with larger packets. Supposedly this is something from the
>    past when transmissions were over copper, not fibre.

	I suppose it can be better detected/solved by checksum/authentication.

> 2) bugs. interfaces that have their MTU off by 1 (or 4. (I have seen
>    these bugs in cisco)). 

	If the MTU is off such that both side does not match, it would be fine
as adjacency is not found and this problem should be caught in early developement.	

> or routers running out of huge buffers.
>    stuff like that.

	Given that only the first IIH is padded, it is not helpful to detect
temporary outage of huge buffer. If the outage is permanent, the system should 
probably detect it and take some action.

	I agree with Henk that these two issues is not big deal though.

Cheers,
- Derek

Ran Atkinson wrote:
> 
>         Henk's historical analysis is extremely helpful.
> I hope we are all now focused on the problem at hand.
> Thanks much for the detailed analysis and history.
> 
> At 19:27 26/06/01, Derek Yeung wrote:
> >        OSPF have the same problem. OSPF solves the problem by putting the
> >MTU in the DDB packet (A.3.3. in RFC 2328). Would it be reasonable
> >to put a TLV in IIH to carry the MTU instead of padding IIH to full
> >MTU size ?
> 
>         This seems like a simpler approach.  The concept is known to
> work (thanks to OSPF).  Why don't we just try this to solve the
> immediate IS-IS issue that Henk outlined ?  Oh, and if we do this,
> it might not hurt to add a MIB object or two to make MTU mismatches
> discovered by IS-IS easy for operators to grab via SNMP.
> 
>         Quite separately, I'll probably draft up an "IP over
> Jumbogram Ethernet-II Framing" spec that just documents the
> as deployed IP/Ethernet practice, as an Informational RFC.  I don't
> see that as an IS-IS WG work item, in no small part because IS-IS
> does not use Ethernet-II Framing.
> 
> Cheers,
> 
> Ran
> [email-masked]
> 
> _______________________________________________
> Isis-wg mailing list  -  [email-masked]
> http://external.juniper.net/mailman/listinfo/isis-wg
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Naiming Shen <[email-masked]>
Date: Sun, 01 Jul 2001 22:57:10 -0700

I once helped a big ISP troubleshooting a network problem, the isis
adjacency wouldn't come up. The link was an ATM interface, the ip level
seemed fine. Then it was found if the IIH was never padded, the adjacency
came up. It turned out to be the ATM link provider had some rate-limiting
mechanim inside the ATM network, the 4470 bytes of padded IIH on this
port just happen to exceed their limit, so some of the ATM cells got
dropped with large packet size. I forget in this case if it was a
misconfiguration by the ATM network provider or the ISP did agree to
buy the link with this limitation, the point here is, without the isis
padding(the first IIH), that ISP might never notice this problem, then
some of their BGP packets could be dropped also over that link.

Yes, isis have cuased lots of "troubles" for vendors and ISPs due to
this padding issue. in most of the cases, IMHO, isis is only the messenger.
if it is shot, unfortunately, there will be no other messengers around
who can detect such a problem in earlier stage.

With all this said, I do sympathize with the isis developers, they have to
prove their innocence every time a bug is filed, because the bugs usually
have the title of "Urgent: IS-IS does not work over .....";-)

thanks.
- Naiming

---

From: mike shand <[email-masked]>
Date: Mon, 02 Jul 2001 12:14:31 +0100

>         Given enough interest, I can send out a draft in a week or so for 

How does this compare with the proposal which was originated in the Sonet 
Interoperability Forum and is being incorporated in ISO/IEC 10589 second 
edition?

>         I suppose it can be better detected/solved by 

Well, no it can't, because it only happens when you have big packets. 
(Naiming gives an example in his reply).

>probably detect it and take some action.

Well its only pt-pt links that only have the first IIH padded, and even 
that is an anachronism, since it was designed for connection oriented data 
links (such as HDLC I-frame service). Running over PPP (using HDLC 
UI-frames) doesn't have the right properties, so it should probably be 
always padded (or not at all if that what you want).

>         I agree with Henk that these two issues is not big deal though.

Yes, I agree its not a big deal.