Subject: Re: MPLS and IS-IS

From: "J. Noel Chiappa" <[email-masked]>
Date: Wed, 17 May 2000 15:26:28 -0400

> From: Danny McPherson <[email-masked]>

    > Note also that besides what Curtis/Dave mentioned wrt the state of a
    > particular vendors implementation having an impact on which IGP legacy
    > providers deployed ... seemingly more stable IS-IS suuport

My dim recollection is that for a variety of reasons, the major vendor had a
better IS-IS implementation, and that led to a lot of people starting off
with IS-IS, and of course once something's deployed, people tend to stick
with it. 

Irrespective of who's running what, I'd be interested in hearing someone
compare the technical aspects of the *protocols* (although of course the
quality of the available implementation is a factor in any operational
choice) - I used to be able to do this, but it's been years since I looked at
the two of them in detail.

	Noel

---

From: Andrew Partan <[email-masked]>
Date: Wed, 17 May 2000 16:09:40 -0400 (EDT)

> better IS-IS implementation,

That plus a desire to route both IP and CLNS.

> compare the technical aspects of the *protocols*

One main difference is security - its difficult to send a forged
ISIS packet across the Internet to attack someone.  ISIS does not
run on top of IP (unless you use that non-default encapsulation);
thus it only exists on a link between routers.

	[email-masked] (Andrew Partan)

---

From: Quaizar Vohra <[email-masked]>
Date: Wed, 17 May 2000 13:26:48 -0700 (PDT)

Here are a few differences :

1) In OSPF, an ABR can be connected to more than 2 areas which brings
in a whole lot of complexity during post SPF route calculation when
a route is accesible from more than 1 area. While in ISIS, a router
can be connected to atmost 2 areas, i.e. L1 and L2 and you strictly
prefer routes from L1 over L2. Offcourse the route selection becomes
more complex when ISIS allows leaking L2 into L1 (new ISIS draft) but
is still simpler than supporting multiple areas on an ABR which have
same level of priority.

2) DR election in OSPF is much more complex because a DR has to 
play a more complex role in OSPF than ISIS because of a more complex
flood/ack mechanism of OSPF.

3) ISIS allows breaking of a large LSP into MTU sized chunks,
while OSPF depends on IP fragmentation. If one fragment is lost
you end up transmitting only that fragment in ISIS. In OSPF you end
up trasnsmitting an entire LSA.

4) 35 K in OSPF lines of code vs 15 K lines of ISIS code.

5) ISIS lacks virtual link and NSSA like optimizations.

OSPF seems more complex to implement but the complexity could
be gotten rid off if you choose note to implement the not so
heavily used features as in 5). 

Quaizar

---

From: Dorian Kim <[email-masked]>
Date: Wed, 17 May 2000 16:31:39 -0400

> That plus a desire to route both IP and CLNS.

Yup, back then, many networks ran CLNP native, and had requirements to 
support both IP and CLNS, many with eye on moving to reduce "legacy" IP
support.
 
-dorian

---

From: Alex Zinin <[email-masked]>
Date: Thu, 18 May 2000 00:00:56 -0700

Some notes:

> flood/ack mechanism of OSPF.

I wouldn't say DR election is really much more complex.
Yes we elect BDR as well, yes we optimize flooding through
broadcast links, but I doubt it adds much of the complexity.

> up trasnsmitting an entire LSA.

1. OSPF RFC *discourages* origination of big LSAs. They can be used,
   but if the implementation is clueful enough, it is not necessary
   [unless you have a really large number of neighbors or stub hosts,
   but even then you can do some tricks]
   
2. I'd say "an entire LSA" is going to be much smaller than an LSP
   fragment. This is because in ISIS we put TLVs to different
   fragments of the LSP and the number of fragments is limited, while
   in OSPF we originate different LSAs for different purposes and
   the number of originated LSAs is not limited [e.g. you originate
   a separate LSA for every inter-area or external route].

3. We do not retransmit LSAs in OSPF, we send LS Update packets that
   contain them.

> heavily used features as in 5). 

You wouldn't be compliant to the RFC without the VLs :))

Alex.

---

From: Quaizar Vohra <[email-masked]>
Date: Thu, 18 May 2000 02:12:08 -0700 (PDT)

>    but even then you can do some tricks]

OSPF does certainly mention breaking OSPF packet types likely to be
large into several seperate protocol packets. But I certainly dont
know of a way of breaking an LSA itself. Specially if router LSAs are
large. If you are refering to A.1 in rfc 2328 then this is what I 
interpret.

I should have added that 3) is true only in the router LSA context.
An OSPF router LSA can be larger than the link MTU and hence would
fit one single LS update paclet and would need IP fragmentation.

Yes I agree that an ISIS LSP can be much larger as it contains all
the other TLVs, just not the IS Reachability TLV. But loosing
an LSP fragment is not worse than loosing an OSPF LS update
packet with all its different LSAs, as you would end up loosing
all the LSAs in the packet.

But the issue I was raising was that if a router LSA is larger than
the link mtu, it will fit a single update packet which will be IP
fragmented. If one IP frag is lost, you end up retrasmitting the
entire LSA.  While in case of ISIS the corresponding IS Reachability
TLVs will span several LSP fragments. If one is lost, you just need
to retranmit that single LSP fragment.

Afterall this might not be so important if your topology doesnot
have a large degree of connectivity, e.g. in an ATM overlay model.

 >    a separate LSA for every inter-area or external route].

Agreed, but this is another difference. A pro for the OSPF.

 > 3. We do not retransmit LSAs in OSPF, we send LS Update packets
that
 
The unit of retransmission is an LSA not an LS update packet. Yes
if an LS update packet is lost, all its constituent LSAs will need
retrasmitting. So is the case of LSP fragment.

---

From: Alex Zinin <[email-masked]>
Date: Thu, 18 May 2000 12:45:48 -0700

> large.

Nothing that the standard would speak about, but if you ever need to
announce a large number of adjacencies, there are some methods
[just off-topic a bit].

> If you are refering to A.1 in rfc 2328 then this is what I 
> interpret.

> I should have added that 3) is true only in the router LSA context.

correct

> fit one single LS update paclet and would need IP fragmentation.

The question is when would it be so large.
Is it a good network design when a router has over 100 neighbors
in the same area [note that we're not talking about LANs]?

> all the LSAs in the packet.

The standard does not specify how many LSAs you should put
into a single LSU. It's up to the implementers to choose
between OSPF packet header overhead and possible retransmission
overhead.

> to retranmit that single LSP fragment.

This is correct, but again---when would you have a big router-LSA?

> have a large degree of connectivity, e.g. in an ATM overlay model.

Exactly for OSPF :) For ISIS you still have that limited number
of LSP frags possibly leading to bigger size of each fragment :)

> retrasmitting. So is the case of LSP fragment. 

Yeah, I should've said we drop LS Update packet and retransmit
several [1 or more] LSAs in another LSU packet.

Alex.