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

[Christopher LILJENSTOLPE <[e-mail]>]

Greetings all,


On 07Dec2010, at 07.21, Shane Amante wrote:

> 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?
> 
> 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 ...

I support Shane in this concise description of the problem.  We CAN do it (in most cases) with what we have now, we WILL (and do) bork then network some percentage of the time when doing so.  This is an anti-borking approach, and I support it.  The problem will just get worse as the interface and meshing ratios go up, which they inevitably will.

	Chris

> 
> -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

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