Re: [Isis-wg] draft-amante-isis-reverse-metric-01

["Les Ginsberg (ginsberg)" <[e-mail]>]

Shane -

> -----Original Message-----
> From: Shane Amante [mailto:[e-mail]]
> Sent: Monday, December 06, 2010 12:22 PM
> To: Les Ginsberg (ginsberg)
> Cc: isis mailing list
> Subject: Re: [Isis-wg] draft-amante-isis-reverse-metric-01
> 
> Les,
> 
> On Dec 6, 2010, at 09:51 MST, Les Ginsberg (ginsberg) wrote:
> > What we agree on is the need for a new tool (advertise non-zero cost
> in
> > pseudo-node LSPs) to assist in making LAN maintenance easier (albeit
> > this has some risks as you have highlighted in your survey).
> 
> OK.
> 
> 
> > What we don't agree on is that the convenience of being able to go
to
> > Node A and issue command(s) which make the necessary temporary
config
> > changes (as opposed to going to Node A and B) justifies the
> introduction
> > of the Reverse Metric TLV and its associated complexities.
> 
> With all due respect, it sounds like you may not appreciate the
> size/class of networks we run today.  :-)
> 
> Over the last several years, we (and other SP's) have been deploying
> multi-Terabit class routers, (i.e.: no "marketing math" <ahem>).  Each
> of these have onboard several hundred high-speed interfaces _each_.
> You're asserting that it's easier, on a _daily_ basis, for me and
other
> SP's to:
> a)  accurately identify the same [point-to-point] interface on two,
> separate routers (again, w/ hundreds of interfaces apiece) at 3AM in
> the morning;
> b)  remember/write-down the existing IS-IS metric that was configured
> *before* I begin the maintenance;
> c)  change the metric (on both sides) to isolate the link/LAN; and,
> d)  back out the above changes, at a similar unholy hour of the
> morning?

I am actually more sympathetic to your concerns than it may appear.

Just because I am pushing for doing this via local config and against
via a protocol extension does not mean that I am against the concept of
a temporary metric change. You are asking implementations to support the
idea of a temporary change to the currently advertised mettric w/o
altering the saved configuration. This certainly can be done w/o
extending the protocol - so there is no need to "remember/write-down the
existing IS-IS metric that was configured *before* I begin the
maintenance". You would simply remove the temporary config and the
router would automatically revert to the saved config. Internally this
has to be done regardless of whether you use the TLV or not.

At the risk of repeating myself (again!!) I would emphasize the only
difference between what you want and what I want is whether it requires
a protocol extension to do it - we aren't disagreeing on the
functionality that is desirable.

   Les

> 
> And, we wonder why the Internet is only perceived as a "best-effort"
> network?
> 
> 
> On a more serious note, it's important to recognize that in order to
> mitigate human-error, we need to reduce the burden on operators to
> "always get it right", as you seem to imply above, and certainly as
our
> executives (and customers) want us to.  Codifying something like the
> Reverse Metric TLV in the protocol allows operators to have a
> _repeatable_, interoperable mechanism that will dramatically reduce
the
> risk of 'human error' for a widely accepted & used operational
practice
> (link isolation).  Given that all public studies I've seen classify
> 'human error' as the dominant cause of network outages, one would
think
> we should be looking at ways to remedy that ...
> 
> -shane