Subject: RE: [Isis-wg] Meeting minutes ...

From: "DUBOIS Nicolas FTRD/DAC/ISS" <[email-masked]>
Date: Wed, 14 Aug 2002 14:27:30 +0200

My understanding is that:

	- Such a mechanism would be useful on unreliable links such as
satellite ones.
	- Such a mechanism would help accounting the time the link was
unreliable and not useful for traffic from the control plane point of
view. You could log the missed sequence number and time somewhere. It
could help detect that one link is too unreliable for control plane
traffic before breaking this control plane traffic and causing
instability in the network.
	- It could be an indicator of control plane health on high
quality link.	
	- Such a mechanism would help on complex broadcast subnets and
parralel links where you do not always understand what is happening. It
could detect duplicate hello packets for example.

For the technical and political details I don't know, even though it
doesn't seem very complicated to implement.

I think it would be useful in our networks, but this doesn't mean we
would use it. There are so many useful refinements in IP that you can't
choose which ones you should use ... 

Best regards,

Nicolas

-----Message d'origine-----
De : Naiming Shen [mailto:[email-masked]]
Envoye : mercredi 14 aout 2002 00:43
A : Dave Katz
Cc : [email-masked]; [email-masked]
Objet : Re: [Isis-wg] Meeting minutes ... 

Without trying to get into the details...

 ] 
 ] It's a simple enough proposal, and as such I really don't care that
 ] much about it (the additional complexity added is almost
 ] unmeasurable), but without a really compelling argument of its
 ] usefulness it does not seem a good candidate for expending time and
 ] trees (or oxide particles) to get it through standardization.

If asked if there is a really compelling reasons for this
seq# draft, I actually can not think of any myself.

I think everything in this scheme can be achieved somehow by the
existing tools/utility/etc. For example, this seq# can detect
exactly when and how many IIH packets being lost in particular
interface/adjacency. We of course can achieve this by log-on/snmp-get
stats on every router/every link/every minutes to get the same info.
But to have a mechanism to be "event driven" is also nice. Sometimes
we discover problems by surprise. Wouldn't it be nice to find why
one particular adj loss is high than just assume everything must be
fine(assume adj didn't bounce)? but those things may not be
classified as "compelling" though.

thanks.

 ] 
 ] I'll happily switch sides if somebody can show me something
compelling
 ] and concrete that this will gain us; my intuition is not known to be
 ] infallible.
 ] 
 ] --Dave

- Naiming

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

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

---

From: Tony Przygienda <[email-masked]>
Date: Wed, 14 Aug 2002 09:20:14 -0700

>doesn't seem very complicated to implement.
technically is very simple to do (and optional anyway)

politically this group has always had the philosophy of airing the 
politics on the list, albeit
sometimes in the background a first round of 'densification' by relevant 
parties was happening
to not let the list run wild ...  At least that's my perception.

so none of the above has an implication of whether it will happen or 
not, the issue is
purely whether there is enough merit to justify doing it.

    -- tony