too many routes

Mon Sep 15 02:49:58 UTC 1997

> > > AFAICT there is only one orderable, deployable and tested
> > > IP router which observably terminates multiple 622-Mbit/s bit
> > > pipes, notably that made by cisco.  
> > 
> > 	http://www.ascend.com/505.html
> >   lists their support for such interfaces.

> I hope the comments privately prior to your writing any of
> this that pointed out that nowhere in this URL or in
> Ascend's other literature is the concept of non-ATM 622
> mentioned.  Oh wait, that's a non sequitur, because it's
> the same thing as POS, right, only with extra features.

  I see now where we missed each other -- no, I know of no POSIP
  interface for OC12 with the exception of Cisco's.

  However, as it is not a tool that I can put into my great big bag
  of router tricks (with the exception of peerings or customer
  connections, which I'm pondering) it's not too important (to me)
  (right now).

  We differ in this manner -- you feel the negatives of atm forbid
  its use *period*, while I think its benefits outweight any negatives
  at this time, and couldn't consider growing a large network
  without its flexibility.

> >   On their head?  I can assure you the IGP is still a manageable
> >   problem in larger ISPs with meshed backbones.  In fact, there is
> >   one solution available that is not yet even exercised.
> 
> It's only manageable because 

  But it's manageable.

> because Cisco has no trouble with the idea of adding in
> richer metrics to iIS-IS.  (Well, neither do I, actually :) )

  Funny you and cisco agreeing.  Nonetheless, the metric set is
  its own problem, but moderately orthagonal to any of these
  discussions.  On that tangent, however, flooding is what we're
  mostly concerned about, and it's just not that bad.

> Of course, if you take your approach and DON'T route
> dynamically between routers, but rather reroute VCs around
> link failures, then you might not have these problems
> except when fun things happen like ATM switches reloading
> or router-to-switch failures happen.  At that point you
> have the fun of working out appropriate backup paths for
> the traffic that used to fan out over a large number of
> VCs.  This is non trivial and scales geometrically with
> the size of the mesh.

  The scaling issue is synonymous w/ an entirely L3 network.  L2
  networks just put it off and make it somewhat less likely.

  See, I get the impression that people on this list can be
  categorized as two kinds -- router people and network people.
  That may be too strict a delineation.

> > > multicast and can put up with interesting buffering and
> > > switching effects 
> > 
> >   Okay, I'll bite: Which interesting buffering and switching effects?

  (paragraph about buffer:flow ratios deleted)

  Hmmm.  So how does this change by putting lots of virtual
  interfaces on a router and putting the buffering into L2?

> > > and, as you say, the dynamics of WHY it
> > > works vs. why it doesn't work when things break.
> > 
> >   Yes, indeed this is a tradeoff.

> Obviously you and I have different thoughts about
> Byzantine failures.  I've experienced enough of them
> driven by multilayer operability issues with a small set

  Perhaps it's a difference in the quality or quantity of 
  those managing the network.  ;-)  The interoperability adds a
  variable, but the scalars in the equation minimize probability or
  problems.

> of vendors that widening the vendor base substantially
> (i.e., adding lots of switch vendors and the like, not
> just adding a second router vendor) or increasing the
> number of layers which have to interoperate does not
> appeal much to me.

  That's why you do it your way and.....

> >   But, the more I think about the KISS principle, I become convinced
> >   that only our own limitations, ignorance, and hesitancy prevent us
> >   from adding complexity to achieve increased control.
> 
> Sure.  How much do you want to spend on NOC staff is a
> factor in how much complexity NOC staff can handle, and
> that is a factor in how quickly Byzantine failures can be
> dealt with.

   Yep.

> Personally, Byzantine failures that require waking up
> senior smart people at multiple vendors' companies are
> scary and as Byzantine failures happen sometimes in big
> networks, keeping the number of people potentially needed
> to effect a fix for something really weird strikes me as a
> win.
> 
> In short, defensive engineering.

  At the cost of scalability.  Not a win.  Anytime you limit growth
  to a variable you are doomed  (ahh physical space you evil beast).  
  Instead, you educate and.... this thread goes nowhere.  I see your 
  point, we disagree.

> Sure complexity seems attractive, but only until your
> first major meltdown driven directly by or even only
> exacerbated by that complexity.

  The opportunity to have a complex network is arift with its own
  problems.

  Once your problem set becomes large enough your
  solution set becomes larger.  Increase your richness in variables
  to solve more quickly and exactly.

> >   Why do you always insist on linking one's place of business with
> >   their technological idealogy? 
> 
> Because:
> 
> 	a) it makes people angry, and that's really funny
> 	b) it reminds people whom they are working for and
> 	   what trade-offs they make between what they
>            want and what their employers say they want
> 	c) a + b sometimes causes people to fix their
>            employers into doing things "correctly", or
> 	   leads people into realizing their employers are
>            hopeless and that there are other opportunities
>            elsewhere (which sometimes also fixes the employer)
> 
> the latter part of (c) is particularly edifying if it
> involves physical violence to doors and so forth.
> 	
> So, needle needle, if you are at variance with UUWHO's
> technical policies, why are you still there?

  I don't accept your assertion, but in answer to the latter
  query:  They/We rock.  :-)

> >   Hmm, I tend to be atheistic about technology -- what can it do for
> >   me today, and what will it to do tomorrow with a reasonable chance
> >   of success.
> 
> I think you mean agnostic, not atheistic.  

  No, I mean atheistic. I am without religion with regards to L2
  fabric selection for networking.  You want to believe (smith's
  reference), but you're just not sure.  I don't believe, I 
  rely on facts.  You do too, but you ignore some facts because of
  your religious tendencies.

> I distinctly
> remember you comparing me to Jesus Christ.

  Yes, remember the crucifix phrase?

> > > There may be choice in what you can put at the end of an
> > > OC12 though, but it's either something smart or something
> > > you'd find at Hobson's Tavern.
> > 
> >   How do you define smart?
> 
> When you put your brain into a blender and unpack it into
> individual cells in hopes you can put it all back together
> the way it was without having noticed, that's not very
> smart.

  Hmm, I thought that's what telnet did to keystrokes gifs.  Or what 
  sonet did to PPP or whatever those l2 things are that the cisco OC12 
  interface sends out.  Or what web servers did to IP when they send 
  noodie gifs to pedophiles using PGP.

> 	Sean. (don't send the next cheesecake as
> 		breadcrumbs please :-) )

  You owe me.  I'll take a pound of cheese to go with your next
  mail.  :-)

  -alan

  ps. for those of you at home or work forced to endure this anecdotal
      parenthetical, I used to work at a particular NSP who used 
      Sean's previous employer for internet connectivity.  His 
      always happy and never wavering commitment to customer
      service and reliability soon found us cheerful chums.  In 
      thanks to this level of service, I bestowed a cheesecake to
      him from a customer of ours at the time.  I was not reimbursed
      for this from my company, but I guess it's too late....