Subject: Re: MPLS and IS-IS

From: Danny McPherson <[email-masked]>
Date: Wed, 17 May 2000 10:28:34 -0600

> I find that companies building products that support both protocols have to
> spend more time on bringing OSPF up to RFC compliancy (eg adding yet another
> LSA type), because it's so well defined and attempts to solve so many
> problems, rather than focusing on code and protocol optimizations that can
> solve more pressing customer problems.

I find that initially these companies first implement and stabilize 
the feature sets they're customers are asking for and *deploying*, then 
worry about the 'kitchen sink'.  

> I do believe the "perception" goes a little bit beyond implementation only
> issues.

I don't completely follow you here.  Are you suggesting that implementation
difficulty alone makes the OSPF routing protocol itself less scalable?  While
they're indeed related, they're still very separate things.

-danny

---

From: Ben Black <[email-masked]>
Date: Wed, 17 May 2000 10:30:19 -0700

> they're indeed related, they're still very separate things.

An overly complex design will almost certainly result in more difficult
implementation.  More difficult implementations generally give rise to
more bugs.  I believe there is a strong correlation between protocol
design quality and implementation quality and simply dismissing that
relationship seems rather ivory towerish.

Ben

---

From: Dave Katz <[email-masked]>
Date: Wed, 17 May 2000 11:55:03 -0700 (PDT)

It is certainly true that a more complex design leads to more complex
code, which in turn leads to more bugs, particularly early in the life
cycle of the implementation.

However, keep in mind that both of these protocols have been around for
over ten years now.  Cisco's OSPF implementation is nearly ten years old,
their IS-IS implementation was rewritten about six years ago.  Juniper's
implementations are both about three years old.  All have seen enough
service to shake out most of the bugs, effectively negating the impact
of complexity on bug counts.

While complexity impacts implementation quality, the biggest factors
are a combination of the skill of implementor and the amount of
real-world use that the code gets.  I've seen astonishingly awful
implementations of simple things, as well as very nice implementations
of complex things.  I've also seen very nice implementations with
head-slapping day-one bugs that don't turn up for months because of
a lag in deployment.

At the end of the day, while OSPF is more complex than IS-IS, it is not
*that* much more complex.  The stuff that is hard to do well is, for
the most part, common to the two protocols.  Each has its peculiar
challenges.

--Dave

---

From: John Day <[email-masked]>
Date: Wed, 17 May 2000 16:00:21 -0400

>the most part, common to the two protocols.  Each has its peculiar
It is not just shaking out the implementation that reduces the stability,
but the number of "knobs" you have for tuning it.  OSPF has many more
"knobs" than ISIS.  This makes it "more flexible", but it also makes
getting a stable configuration more difficult.  The analogy I have always
used that it was a bit like trying to tune an old TV tube.  There are only
3 knobs but any adjustment of one affects the others.  The problem with
OSPF is that there are many more than 3 knobs and none are orthogonal to
any of the others.  This makes finding a stable configuration very
difficult and the bigger the network the more difficult it will be and
hence the belief that it doesn't scale well.

---

From: "Chris Whyte" <[email-masked]>
Date: Wed, 17 May 2000 14:12:32 -0700

> worry about the 'kitchen sink'.

But once you introduce the 'kitchen sink' you have to revisit the stability
issue (again). I have yet to experience a company who seems to do both at
the same time. That is, you ramp up on features until stability becomes a
problem, then you address the stability issue. Chicken and the egg thing...

Sure, maybe the startups don't have to deal with this cycle (to the same
degree) quite yet. But I believe it's somewhat inevitable for them too.

> they're indeed related, they're still very separate things.

That's not really what I was suggesting.

So yes, 5-6 years ago people might have chosen IS-IS over OSPF because of
cisco's implementation issues but even today we see many more SPs around the
world embracing IS-IS. And since customers drive much of the feature
development, MPLS/TE using IS-IS.

Why? Well, possibly lots of reasons of which more are probably intangible
than tangible. But having myself spent time building and/or supporting both,
and seeing others building and supporting both, I've clearly come to the
conclusion that it's a bit beyond any one implementation.

Possibly 244 pages of a spec (OSPF) has something to do with it...

Thanks,

Chris

---

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

> Possibly 244 pages of a spec (OSPF) has something to do with it...

Don't underestimate the people factor. People got used to/trained with
ISIS at most large ISPs. With the ever rotating musical chairs game of 
people that seems to be going at the ISPs engineering departments, this 
means that people bring what they got used to with them, hence
contributing greatly to spread of ISIS.

-dorian

---

From: "Chris Whyte" <[email-masked]>
Date: Wed, 17 May 2000 15:10:02 -0700

> contributing greatly to spread of ISIS.

I completely agree. But I also see nothing wrong with making decisions based
on what's been widely implemented in some of the largest, most complex
networks, in the world. In my mind, "smart" networking has mostly been about
choosing the road *more* travelled, as opposed to making general decisions
in life.

Like I said above, many of the reasons are likely more intangible than
tangible. It always seems like we're looking for tangible reasons in order
to understand why, and where, we are today.

People appear to feel very comfortable with building large networks with
IS-IS over OSPF. I believe you can get into this analysis paralysis phase of
trying to understand why, or you can just accept it for what's it worth and
continue to ride the wave. Personally, I prefer to take the simple route and
ride the wave.

Unfortunately, many of us as engineers have a tendency to analyze things to
death at times and I wonder what we really accomplish in the process.

And mind you, this is coming from someone who was a complete believer that
OSPF was the only way to build a network 3 years ago. Of course, I didn't
know jack about IS-IS back then either. :-)

Thanks,

Chris

---

From: Alex Zinin <[email-masked]>
Date: Wed, 17 May 2000 17:43:34 -0700

> contributing greatly to spread of ISIS.

Unfortunately this is true.

It's becoming ok for some reason to change the IGP when a new "smart"
guy comes in just because this guy feels comfortable with the other
proto, instead of having this guy study the one already used.
And we're talking about *operational* networks, not just labs.

Alex.

---

From: Dave Katz <[email-masked]>
Date: Wed, 17 May 2000 17:54:45 -0700 (PDT)

Frankly, this is the ISP's call, not the vendors'.  It guarantees
continued employment for the vendors' customer support departments,
and is self-limiting on the ISP's side if it turns out to be a bad
call...

---

From: Dorian Kim <[email-masked]>
Date: Wed, 17 May 2000 20:59:10 -0400

> And we're talking about *operational* networks, not just labs.

This is not necessarily a bad thing in and of itself if done with due 
consideration.

After all, it's an operational network, meaning that there are people
operating it, and one arrives at the best technology to use via 
looking at the network itself and the people running as well.

-dorian

---

From: Alex Zinin <[email-masked]>
Date: Wed, 17 May 2000 23:06:01 -0700

> and is self-limiting on the ISP's side if it turns out to be a bad

This may be true...

However, this also is a matter of stability of ISPs' networks [read
stability of the Internet] and of things like the number of night
pages from your customer...

And one more point---if you really care about your customer, do
you want them to change their IGP just because some ppl [that usually
come and go] feel better about the other proto?

Alex.

---

From: Alex Zinin <[email-masked]>
Date: Wed, 17 May 2000 23:13:42 -0700

> This is not necessarily a bad thing in and of itself if done with due 

Well, sure it's not, provided [as you say] it's really and really
justified.

Can you imagine a new PC support guy coming in and changing all
OS'es from Win9X to OS/2 just because he thinks it's cool and Win9X
makes him seek? ;) See what I'm getting on? If personal preferences
are the only *real* driving factor and it's affecting one's
engineering, troubleshooting and NOC services [just because ppl
already know the proto they've been working with for considerable time]
it seems to be that the change [which is not bad per se, of course]
may probably lead to bad things :)

> operating it,

I'd say "operational" == "the one that actually operates" :)

Alex.

>  and one arrives at the best technology to use via

---

From: Dave Katz <[email-masked]>
Date: Wed, 17 May 2000 23:26:28 -0700 (PDT)

What I want them to do is not at issue.  I would advise a customer
against making such changes willy-nilly, but I don't think there are
very many that would make such a change lightly.  I'll settle for
getting enough notice so that we can help with the transition (as
opposed to "guess what, we're switching IGPs this weekend!")

ISPs that are flippant about such issues don't stay in business too
long (or at least the engineers making such decisions don't stay
employed too long).  Self-correcting.

---

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

> hence the belief that it doesn't scale well.

But another question is---what are the knobs and what are just usual
configuration commands, and how many knobs do you really *have* to touch?
I mean in order to get OSPF up and running all you need is just start
the process and assign interfaces to areas. You want ABR to summarize
the routes---you need one more command to tell him how you want to be
done [I can't imagine any proto doing this automagically other than
the way RIPv1 and IGRP did this in classful networks]. You need the
area to be stub---just mark it as stub. You want no inter-area route
to go into it---just tell the ABR about it.

I mean, most of the commands [that actually correspond to protocol-
specific settings] *are* orthogonal.

Alex.

---

From: Randy Bush <[email-masked]>
Date: Thu, 18 May 2000 08:31:56 +0200

> pages from your customer...

so, should we expect an internet-draft from you outlawing smart people doing
smart things to their own networks?

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 18 May 2000 08:36:50 +0200

> opposed to "guess what, we're switching IGPs this weekend!")

uh, dave.  other than network stability etc, a customer should neither know
nor care what igp an isp runs.  no notice to customers should be relevant.

until mpls/igp/te, one's igp was a trivial part of one's configuration,
merely a way to help the bgp-enabled interfaces find eachother and to do
some very primitive te.

randy

---

From: Dave Katz <[email-masked]>
Date: Thu, 18 May 2000 08:55:22 -0700 (PDT)

Note that, to me, "customer" == "ISP".

   MIME-Version: 1.0
   Content-Type: text/plain; charset=us-ascii
   Content-Transfer-Encoding: 7bit
   From: Randy Bush <[email-masked]>
   Cc: [email-masked]
   References: <[email-masked]>
	   <[email-masked]>
   Sender: Randy Bush <[email-masked]>
   Date: Thu, 18 May 2000 08:36:50 +0200

   randy