Subject: Re: [Isis-wg] two drafts

From: [email-masked]
Date: Thu, 4 Mar 2010 17:14:23 +0800

I did not see the mail I posted to [email-masked] using foxmail. Sent it out again using web mail. Sorry for the possible duplication.
/////////////////////

I agree with you Tony.  You said: As we move to having more field implementations and more complex heterogeneous networks I would expect that we will see more of these issues, not less. 

One of China Mobile's backbone networks is a heterogeneous network, which consists of nearly 800 routers from three vendors. Several times of whole network flapping occurred in this network in 2007 and 2008 due to one vendor's products generating purge LSPs when they received corrupted LSPs.  

--------------------------------------------
Zhenqiang Li
13911635816
Department of Network Technology
China Mobile Research Institute
2010-03-03

发件人： Tony Li
发送时间： 2010-03-03 01:17:55
收件人： mike shand; Les Ginsberg (ginsberg)
抄送： adrian.farrel; isis-wg; Li Lianyuan; [email-masked]; 李振强; Dan King; shengcheng
主题： Re: [Isis-wg] two drafts

Hi Mike,

a) Are there examples of cases of
> inappropriate purging behaviour other 
than incorrect treatment of checksum
> errors? The new TLV would be 
useless to identify the latter, since if the
> implementation had been 
updated to include the purge TLV it would be
> ludicrous to have not also 
implemented the correct checksum error behaviour.
> It would only be 
useful to identify some other form of inappropriate purging
> which might 
occur, and I am not sure what that could be.

Yes, I can recall certain implementation development scenarios where there
was some inappropriate purging.  These were typically a node trying to
self-purge and making some truly egregious mistakes.  A related, and more
notable failure was an implementation that failed to retain the LSP header
after purging and while flooding was still in progress.  That one made it to
the field with truly horrid results.

As we move to having more field implementations and more complex
heterogeneous networks I would expect that we will see more of these issues,
not less. 

> b) Would locating
> the source of a correctly initiated purge ever be 
useful? Why would you want
> to know which router had first decremented 
the lifetime to zero? Perhaps if
> there were a bug which was causing it 
to excessively rapidly decrement the
> lifetime. Has this ever been 
reported? Or why would you want to know which
> router becoming a new DIS 
had purged the old DIS's pseudonode LSP, especially
> when you could see 
from the LSPDB that it was now DIS.

Again, the problem is locating the source of an incorrectly initiated purge.

I take Tony's point
> that it MIGHT just be useful in some circumstances, 
but this seems like an
> excessive change to the protocol unless 
significant utility can be
> demonstrated.

My point is slightly stronger: this WOULD be useful in debugging purge
issues, both in implementations and in networks; in the lab and in the
field.  And once you have the problem, it's a bit late to add the TLV.

>I think if a number of people said "Gosh I wish I had had that
> facility 
when I was trying to debug my purging problem (in a version 2
> conforming 
implementation of course) . It would have saved me so much time.",
> then 
maybe we should consider it.

+1

Tony