Subject: [Isis-wg] two drafts

From: "李振强" <[email-masked]>
Date: Tue, 2 Mar 2010 11:29:42 +0800

Hello, ISIS experts,

I am Zhenqiang Li from China Mobile. The attachments are two drafts submitted by China Mobile. Comments and suggestions are welcomed. They will be modified according to your comments and submitted to the coming IETF meeting. I will try to ask the chairman to allocate a time slot for them to be discussed during the meeting.

Best Regards,

Zhenqiang Li  Ph. D.
+86 13911635816
Department of Network Technology
China Mobile Research Institute
2010-03-02

---

From: Tony Li <[email-masked]>
Date: Mon, 01 Mar 2010 21:31:36 -0800

Hi,

One question with your purge TLV.  What happens when this is used in
conjunction with authentication?  RFC 5304 specifies that all TLV’s shall be
removed prior to computing authentication of a purge.  I believe you would
want to amend this.

RFC 5310 omits discussion of purges, which is probably an error.

Tony

On 3/1/10 7:29 PM, "李振强" <[email-masked]> wrote:

> Hello, ISIS experts,
>  
> I am Zhenqiang Li from China Mobile. The attachments are two drafts submitted
> by China Mobile. Comments and suggestions are welcomed. They will be modified
> according to your comments and submitted to the coming IETF meeting. I will
> try to ask the chairman to allocate a time slot for them to be discussed
> during the meeting.
>  
> Best Regards,
>  
> 
> Zhenqiang Li  Ph. D.
> +86 13911635816
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 1 Mar 2010 22:10:04 -0800

Tony -

I think your question is beside the point.

draft-wei-isis-tlv-00.txt is discussing an enhancement to a behavior (purging on received LSP checksum error) which has been defined as incorrect behavior since 1993 (when the flaw in the 1992 version of ISO 10589 was corrected via TC1). Given that the correct behavior specified is to discard there is no need for this enhancement.

(Your comment regarding RFC 5310 may be correct - but that is a separate matter)

   Les

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Tony Li
> Sent: Monday, March 01, 2010 9:32 PM
> To: 李振强; isis-wg
> Cc: Dan King; [email-masked]; Li Lianyuan; adrian.farrel
> Subject: Re: [Isis-wg] two drafts
> 
> 
> Hi,
> 
> conjunction with authentication?  RFC 5304 specifies that all TLV’s
> shall be removed prior to computing authentication of a purge.  I
> believe you would want to amend this.
> 
> 	I am Zhenqiang Li from China Mobile. The attachments are two
> drafts submitted by China Mobile. Comments and suggestions are
> welcomed. They will be modified according to your comments and
> submitted to the coming IETF meeting. I will try to ask the chairman to
> allocate a time slot for them to be discussed during the meeting.
> 
> 	Best Regards,
> 
> 
> ________________________________
> 
> 	Zhenqiang Li  Ph. D.
> 	+86 13911635816
> ________________________________
>

---

From: Tony Li <[email-masked]>
Date: Mon, 01 Mar 2010 23:16:47 -0800

Les,

I agree with you, but only partially.

You are correct, that initiating a purge in response to a checksum error is
an incorrect behavior.

However, there are still other, correct behaviors that result in generating
purges.  In these cases, I view the proposed TLV as useful.  If you have to
trigger a purge, being able to backtrack to the source is vital to
debugging.  This part, I believe is wholly on point, and thus the
interaction with RFC 5304 is on point.

Tony

On 3/1/10 10:10 PM, "Les Ginsberg (ginsberg)" <[email-masked]> wrote:

> draft-wei-isis-tlv-00.txt is discussing an enhancement to a behavior (purging
> on received LSP checksum error) which has been defined as incorrect behavior
> since 1993 (when the flaw in the 1992 version of ISO 10589 was corrected via
> TC1). Given that the correct behavior specified is to discard there is no need
> for this enhancement.
>

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 1 Mar 2010 23:35:24 -0800

Tony -

> Sent: Monday, March 01, 2010 11:17 PM
> To: Les Ginsberg (ginsberg); 李振强; isis-wg
> Cc: adrian.farrel; Dan King; Li Lianyuan; [email-masked]

I believe the legitimate purge cases are limited to:

1)Originating IS purges its own LSP. This case is not really of concern here.

2)LSP owned by another IS ages out - in which case all ISs will trigger the purge at roughly the same time. The enhancement does not seem useful in this case.

Have I overlooked something??

   Les

> > (Your comment regarding RFC 5310 may be correct - but that is a
> separate
> > matter)
> >
> >    Les
> >

---

From: Tony Li <[email-masked]>
Date: Tue, 02 Mar 2010 00:04:47 -0800

Hi Les,

> 2)LSP owned by another IS ages out - in which case all ISs will trigger the
> purge at roughly the same time. The enhancement does not seem useful in this
> case.
> 

I disagree that having a tag in case 2 is not useful.  In fact, it would
seem very useful in debugging purge propagation.

Another case of legitimate purges is when there is a new DIS election.  See
8.4.5.d&e.

In general, the cost seems very low, the potential for debugging information
seems worthwhile.

Why not?

Tony

---

From: shengcheng <[email-masked]>
Date: Tue, 02 Mar 2010 16:14:42 +0800

Hi Tony,

I have a question: Can we modify the ISIS behaviour of purging other's LSP to just permit to purge self-originated LSP which is similar to what OSPF does ?

Thanks
Sheng

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 2 Mar 2010 00:24:13 -0800

Tony -

> From: Tony Li [mailto:[email-masked]]
> Sent: Tuesday, March 02, 2010 12:05 AM

Yup.

> In general, the cost seems very low, the potential for debugging

I don't think that debugging correct behavior is a priority. And if it is existing debug logs which most implementations provide seem quite adequate.

What one might want to do is debug incorrect purges - but the notion that an implementation which is behaving pathologically would also be well behaved enough to leave its fingerprints doesn't fill me w confidence.

Note also that what you and I are discussing is NOT what the submitted draft is discussing. :-)

  Les

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 2 Mar 2010 00:36:28 -0800

Sheng -

IS-IS does not allow purging LSPs owned by another IS except in two circumstances:

1)LSP ages out
2)DIS change (new DIS is allowed to purge the old DIS pseudo-node LSPs- thanx to Tony for reminding me)

There was an unfortunate error in the original ISO 10589-1992 spec which specified purging an LSP received w checksum error. This was quickly corrected in Technical Corrigendum I (ISO speak...) published in 1993 to specify discard. Unfortunately, many folks only look at the 1992 spec and are unaware of TC1. 

The 2002 edition of 10589 (the latest version) incorporates TC1.

   Les

> From: shengcheng [mailto:[email-masked]]
> Sent: Tuesday, March 02, 2010 12:15 AM
> To: Tony Li; Les Ginsberg (ginsberg); 李振强; isis-wg
> Cc: [email-masked]; adrian.farrel; Li Lianyuan; Dan King
> I have a question: Can we modify the ISIS behaviour of purging other's
> LSP to just permit to purge self-originated LSP which is similar to
> what OSPF does ?
> 
> Thanks
> Sheng
> 
> 
> To: "Les Ginsberg (ginsberg)" <[email-masked]>; "李振强"
> <[email-masked]>; "isis-wg" <[email-masked]>
> Cc: <[email-masked]>; "adrian.farrel"
> <[email-masked]>; "Li Lianyuan" <[email-masked]>;
> "Dan King" <[email-masked]>

---

From: Tony Li <[email-masked]>
Date: Tue, 02 Mar 2010 00:48:12 -0800

Hi Les,

> I don't think that debugging correct behavior is a priority. And if it is
> existing debug logs which most implementations provide seem quite adequate.

Well, if all implementations had only correct behaviors, then debugging
would certainly be simpler.  ;-)  Unfortunately, that's not the reality that
we seem to live in.

Further, the whole point of this extension is to help localize exactly which
debugging log to look into.  When you consider that some folks are deploying
areas with hundreds of ISes, and climbing, this is becoming more pressing.

> What one might want to do is debug incorrect purges - but the notion that an
> implementation which is behaving pathologically would also be well behaved
> enough to leave its fingerprints doesn't fill me w confidence.

I concur.
 
> Note also that what you and I are discussing is NOT what the submitted draft

More precisely, I think we agree that the motivations that originated the
draft are misdirected.  However, I'm trying to argue that the tool is still
of value, and I'm unwilling to "throw the baby out with the bath water".

Tony

---

From: shengcheng <[email-masked]>
Date: Tue, 02 Mar 2010 16:55:57 +0800

Les,

I know the ISIS purge specification and the "unfortunate" history. :)

Yes, purge should be based on a specific reason, whether it is LSP age or DIS change. 
But if am right, OSPF keep silent(compared to purge other's LSP) in the same scenarios and the protocol still works well in reality.
So my question is to why we can't follow OSPF's purge(flush) behaviour?

Second, i think the "purge" history is just well known by a few ISIS experts just like you. Many ISIS guys maybe know it after a long time from knowing the protocol.
It is difficult to find the modificaiton by comparing ISO 10589 1992 and 2002 verstion(most content are same except the document format)

Anyway, in my personal view, history has made such "mistakes" and leave negative effect. Maybe, the Group need to do sth to improve.

Thanks
Sheng

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 2 Mar 2010 01:31:15 -0800

Sheng -

In regards to OSPF, RFC 2328 specifies equivalent behavior when LSAs reach MAXAGE. From Section 14:

"As a router ages its link state database, an LSA's LS age may reach
    MaxAge.[21] At this time, the router must attempt to flush the LSA
    from the routing domain.  This is done simply by reflooding the
    MaxAge LSA..."

Apart from purging on checksum error (which was long ago removed from the specification) - I am not aware that purging is problematic. So I am not sure what problem it is that you believe will be solved if we just don't purge at all.

That said, purging is an optimization. It reduces the size of the stored link state database - something that customers (in my experience) have been concerned about. You could continue to leave stale entries in the database (and in some scenarios this does occur e.g. when an IS fails) and the protocol continues to operate correctly. This fact does not make it desirable to leave stale entries.

In regards to the purge history - while it is no doubt true that many folks are not familiar with the old ISO Technical Corrigenda - the issue of purging on checksum error is well known and has been widely discussed in public many times in forums like this - as well as by protocol vendors in their documentation and interaction w customers. It is also discussed in RFC 3719 Section 8 - which is not nearly as lengthy as ISO 10589. :-)

So I do not agree that the community of experts has been remiss in addressing this issue nor in publicizing it.

   Les

> Sent: Tuesday, March 02, 2010 12:56 AM
> To: Les Ginsberg (ginsberg); Tony Li; 李振强; isis-wg
> But if am right, OSPF keep silent(compared to purge other's LSP) in the
> same scenarios and the protocol still works well in reality.
> Second, i think the "purge" history is just well known by a few ISIS
> experts just like you. Many ISIS guys maybe know it after a long time
> from knowing the protocol.
> It is difficult to find the modificaiton by comparing ISO 10589 1992
> and 2002 verstion(most content are same except the document format)
> 
> Anyway, in my personal view, history has made such "mistakes" and leave
> negative effect. Maybe, the Group need to do sth to improve.
> 
> 
> Thanks
> Sheng
> 
> To: "shengcheng" <[email-masked]>; "Tony Li" <[email-masked]>;
> "李振强" <[email-masked]>; "isis-wg" <[email-masked]>
> > There was an unfortunate error in the original ISO 10589-1992 spec
> which specified purging an LSP received w checksum error. This was
> quickly corrected in Technical Corrigendum I (ISO speak...) published
> in 1993 to specify discard. Unfortunately, many folks only look at the
> 1992 spec and are unaware of TC1.
> >
> >> >> purge at roughly the same time. The enhancement does not seem
> useful
> >> in this
> >> >> case.
> >> >>

---

From: mike shand <[email-masked]>
Date: Tue, 02 Mar 2010 14:03:36 +0000

I think that the fact that the most recent (i.e. 8 year old) version of 
ISO/IEC 10589 describes the correct checksum error behaviour AND that 
RFC 3719 draws attention to this is perfectly adequate documentation of 
the correct protocol. I fail to see how another draft would make the 
situation any better. Indeed it would further muddy the waters in my 
opinion.

As for the utility of the proposed "purge TLV".

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.

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.

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.

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. But in the absence of such evidence I am 
sceptical.

As for changing the purge behaviour. No!  I see absolutely no benefit in 
removing, or otherwise altering the purge behaviour.

    Mike

Les Ginsberg (ginsberg) wrote:
>>> IS-IS does not allow purging LSPs owned by another IS except in two
>>>       
>> circumstances:
>>     
>>> 1)LSP ages out
>>> 2)DIS change (new DIS is allowed to purge the old DIS pseudo-node
>>>       
>> LSPs- thanx to Tony for reminding me)
>>     
>>>> Cc: [email-masked]; adrian.farrel; Li Lianyuan; Dan
>>>>         
>> King
>>     
>>>> I have a question: Can we modify the ISIS behaviour of purging
>>>>         
>> other's
>>     
>>>> <[email-masked]>; "Li Lianyuan"
>>>>         
>> <[email-masked]>;
>>     
>>>>>> 1)Originating IS purges its own LSP. This case is not really of
>>>>>>             
>>>> concern here.
>>>>         
>>>>>> 2)LSP owned by another IS ages out - in which case all ISs will
>>>>>>             
>>>> trigger the
>>>>         
>>>>> I disagree that having a tag in case 2 is not useful.  In fact, it
>>>>>           
>>>> would
>>>>         
>>>>> Another case of legitimate purges is when there is a new DIS
>>>>>           
>>>> election.  See
>>>>         
>>>>> 8.4.5.d&e.
>>>>>
>>>>> In general, the cost seems very low, the potential for debugging
>>>>>           
>>>> information
>>>>         
>>>>> seems worthwhile.
>>>>>
>>>>> Why not?
>>>>>
>>>>> Tony
>>>>>
>>>>>

---

From: Tony Li <[email-masked]>
Date: Tue, 02 Mar 2010 09:02:53 -0800

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 

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 

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

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 2 Mar 2010 09:13:52 -0800

Tony -

> Sent: Tuesday, March 02, 2010 12:48 AM
> > Note also that what you and I are discussing is NOT what the
> submitted draft
> > is discussing. :-)
> 
> 

Well put.
So let's look at the various cases.
We both seem to agree that we are confining ourselves to the legitimate cases where purging is done. There are three (unless I have forgotten yet another one :-) ):

1)Originator purges its own LSP.

Clearly we know exactly what IS is doing the purge in this case - I do not see how the new TLV adds value here.

2)DIS change

There are potentially two ISs who could do the purge - the new DIS and/or the resigning DIS. Again, the identity of the ISs is known and I do not see that the new TLV adds value here.

3)LSP ages out

Here any IS could do a purge - and as the age would expire at roughly the same time throughout the network it is likely that multiple ISs would initiate a purge. Now, assuming that the new TLV were used to help identify the source of a purge, exactly how would this work? It seems to require that every IS store multiple copies of the same purged LSP where each copy has a different "purge source". It also seems to require that each of these multiple copies gets flooded - otherwise the information that you need is not present throughout the network - and therefore the ability to isolate the source(s) of the purge would be compromised. This suggests that a rather significant change to the operation of the Update Process would be required in order to take advantage of this new information.

Whatever benefit might be gained in debugging (which seems low to me) is far outweighed by the risk/effort associated w modifying the update process.

   Les

---

From: mike shand <[email-masked]>
Date: Tue, 02 Mar 2010 17:27:20 +0000

Les,
I don't think we would do that. I think only the first person that
purges (who first floods the purged LSP) would be recorded.

So would this be useful? In the case where there is some rogue router
that is purging early, becuase it is perhaps decrementing the age too
often it might. What the netowrk would see would be that for some
strange reasons LSPs seem to be timeing out before they are refreshed.
How do you find who is resonsible?

So I think it might help there. But does it ever happen?

Mike

---

From: Tony Li <[email-masked]>
Date: Tue, 02 Mar 2010 10:25:12 -0800

Hi Les,

> We both seem to agree that we are confining ourselves to the legitimate cases
> where purging is done. There are three (unless I have forgotten yet another
> one :-) ):

Yes, but I'm still trying to deal with the cases where a well-intentioned
implementation has bugs and is generating purges incorrectly.  Enhancing
debugging in these cases would be beneficial.

Note that this information is also helpful in a negative way: if an
implementation generates these TLVs when it purges, then an unmarked purge
is much more likely to have come from a different implementation.

> Here any IS could do a purge - and as the age would expire at roughly the same
> time throughout the network it is likely that multiple ISs would initiate a
> purge. Now, assuming that the new TLV were used to help identify the source of
> a purge, exactly how would this work? It seems to require that every IS store
> multiple copies of the same purged LSP where each copy has a different "purge
> source". It also seems to require that each of these multiple copies gets
> flooded - otherwise the information that you need is not present throughout
> the network - and therefore the ability to isolate the source(s) of the purge
> would be compromised. This suggests that a rather significant change to the
> operation of the Update Process would be required in order to take advantage
> of this new information.

Or, you simply log the initiator and flood the purge.  No change to the
update process, only to purge formatting.

Tony

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 2 Mar 2010 10:52:47 -0800

Tony -

If viewed in this context:

1)Every LSP contains the identity of the IS which generated it
2)As purge LSPs are allowed to be generated by someone other than the owner it is reasonable to include the identity of the "purger" in such LSPs
3)No other protocol changes

I am somewhat more receptive to this idea.

The question now is how many of the problematic cases that have been encountered would this actually have helped?

You mention two:

1)a node trying to self-purge and making some truly egregious mistakes.

2)an implementation that failed to retain the LSP header
after purging and while flooding was still in progress.

The first one lacks sufficient detail to judge whether this new mechanism might have helped. In the second case I assume the purged LSP had some "randomness" in its identity when sent on the wire? In which case knowing who sent it would be helpful in identifying the problematic implementation - assuming that an implementation which fails to keep the header around somehow manages to include this new TLV when flooding it.

The question for me now that we seem to have agreed on the limited scope is whether the new functionality is useful enough to warrant the effort. Or, to put it another way, would anyone actually deploy this change? Unless you are planning to write (yet another) IS-IS implementation I think we need to hear an opinion from someone else. :-)

And, as a point of emphasis, what we are discussing is NOT targeted at solving the problem mentioned in draft-wei-isis-tlv-00.txt. The solution to that is to conform to the spec and don't purge on received checksum error.

   Les

> Sent: Tuesday, March 02, 2010 10:25 AM

---

From: Nischal Sheth <[email-masked]>
Date: Tue, 2 Mar 2010 10:58:29 -0800

> So I think it might help there. But does it ever happen?

Haven't seen this with IS-IS yet, but have encountered a couple of buggy
OSPF implementations which jittered their aging timers and hence ended up
purging LSAs before they could be refreshed by the originator.

-Nischal

---

From: shengcheng <[email-masked]>
Date: Wed, 03 Mar 2010 17:37:55 +0800

Hi Les

To be strict, what i said about OSPF and ISIS is not correct. But, I regard "flush other's LSA/LSP" here as to "purge other's LSA/LSP with a normal age ".
For example, when DR change, new OSPF DR will not flush the previous DR's network LSA. So, OSPF and ISIS are different here.
If ISIS's flush mechanism  were originally defined similarly to OSPF, we will not discuss about the topic here and Chinamobile will also not propose the TLV draft. : ) 

I have read RFC 3719 when it was released on 2004, before which vendors have released routing OS version based on ISO 10589 of 1992 version I think.

Thanks&Regards
Sheng

---

From: Tsui James <[email-masked]>
Date: Wed, 3 Mar 2010 23:08:56 +0800

*for **draft-li-isis-error-lsp-processing-02.tx :*
*
*
*Your question does exist in the current network, but the root cause is that
some vendors not fully in accordance with protocol.*
*So, i think it's unnecessary to submit such a draft and RFC 3719 is clearly
enough to solve the problem.*

for  *draft-wei-isis-tlv-00.txt:*
*
*
*I think you mainly want to quickly locate the fault  source where the LSP
is modified Illegally . Maybe caused by bit hopping.*
*But it is easier to add a log or warning or trap to locate the fault
source.*
*Do you think so ? *
*
*
Best regards!
*=============*
*James*

在 2010年3月2日 上午11:29，李振强 <[email-masked]>写道：

>  Hello, ISIS experts,
>
> I am Zhenqiang Li from China Mobile. The attachments are two drafts
> submitted by China Mobile. Comments and suggestions are welcomed. They will
> be modified according to your comments and submitted to the coming IETF
> meeting. I will try to ask the chairman to allocate a time slot for them to
> be discussed during the meeting.
>
> Best Regards,
>
>  ------------------------------
>  Zhenqiang Li  Ph. D.
> +86 13911635816

-- 
========================
Best regards!

                               James.Tsui

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 3 Mar 2010 10:46:50 -0800

Sheng -

The problem in the ChinaMobile network is caused by one or more implementations which do not adhere to the IS-IS standard. 

The purging mechanism as defined in the current IS-IS specification is not at issue and requires no changes. Specifically, the requirement to purge the old DIS pseudo-node LSPs on a DIS change does not contribute to the ChinaMobile network problem.

What is being discussed in this thread is a proposal to make it easier to identify the source of a purge so that a flawed implementation can be more easily identified. In discussing the potential use cases it is enlightening that a use case for such a mechanism has been seen in OSPF. :-)

   Les

> Sent: Wednesday, March 03, 2010 1:38 AM
> To be strict, what i said about OSPF and ISIS is not correct. But, I
> regard "flush other's LSA/LSP" here as to "purge other's LSA/LSP with a
> normal age ".
> For example, when DR change, new OSPF DR will not flush the previous
> DR's network LSA. So, OSPF and ISIS are different here.
> If ISIS's flush mechanism  were originally defined similarly to OSPF,
> we will not discuss about the topic here and Chinamobile will also not
> propose the TLV draft. : )
> 
> I have read RFC 3719 when it was released on 2004, before which vendors
> have released routing OS version based on ISO 10589 of 1992 version I
> think.
> 
> Thanks&Regards
> Sheng
> 
> Cc: "Dan King" <[email-masked]>; <[email-masked]>;
> "Li Lianyuan" <[email-masked]>; "adrian.farrel"
> <[email-masked]>
> > Apart from purging on checksum error (which was long ago removed from
> the specification) - I am not aware that purging is problematic. So I
> am not sure what problem it is that you believe will be solved if we
> just don't purge at all.
> >
> > That said, purging is an optimization. It reduces the size of the
> stored link state database - something that customers (in my
> experience) have been concerned about. You could continue to leave
> stale entries in the database (and in some scenarios this does occur
> e.g. when an IS fails) and the protocol continues to operate correctly.
> This fact does not make it desirable to leave stale entries.
> >
> > In regards to the purge history - while it is no doubt true that many
> folks are not familiar with the old ISO Technical Corrigenda - the
> issue of purging on checksum error is well known and has been widely
> discussed in public many times in forums like this - as well as by
> protocol vendors in their documentation and interaction w customers. It
> is also discussed in RFC 3719 Section 8 - which is not nearly as
> lengthy as ISO 10589. :-)
> >
> > So I do not agree that the community of experts has been remiss in
> addressing this issue nor in publicizing it.
> >
> >   Les
> >
> >> Yes, purge should be based on a specific reason, whether it is LSP
> age
> >> or DIS change.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 3 Mar 2010 12:23:54 -0800

Just in case there was some misinterpretation of my post - I am NOT suggesting that IS-IS is better than OSPF in some way (or vice versa as Sheng was claiming). I was pointing out that both OSPF and IS-IS are vulnerable to problems associated with a misbehaving implementation related to purging - and we have existence proofs of that for both protocols.

   Les 

> Behalf Of Les Ginsberg (ginsberg)
> Sent: Wednesday, March 03, 2010 10:47 AM
> To: shengcheng; Tony Li; 李振强; isis-wg
> The problem in the ChinaMobile network is caused by one or more
> implementations which do not adhere to the IS-IS standard.
> 
> The purging mechanism as defined in the current IS-IS specification is
> not at issue and requires no changes. Specifically, the requirement to
> purge the old DIS pseudo-node LSPs on a DIS change does not contribute
> to the ChinaMobile network problem.
> 
> What is being discussed in this thread is a proposal to make it easier
> to identify the source of a purge so that a flawed implementation can
> be more easily identified. In discussing the potential use cases it is
> enlightening that a use case for such a mechanism has been seen in
> OSPF. :-)
> 
>    Les
> 
> > > In regards to OSPF, RFC 2328 specifies equivalent behavior when
> LSAs
> > reach MAXAGE. From Section 14:
> > >
> > >> But if am right, OSPF keep silent(compared to purge other's LSP)
> in
> > the
> > >> >> LSP to just permit to purge self-originated LSP which is
> similar
> > to
> > >> >> what OSPF does ?
> > >> >>
> > >> >> Thanks
> > >> >> Sheng
> > >> >>
> > >> >>
> > >> >> > I disagree that having a tag in case 2 is not useful.  In
> fact,
> > it
> > >> >> would

---

From: Dave Katz <[email-masked]>
Date: Wed, 3 Mar 2010 00:08:34 -0800

Beat me to it.

We're *still* seeing behavior like this in the field, a decade after  
first running across it, and it is quite difficult to track down.  It  
has been found in at least two implementations (one from a deservedly  
defunct company, but also one from a Major Router Vendor That I Once  
Worked For, but at least I didn't break *that* code <cough>).

Of course, one could argue that my one-line "optimization" of bumping  
OSPF refresh times up to 50 minutes from 30 (thus exposing the 45-60  
minute early purges) was a contributing factor, but this does  
demonstrate that implementors will always do things that, um, surprise  
us.

Is it worth torquing the protocol for this feature?  I don't know (and  
it will probably take a very long time for this to actually make it  
into the field, assuming that it is adopted.)

I guess I must have missed the TC when it came out (maybe ANSI X3S3.3  
was defunct by then) because I think the great UUnet meltdown must  
have been '95 or '96, when some link in Texas was delivering corrupted  
packets with valid datalink checksums.  This of course soon led to  
every LSP in the network being purged.  Repeatedly.  How cool was  
that?  ;-)

--Dave

---

From: Russ White <[email-masked]>
Date: Wed, 03 Mar 2010 15:00:43 -0500

> What is being discussed in this thread is a proposal to make it
> easier to identify the source of a purge so that a flawed
> implementation can be more easily identified. In discussing the
> potential use cases it is enlightening that a use case for such a
> mechanism has been seen in OSPF. :-)

I would say anything to make troubleshooting and running the network
better--well, go for it. I don't think such a thing should be a "must,"
but if vendors want to implement it as a "general help," I don't see
anything wrong with it.

Russ

- --
[email-masked] :: CCIE :: CCDE :: <>< Grace Alone

Extremism is a mental disorder in which a person actually believes
jumping off a fifty story building will kill you. We all know from
watching cartoons there is a high probability your shirt will be caught
on a flag pole.

---

From: Shane Amante <[email-masked]>
Date: Thu, 4 Mar 2010 08:26:28 -0700

[Trimming cc: list]

Speaking as a operator ... +1.  Although, I would put a finer point on what Russ said below and hope this would be a should implement, (rather than may).

-shane

On Mar 3, 2010, at 13:00 MST, Russ White wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iEYEARECAAYFAkuOv+sACgkQER27sUhU9ORb9ACeN/kbjCCDWxCqfNk4DLuBF+Pj
> tUIAoKV00WSF0iq288qOnnX3hpFqcUJp
> =wmI+
> -----END PGP SIGNATURE-----

---

From: mike shand <[email-masked]>
Date: Thu, 04 Mar 2010 15:37:53 +0000

OK, it looks as if there is some support for this at least. I don't have 
any problems with that provided we are simply talking about adding the 
proposed TLV (and figuring out how to deal with authentication) and 
making NO other changes to the behaviour.

However, I suspect there will not be much incentive for this to be 
implemented, and remember that it won't do anything to address the 
original problem caused by  pre-TC1 behaviour (since the rogue systems 
wouldn't implement it anyway, and if they were upgraded to implement it 
then surely they would be upgraded to implement the correct behaviour).

    Mike

---

From: David Ward <[email-masked]>
Date: Thu, 4 Mar 2010 09:46:32 -0800

Dave -

I think at most we have to call out the issue in some sort of "informational" spec. The issue as you mention with changing the spec iis the time to upgrade gear in the internet and to make vendors aware about reusing/porting/licensing-buying third party code with this problem. To avoid this sort of thing, some doc has to be able to be held up to the software forklift driver and make folks aware about the fail mechanisms of blindly coding jitter algorithms and timers. 

-DWard