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

From: Micah Bartell <[email-masked]>
Date: Wed, 31 May 2000 17:25:35 -0500

Actually the IIH should be at least maxsize-1 octets.  maxsize is the maximum of the three following values:

1. dataLinkBlocksize
2. originatingL1LSPBufferSize
3. originatingL2LSPBufferSize

The reason for using maxsize-1 is any padding added needs to be at least 2 octets.  So if the PDU length is maxsize-1 you can't add 2 octets, requiring that to be a valid size also.

/mpb

At 06:01 PM 5/31/2000 -0400, Jeff Parker wrote:
>I think section 8.2.3 of ISO 10589 specifies that you use the appropriate
>L1 or L2 BufferSize, rather than the interface MTU.   
>
>- jeff parker
>- Lucent Technology
> > 
> > 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
> > >> 
> > >> 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
> > >
> > >-- 
> > >Rick Han
> > >Iron Bridge Networks, Inc.
> > >[email-masked]
> > >(781)372-8180
> > >
> > >
> > ____________________________________________________________________
> > 
> >   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
> > 
>
>_______________________________________________
>Isis-wg mailing list  -  [email-masked]
>http://external.juniper.net/mailman/listinfo/isis-wg 

--
Micah Bartell, CCIE #5069			[email-masked]
Network Consulting Engineer, NSA		Phone: 972.364.8829
Cisco Systems, Inc				Fax: 972.364.8829
--
The Network Works, No Excuses

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

---

From: "Rajesh Saluja" <[email-masked]>
Date: Wed, 31 May 2000 18:58:16 -0400

IIH maximum size and LSP maximum size are two different things. IIH size
should be at least equal to the maximum(dataLinkBlocksize
(MTU),LSPBuffersize) -1 according to the spec.
The LSP packet maximum size has really a global significance in an ISIS
area and it should be set consistently by system management. LSP packets
have to travel throughout the area.

Also note that dataLinkBlocksize should always be greater than or equal
to the maximum of the LSPBufferSize. So IMHO IIH size is nothing but
dataLinkBlocksize - 1.

Regards,
Rajesh