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

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

> 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

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

---

From: Jeff Parker <[email-masked]>
Date: Wed, 31 May 2000 18:01:39 -0400

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:
> ____________________________________________________________________
> >> 
> >>   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
> >> 
> ____________________________________________________________________
> >> 
> >-- 
> >Rick Han
> >Iron Bridge Networks, Inc.
> >[email-masked]
> >(781)372-8180
> >
> >
> ____________________________________________________________________
> 
>   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
> ____________________________________________________________________
>

---

From: Les Ginsberg <[email-masked]>
Date: Wed, 31 May 2000 16:04:23 -0700

The problem that Rick refers to is not quite as bad as his example suggests.
"originatingLxBufferSize" is limited to values between 512-1492. So long as
the MTU of any link over which IS-IS operates is >= 1492 there should never
be a problem propagating LSPs due to PDU size issues. This issue, as Jeff
remembers all too well, actually occurs only when some of the links used for
IS-IS have an MTU smaller than 1492 - as is the case with SONET DCC.

The solution referred to below does not eliminate the problem, but it
provides the protocol with the tools to detect and report the problem,
hopefully before it ever occurs.

The proposal is part of the revised agenda the US has submitted to ISO for
producing a new draft revision of ISO 10589:1992. Inclusion of this proposal
is of course subject to review by the international community - as of this
date the revised draft is not yet available and the international review
process has not yet begun.

   Les

> -----Original Message-----
> From: Jeff Learman [mailto:[email-masked]]
> Sent: Wednesday, May 31, 2000 2:54 PM
> To: [email-masked]
> Cc: Jeff Parker; [email-masked]
> Subject: Re: [Isis-wg] question on MTU
> 
> 
>

---

From: Les Ginsberg <[email-masked]>
Date: Wed, 31 May 2000 17:14:14 -0700

(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. I believe the original
text in ISO 10589 8.2.3c is better, even if it rarely comes into play.

Of course, given the global significance of originatingLxLSPBufferSize, this
still does not guarantee consistency throughout the area/domain - hence the
problem that occurs in SONET environments.

   Les

> From: Rajesh Saluja [mailto:[email-masked]]
> Sent: Wednesday, May 31, 2000 3:58 PM
> To: Micah Bartell
> Cc: Jeff Parker; Jeff Learman; [email-masked];
> [email-masked]
> 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
> 
> Micah Bartell wrote:
> > 
> > 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:
> > 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
> >

---

From: Les Ginsberg <[email-masked]>
Date: Wed, 31 May 2000 20:39:27 -0700

I agree - I think it would be a useful addition to the three way handshake
RFC -
send padded IIHs until the adjacency is in the UP state. 

I also agree that the receiving side should not check the size of the
received IIH.

In addition to solving the issue in cases where the "first" IIH was lost, it
would eliminate wording in 10589 that has always been a bit confusing. The
use
of the term "first" IIH PDU was never unambiguous. It really meant the IIH
sent
as a result of receiving an ISH PDU and if for some strange reason multiple
ISH
PDUs were received then one was left to wonder how to resolve the
designation of
an IIH sent in response to receipt of an ISH which was not the "first".

Much less ambiguous to say "an IIH should be padded if the adjacency is not
in the
UP state".

  Les

> Sent: Wednesday, May 31, 2000 2:30 PM
> To: Jeff Parker
> Cc: [email-masked]
> Subject: RE: [Isis-wg] question on MTU
> 
> 
> 
> Jeff
>