Subject: [Isis-wg] ISIS as Pack Mule?

From: David Hudek <[email-masked]>
Date: Tue, 14 Aug 2001 15:35:56 -0700

For various reasons, there would appear to be a growing
trend of having ISIS act as a convenient flooding mechanism 
for conveying different types of information that is
essentially a "dont-care" for ISIS itself. Draft RFCs call
for data to be added to LSPs that may be of interest to other
entities, such as GMPLS or a constraint based SPF, but would
not make any difference to a normal ISIS default metric SPF run.

When that dont-care data changes within an LSP, a straightforward 
implementation that compares a modified checksum and/or does a simple
byte-wise comparison on received LSPs (as mentioned in 10589) would 
detect that LSP data had changed, and schedule what will turn out to be
an unnecessary SPF run. Even if ISIS would prefer not send updated LSPs
very frequently if only non-ISIS data changes, there will be pressure to
act in a timely fashion from the point of view of the other
entities to convey their changed and changing data rapidly.
If this dont-care data changes frequently there would be frequent 
unnecessary SPF runs (gated by whatever SPF pacing scheme one uses). 
As more types of dont-care data is loaded aboard LSPs over time, the 
liklihood of frequent dont-care changes increases. 

Of course, a receiver could actually intelligently parse
each received LSP that differs, comparing fields against the earlier
version, and decide for itself if the changes warrant an SPF run, 
but that seems like a lot of unnecessary extra work given 
that the originator of an LSP ought to know why they are
changing it in the first place and could just simply let everyone
else know. 

I was wondering about the effect of adding a new TLV in which 
the originator could convey that info. It might be as simple as 
a yes/no whether or not any change from the LSP with previous 
seqnum actually mattered to ISIS, or as complex as indicating 
which entity(ies) might be interested in the change, or something 
in-between. 

At first blush, it seems like it would improve scalability,
with the only down-side being some security issues (however,
none seem insurmountable). Folks can continue to load up ISIS with 
data only meaningful to other entities, and the extra burden
would be generally limited to the flooding aspect, not also
unnecessary SPF runs or extra parsing/comparisons. ISIS could even
act more responsively to dont-care data changes, updating LSPs
somewhat more frequently since their effect would be somewhat mitigated.
So of course, the question arises, what's the horrible
fatal flaw that's not jumping out just yet?  :-)
Is this something worth pursuing?

Thanks,
dave h
[email-masked]
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 14 Aug 2001 13:21:19 -0700

> which entity(ies) might be interested in the change, or something

The above has been proposed for PNNI years ago which had a somehow similar
problem (lots of QoS metrics that when changed will not necessarily
trigger computations) and it has not been well received due to several
reasons.  One of them being that to do things well you need basically
a bitfield @ every TLV, sub-TLV, sub-subTLV level which is not very
convienent and leads to a complex, easily broken representation.
The other problem being that just missing one of those
something-changed-bits can lead to catastrophic failures easily that are
very hard to track
down. Philosophically, it is not a good idea to put redundant data into
the protocol messages since you have to account for behavior when
the data contradicts itself. Messy stuff ...

At least one leading vendor implemented the 'smart parse & figure out
changes' thing and
it worked very well without a lot of CPU overhead. Yes, some tricky
code is involved but that's how protocol implementors make their
living and vendors differentiate themselves ...

I guess I'm saying my initial reaction is that's an implementation
specific thing which we don't  govern in the workgroup normally.

    thanks

    -- tony