Subject: RE: (no subject)

From: "Nast, Douglas P" <[email-masked]>
Date: Mon, 6 May 2002 14:15:49 -0700

SK,

I am not aware that OSPF has such a restriction regarding MTUs. That is,
this is not a part of the criteria in deciding whether to form an adjacency
or not, as far as I know.  

While OSPF packets can be 64k bytes in theory, OSPF in practice uses
semantic fragmentation to avoid IP fragmentation (which is considered
inefficient and problematic):  Individual LSAs are seldom more than a few
hundred bytes, and a big update can be split into many smaller ones each no
bigger than one LSA.  In some cases fragmentation cannot be avoided (a
single Link State Advertisement that exceeds say 1500 bytes), and I believe
in such cases OSPF bites the bullet and uses IP fragmentation.  

If the restriction of uniform MTU throughout the AS or area exists for
common IGPs I would be very interested to learn more about it. I have
configured RIP, EIGRP, OSPF, and BGP on many routers and never had to
concern myself with MTUs, but maybe I've just been lucky and oblivious. 

D. Nast, Boeing

-----Original Message-----
From: Sachidananda K [mailto:[email-masked]]
Sent: Monday, May 06, 2002 6:54 AM
To: [email-masked]
Subject: (no subject)

Hi All,

I was not very sure about the question whether it was appropriate to place 
it here. However, since the question has to do with most of the routing 
protocols (unicast in particular), I thought there could be some response 
from the group.
My question is as follows:

IP supports the fragmentation and re-assembly concept. That is to aid the 
support for topologies with the media having different MTUs. However, to my 
knowledge, the IGPs (IS-IS as well as OSPF) creates the topology information

only if the MTUs through out the domain is same all over. I'm not very sure 
about RIP. Under such a senario, within a domain there would not be any 
requirement for fragmentation and re-assembly. I'm not quite sure as to why 
the IGPs have such an architectural restriction even though the IP can still

operate over the topology with different MTUs. Could any body please clarify

this to me.
Secondly, if at all the above is well said and implemented, then would it be

wise to implement the fragmentation/re-assembly only at the ASBRs.

Thanking in advance for all the responses.

Sachi.

_________________________________________________________________
Join the world's largest e-mail service with MSN Hotmail. 
http://www.hotmail.com

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Jeff Parker & Nancy Belkov <[email-masked]>
Date: Mon, 6 May 2002 20:43:32 -0400

>concern myself with MTUs, but maybe I've just been lucky and oblivious.

Doug -
	As was hinted by Venkata, IS-IS assumes a common MTU.
This is from some text the IS-IS WG is putting together.  The references
are to ISO 10589 and RFC 1195.

- jeff parker

9.0 ReceiveLSPBufferSize

    Since IS-IS does not allow segmentation of protocol PDUs, Link State
    PDUs (LSPs) must be propagated without modification on all IS-IS
    enabled links throughout the area/domain. Thus it is essential to
    configure a maximum size that all routers can forward, receive, and
    store.

    This affects three aspects, which we discuss in turn:

      (1)  The largest LSP we can receive (ReceiveLSPBufferSize)

      (2)  The size of the largest LSP we can generate
           (originatingL1LSPBufferSize and originatingL2LSPBufferSize)

      (3)  Available Link MTU for supported Circuits (MTU).  Note this
           may differ from the MTU available to IP clients.

    The protocol provides the architectural constant ReceiveLSPBufferSize
    with value 1492 bytes, and two private management parameters,
    originatingL1LSPBufferSize for level 1 PDUs and
    originatingL2LSPBufferSize for level 2 PDUs. The originating Buffer
    Size parameters define the maximum size of an LSP that a router can
    generate.  The protocol directs the implementor to treat a PDU larger
    than ReceiveLSPBufferSize as an error.

    It is crucial that
           originatingL1LSPBufferSize <= ReceiveLSPBufferSize
           originatingL2LSPBufferSize <= ReceiveLSPBufferSize
    and that for all L1 links in the area
           originatingL1LSPBufferSize <= MTU
    and for all L2 links in the domain
           originatingL2LSPBufferSize <= MTU

    The original thought was that operators could decrease the originat-
    ing Buffer size when dealing with smaller MTUs, but would not need to
    increase ReceiveLSPBufferSize beyond 1492.

    With the definition of new information to be advertised in LSPs, such
    as the Traffic Engineering TLVs, the limited space of the LSP data-
    base which may be generated by each router (256 * 1492 bytes at each
    level) has become an issue. Given that modern networks with MTUs
    larger than 1492 on all links are not uncommon, one method which can
    be used to expand the LSP database size is to allow values of
    ReceiveLSPBufferSize greater than 1492.

    Allowing ReceiveLSPBUfferSize to become a configurable parameter
    rather than an architectural constant must be done with care: if any
    system in the network does not support values larger than 1492 or one
    or more link MTUs used by IS-IS anywhere in the area/domain is
    smaller than the largest LSP which may be generated by any router,
    then full propagation of all LSPs may not be possible.

    The steps below are recommended when changing ReceiveLSPBufferSize.

      (1)  Set the ReceiveLSPBufferSize to a consistent value throughout
           the network.

      (2)  The implementation SHOULD not enable IS-IS on circuits which
           do not support an MTU at least as large as the originating
           BufferSize at the appropriate level.

      (3)  Include a originatingLSPBufferSize TLV when generating LSPs,
           as described in section 9.8 of [3].

      (4)  When receiving LSPs, check for an originatingLSPBufferSize
           TLV, and report the receipt of values larger than the local
           value of ReceiveLSPBufferSize through the defined Notifica-
           tions and Alarms.

      (5)  Report the receipt of a PDU larger than the local ReceiveL-
           SPBufferSize through the defined Notifications and Alarms.

      (6)  Do not discard large PDUs by default.  Storing and processing
           them as normal PDUs may help maintain coherence in a miscon-
           figured network.

    Steps 1 and 2 are enough by themselves, but the consequences of
    mismatch are serious enough and difficult enough to detect, that
    steps 3-6 are recommended to help track down and correct problems.