Subject: Re: Clarification in size of Rtr and network LSA

From: Mike Fox <[email-masked]>
Date: Fri, 13 Jun 2003 09:17:08 -0400

Krishna Rao wrote:

Hi,
> Usually we allocate
> (Max MTU size - (OSPF header size  + IP header size +
> MD5 authentication size) --> 1500 - (28 + 20 + 16)= 1436
> and start filling the LSA. For Point to point interface we add two
> links and need 24 bytes for each point to point interface. That results
> in supporting only 59 interfaces in a single area. Is this an acceptable
argument?
> or Should we design such that OSPF sends a LSA more than MTU size and
gets fragmented in IP.
> What is the scalabilty figure for Number of interfaces in a area for
popular routers?

Krishna,

We have been facing this problem for years.  Our platform supports virtual
interfaces (VIPA) and they can run into the hundreds on one host.  We have
found ourselves having to build router LSAs that are much larger than the
largest MTU size.  While you like to avoid IP fragmentation when you can,
in this case you simply can't.  However, as RFC 2328 makes clear in
Appendix A.1, Encapsulation of OSPF Packets, you can build any OSPF packet
including the router LSA up to 65535 bytes (including all headers) in size.
In our experience not all the OSPF implementations support this properly,
but I think the word is getting out and more of them are as time goes by.

Also note that this problem is solved in OSPFv3, where router LSAs are not
required to flow as one packet.

Mike
-----------------------------------------------------------------------
Enterprise Network Solutions
-----------------------------------------------------------------------
Research Triangle Park, NC  USA

---

From: Don Goodspeed <[email-masked]>
Date: Fri, 13 Jun 2003 15:16:17 -0400

Ok, ok.  I admit I was just stirring the pot a little.

I just wanted people to see that, like it or not,
fragmentation is a way of life in OSPF if you have
more than a 100+ links on a router.

Cheers,
Don

Don Goodspeed wrote:
> Hmmm. Would a scheme like ISIS has for extended LSPs
> work for the router LSA? If we could use a range of
> router IDs that are not assigned, then maybe. Or we
> could use a non-backward compatible method using opaque
> LSAs. Any ideas? -don

Don,

Let's not go there ;^). Every implementation should
support IP fragmentation and reassembly up to a certain
limit (if not the full 64K). This should more than exceed
anybody's requirement for the number of interfaces in a
single area. For example, if one supports IP fragmentation
and reassembly up to 16K (not an unreasonable number since
there are some DLCs that support MTUs this big) one can
support around 1350 numbered P2P interfaces or around
2700 numbered or transit interfaces. Does anyone have
a requirement to support more interfaces
in a single area?

Thanks,
Acee

>
> ================================
> Krishna,
>
> I myself don't like fragmentation, if just due to the fact
> that any fragment gets dropped, then the whole packet/frame
> needs to be rexmit'ed.
>
> Additionally, I would expect at least consistency counts for
> each LSA type. This count should be retrieveable before
> you start filling the LSA. With this count you can allocate
> the proper memory size.
>
> Mitchell Erblich
> Sr Software Engineer
> -------------
>
> Krishna Rao wrote:
>
>>Hi,
>>This is w.r.to the size of the Router LSA to be generated. We can not predict the size of the router LSA initially in the process of forming the Router LSA. Usually we allocate (Max MTU size - (OSPF header size + IP header size + MD5 authentication size) --> 1500 - (28 + 20 + 16)= 1436) and start filling the LSA. For Point to point interface we add two links and need 24 bytes for each point to point interface. That results in supporting only 59 interfaces in a single area. Is this an acceptable argument? or Should we design such that OSPF sends a LSA more than MTU size and gets fragmented in IP.
>>What is the scalabilty figure for Number of interfaces in a area for popular routers?
>>
>>Thanks in advance,
>>Regards,
>>Krishna
>
>
> _______________________________________________
> Join Excite! - http://www.excite.com
> The most personalized portal on the Web!
>

--
Acee

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!