Subject: [Isis-wg] IS-IS Reason TLV draft-aravind-isis-reason-tlv-00

From: <[email-masked]>
Date: Tue, 18 Nov 2014 09:41:26 +0530

Hi All,

Proposed a mechanism to advertise the reasons for generation of new Link State Packet (LSP) Updates using Reason TLVs.

Kindly let me know your valuable comments.

Name:           draft-aravind-isis-reason-tlv
Revision:       00
Title:          IS-IS Reason TLV
Document date:  2014-11-17
Group:          Individual Submission
Pages:          6
URL:            http://www.ietf.org/internet-drafts/draft-aravind-isis-reason-tlv-00.txt
Status:         https://datatracker.ietf.org/doc/draft-aravind-isis-reason-tlv/
Htmlized:       http://tools.ietf.org/html/draft-aravind-isis-reason-tlv-00

Thanks,
S. Aravind Prasad

---

From: "Osborne, Eric" <[email-masked]>
Date: Tue, 18 Nov 2014 22:01:37 +0000

I don't see the value in this.

i) Link state protocols are to tell everyone things everyone needs to know. Does every router in the network need to know the cause code for every LSA generated by a single node?  What would these nodes do with it that an NMS wouldn't?  

ii) The dampening thing seems perilous.  What happens if some edge boxes don't support reason-based dampening but core boxes do?  All sorts of bad stuff, that's what.  What's wrong with just implementing dampening as a feature on the box which would otherwise flood the change?

iii) 'easy debugging' seems speculative at best.  Why do all nodes need to know what's going on with every node in the level?  I get that it's nice to have all debugs go to a single place, but it seems much more useful to have some sort of central NMS do this.  In the spirit of the current fad, perhaps a YANG model with an oper section that's sent up to a netconf server.  Or perhaps some sort of simple network management protocol of some sort....if only we had a good name for one...perhaps it could send Transit Router Alert Packets [TRAPs] with this sort of cause code....

iv) Back to the top, " crucial decisions like running SPF calculations could be done more efficiently and with less processing overload".  Do you have data that says that your way is more efficient?  Do you have data that says that the current way of doing things is inefficient enough to fix?  I admit to not being neck deep in the specifics of ISIS TLV handling, but it sounds like what you're suggesting is essentially a back door around the current LSP format.  If this is really a problem you should solve it in the base protocol, not by adding additional information that needs to be flooded and parsed and reconciled.

eric

> -----Original Message-----
> From: Isis-wg [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, November 17, 2014 11:11 PM
> To: [email-masked]
> Subject: [Isis-wg] IS-IS Reason TLV draft-aravind-isis-reason-tlv-00
> 
> Hi All,
> 
> Proposed a mechanism to advertise the reasons for generation of new Link
> State Packet (LSP) Updates using Reason TLVs.
> 
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 20 Nov 2014 03:45:35 +0000

+1

I don't see that the proposal solves any existing problem - and it creates problems by unnecessarily adding to the amount of information contained in LSPs and creating ambiguity (should I believe the description of what changed or the actual changes themselves?)

The premise in Section 2.1 is that a "description" of what changed in an LSP would somehow save processing time in the receiving nodes. But since in order to correctly update my forwarding tables the receivers have to process the neighbor/reachability onformation TLVs in the LSP all processing the description does is add to the processing load. Can the author empirically demonstrate the savings by implementing the proposal and comparing performance?

The premise in Section 2.3 seems to be that it is more efficient to send an update with an explanation to ignore it  than it is to simply send no update at all. And once having sent a transient update it then becomes necessary to send a second update which restores the reachability information which was removed.  Do we then need a revised description to assure us that the second update reresents no change from the N-2 state that existed before the transient update? And of course we can't verify  that the latest update is the same as the N-2 state unless we have retained multiple old versions - thus bloating the memory consumed by the LSPDB.

The premise in Section 2.4 is that receivers require the textual description in order to output meaningful debugs as to what has changed in an LSP update. But many implementations do a quite fine job of this today - and they do it as a side effect of the necessary parsing of the LSP contents.

It is quite tempting to become sarcastic here - but for once I'll restrain myself and simply echo Eric's words - "I don't see the value of this."

   Les

> From: Isis-wg [mailto:[email-masked]] On Behalf Of Osborne, Eric
> Sent: Tuesday, November 18, 2014 2:02 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] IS-IS Reason TLV draft-aravind-isis-reason-tlv-00
> 
> i) Link state protocols are to tell everyone things everyone needs to know.
> Does every router in the network need to know the cause code for every
> LSA generated by a single node?  What would these nodes do with it that an
> NMS wouldn't?
> 
> ii) The dampening thing seems perilous.  What happens if some edge boxes
> don't support reason-based dampening but core boxes do?  All sorts of bad
> stuff, that's what.  What's wrong with just implementing dampening as a
> feature on the box which would otherwise flood the change?
> 
> iii) 'easy debugging' seems speculative at best.  Why do all nodes need to
> know what's going on with every node in the level?  I get that it's nice to
> have all debugs go to a single place, but it seems much more useful to have
> some sort of central NMS do this.  In the spirit of the current fad, perhaps a
> YANG model with an oper section that's sent up to a netconf server.  Or
> perhaps some sort of simple network management protocol of some
> sort....if only we had a good name for one...perhaps it could send Transit
> Router Alert Packets [TRAPs] with this sort of cause code....
> 
> iv) Back to the top, " crucial decisions like running SPF calculations could be
> done more efficiently and with less processing overload".  Do you have data
> that says that your way is more efficient?  Do you have data that says that
> the current way of doing things is inefficient enough to fix?  I admit to not
> being neck deep in the specifics of ISIS TLV handling, but it sounds like what
> you're suggesting is essentially a back door around the current LSP format.
> If this is really a problem you should solve it in the base protocol, not by
> adding additional information that needs to be flooded and parsed and
> reconciled.
> 
> 
> 
> 
> eric
> 
> 
> 
> 
> > URL:            http://www.ietf.org/internet-drafts/draft-aravind-isis-reason-
> tlv-
> > 00.txt

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Thu, 20 Nov 2014 14:28:42 +0000

++1 - I certainly don¹t want to see the equivalent OSPF draft ;^) If there
is any requirement, it is I2RS exposure of a standard LSP change and SPF
run wrapping log. I know I¹ve found the proprietary wrapping logs quit
useful in debugging OSPF problems.

Thanks,
Acee 

On 11/19/14, 10:45 PM, "Les Ginsberg (ginsberg)" <[email-masked]>
wrote:

>+1
>
>I don't see that the proposal solves any existing problem - and it
>creates problems by unnecessarily adding to the amount of information
>contained in LSPs and creating ambiguity (should I believe the
>description of what changed or the actual changes themselves?)
>
>The premise in Section 2.1 is that a "description" of what changed in an
>LSP would somehow save processing time in the receiving nodes. But since
>in order to correctly update my forwarding tables the receivers have to
>process the neighbor/reachability onformation TLVs in the LSP all
>processing the description does is add to the processing load. Can the
>author empirically demonstrate the savings by implementing the proposal
>and comparing performance?
>
>The premise in Section 2.3 seems to be that it is more efficient to send
>an update with an explanation to ignore it  than it is to simply send no
>update at all. And once having sent a transient update it then becomes
>necessary to send a second update which restores the reachability
>information which was removed.  Do we then need a revised description to
>assure us that the second update reresents no change from the N-2 state
>that existed before the transient update? And of course we can't verify
>that the latest update is the same as the N-2 state unless we have
>retained multiple old versions - thus bloating the memory consumed by the
>LSPDB.
>
>The premise in Section 2.4 is that receivers require the textual
>description in order to output meaningful debugs as to what has changed
>in an LSP update. But many implementations do a quite fine job of this
>today - and they do it as a side effect of the necessary parsing of the
>LSP contents.
>
>It is quite tempting to become sarcastic here - but for once I'll
>restrain myself and simply echo Eric's words - "I don't see the value of
>this."
>
>   Les
>
>
>> > URL:          
>>http://www.ietf.org/internet-drafts/draft-aravind-isis-reason-
>> tlv-
>> > 00.txt
>> > Status:       
>>https://datatracker.ietf.org/doc/draft-aravind-isis-reason-tlv/
>> > Htmlized:     
>>http://tools.ietf.org/html/draft-aravind-isis-reason-tlv-00
>> >
>> >
>> > Thanks,
>> > S. Aravind Prasad