Re: [Isis-wg] two drafts

[Jie Dong <[e-mail]>]

Hi MIke,

> If it is proposing changes to improve interoperability then 
> they will only be fully effective if everyone implements 
> them. In which case, wouldn't it be better for everyone to 
> implement the correct behaviour in the first place.

IMO, this draft does not require it be implemented by everyone.
 
If one router implements this draft, it has the capability of working with
other devices which may not fully implement IS-IS specification. In other
word, it can help suppress potiential network instability caused by
nonstandard devices. 

Best regards,
Jie

> I don't believe we should be making changes to the protocol 
> to accommodate broken implementations.
> 
> Mike
> 
> 
> [e-mail] wrote:
> > Hi, Mike,
> >
> > Specification is different from reality and implementation.
> > Misbehaviour caused network flapping occured in China 
> Mobile's network in 2007, 5 years after the correct 
> processing mechanism published.
> >
> > What are proposed in draft-li-isis-error-lsp-processing are 
> helpful to increase the interoperability of ISs from 
> different vendors and to increase the robustness of ISIS protocol.
> >
> > Best Regards,
> >
> > 
> ----------------------------------------------------------------------
> > ----------
> > Zhenqiang Li
> > 13911635816
> > Department of Network Technology
> > China Mobile Research Institute
> > 2010-03-05
> >
> > 
> ----------------------------------------------------------------------
> > ----------
> >
> > ·¢¼þÈË£º mike shand
> > ·¢ËÍʱ¼ä£º 2010-03-05 17:45:21
> > ÊÕ¼þÈË£º [e-mail]
> > ³­ËÍ£º isis-wg
> > Ö÷Ì⣺ Re: [Isis-wg] two drafts
> >
> > I see no reason to change anything. The correct procedure has been 
> > published for the last 8 years. I see no benefit in yet 
> another draft 
> > drawing attention to this.
> >
> > Mike
> >
> > [e-mail] wrote:
> >   
> >> Hi, Les,
> >>  
> >> I will revise draft-wei-isis-tlv according to the discuss 
> raised here.
> >>  
> >> For draft-li-isis-error-lsp-processing, it was presented 
> in IETF 75 meeting and we did not get more argument after the 
> answer in the meeting. Please refer to the minute.
> >> It is not historic to provide the switch. Cisco GSR 
> routers still have the switch in the field network. From the 
> view of the operaters, at least China Mobile, such switch is 
> welcome. But the default state should be what is said in my 
> draft to in according with ISO 10589.
> >> Besides, some other suggestions are given in my draft, 
> such as providing correct chechsum even in purge LSP, correct 
> processing procedure for zero checksum/remianing lifetime LSPs.
> >> Why do you want to abandon the whole draft?
> >>  
> >>
> >> 
> ---------------------------------------------------------------------
> >> -----------
> >>
> >> Zhenqiang Li
> >> 13911635816
> >> Department of Network Technology
> >> China Mobile Research Institute
> >> 2010-03-05
> >>
> >> 
> ---------------------------------------------------------------------
> >> -----------
> >>
> >> ·¢¼þÈË£º Les Ginsberg (ginsberg)
> >> ·¢ËÍʱ¼ä£º 2010-03-05 11:41:55
> >> ÊÕ¼þÈË£º ÀîÕñÇ¿; isis-wg
> >> ³­ËÍ£º
> >> Ö÷Ì⣺ RE: RE: [Isis-wg] two drafts
> >>  
> >> Zhenqiang -
> >>  
> >> You submitted two drafts.
> >>  
> >> 1) draft-wei-isis-tlv-00.txt
> >>  
> >> This is proposing a new TLV to advertise the source of the 
> purge. This has received some favorable interest and in my 
> view (which is not authoritative) should move forward - 
> though significant revisions will need to be made to the 
> draft to address all of the concerns/limitations that have 
> been raised.
> >>  
> >> 2) draft-li-isis-error-lsp-processing-02.txt
> >>  
> >> This is proposing to allow an IS to either discard or 
> purge a received corrupted LSP.
> >>  
> >> It is the latter draft's intentions that I was responding 
> to in my most recent reply to you. The fact that some 
> implementations have historically provided a knob to enable 
> either behavior (discard/purge) is not reason to preserve the 
> purge behavior. Evidence is now clear that discard is the 
> correct behavior and has proven to be safe. There is no 
> reason to reintroduce purging as a valid option - so in my 
> view the second draft should be abandoned.
> >>  
> >>    Les
> >>  
> >>   
> >>     
> >>> -----Original Message-----
> >>> From: ÀîÕñÇ¿ [mailto:[e-mail]]
> >>> Sent: Thursday, March 04, 2010 6:37 PM
> >>> To: Les Ginsberg (ginsberg); isis-wg
> >>> Subject: Re: RE: [Isis-wg] two drafts
> >>>
> >>>
> >>> Hi, Les,
> >>>
> >>> Thank you for your active discussion in the mail list.
> >>>
> >>> Yes, you are right. ISO 10589 specified the correct behavior for 
> >>> routers receiving a corrupt LSP in 2002. However, the network 
> >>> flapping occurred in China Mobile's network in 2007. 
> Unfortunately, 
> >>> we even did not see any corruptedLSPReceived warning from the NMS.
> >>>
> >>> What we are discussed here are the differences between 
> >>> implementations and specifications. The purpose of this 
> draft is not 
> >>> to revise the specification back to purge corrupted LSPs, 
> but to add 
> >>> a new TLV to record the source of the purge LSP. This method I 
> >>> believe is benificial to debug and locate network 
> problems, such as flapping.
> >>>
> >>> Best Regards,
> >>> ---------------------------------------
> >>> Zhenqiang Li
> >>> 13911635816
> >>> Department of Network Technology
> >>> China Mobile Research Institute
> >>> 2010-03-05
> >>>
> >>>
> >>>
> >>> ·¢¼þÈË£º Les Ginsberg (ginsberg)
> >>> ·¢ËÍʱ¼ä£º 2010-03-04 23:37:03
> >>> ÊÕ¼þÈË£º [e-mail]; isis-wg
> >>> ³­ËÍ£º
> >>> Ö÷Ì⣺ RE: [Isis-wg] two drafts
> >>>
> >>> Zhenqiang -
> >>>
> >>> ISO 10589(2002) Section 7.3.14.2e specifies:
> >>>
> >>>   <snip   >
> >>> An Intermediate system receiving a Link State PDU with an 
> incorrect 
> >>> LSP Checksum or with an invalid PDU syntax shall
> >>>
> >>> 1) generate a corruptedLSPReceived circuit event,
> >>>
> >>> 2) discard the PDU.
> >>>   <end snip   >
> >>>
> >>> This follows a safe practice of dealing with corrupted 
> LSPs in a way 
> >>> which avoids dangerous LSP storms.
> >>>
> >>> Your argument is if the corrupted LSP is discarded 
> "silently" then 
> >>> you do not actually know that corrupted LSPs are being 
> received - so 
> >>> you would like the spec to be revised to allow ISs to 
> purge corrupted LSPs.
> >>> This of course puts the network at risk for LSP storms - which 
> >>> according to your post below you have actually experienced.
> >>>
> >>> The safe solution is to follow the spec which not only stipulates 
> >>> that corrupted LSPs should be discarded but also specifies that a 
> >>> management event be generated so the occurrence of 
> corrupted LSPs is reported.
> >>> Rather than do this, your proposal not only would restore 
> a proven 
> >>> dangerous behavior (purging corrupted LSPs) but do so in 
> a way which 
> >>> does NOT generate any events (you specify treating 
> corrupted LSPs in 
> >>> the same manner as LSPs which have aged out).
> >>>
> >>> I do not see any reason to support this proposal.
> >>>
> >>>    Les
> >>>
> >>>
> >>>   > -----Original Message-----
> >>>   > From: [e-mail] 
> [mailto:[e-mail]] On
> >>>   > Behalf Of [e-mail]
> >>>   > Sent: Thursday, March 04, 2010 1:18 AM
> >>>   > To: isis-wg
> >>>   > Subject: Re: [Isis-wg] two drafts
> >>>   >
> >>>   > I did not see the mail I posted to [e-mail] 
> using foxmail.
> >>> Sent
> >>>   > it out again using web mail. Sorry for the possible 
> duplication.
> >>>   > /////////////////////////////////////
> >>>   >
> >>>   >
> >>>   > Hi, Les, Tony and Sheng,
> >>>   >
> >>>   > Thank you for your discussion.
> >>>   > China Mobile submitted this draft since several times 
> of severe whole
> >>>   > network flapping occurred in our network in the past 
> three years. We
> >>>   > found the reason was that the products of some vendor 
> generated purge
> >>>   > LSP when they received LSP with an invalid checksum. 
> The flapping
> >>>   > impacted the services carried in our network and we 
> spent a lot 
> >>> of hard
> >>>   > time to look for the reason and to locate the flapping source.
> >>>   >
> >>>   > One disadvantage of discarding the corrupted LSP 
> silently is no
> >>>   > indication of network misbehavior. So, some vendors 
> (e.g. Cisco)
> >>>   > provide switch to control the process manner: whether 
> to discard the
> >>>   > corrupted LSP or to generate a purge LSP.
> >>>   >
> >>>   > The method mentioned in this draft is helpful to 
> locate the flapping
> >>>   > source when flapping does occur in the network.
> >>>   >
> >>>   > Best Regards,
> >>>   >
> >>>   >
> >>>   > 
> >>> 
> --------------------------------------------------------------------
> >>> -
> >>> --
> >>>   > ---------
> >>>   >
> >>>   > Zhenqiang Li
> >>>   > 13911635816
> >>>   > Department of Network Technology
> >>>   > China Mobile Research Institute
> >>>   > 2010-03-02
> >>>   >
> >>>   > 
> >>> 
> --------------------------------------------------------------------
> >>> -
> >>> --
> >>>   > ---------
> >>>   >
> >>>   > ·¢¼þÈË£º Les Ginsberg (ginsberg)
> >>>   > ·¢ËÍʱ¼ä£º 2010-03-02 17:46:14
> >>>   > ÊÕ¼þÈË£º shengcheng; Tony Li; ÀîÕñ[e-mail]
>;
> >>> isis-wg
> >>>   > ³­ËÍ£º [e-mail]; adrian.farrel; Li 
> Lianyuan; Dan
> >>>   > King
> >>>   > Ö÷Ì⣺ RE: [Isis-wg] two drafts
> >>>   >
> >>>   > 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
> >>>   >
> >>>   >    > -----Original Message-----
> >>>   >    > From: shengcheng [mailto:[e-mail]]
> >>>   >    > Sent: Tuesday, March 02, 2010 12:56 AM
> >>>   >    > To: Les Ginsberg (ginsberg); Tony Li; ÀîÕñÇ¿; isis-wg
> >>>   >    > Cc: [e-mail]; adrian.farrel; 
> Li Lianyuan; Dan
> >>>   > King
> >>>   >    > Subject: Re: [Isis-wg] two drafts
> >>>   >    >
> >>>   >    > 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
> >>>   >    >
> >>>   >    > ----- Original Message -----
> >>>   >    > From: "Les Ginsberg (ginsberg)"     
> <[e-mail]    >
> >>>   >    > To: "shengcheng"     <[e-mail]    >; "Tony Li"
> >>>   <[e-mail]
> >>>   >    >;
> >>>   >    > "ÀîÕñÇ¿"     <[e-mail]    >; 
> "isis-wg"     <isis-
> >>> [e-mail]
> >>>   >    >
> >>>   >    > Cc:     <[e-mail]    >; 
> "adrian.farrel"
> >>>   >    >     <[e-mail]    >; "Li Lianyuan"
> >>>   >    >    <[e-mail]    >; "Dan King"  
>    <[e-mail]
> >>>   >
> >>>   >    > Sent: Tuesday, March 02, 2010 4:36 PM
> >>>   >    > Subject: RE: [Isis-wg] two drafts
> >>>   >    >
> >>>   >    >
> >>>   >    >     > 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
> >>>   >    >     >
> >>>   >    >     >    > -----Original Message-----
> >>>   >    >     >    > From: shengcheng 
> [mailto:[e-mail]]     >    > Sent:
> >>> Tuesday,
> >>>   >    > March 02, 2010 12:15 AM     >    > To: Tony Li; 
> Les Ginsberg
> >>> (ginsberg);
> >>>   >    > ÀîÕñÇ¿; isis-wg     >    > Cc: [e-mail];
> >>> adrian.farrel;
> >>>   > Li
> >>>   >    > Lianyuan; Dan King     >    > Subject: Re: 
> [Isis-wg] two drafts     >    >
> >>>   >    >
> >>>   > 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
> >>>   >    >     >    >
> >>>   >    >     >    >
> >>>   >    >     >    > ----- Original Message -----
> >>>   >    >     >    > From: "Tony Li"     <[e-mail]  
>   >     >    > To: "Les
> >>> Ginsberg
> >>>   >    > (ginsberg)"     <[e-mail]    >; "ÀîÕñÇ¿"
> >>>   >    >     >    >     <[e-mail]    
> >; "isis-wg"     <isis-
> >>> [e-mail]    >
> >>>   >    >    >    > Cc:     <[e-mail]  
>   >; "adrian.farrel"
> >>>   >    >     >    >     <[e-mail]    >; 
> "Li Lianyuan"
> >>>   >    >     <[e-mail]    >;
> >>>   >    >     >    > "Dan King"     <[e-mail]   
>  >     >    > Sent: Tuesday,
> >>> March 02,
> >>>   >    > 2010 4:04 PM     >    > Subject: Re: [Isis-wg] 
> two drafts     >    >     >
> >>>   >     >    >     >
> >>>   >    >    >    >     > Hi Les,     >    >     >     >   
>  >     >    > 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??
> >>>   >    >     >    >     >
> >>>   >    >     >    >     >
> >>>   >    >     >    >     > 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
> >>>   >    >     >    >     >
> >>>   >    >     >    >     >
> >>>   >    >     >    >     > 
> _______________________________________________
> >>>   >    >     >    >     > Isis-wg mailing list
> >>>   >    >     >    >     > [e-mail]
> >>>   >    >     >    >     > 
> https://www.ietf.org/mailman/listinfo/isis-wg
> >>>   >    >     >
> >>> 
> --------------------------------------------------------------------
> >>> ----
> >>>
> >>> _______________________________________________
> >>> Isis-wg mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/isis-wg
> >>>     
> >>>       
> 
>