Subject: Re: [Isis-wg] Regarding draft-li-isis-error-lsp-processing-03

From: [email-masked]
Date: Fri, 28 May 2010 16:29:41 +0800

Thanks Chris & Dave. 
I posted the previous discussion below. From the discuss, we can see that some guys think the proposed checksum calculation is reasonable. More comments are welcome. If we all love this points, I will submit a document only contain this points.

//////////////////////////////////////////////////////
Hi Les,

IMO, the intention of this draft is to recommend routers to be strict on
what they advertise and be generous on what they receive, and in this way
the network can be more interoperable and fault-tolerant.

I agree that non-conformant implementations should be fixed as long as they
are found out, but making correct implementations more robust may also be
helpful to operators and their network.

Best regards,
Jie

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Les Ginsberg (ginsberg)
> Sent: Tuesday, April 06, 2010 1:05 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] IETF-77 isis-wg meeting minutes 
> posted. (ChristianHopps)
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of [email-masked]
> > Sent: Monday, April 05, 2010 9:10 PM
> > To: [email-masked]
> > Subject: Re: [Isis-wg] IETF-77 isis-wg meeting minutes posted.
> > (ChristianHopps)
> > 
> > 
> > Thanks Chris & Dave,
> > 
> > For draft-li-isis-error-lsp-processing-03, I think it's better to 
> > mention following point in the minute.
> > Generating correct chesksum for all kinds of LSPs including zero 
> > remaining lifetime LSP is helpful to increase the IS's 
> compatibility.
> 
> 
> This point was made in the presentation - which itself is 
> available online. The contents of the presentations are 
> therefore not intended to be captured in the minutes - but 
> rather the minutes are intended to capture what was said 
> during the meeting in the discussion of the presentations.
> 
> Responding to your statement as a continuation of your 
> argument in favor of the draft, I do not agree with this 
> point. What is needed to "increase compatibility" is for all 
> implementations to follow the existing normative statements 
> in the specification - not to invent some new normative 
> behavior - which requiring checksum calculation on a zero 
> remaining lifetime LSP would be. This is the substance of a 
> number of responses made during the meeting i.e. the only 
> change necessary is for the implementations which are 
> non-conformant to be fixed.
> 
>    Les
> 
> > 
> > Best Regards,
> >
> --------------------------------------------------------------
> ---------
> > ---------
> > 
> > Zhenqiang Li
> > 13911635816
> > Department of Network Technology
> > China Mobile Research Institute
> > 2010-04-06
> > _______________________________________________
> > Isis-wg mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/isis-wg
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

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
> 
> 
> [email-masked] 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
> > 收件人： [email-masked]
> > 抄送： 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
> >
> > [email-masked] 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:[email-masked]]
> >>> 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
> >>> 收件人： [email-masked]; 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: [email-masked] 
> [mailto:[email-masked]] On
> >>>   > Behalf Of [email-masked]
> >>>   > 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 [email-masked] 
> 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; [email-masked]
>;
> >>> isis-wg
> >>>   > 抄送： [email-masked]; 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:[email-masked]]
> >>>   >    > Sent: Tuesday, March 02, 2010 12:56 AM
> >>>   >    > To: Les Ginsberg (ginsberg); Tony Li; 李振强; isis-wg
> >>>   >    > Cc: [email-masked]; 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)"     
> <[email-masked]    >
> >>>   >    > To: "shengcheng"     <[email-masked]    >; "Tony Li"
> >>>   <[email-masked]
> >>>   >    >;
> >>>   >    > "李振强"     <[email-masked]    >; 
> "isis-wg"     <isis-
> >>> [email-masked]
> >>>   >    >
> >>>   >    > Cc:     <[email-masked]    >; 
> "adrian.farrel"
> >>>   >    >     <[email-masked]    >; "Li Lianyuan"
> >>>   >    >    <[email-masked]    >; "Dan King"  
>    <[email-masked]
> >>>   >
> >>>   >    > 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:[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     >    > 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"     <[email-masked]  
>   >     >    > To: "Les
> >>> Ginsberg
> >>>   >    > (ginsberg)"     <[email-masked]    >; "李振强"
> >>>   >    >     >    >     <[email-masked]    
> >; "isis-wg"     <isis-
> >>> [email-masked]    >
> >>>   >    >    >    > Cc:     <[email-masked]  
>   >; "adrian.farrel"
> >>>   >    >     >    >     <[email-masked]    >; 
> "Li Lianyuan"
> >>>   >    >     <[email-masked]    >;
> >>>   >    >     >    > "Dan King"     <[email-masked]   
>  >     >    > 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
> >>>   >    >     >    >     > [email-masked]
> >>>   >    >     >    >     > 
> https://www.ietf.org/mailman/listinfo/isis-wg
> >>>   >    >     >
> >>> 
> --------------------------------------------------------------------
> >>> ----
> >>>
> >>> _______________________________________________
> >>> Isis-wg mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/isis-wg
> >>>     
> >>>       
> 
> 

--------------------------------------------------------------------------------

Zhenqian Li
13911635816
Department of Network Technology
China Mobile Research Institute
2010-05-28

--------------------------------------------------------------------------------

发件人： [email-masked]
发送时间： 2010-05-28 02:59:30
收件人： [email-masked]
抄送： 
主题： Isis-wg Digest, Vol 73, Issue 17

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/isis-wg

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.

Send Isis-wg mailing list submissions to
[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
https://www.ietf.org/mailman/listinfo/isis-wg
or, via email, send a message with subject or body 'help' to
[email-masked]

You can reach the person managing the list at
[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Isis-wg digest..."

Today's Topics:

   1. Regarding draft-li-isis-error-lsp-processing-03 (Christian Hopps)

----------------------------------------------------------------------

Message: 1
Date: Thu, 27 May 2010 09:28:29 -0400
From: Christian Hopps  <[email-masked] >
Subject: [Isis-wg] Regarding draft-li-isis-error-lsp-processing-03
To: "[email-masked] list"  <[email-masked] >
Cc: Christian Hopps  <[email-masked] >
Message-ID:  <[email-masked] >
Content-Type: text/plain; charset=us-ascii

[sorry for being late on this folks]

Regarding draft-li-isis-error-lsp-processing-03  

During the IETF-77 isis-wg meeting, after a good amount of opinions were expressed, the in-room consensus was to not accept the draft as a WG document. Before this can be considered the official WG position; however, the mailing list needs to be consulted.

Considering the opinions recorded in the minutes, are there any new points or opinions that people would like to express on the list, or should the consensus from IETF-77 hold?

Thanks,
Chris & Dave.

------------------------------

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

End of Isis-wg Digest, Vol 73, Issue 17
***************************************

---

From: mike shand <[email-masked]>
Date: Fri, 28 May 2010 09:57:40 +0100

What I see in the transcript below, other than the views of the authors,
is repeated statements of the views of Les and myself which can be
summarised as

1) The existing specifications are both clear and correct
2) There is no need to introduce a change to the requirements for
checksum computation
3) To make such a change is likely to introduce more confusion, both
from a specification and an implementation point of view.
4) The existing incorrect implementations should be fixed

The only support I see is for the purge identification TLV, which is
proceding as a seperate draft.

Mike

-- 
For corporate legal information go to:
www.cisco.com/web/about/doing_business/legal/cri