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

From: Jeff Learman <[email-masked]>
Date: Wed, 31 May 2000 17:29:42 -0400

Jeff

Good point -- that would solve the problem.  This could be added
to the 3-way handshake RFC.  It might be unnecessary, though, when
operating over links where the MTU is negotiated end-to-end
and IS-IS is using the result of that negotiation.

Unfortunately, it wouldn't guarantee that you can receive big
packets from the other end, which might not implement the new
requirement.  To do that, you'd have to check the size of the
neighbor's IIH and only accept it if it looks like it's padded
to a maximum size, during initialization phase.  (But how would
you do that?  Presence of any padding option over some given
size?)

As you probably know, the check is important to make sure that
any LSP you send over the link will actually make it.  It is not
necessary that the MTU size be equal in both directions, so
it wouldn't necessarily be a good idea to require the received
IIH to match your own MTU size.  While I suppose it's uncommon
to have asymmetrical MTU sizes, it might be useful in certain
situations, like ADSL.  To add such a check would be to add a
new restriction on the use of IS-IS.

Regards,
Jeff

At 05:10 PM 5/31/00 -0400, you wrote:
>> I think the idea was to make sure that whatever your idea of
>> the MTU size is, that you can transmit a packet of that size
>> without worrying about it being dropped by the link layer.
>> If you're transmitting IIHs that are too large to be received
>> at the other end, your data-link connection will go down and
>> the adjacency will never come up.  But this only works if the
>> link is reliable (that is, if the link goes down if it can't
>> deliver a packet).
>> 
>>   Jeff Learman                           Internet:     [email-masked]
>
>You could send padded packets on pt2pt until the adjacency comes up.  
>This makes no assumptions about the reliability of the link layer.  
>
>- jeff parker
>- Lucent Technology

____________________________________________________________________

  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
____________________________________________________________________

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

---

From: Jeff Learman <[email-masked]>
Date: Wed, 31 May 2000 17:54:24 -0400

This is a big, bad, nasty problem.  This case is NOT handled by
the protocol -- you aren't told what to do, and no matter what you
do, it's not good.  It was discussed in detail at the SONET
Interoperability Forum, where we have the unlucky situation that
the SONET management channel (normally unused by you IP folks)
is specified to use an MTU size of 512 bytes, but the rest of
the natural world uses a size of 1500.

Fortunately, there is a solution, which can be found in

  ftp://ftp.atis.org/pub/sif/arch/ar820317.doc

I believe that this was submitted to ISO as a defect report or
technical corrigendum, but I don't know the current status.
Perhaps Les Guinsberg or Tom Rutt could fill us in, if they
are listening.

Regards,
Jeff

At 09:52 PM 5/31/00 +0000, Rick Han wrote:
>Suppose we have following setup:
> router1 (R1) --- router2 (R2)----- router3 (R3)
>
>linkMTU between R1 and R2 is 4k, and linkMTU between R2 and R3 is 2k. If R1
>sends a HELLO padded to 4k and R2 accepts it. What does R2 do to the
>following LSPs from R1, if they are in 4k packets? How does R2 propagate
>them to R3? I guess that's why the adjacency between R1 and R2 is supposed
>to be droped at the first place. But if we accept the neighbor, then what
>if R1 sends two LSPs, one in 1.5k and another in 3k? The smaller LSP can go
>through to R3 but the bigger one get droped at the link. Now we have
>un-synchronized database over the domain. 
>
>Rick
>
>Jeff Learman wrote:
>> 
>> Jeff
>> 
>-- 
>Rick Han
>Iron Bridge Networks, Inc.
>[email-masked]
>(781)372-8180
>
>

---

From: Dave Katz <[email-masked]>
Date: Wed, 31 May 2000 16:21:45 -0700 (PDT)

LSPs have an architecturally-defined maximum size (1492 if memory
serves) because, unlike in OSPF, they are not regenerated hop-by-hop
so they must be small enough so that they are guaranteed to be able to
cross *any* media in the network.  Trying to use variable sizes gets
very interesting.  NLSP was operationally problematic due to this (try
setting the MTU to 1500 and then accidentally using SNAP encapsulation
on some links--whee!)

The "big, bad, nasty problem" is due to the media of choice in the
SONET application having an unfortunately small MTU, and the problem
is confined entirely to such media (I think ARCnet is about the only
other one; see earlier comment about NLSP).  It in particular is *not*
any sort of problem when dealing with links having MTUs *larger* than
1492.

Even if the link MTU were negotiated, it would *not* have any use in
the protocol per se (other than complaining if it were too small).
OSPF has a hook added after the original spec came out which won't
allow neighbors to become adjacent unless their MTUs agree--this is
more important because LSUpdates are built hop-by-hop and so can
become MTU-sized if the implementor so desires, but it also leads to
regular customer service calls asking "why are my neighbors stuck in
EXSTART state."

IIH padding was intended to catch badly misconfigured boxes, and to a
lesser extent size-dependent errors (though the padded ones were only
supposed to be sent on point-to-point links only briefly, and these
are the only links that usually ever show any size dependency).

IIH padding has, in practice, been largely deprecated because it is
essentially useless and creates lots of unnecessary customer service
calls to vendors ("Why is my adjacency stuck in Init state?").
Incoming padding should be ignored, period.

--Dave

   X-Sender: [email-masked]
   X-Mailer: Windows Eudora Pro Version 3.0.1 (32)
   Date: Wed, 31 May 2000 17:54:24 -0400
   From: Jeff Learman <[email-masked]>
   Cc: Jeff Parker <[email-masked]>, [email-masked]
   References: <[email-masked]>
   Mime-Version: 1.0
   Content-Type: text/plain; charset="us-ascii"
   Sender: [email-masked]
   Errors-To: [email-masked]
   X-Mailman-Version: 1.0rc3
   Precedence: bulk
   List-Id: IETF IS-IS working group <isis-wg.external.juniper.net>
   X-BeenThere: [email-masked]

   Regards,
   Jeff