[c-nsp] IS-IS Multiarea on 12.2 SR

[Mark Tinka]

On Wednesday 11 November 2009 05:13:40 am Richard A 
Steenbergen wrote:

> <arguing with the teacher hat>

:-).

> I have nothing against advocating that you design your
> network to scale from the very beginning, and (without
> trying to channel Vijay Gill here) IMHO if oyu don't
> design your netwrok to scale then in all likelihood it
> WON'T scale.

Agree.

> But there is also a point where you start
> making more trouble for yourself than you save, and may
> actually inhibit your growth by adding unnecessary
> additional complexity.

Also agree, e.g., it is possible to build too much 
redundancy that just ends up being complex, it is possible 
to have too many upstream service providers that your eBGP 
routing policy becomes too complicated and fails to work as 
expected, e.t.c.

We say, "Scale, but KISS".

> Smart network engineering is about
> knowing the network you are trying to build, and figuring
> out where that magic line is so you don't cross it.

Also agree.

Again, we don't say "Scale for scaling's sake", on the 
assumption that it is possible for those learning to 
misunderstand the message and think scaling = complexity, 
and that complexity may be justified by the need to scale.

Unfortunately, without getting into the full details about 
the workshops we give, I can understand why you may think we 
may be advocating for "blind scaling", for lack of a better 
term. But on the contrary, our messages are very specific to 
areas where scaling is important, without adding undue 
complexity, and keeping things as simple as they should be.

So yes, in principle, agree here also.

> I think your argument applies perfectly to situations
> like "but I only have a few hundred /30s between my 10
> 3560s, why can't I just redistribute connected/static
> into my IGP and call it a day".

:-), not at all, actually.

We NEVER advocate for any customer prefixes (including /30 
point-to-points) to be anywhere near the IGP.

We also NEVER advocate for any kind of redistribution 
(although we realize a lot of folks tend to trade-off when 
it comes to this, mostly due to mind-set, laziness, e.t.c.).

I once gave a workshop where the entire class agreed that 
redistribution isn't necessarily a good thing when done 
blindly and with laziness as an unconscious motive. We all 
agreed that if it was possible, avoid it, unless you really 
know what you're doing, e.g., l3vpn's for PE-CE routing, 
redistribution controlled with route-maps, e.t.c. Then what 
happens, one of the attendees goes back and actually 
continues to redistribute all Connected and Static entries 
without prejudice because when he joined the trade, it was 
engrained in him either by books, mentors, vendor marketing, 
e.t.c. - as instructors, we can also only go so far :-\.

> Yes you COULD, but if you
> grow your network by even a very small amount you'll
> start to bump the CAM limits on your stackable switches,
> and thus you should probably engineer your network to
> scale past that limit from the very beginning.

Agree - of course, there are dynamics that cannot be 
captured during workshops, e.g., will you use regular 
routers at the edge or TCAM-limited so-called Layer 3 
switches instead; to run with your example, Richard.

Like you say, there is no magic solution. Our message, while 
specific, is also generalized in many areas; scale as long 
as you keep simplicity in mind, but adapt to your individual 
environments and make your own decisions because no two 
networks have the same "pocket-depth", nor do they have the 
same topology.

So yes, in principle, agree here also.

> Taking the
> time to design a system with only loopbacks into IGP +
> iBGP loopback peering and redistribution of other routes
> into BGP may be more time consuming than just slapping a
> redist into your IGP, but it will save you more time in
> the end.

But this is exactly what our workshops advocate. Nowhere do 
we say you should do anything else :-). IGP only for 
infrastructure + Loopbacks. iBGP for all customer prefixes. 
Is our message. 

But you do get some folk who've heard this for the first 
time at the workshop and fail to comprehend why an IGP is 
not used for "all internal" routing entries. So they'll 
gladly do the workshop with you, as well as the labs, but go 
back home and continue to bloat their IGP. Again, as 
instructors, we can only go so far.

So yes, agree here also (is it getting old, hehe?).

> On the other hand, what level of scale do you need before
> IGP areas actually start to pay off, and make it worth
> the added complexity and other issues you will impose
> (inter-area TE problems, etc)? You'd need to take your 10
> routers to what? 100? 1000? 10000? At what point does
> your newly expanded network look absolutely nothing like
> your original network, to the point that nothing you
> decided about your 10 router network has any bearing on
> your new network? If you're really designing some massive
> dial network with the potential for 10000 pops, or the
> next IBM Global Services network, you may have a
> legitimate reason for needing the IGP areas. But if
> you're building a more concentrated network there just
> may never be a situation where there is any benefit no
> matter how big you grow (i.e. I don't think Level 3 has
> any need for them :P).

Again, I agree - that's why I mentioned, in my previous post 
to you, that our message on "Scale as early as possible (in 
correspondence with your individual environment and with 
simplicity at heart)", transcends just IGP routing; there's 
a lot more to it that will influence the choices the 
operators that attend our workshops will make. We look at 
the issues holistically, not individually, and hope that the 
attendees make the most reasonable design decision based on 
the "most neutral" information provided, e.g.:

	- Solve the iBGP mesh problem with route reflectors or
 	  confederations. Route reflectors are simpler than
	  confederations, but there have been corner cases where
	  confederations have been desirable. Because those corner
	  cases are few and far between, and we think simplicity in
	  this case is trumps "corner case", we recommend the use
	  route reflectors.

	- We get attendees asking what model of XR 12000 series or
	  CRS-1 is better for their core just because the Cisco 
	  product positioning says so, or which model in the
	  T-series range is better just because Juniper product
	  positioning says so. Our advice is neutral, "Don't drink
	  the marketing cool aid. Many networks have 7200-VXR's or
	  M7i's as core, because that's all they've ever needed in
	  their plans - and they work". 

	- Static routing in a 5-router network will work well, but
	  just because it is small, doesn't mean you should wait
	  until you explode to 100 routers before you consider
	  moving to dynamic routing, especially if router and
	  network resources are not an issue. Here, we're
	  recommending to scale early because we assume the network
	  might either grow, or become too complex to manage as the
	  number of routing entries increases, or both.

	- RFD (Route Flap Dampening) has a specific solution to
	  solve. But given that router control planes are getting
	  faster, global connectivity is getting more stable with
	  more sub-sea and terrestrial connectivity coming online,
	  e.t.c., many networks realize that the troubles RFD
	  causes may not be worth the perceived benefits. So, if
	  you have to deploy it, think about what it means to your
	  business/network - if it were I (the instructor), I	
   	  wouldn't for A, B, C, D reasons.

Our goal is not to simply say, "Take our word for it, it's 
the rule". Our goal is to foster open and unrestricted 
thinking, with some basic guidelines, of course.

So yes, in principle, agree here also.

> There is no right answer for
> everyone, your network may look very different from mine,
> etc.

Agree, based on my arguments above. We try to provide 
fundamental principles with basic guidelines, not rules.

The idea is knowledge transfer, not technology transfer.

To analogize, "It is wrong to kill someone, but just because 
we haven't explicitly mentioned that stabbing them without 
causing them death is equally as wrong, doesn't mean we're 
sanctioning it - learn to think beyond the marketing/snazzy 
slides/RFC's/vendor-centric fora/news media/standards bodies 
meetings, e.t.c.".

> We can both make arguments for simplistic theories
> like "you should always design to scale" vs "keep it
> simple stupid"...

I know this is just an example you're giving, but to nit-
pick, there's no reason why you can't scale and maintain 
simplicity at the same time - and I'm sure you agree also 
that you can scale while maintaining simplicity, depending 
on the situation at hand. But my actual comment on this one 
is, some ideologies compliment each other, they are not 
always necessarily presented (to be considered) in contrast.

But in general, ...

> until we're blue in the face, but at the
> end of the day this is an engineering question to which
> there is no one correct answer.

... I take your point, and I agree, again, per my arguments 
above.

> </arguing with the teacher hat>

I guess the issue here was that you may not be familiar with 
the kinds of workshops we run, so it may not be unreasonable 
to assume we're teaching "scalability" for its own "sake".

In fact, to illustrate the kind of confusion we put our 
attendees through, on the one hand, we say, "Aggregate your 
eBGP announcements as much as possible, and where you can, 
aggregate your iBGP announcements just as much". On the 
other, we say, "Route summarization in a link state IGP 
helps scale the network, but it may break optimal routing, 
so in this case, we trade-off scalability for optimality". 
Attendees get very confused about why we "selectively" 
scale, and the devil is in the details, as I'm sure you can 
appreciate. However, those that manage to understand the 
tactics we use to open up their minds, then ask, "But 
doesn't the use of Route Leaking in IS-IS moot the need for 
multiple levels on the basis of building a multi-level IS-IS 
network just for scaling? So then what is the point of 
having multiple levels in IS-IS in the first place?" When we 
hear questions like these, we know we have reached success 
:-).

There's tons of other cases, but this is the general idea. 
We encourage workshops given by other operators, because 
there's nothing like it when compared to reading vendor 
certification material, reading RFC spec's, reading vendor 
product marketing data sheets, or attending classes given by 
individuals that have learned how IP networks work, but have 
never run a network.

> Did I mention I got a lot of D's in class from arguing
> with the teacher?

+1 :-).

Cheers,

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20091111/62ddec26/attachment.bin>