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

[Christopher LILJENSTOLPE <[e-mail]>]

Greetings Les,
	
On 07Dec2010, at 08.47, Les Ginsberg (ginsberg) wrote:

> 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.
> 
The difference is that, by doing this via a temporary config method, it would have to be done at both ends (see my earlier comments).  In  Shane's model, it only needs to be done in one router.

> 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
> _______________________________________________
> Isis-wg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg
> 

---
李柯睿
Check my PGP key here:
https://www.asgaard.org/~cdl/cdl.asc