Subject: (no subject)

From: "Sachidananda K" <[email-masked]>
Date: Mon, 06 May 2002 13:53:43 +0000

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

---

From: "Naidu, Venkata" <[email-masked]>
Date: Mon, 6 May 2002 16:29:41 -0400

Sachin:

-> 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.

  OSPF specification just *recommends* to avoid fragmentation.
  IP fragmentation has some performance & prone to communication
  failures. Look at...

http://www.ecse.rpi.edu/Homepages/shivkuma/teaching/sp2001/readings/ccr-9501
-mogulf1.pdf

  Don't get confused with the exchange of MTU negotiation 
  procedure in OSPF. That is nothing to do with whether
  router is fragmentation capable or not. Please look at
  OSPF mailing list discussion...

http://discuss.microsoft.com/SCRIPTS/WA-MSD.EXE?A2=ind0008&L=OSPF&D=0&P=5310

-> 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.

  Why only ASBR? You can create any LS Update packet 
  lager that (path/link) MTU.

  ISIS runs directly on Layer 2 so there is no IP fragmentation 
  issues. But it has its own drawbacks...

--
Venkata Naidu

---

From: Jung Cyndi-ACJ099 <[email-masked]>
Date: Tue, 7 May 2002 17:46:38 -0500

IS-IS does have a requirement that all routers on a given subnet
agree on the MTU for that subnet.  The base standard implicitly enforces
this by requiring that the HELLO packets be padded to that MTU, such
that a router with a smaller MTU will not receive the HELLO from the
router with the larger MTU, preventing any adjacency to be formed.  This
of course has the very annoying consequence that HELLO packets on a
medium with a large MTU are very large (FDDI, for example), in order
to avoid adjacencies between routers where subsequent data forwarding
would fail - FDDI<->ethernet bridges that were so popular a decade ago
were the stimulus for this.  Later, when IS-IS was adopted for the NLSP
protocol of the Netware suite this behavior was replaced with a field in
the HELLO packet.  Some IS-IS implementations have made the padding
optional.

As for across the domain, the min(MaxMTU) placed an upper bound on the size
of a single LSP segment.  This is also the case in NLSP and in Integrated
IS-IS.
The LSP segments as originated are never modified, repacketized, fragmented,
as they are flooded throughout the area or L2 subdomain.  This is not just
because they are transmitted on the datalink layer, but it has to do with
the
method of identifying an LSP in the reliable flooding mechanism.  But the
MTU is not required to be the same throughout the domain - just the
LSPBufferSize.
The IS-IS base standard gives this a value of 1492 - it would be painful to
modify it across all the routers in a domain, so you can safely assume that
IS-IS
has a minimum MTU equal to the max MTU of the Ethernet, but larger MTUs are
certainly allowed within a single domain.

Cyndi

-----Original Message-----
From: Nast, Douglas P [mailto:[email-masked]]
Sent: Monday, May 06, 2002 2:16 PM
To: 'Sachidananda K'; [email-masked]
Subject: RE: (no subject)

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,

this to me.

Sachi.

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