Subject: Paper comparing OSPF and ISIS

From: Manav Bhatia <[email-masked]>
Date: Wed, 4 Sep 2002 15:42:37 +0530

Hi,
The question of OSPF vis-a-vis IS-IS has been raised more than once in the
mailing lists (both OSPF and ISIS) and elsewhere and there seems to be no
apparent paper which clearly differentiates between the two. I started with
IS-IS and moved to OSPF some time back, and in my quest stumbled upon Dave
Katz presentation on the same. In my course of transitioning to OSPF I had
written a lot of notes and ideas (borrowed from Dave presentation and some
helpful cues which i took from Radia Perlman's "Interconnections") on the
key differences between these 2 link state routing protocols.

I have assimilated all of those in this document which i am hereby
attaching with this mail of mine. I would like to hear from other people
their views/thoughts/experiences with these protocols and i intended to
capture all that in the updated document which can then be used as a
reference in understanding as to how/what/where the two link state routing
protocols differ.

Manav

----
"When you are courting a nice girl an hour seems like a second. When you
sit on a red-hot cinder a second seems like an hour. That's relativity."

-Albert Einstein, on relativity

---

From: Rohit Gupta <[email-masked]>
Date: Wed, 4 Sep 2002 06:41:44 -0700

Hi,
I just went thru your paper on comparing ISIS and OSPF
and i could not understand how TCP ACK came into
picture when comparing two link state routing
protocols?

In Section where you describe the encapsulation you
mention that there is some problem in IS-IS and you
waste additional bandwith?

Please Help ..

-- Rohit

>      Manav Bhatia
>
>      Samsung Electronics
>
>      September 2002
>
>               A Comparative Study of OSPF and IS-IS
>
>   There are two link state routing protocols
> available. One is the
>   IS-IS developed by ISO exclusively for the ISO
> networks and the other
>   is OSPF developed by the IETF because the former
> did not, originally run
>   on TCP/IP networks. Since then many changes have
> come in both the
>   routing protocols. IETF has come out with the
> Integrated IS-IS which runs
>   IS-IS for TCP/IP networks.
>
>   This document compares the two link state routing
> protocols in each
>   area of the specification and also compares the
> two link state
>   routing protocols in terms of the scalability
> issues.
>
>   This document compares the two routing protocols
> in terms of
>
>   1. Encapsulation
>   2. Network Types Supported
>   3. Partition Repair
>   4. Packet Encoding
>   5. Data base granularity
>   6. Neighbour Establishment
>
>   7. Designated Router Concept
>   8. LAN Flooding
>   9. Scalability Issues
>   10. Metrics Used
>   11. Authentication and Security
>   12. MPLS/GMPLS and Traffic Engineering Extensions
>   13. Support for Ipv6
>
>   There is a list of abbreviations used at the end
> of this document
>
>   1. Introduction
>
>   In essence each router distributes its view of the
> local neighbourhood
>   and floods it within the area within the network
> and every other
>   router ends up with a map of the topology (the
> information in the LSPs
>   yields complete knowledge of the graph) and then
> routes are computed
>   based on the map each has by running the
> Dijkstra's algorithm on the
>   LSD. Both the link state routing protocols have a
> 2 level hierarchy.
>   In OSPF there is this concept of a backbone area
> and a non zero area.
>   In IS-IS, there are level 1 and level 2 areas.
> Both of the routing
>   protocols are widely deployed in the field.
>
>   We could have actually gone ahead with one
> protocol (IS-IS) wherein
>   extending and adapting IS-IS for IP was possible
> by merely adding IP
>   reachability information along with the existing
> model. Incidentally
>   this is what Integrated IS-IS does (RFC 1195) but
> nobody thought of it
>   before and in the mean time work on OSPF had
> already gained momentum.
>   Moreover people wanted an "IPv4" only protocol
> which was very much
>   optimised and directed towards IPv4 and one which
> would have all
>   mechanisms to make the adjacencies come up faster
> on the IP networks.
>   OSPF was thus designed specifically for IP (rather
> IPv4!) and is
>   loosely based on IS-IS.
>
>
>
>
>              [Page 1]
>
>   The repercussions of having an "IPv4" only
> protocol become clear in the
>   following sections for it obviously introduces
> some amount of complexity in
>   the protocol. IS-IS is a lot simpler but then it
> was never designed for IP
>   so we have some strange things like assigning OSI
> addresses to our IP only
>   router. This often confuses people and everyone
> ends up making calls to the
>   customer support centre.
>
>   2. Encapsulation
>
>   OSPF runs over IP and as a result of which we can
> have virtual links.
>   This implies that we can send an OSPF packet from
> one part of the planet
>   to the other. The downside of this is that it
> makes OSPF vulnerable to the
>   classic DoS (discussed at length in later
> sections) attacks and all such
>   related attacks.
>
>   If LSAs get really big then we can have IP
> fragmentation to make them fit.
>   One of the advantages of using IP encapsulation is
> that we can use VCmux
>   encaps on ATM. This is basically no encapsulation
> and everything on the
>   VC has to be necessarily IP. So if you're running
> OSPF on ATM then you
>   can turn off all encapsulations and save on the
> bandwidth in the ATM
>   network.
>
>   IS-IS on the other hand runs directly over layer 2
> i.e. next to IP, which
>   means that we cant have virtual links unless we
> have some sort of
>   explicit tunnelling. Since it does not run on IP
> these packets cannot be
>   routed beyond the immediate next hop and can never
> be sourced by non-border
>   routers. This makes ISIS difficult to spoof
> because there's now no way
>   to get an IS-IS packet into the inside of your
> network from outside
>   (because its not an IP packet) unless you
> accidentally let a GRE tunnel
>   remain open or something.
>
>   IS-IS requires ATM SNAP encapsulation because its
> not an IP packet thereby
>   loosing on the bandwidth efficiency we have with
> OSPF. This adds enough
>   bytes so a TCP ACK won't fit into one ATM cell (it
> does in OSPF). We thus
>   waste some extra bandwidth.
>
>   Suggestions to run OSPF directly over data link
> layer has the inherent
>   problem where we need to provide code points of
> access in OSPF for each
>   of the data link protocol types. For e.g.
> (Frame-relay, Ethernet, ATM,
>   PPP etc).
>
>   Moreover, most of the link layers don't provide
> fragmentation and
>   reassembly services. IP (not as a protocol but as
> a technology) supports
>   virtually all Layer 2 (except X.25). So the
> protocols running over IP need
>   not worry about services offered by IP. There are
> definite (dis)advantages
>   if we run OSPF directly over L2 but advantages
> overweigh. Once again ,
>   virtual links (widely used) are not possible if we
> run OSPF over Layer 2.
>   For these reasons it is better to run OSPF over
> IP.
>
>   Refer to John Moy's book section 3.2 Design
> Decisions for more details.
>
>   The other obvious advantage of running over IP is
> the ability to use IP
>   multicast when running over broadcast networks.
>
>   Also, one nice feature about IP encapsulation of
> OSPF packets is that it
>   tests processing of IP packets on the interfaces.
> I've seen routers not
>   being able to process IP packets on interfaces,
> but still maintaining ISIS
>
>
>
>              [Page 2]
>
>   adjacencies, so the rest of the network still used
> the link. This is not
>   possible in OSPF where the HELLO protocol ensures
> that communication
>   between the neighbours is bidirectional.
>
>
=== message truncated ===

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

---

From: Manav Bhatia <[email-masked]>
Date: Wed, 4 Sep 2002 19:37:05 +0530

Rohit,
In ATM VC multiplexing (null encapsulation) there is no SNAP header and
hence no additional overhead in the cell.  As the name suggests, in
LLC/SNAP encaps we store LLC-SNAP information in the cell resulting in a
packet size > 40 bytes. Now, a simple TCP ACK message is of 40 bytes.
LLC/SNAP header adds 3 more bytes. AAL5 adds an additional 8 bytes in
either case. ATM LLC/SNAP encapsulation thus adds enough bytes so that a
TCP ACK wont fit into one ATM cell!

Thus if we know that we are using only IP then it is better to go in for VC
mux encaps because we save a lot of bandwidth.

IS-IS requires ATM LLC/SNAP encapsulation because its not an IP packet
thereby loosing on the bandwidth efficiency we have with OSPF.

I hope it makes it clear.

Regards,
Manav

----- Original Message -----
From: "Rohit Gupta" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 04, 2002 7:11 PM
Subject: Re: Paper comparing OSPF and ISIS

| Hi,
| I just went thru your paper on comparing ISIS and OSPF
| and i could not understand how TCP ACK came into
| picture when comparing two link state routing
| protocols?
|
| In Section where you describe the encapsulation you
| mention that there is some problem in IS-IS and you
| waste additional bandwith?
|
| Please Help ..
|
| -- Rohit
|
| --- Manav Bhatia <[email-masked]> wrote:
| > Hi,
| > The question of OSPF vis-a-vis IS-IS has been raised
| > more than once in the
| > mailing lists (both OSPF and ISIS) and elsewhere and
| > there seems to be no
| > apparent paper which clearly differentiates between
| > the two. I started with
| > IS-IS and moved to OSPF some time back, and in my
| > quest stumbled upon Dave
| > Katz presentation on the same. In my course of
| > transitioning to OSPF I had
| > written a lot of notes and ideas (borrowed from Dave
| > presentation and some
| > helpful cues which i took from Radia Perlman's
| > "Interconnections") on the
| > key differences between these 2 link state routing
| > protocols.
| >
| > I have assimilated all of those in this document
| > which i am hereby
| > attaching with this mail of mine. I would like to
| > hear from other people
| > their views/thoughts/experiences with these
| > protocols and i intended to
| > capture all that in the updated document which can
| > then be used as a
| > reference in understanding as to how/what/where the
| > two link state routing
| > protocols differ.
| >
| > Manav
| >
| > ----
| > "When you are courting a nice girl an hour seems
| > like a second. When you
| > sit on a red-hot cinder a second seems like an hour.
| > That's relativity."
| >
| > -Albert Einstein, on relativity
| >
| > >
|
| >      Manav Bhatia
| >
| >      Samsung Electronics
| >
| >      September 2002
| >
| >               A Comparative Study of OSPF and IS-IS
| >
| >   There are two link state routing protocols
| > available. One is the
| >   IS-IS developed by ISO exclusively for the ISO
| > networks and the other
| >   is OSPF developed by the IETF because the former
| > did not, originally run
| >   on TCP/IP networks. Since then many changes have
| > come in both the
| >   routing protocols. IETF has come out with the
| > Integrated IS-IS which runs
| >   IS-IS for TCP/IP networks.
| >
| >   This document compares the two link state routing
| > protocols in each
| >   area of the specification and also compares the
| > two link state
| >   routing protocols in terms of the scalability
| > issues.
| >
| >   This document compares the two routing protocols
| > in terms of
| >
| >   1. Encapsulation
| >   2. Network Types Supported
| >   3. Partition Repair
| >   4. Packet Encoding
| >   5. Data base granularity
| >   6. Neighbour Establishment
| >
| >   7. Designated Router Concept
| >   8. LAN Flooding
| >   9. Scalability Issues
| >   10. Metrics Used
| >   11. Authentication and Security
| >   12. MPLS/GMPLS and Traffic Engineering Extensions
| >   13. Support for Ipv6
| >
| >   There is a list of abbreviations used at the end
| > of this document
| >
| >   1. Introduction
| >
| >   In essence each router distributes its view of the
| > local neighbourhood
| >   and floods it within the area within the network
| > and every other
| >   router ends up with a map of the topology (the
| > information in the LSPs
| >   yields complete knowledge of the graph) and then
| > routes are computed
| >   based on the map each has by running the
| > Dijkstra's algorithm on the
| >   LSD. Both the link state routing protocols have a
| > 2 level hierarchy.
| >   In OSPF there is this concept of a backbone area
| > and a non zero area.
| >   In IS-IS, there are level 1 and level 2 areas.
| > Both of the routing
| >   protocols are widely deployed in the field.
| >
| >   We could have actually gone ahead with one
| > protocol (IS-IS) wherein
| >   extending and adapting IS-IS for IP was possible
| > by merely adding IP
| >   reachability information along with the existing
| > model. Incidentally
| >   this is what Integrated IS-IS does (RFC 1195) but
| > nobody thought of it
| >   before and in the mean time work on OSPF had
| > already gained momentum.
| >   Moreover people wanted an "IPv4" only protocol
| > which was very much
| >   optimised and directed towards IPv4 and one which
| > would have all
| >   mechanisms to make the adjacencies come up faster
| > on the IP networks.
| >   OSPF was thus designed specifically for IP (rather
| > IPv4!) and is
| >   loosely based on IS-IS.
| >
| >
| >
| >
| >              [Page 1]
| >
| >   The repercussions of having an "IPv4" only
| > protocol become clear in the
| >   following sections for it obviously introduces
| > some amount of complexity in
| >   the protocol. IS-IS is a lot simpler but then it
| > was never designed for IP
| >   so we have some strange things like assigning OSI
| > addresses to our IP only
| >   router. This often confuses people and everyone
| > ends up making calls to the
| >   customer support centre.
| >
| >   2. Encapsulation
| >
| >   OSPF runs over IP and as a result of which we can
| > have virtual links.
| >   This implies that we can send an OSPF packet from
| > one part of the planet
| >   to the other. The downside of this is that it
| > makes OSPF vulnerable to the
| >   classic DoS (discussed at length in later
| > sections) attacks and all such
| >   related attacks.
| >
| >   If LSAs get really big then we can have IP
| > fragmentation to make them fit.
| >   One of the advantages of using IP encapsulation is
| > that we can use VCmux
| >   encaps on ATM. This is basically no encapsulation
| > and everything on the
| >   VC has to be necessarily IP. So if you're running
| > OSPF on ATM then you
| >   can turn off all encapsulations and save on the
| > bandwidth in the ATM
| >   network.
| >
| >   IS-IS on the other hand runs directly over layer 2
| > i.e. next to IP, which
| >   means that we cant have virtual links unless we
| > have some sort of
| >   explicit tunnelling. Since it does not run on IP
| > these packets cannot be
| >   routed beyond the immediate next hop and can never
| > be sourced by non-border
| >   routers. This makes ISIS difficult to spoof
| > because there's now no way
| >   to get an IS-IS packet into the inside of your
| > network from outside
| >   (because its not an IP packet) unless you
| > accidentally let a GRE tunnel
| >   remain open or something.
| >
| >   IS-IS requires ATM SNAP encapsulation because its
| > not an IP packet thereby
| >   loosing on the bandwidth efficiency we have with
| > OSPF. This adds enough
| >   bytes so a TCP ACK won't fit into one ATM cell (it
| > does in OSPF). We thus
| >   waste some extra bandwidth.
| >
| >   Suggestions to run OSPF directly over data link
| > layer has the inherent
| >   problem where we need to provide code points of
| > access in OSPF for each
| >   of the data link protocol types. For e.g.
| > (Frame-relay, Ethernet, ATM,
| >   PPP etc).
| >
| >   Moreover, most of the link layers don't provide
| > fragmentation and
| >   reassembly services. IP (not as a protocol but as
| > a technology) supports
| >   virtually all Layer 2 (except X.25). So the
| > protocols running over IP need
| >   not worry about services offered by IP. There are
| > definite (dis)advantages
| >   if we run OSPF directly over L2 but advantages
| > overweigh. Once again ,
| >   virtual links (widely used) are not possible if we
| > run OSPF over Layer 2.
| >   For these reasons it is better to run OSPF over
| > IP.
| >
| >   Refer to John Moy's book section 3.2 Design
| > Decisions for more details.
| >
| >   The other obvious advantage of running over IP is
| > the ability to use IP
| >   multicast when running over broadcast networks.
| >
| >   Also, one nice feature about IP encapsulation of
| > OSPF packets is that it
| >   tests processing of IP packets on the interfaces.
| > I've seen routers not
| >   being able to process IP packets on interfaces,
| > but still maintaining ISIS
| >
| >
| >
| >              [Page 2]
| >
| >   adjacencies, so the rest of the network still used
| > the link. This is not
| >   possible in OSPF where the HELLO protocol ensures
| > that communication
| >   between the neighbours is bidirectional.
| >
| >
| === message truncated ===
|
|
| __________________________________________________
| Do You Yahoo!?
| Yahoo! Finance - Get real-time stock quotes
| http://finance.yahoo.com

---

From: Rohit Gupta <[email-masked]>
Date: Wed, 4 Sep 2002 07:14:59 -0700

Hi Manav,
Thanks for the prompt reply !!
I was just getting confused with how TCP came in
between ISIS and OSPF!

Can we make this paper some sort of informational
draft/working group paper after everyone has given his
inputs so that everybody has access to it and it keeps
getting updated because such papers are very useful
and very difficult to find! :-)

just my two cents :-)

-- Rohit

---

From: Dave Katz <[email-masked]>
Date: Wed, 4 Sep 2002 09:18:15 -0700

Actually this is not true;  there is the infamous "Henk Hack" whereby
you can run ISIS over a VCMUX PVC:  you do protocol identification based
on the first byte of the packet.  0x83 (IIRC) is IS-IS, 0x4x is IP.  It's
a NLPID stood on its head.

I don't know that anybody has implemented this, though we've considered it;
mostly it took the wind out of the sails of ISIS-over-IP.

---

From: Manav Bhatia <[email-masked]>
Date: Thu, 5 Sep 2002 16:11:01 +0530

Expounding on what Dave just said.

The first two fields in the IP header are the 4-bit version number and the
4-bit header length. The value of the first byte is normally 0x45. If there
are IP header options attached to the IP header, the first byte can be
between 0x46 and 0x4F. The first byte in an IS-IS packet is always 0x83.
Thus by looking at the first byte of an incoming packet, the receiver can
separate IP and IS-IS packets. Because of this feature we do not to depend
on the ATM layer anymore to help us with the demultiplexing. Routers can
now send and receive both IS-IS and IP packets using vc mux encaps which is
what we wanted to do to avoid the atm cell tax.

But is anybody aware of why there aren't any implementations out there for
this or why this wasn't accepted?

----- Original Message -----
From: "Dave Katz" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 04, 2002 9:48 PM
Subject: Re: Paper comparing OSPF and ISIS

| Actually this is not true;  there is the infamous "Henk Hack" whereby
| you can run ISIS over a VCMUX PVC:  you do protocol identification based
| on the first byte of the packet.  0x83 (IIRC) is IS-IS, 0x4x is IP.  It's
| a NLPID stood on its head.
|
| I don't know that anybody has implemented this, though we've considered
it;
| mostly it took the wind out of the sails of ISIS-over-IP.
|
|    IS-IS requires ATM LLC/SNAP encapsulation because its not an IP packet
|    thereby loosing on the bandwidth efficiency we have with OSPF.

---

From: Dave Katz <[email-masked]>
Date: Thu, 5 Sep 2002 08:07:05 -0700

The demise of ATM cores in the largest ISPs (which are also among the few
running ISIS) made this pretty moot.

---

From: Erblichs <[email-masked]>
Date: Mon, 23 Sep 2002 17:10:44 -0700

Manov and Group,

        I wanted to wait to see what comments I saw and then try to give
        a limited response. I realize that you like most of us are not
        technical writers, but hopefully good engineers. So, I am going
        to skip on any verbage except that your first sentance in section
        "1" is the longest I have ever seen at 62 words.. Wow..

        Section 6. Database Granularity
        "key design difference" ...

           If I said that, "OSPF uses a distance vector algorithm for
inter-area
           routes and a link-state protocol for intra-area routes vs IS-IS
using
           link-state protocols for both",  wouldn't this be the key / most
important
           design difference?

        There are a number of more items that I question in this document, but
the
        reader should question them for himself or herself..

        Enough said....

        Mitchell Erblich
        ===================

---

From: Dave Katz <[email-masked]>
Date: Mon, 23 Sep 2002 17:14:48 -0700

This sentence is also fundamentally incorrect.

---

From: Misha Dovek <[email-masked]>
Date: Tue, 24 Sep 2002 09:28:04 +0530

OSPF has distance vector in backbone because all the information required by
the routers inside an area to compute best paths to other areas is "leaked"
to them via summary LSAs. This was not done in the original ISIS spec and
the L1 (internal) routers had just one default exit out of  the L1 area.
This forced ISIS to have strict hierarchical routing in L2 subdomain too.

is my understanding correct?

Misha

---

From: Dave Katz <[email-masked]>
Date: Mon, 23 Sep 2002 22:57:07 -0700

No.

So long as the L2/Backbone sees some kind of summarization of the contents
of the area (as opposed to the details of the area) then it is inherently
DV.  As the whole point of having areas is to hide the details and summarize,
there's no true LS routing interarea.  The optimality or lack of it is
orthogonal to whether the routing is DV or not.  Even if no summarization
is configured in OSPF, the Summary LSAs that represent each area are
nothing but a distance and a next hop.

---

From: Dave Katz <[email-masked]>
Date: Mon, 23 Sep 2002 22:58:12 -0700

Er, that is, "each route."

---

From: Erblichs <[email-masked]>
Date: Tue, 24 Sep 2002 10:25:01 -0700

Dave,

        1) In my opinion, this is the most major difference between
           OSPF and IS-IS.

        2) Reference : Cisco's Routing TCP/IP : p. 475
           "So, while OSPF is a link state protocol within an area, it uses
            a distance vector algorithm to find inter-area routes".

        So my statement:

                If I said that, "OSPF uses a distance vector algorithm for
   inter-area
              routes and a link-state protocol for intra-area routes vs
IS-IS
   using
              link-state protocols for both",  wouldn't this be the key
/ most
   important
              design difference?

        So, Dave you disagree with #1, or #2, or both?
        If you disagree with #2 are you disagreeing with "uses a distance
vector
        algorithm"?

        Mitchell Erblich
------------------------------------

---

From: Dave Katz <[email-masked]>
Date: Tue, 24 Sep 2002 10:20:02 -0700

Unfortunately it is fundamentally untrue.

           So my statement:

All of the above.  Both protocols effectively use a DV algorithm for
interarea routes, as both protocols advertise only destination/distance
information across area boundaries, and purposely hide topology information.
The differences between them are only of degree (and even the degree has
been made negligible by the route leaking mods to ISIS.)

Bottom line is that there is no *fundamental* difference between ISIS
and OSPF; it's all in details and style.