Subject: Re: [Isis-wg] question on MTU

From: "Rajesh Saluja" <[email-masked]>
Date: Wed, 31 May 2000 23:49:38 -0400

Les Ginsberg wrote:
> 
> (At the risk of belaboring a point...)
> 
> dataLinkBlockSize SHOULD always be >= originatingLxBufferSize. The point of
> sending a padded IIH which is the maximum of the bunch is precisely to
> detect those misconfigurations where this is not the case. So if
> dataLinkBlockSize is NOT large enough, the adjacency presumably will never
> come up. Therefore stating that
> 
>     "So IMHO IIH size is nothing but dataLinkBlocksize - 1."
> 
> is denying the possibility of a misconfiguration. 

Yes, I should say that if you impose the requirement ( dataLinkBlocksize
>= Buffersize ), then IIH size = dataLinkBlocksize - 1.
The reason why it is not possible to enforce this requirement in
explained in ISO 10589 section 8.2.3c.

But I was wondering if this mechanism on P2P link could result in one
way adjacency if you do not implement three way handshake mechanism.

Consider IS A and IS B connected by P2P link.
Suppose P2P link MTU size = X
A - Buffersize = Y
B - Buffersize = Z ( misconfiguration )
where Y < X < Z

A will send padded Hello with size max(X,Y) i.e. X - 1.
When B receives, it is going to accept this packet. Right? ( I do not
see any check on the padded hello size at the receive end ).
So B will make adjacency A UP ( if you do not implement three way
handshake )

B will send padded Hello with size max(X,Z) i.e. Z-1 but it can not be
delivered becuase DataLinkBlockSize is less. A will never receive Hello
packet from B.
So you end up with one-way adjacency. ( an example of link failing in
one direction ? ) 

Please correct me if I am missing anything.

Thanks,
Rajesh

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Jeff Learman <[email-masked]>
Date: Thu, 01 Jun 2000 10:10:05 -0400

Rajesh,

You are correct -- you can get a persistent one-way adjacency.
At the risk of sounding like a broken record, let me note that
this wouldn't happen when operating IS-IS as it was designed
to operate, over reliable p2p links.

Fortunately, thanks to the "robustness check" for two-way
connectivity, this isn't a problem unless there are
multiple links between systems.  In this case, if you
were so unlucky as to have the same problem in different
directions on two links, you would have a black hole.
Of course, the 3-way handshake solves the problem.

Thanks to Les, Jeff, and Dave for detecting my mistake about a
4K link not causing the "inconsistent LSP buffer size" problem.

I also agree with Micah Bartell -- the IIH should be
AT LEAST maxsize - 1.  It's better to make it maxsize
unless you simply can't because of the size of your IIH
ending at maxsize - 1.  (That's assuming you think the check
is worthwhile at all.)

Concerning what Dave Katz says about the unfortunate choice
of SONET using a 512-byte MTU size, I completely agree that
this was a particularly bad choice by Bellcore.  Actually,
this is not a media limitation, simply a poor choice of the
default for a LAPD parameter.  However, the IS-IS spec does
not prohibit the use of smaller MTU sizes; it is certainly
possible to use a consistently small LSP buffer size in a
subdomain.  IS-IS is flawed in that it does not properly
address what should be done when the LSP buffer size is
inconsistent.  The good news is that, as Dave and Les point
out, it isn't a problem unless you use an MTU size smaller
than 1492.

And Rajesh is correct that a link-by-link check is not sufficient
to guarantee the end-to-end requirement for passing LSPs.
The fact that maxsize is limited by LSP buffer size indicates
that it's a check for passing LSPs and not a true MTU size check
(which is better to do using LCP's MRU configuration option,
and has nothing to do with routes anyway).  This means that the
IIH padding doesn't really serve any purpose, as Dave points out.

I still agree with Les and Jeff that, if you're going to send
padded IIHs, it's best to continue doing it until the adjacency
goes into the UP state.  But sending padded IIHs could be made
optional if the MTU size is negotiated.  And I take back my
suggestion about checking the size on received IIHs!  Bad idea!

Regards,
Jeff

>Please correct me if I am missing anything.
____________________________________________________________________

  Jeff Learman                           Internet:     [email-masked]
  Engineering Manager                    Voice:     (734)-975-7323
  ONE (Open Networks Engineering, Inc)   Fax:       (734)-975-6940
  2725 South Industrial Pkwy, Suite 100
  Ann Arbor, MI  48104  USA
____________________________________________________________________