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

From: Naiming Shen <[email-masked]>
Date: Mon, 12 Aug 2002 16:41:03 -0700

] Dave indicated that he felt the rough consensus was to not take it on as 
 ] workgroup item. Any contradicting opinions please to the mailing list.
 ] 

I obviously have some "contradicting opinions", sorry forgot to
respond to this email thread sooner. I think we need to ask ourselves
that:

  1) if there is a problem?
  2) if yes, then if this is the right approach?

For the first one, I think we currently don't have enough information
in the IGP to effectively troubleshoot adjacency problems, and IGP
adjacency is an important part of network stability. I often get
reports asking routerX adjacencyY was down two hours ago, why? My
response usualy would be: I don't know why. It could be routerX had
problem, or it's neighbors, or it could be protocol packets were
dropped due to congestion somewhere. If we can know where the
problem is, then we might know the solutions either in improving
network design, changing configuration, or tuning implementation.
This sequence number scheme gives us: a) it indicates clearly if
there is protocol packet loss; b) (not currently in the draft, but
should be added) it indicates if neighbors send us IIH on time.
c) (optionally) base on "a" and "b", an implementation can optionally
adjust the holddown in order to avoid a premature adjacency bounce.

This seq# sheme can also help ISPs to determine good configuration
settings on routers. For example, we always wondering: how low should
we set the holddown time(hello-interval plus the multiplier). If we
have a history of IIH loss stats plus the neighbors IIH slip history,
then it's an easy task to determin intervals among the adjacencies
on specific interfaces.

For the second question, my opinion is that, this seq# scheme is
a very simple mechanism, very cheap in terms of implementation and
router resources. also, it does not have to be a "always-on" scheme,
it can be turned on as needed if so desired by implementations.
i don't buy the argument that this can be accompulished by utilities
such as "telnet" or "snmp";

An alternative of course can be a new and generic "link adjacency"
protocol which is not specific to isis or ospf. I think
unless IGP/LDP/etc can use this new "link adjacency" protocol or
piggyback on this protocol, there is an extra hello protocol on
the router needs to be maintained, that may not be a good thing;
also the relation of this new protocol and IGP adjacency problem
is an indirect one, its not as good as the information is within
the IGP itself. For example, if this new protocol delays sending
out packets for a couple of minutes does not necessarily mean
the IGP process also delays for that long. Since this seq# mechanism
is so cheap, why not use it now.

again, we welcome for the discussions on this topic and we want
to ask the working group to accept this as wg document.

thanks.

 ] >
 ] >
 ] > 9) adding Sequence Ids to Hello packets
 ] >
 ] >    Discussion prior to presentation:
 ] >     Chair requested the number of people who read draft: 10 (estimate)
 ] >     Chair determined we should go on to discuss the draft.
 ] >
 ] >    IIH sequence number
 ] >
 ] >    motivation: 1) large of adjacencies
 ] >                2) hold-down timer is low for fast convergence
 ] >            3) congestion over the link
 ] >            4) router process scheduling slips
 ] >            5) massive LSP flooding
 ] >
 ] >     Who's fault is the fluctuation of the links.
 ] >
 ] >   Addition:  new TLV in Hello packet that has sequence number
 ] >
 ] >   Benefit:
 ] >       1) p2mp - if only one receiving router has seq# skips,
 ] >         probably an inbound congestion issues;
 ] >
 ] >         if all the receiving routes for the same router have
 ] >          seq # skips, probably the sender is not sending out
 ] >         the hello packet at the same time
 ] >
 ] >       2) [need the rest of the information here]
 ] >
 ] >
 ] >    purpose:
 ] >      1) mostly NM usage
 ] >      2) adjust the hold time timer to prevent premature adjacency flap
 ] >
 ] >
 ] >     format of the TLV:  Code: 241
 ] >             length: 4 octets
 ] >             value: a 32 bit unsigned number, 0xfffffff[all ones] reserved
 ] >
 ] >       Each level needs to keep sequence number space.
 ] >
 ] >     discussion from list: sub-TLV - for this sequence number is 
 ] > expendable
 ] >               sub-tlv - to indicate time lasp since last IIH or % of 
 ] > interval
 ] >                     this is symmetrical to the sequence # skip for auto
 ] >                     hold-down time adjust.  If one knows the neighbor has
 ] >                     repeated scheduling slips, it an optionally do 
 ] > something
 ] >                     to prevent an adjacency flap
 ] >
 ] >    request: to be a working group
 ] >    Decision:  this draft is not ready to be working group draft
 ] >
 ] >    Discussion:  We do not need sequence IDs to add to hello packets.
 ] >
 ] >         If you receive packets and not other, it may be important to 
 ] > drop the packets.
 ] >
 ] >         [Naiming shen]  It is not a protocol, but an implementation 
 ] > issue on how
 ] >                 to determine the link is down.
 ] >
 ] >         If you have lots of interfaces on the box, you minimize the 
 ] > hello packet
 ] >         processing.
 ] >
 ] >         [Naiming shen]  That's one opinion. Another is send as fast as 
 ] > possible.
 ] >                 This proposal is very simple and does not take much time.
 ] >
 ] >         [Stephen] This is trouble shooting the link and the box.
 ] >
 ] >         [namining shen] We do not have the tools today, and this gives 
 ] > some additional
 ] >                     tools.  It is not a high price.  authentiation
 ] >
 ] >         [Stephen] This is a high price for the additional tool.
 ] >
 ] >         [Ed Kern] this is cranking the complexity knob to solve an 
 ] > edge problem.
 ] >
 ] >         [Naiming Shen] - This is a configuration problem. This is very 
 ] > cheap tradeoff
 ] >                  for trouble-shooting.
 ] >
 ] >         [Ed kern] authentication is required.  This doesn't tell you 
 ] > what the problem
 ] >               is exactly it.  I feel the complexity is increased?
 ] >
 ] >         [Amir] As a sequence number, it is cheap.  However, this is 
 ] > may not be
 ] >             the right direction.  This focus on the link protocols 
 ] > should not
 ] >             come from the is-is working group.  This focus should come 
 ] > from
 ] >             another working group.
 ] >
 ] >         [naiming] A problem on the adjacency is urgent due to fast 
 ] > convergence issues.
 ] >
 ] >         [dave] - You are assuming a trust model with the adjacencies; you
 ] >              have
 ] >
 ] >         [kareeti/dave] It is less expensive to use telnet to debug.
 ] >
 ] >         [xxx] replay attack is a concern. [dave ward] IP sec protects 
 ] > against
 ] >             this feature.  Any additions should await the RP-Sec 
 ] > information.
 ] >
 ] >         [Dorian Kim] This has a good feature, but there are other 
 ] > existing tool that can solve this problem in a network.  As operators 
 ] > we have enough  crud in the routing code.  This feature does not 
 ] > really buy you enoug to add more complexity to the routing system.
 ] 
 ] 
 ] Dave indicated that he felt the rough consensus was to not take it on as 
 ] workgroup item. Any contradicting opinions please to the mailing list.
 ] 

- Naiming

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

---

From: Dave Katz <[email-masked]>
Date: Mon, 12 Aug 2002 18:18:29 -0700 (PDT)

This option is pretty low-overhead, but as such it is also
semantically challenged.  It seems to be most useful on true
multipoint circuits, but the number of those as a percentage of the
ISIS-enabled interfaces in the world would seem to be a small
minority.

If ISIS implementations are done properly, Hellos should not languish
in queues, the incidence of late Hellos (which, after all, typically
average 12.5% *early*) should be roughly zero, and long run-times
affecting adjacency maintenance should also be a thing of the past in
the dominant implementations (if I understand what the Other Guys are
doing.)  Hello drops should thus be detectable on a statistical basis
by measuring the interarrival time and ought to be independent of
router CPU load.

I don't see how this is useful in practice for tuning the hello
protocol in any case.  Adjacency drops are deeply anomalous events,
often with very steep onset, and the anomalies are not predictable.
Implementations in which adjacency stability depends on CPU load or
latency are doomed to collapse catastrophically sooner or later, and
trying to be clever about tuning will likely only move you closer to
the cliff.  Those which are independent won't measure much of anything
interesting, since they should only start to reliably drop hellos only
when the hello processing dominates the CPU, which is an untenable
regime in which to operate.

This would seem to reduce the proposal to a form of link quality detection,
which really ought not be part of ISIS.

My two kopeks...

--Dave

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 12 Aug 2002 20:10:23 -0700

Dave Katz wrote:

>semantically challenged.  
<chair hat off>
agreed that it is kind of hard to grasp one's head around what it really 
measures. It is a loss number
delivered by probes stuck into two not very clearly defined points in 
two boxes and/or
probably the link inbetween. But somehow the idea seems intriguing, kind 
of like
peeking at TCP window size, it's an unclear number but indicative of the 
aggregate
network behavior.

>by measuring the interarrival time and ought to be independent of
hmmm, I think your assertion that hellos will not languish in queues is 
a little bit of a jump.
Even in an excellent implementation with a nice load-shedding, once you 
get to the point
where you cannot minimally process things real-time (maybe your box
is doing plenty high priority other stuff and you have so many 
adjacencies that just
sorting things in and out into proper queues/processes/tasks takes 
serious time and maybe
the whole thing is only transitory), all kind of trade-offs
exist as to drop vs. queue. Nothing surprising there, store-and-forward 
vs. hot-potato
vs. preventive drop strategies, every overprovisioned system in control 
theory is in the
same space. So things may languish in queues some and if they share 
queues, those
queues can grow long. But maybe I completely misunderstood what you are 
trying to say.

>often with very steep onset, and the anomalies are not predictable.
Hmm, I tend to slightly disagree here. If you take just ISIS in a box 
and you load it
up smoothly with more and more adjacencies, properly designed 
load-shedding will
start to show a nice increase in drop rate from a certain point in time 
that will be
probabilistically measurable and then such a scheme would allow you to 
get the
probability numbers you need.  However, for an implementation that sheds 
based on
'over X% CPU load, I drop ALL the hello packets' it will be useless. 
Guess my point is,
without having a 'model' of an implementation we can agree on, we may be 
writing
lots of e-mails without ever communicating.

>the cliff.  
yes, at a ceratin point in time _any_ implementation that takes an 
arbitrary amount of
adjacencies will collapse, be it based on CPU overload or by capping off 
the amount
of adjacencies to protect from CPU overload (but even then it will 
collapse, it's a well-known
control theory thing, if you need to classify your input, your system 
will melt at ceratin
point in time).   By collapse I mean ' it does not serve all adjacencies 
anymore '.

>Those which are independent won't measure much of anything
yes, we're in sync here but this is a softer solution space than you 
make it sound.
An implementation could say 'I do hellos and start to drop them from a 
certain queue
length on and I always serve some flooding at lower priority. Once I see 
unatainable amount of
drop statistically per adjacency, I start to be lazier and lazier with 
flooding'. Yes, it's playing the edge
I do _not_ think is worth playing but then this number could be usefull. 
 In principle I guess
I agree with you that optimizing the implementation to the point where 
you start to
walk the chaos boundary *(which this thing ultimately is a tool for) is 
not worth in
this kind of protocols.

>which really ought not be part of ISIS.
yes, that's the main danger here, we start to build link-monitor things 
into a routing protocol
and that has a high potential to embarass us later ...

I guess I'm neither for nor vs. this thing but I find the discussion 
somehow intriguing.

    -- tony

---

From: Naiming Shen <[email-masked]>
Date: Mon, 12 Aug 2002 22:33:00 -0700

Dave,
	thanks for the comments. see replies in inline.

 ] This option is pretty low-overhead, but as such it is also
 ] semantically challenged.  It seems to be most useful on true
 ] multipoint circuits,

even though the draft discussed more cases in LAN, but if the
time info is added to the seq# scheme, it should help both cases.

 ] but the number of those as a percentage of the
 ] ISIS-enabled interfaces in the world would seem to be a small
 ] minority.

it's true that these days, it seems more p2p links for network
interconnections. but the multi-point media is not going away,
some of them even come back(e.g. RPR).

 ] 
 ] If ISIS implementations are done properly, Hellos should not languish
 ] in queues, the incidence of late Hellos (which, after all, typically
 ] average 12.5% *early*) should be roughly zero, and long run-times
 ] affecting adjacency maintenance should also be a thing of the past in
 ] the dominant implementations (if I understand what the Other Guys are
 ] doing.)

now you have made a couple of assumptions:

  - vendors always implementation them properly without cut corners
    for both yourself and your neighbors
  - users are dealing with very reasonable number of adjacencies
  - users are using very "normal" holddown time

but I think this draft are dealing with "problems", especially in
the cases where one of the above may not be true. Even you trust
yourself, how do you prove it is really your neighbor's problem?
the hard thing for troubleshoot adjacency problem is that, either
side can do something wrong.

 ]  Hello drops should thus be detectable on a statistical basis
 ] by measuring the interarrival time and ought to be independent of
 ] router CPU load.

i doubt this is always true. you can know from statistical point
of view if there is packet being dropped, but you can never be
sure it IS dropped or not. what prevents an implementation to
send IIH multiple times during a statistical interval? not much.
just from recording point of view, there is not much you can say
about protocol packets loss or not, especially if the packet loss
rate is small.

 ] 
 ] I don't see how this is useful in practice for tuning the hello
 ] protocol in any case.

Let me just give some examples:

 - some ISPs used to set holddown time rather long, say 1.5 minutes.
   so the questions is with so much changes since the people invented
   this 1.5 minutes number, is it safe to lower it? lower to what?
   with this seq# scheme, it at least give you some history when a
   user start to change the numbers. is there packet loss during the
   busy hours, network churn times, is neighbor's IIH usually sent
   on time, offset by how much? If one has those numbers, they can
   take the conservative approach by setting it to a very safe value.

 - normally, as you mentioned, if the IIH packets are handled properly,
   the loss, delay probability is not high. but in some cases when
   there is large number of adjs or very fast hellos, how much buffer
   space is enough? I'm not proposing to run with huge number of adjs
   or tune down the iih hold time to extreme low, but those things does
   impact the protocol implementations.

 - when vendors/customers do the IGP scalability testing, what do they
   do if the adjacencies start to drop? just stop? that's fine. but there
   maybe some silly mistakes in the code caused this. If you can have
   more info on what's going on, you can get rid of next round of
   bottlenecks to push those numbers further. those data helps to
   implement protocols better.

 ]  Adjacency drops are deeply anomalous events,
 ] often with very steep onset, and the anomalies are not predictable.
 ] Implementations in which adjacency stability depends on CPU load or
 ] latency are doomed to collapse catastrophically sooner or later, and
 ] trying to be clever about tuning will likely only move you closer to
 ] the cliff. 

what your saying is mostly true. but seq# miss, sending time slip
may not necessary mean adjacency drops. If you have high number
of multipliers, maybe it's perfectly ok to have those misses. But
it is also nice to know if there is miss or not, this will be the
first indication to the users/testers of something is stretched too far.

 ] Those which are independent won't measure much of anything
 ] interesting, since they should only start to reliably drop hellos only
 ] when the hello processing dominates the CPU, which is an untenable
 ] regime in which to operate.

I'm not suggest people should detect the boundary, then just set the
settings on those boundaries. I'm saying its nice to know those boudaries,
also users can intelligently use those data to set their comfortable
numbers.

 ] 
 ] This would seem to reduce the proposal to a form of link quality detection,
 ] which really ought not be part of ISIS.

I don't think this seq# scheme is just here for detect line noise or
link congestions. But if we do believe that vendors always implement
properly, or we will only handle some "reasonable" numbers, then I
do agree that there is no place for this scheme.

thanks.

 ] 
 ] My two kopeks...
 ] 
 ] --Dave

- Naiming

---

From: Naiming Shen <[email-masked]>
Date: Mon, 12 Aug 2002 23:02:01 -0700

Tony,

agree with most of your comments.

 ] 
 ] >This would seem to reduce the proposal to a form of link quality detection,
 ] >which really ought not be part of ISIS.
 ] >
 ] yes, that's the main danger here, we start to build link-monitor things 
 ] into a routing protocol
 ] and that has a high potential to embarass us later ...

at least the "iih sending time slip" data has nothing to do with
"link-monitor" things:-) even if this did reduce to a "link-monitoring"
mechanism, this is for our protocol use as long as there is no such
things exist to use, so i don't feel there is something to be embarassed.

thanks.

 ] 
 ] I guess I'm neither for nor vs. this thing but I find the discussion 
 ] somehow intriguing.
 ] 
 ]     -- tony
 ] 
 ] 

- Naiming

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 13 Aug 2002 07:55:40 -0700

>agree with most of your comments.
the further we apart, the more we agree ;-)

>things exist to use, so i don't feel there is something to be embarassed.
It is 'kind' of a link-monitoring mechanism and since this groups knows 
close to zilch about it
(or rather, even if we know anything about link monitoring, it's not on 
_this_ charter ;-) so we may
do lots of amateurish mistakes that will cost us face later. Anyway, 
that's just a marginal political angle,
if it is agreed by customers and major vendors
upon as thing to worth pursuit in this group, we hijack some of the 
necessary talent
to review and nurse it into shape ....

So again, still undecided and waiting for more opinions ...

    thanks

    -- tony

---

From: Dave Katz <[email-masked]>
Date: Tue, 13 Aug 2002 13:26:35 -0700 (PDT)

Mostly I was trying to make a case that measuring interarrival time was
sufficient to guess at packet drop counts, assuming that something useful
can be done with this information (which I don't think is true.)  It's
also the case that significantly late deliveries of Hello packets will
break the protocol, so if the system is architected in such a way that
Hellos can be delivered very late, then it is arguably seriously broken.

This is at the heart of my argument, which is that you can't really model
implementations, and they tend not to do anything smoothly.  If you add
adjacencies until you cannot keep up with the hello load, this tells
you nothing at all about how stable the system will be when something
really bad happens.  I guess my claim is that measuring hello drops
really doesn't tell you anything terribly useful operationally.

I think we're in nonviolent semiagreement here.  My fundamental beef
is this--Hellos should not be a significant load relative to the
overall capacity of the system, because if they are, you are very
likely to collapse when something important happens (like somebody
advertises full routing into their IGP, one of my favorite pissing
match tests, or even something as simple as a router crashing in a
heavily meshed network.)  When things really start to crank, the
(constant) hello traffic will be in the noise relative to the flooding
traffic, and as such is close to useless in being used as a
measurement tool for network size and tuning.  Measuring Hello loss
only tells you about the capacity of the routing system when it is
quiescent, which is both uninteresting and misleading.  Routing protocols
are kind of like aviation--hours of boredom punctuated by moments of
sheer terror.  ;-)

It's just the wrong place for such functionality.

It would be much more interesting to look at link-state retransmission
rates under battle conditions instead if you really want to get a feel
for capacity.

To restate my original argument (now that it's daytime, maybe I'll be
more coherent), the most important task for a router is to send and
receive IGP hellos.  More important than link-state data, more
important than user packets, more important than management.  If a
system is architected in this way, then Hellos will basically never be
dropped unless you're operating the box in a regime that simply will
not work (it has no cycles left to do anything like routing table
calculations.)  For such systems, measuring the drops don't tell you
anything.  If a system is not architected in this way, then the intent
of the proposal seems to be, as you point out, to try to operate
closer to the edge than is currently the case, but the edge has a way
of suddenly running past you, and then your network looks like the
coyote in a Roadrunner cartoon.

Rather than trying to avoid the cliff, design the system so that it
doesn't have a cliff, and you get to work on a whole different set
of issues instead (hopefully less catastrophic ones.)

--Dave

---

From: "Cleve Mickles" <[email-masked]>
Date: Tue, 13 Aug 2002 17:01:32 -0400

This would be a good troubleshooting tool for large ISIS networks
and specifically for point-2-multipoint networks as I( and Naiming)
worked on in our previous lives.

If folks are (or start) using more GbE or 10GbE to interconnect routers
then tracking the hello sequence numbers adds value.  As Route Processors
have increased in CPU power it is not clear how much of a problem dropped
or out of sequence hellos are today.  If it doesn't add much overhead, then
having the option to monitor IIH sequence numbers would be another
tool to ISPs can use to identify which side of an adjacency is having
problems.

Cleve...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Tony Przygienda
> Sent: Tuesday, August 13, 2002 10:56 AM
> To: Naiming Shen
> Cc: Dave Katz; [email-masked]
> Subject: Re: [Isis-wg] Meeting minutes ...
>
>
> Naiming Shen wrote:
>
> >Tony,
> >

Cleve Mickles
Network Architecture
America Online, Network Operations

---

From: Dave Katz <[email-masked]>
Date: Tue, 13 Aug 2002 14:19:48 -0700 (PDT)

This is because we were, um, naive about such things when the code was
written that required such extreme hold times.  The real problem was a
combination of a lack of priority queueing (at the hardware level) for
ISIS packets, lousy prioritization of IIHs versus other ISIS packets
within the protocol implementation, and hello transmission latency
that was affected by CPU load and was essentially unbounded.  Systems
for which these problems are still true are always going to collapse
under load, and IIH loss measurement is not going to avoid this,
because the collapse conditions are (hopefully) very rare and very
anomalous, and as such you are not going to be able to measure or
model them meaningfully.

If you have *any* loss under steady state conditions due to the sheer
number of Hello packets, then you're operating too close to the edge.
It shouldn't be a buffering issue unless your IIH processing latency
is seriously chunky (at which point the buffering requirements are not
predictable anyhow.)

This is much better addressed through instrumentation of the implementation.

High multipliers should never be necessary unless the system has serious
queueing problems;  in fact, most of the time they work against you if
you are taking any significant Hello processing load.

My claim is that the "boundary" that you are really trying to
determine is "how hard can I push the network without it collapsing"
and that such a boundary cannot be determined because it is not fixed.
Furthermore, there are lots of other mechanisms already available for
characterizing performance under load that are independent of the
protocol spec.

    ] 

There are a couple of issues intermixed here, I think.

One issue is to try to track dropped IIHs.  This can be done by other
means (pulling xmit stats from one side and rcv stats on the other,
for example, or measuring the baseline arrival rate and then seeing
how it is affected by load) albeit not at the level of granularity
that this scheme would provide.  I would make the brash and not
particularly supportable claim that the high granularity comes with
little benefit, but that's my opinion.

Another issue is whether tracking dropped IIHs to a high granularity
is operationally useful.  I just don't see this, and none of the
examples given seem (to me) to be compelling.  Further, it will give
customers a false impression that it actually *is* useful, and
somebody will doubtlessly twist knobs in unreasonable ways, see that
there is no drop, and then get very upset when their network has
problems.

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.

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

---

From: Dave Katz <[email-masked]>
Date: Tue, 13 Aug 2002 14:31:43 -0700 (PDT)

If you can get a statistical approximation of the drop rate per
neighbor without changing the protocol, would that suffice?
Presumably, knowing that one or two hellos disappeared into the void
is not interesting, but 5 or 10 percent would be.  This should be easy
to do without torquing the protocol spec.

---

From: Tony Przygienda <[email-masked]>
Date: Tue, 13 Aug 2002 14:47:58 -0700

>really doesn't tell you anything terribly useful operationally.
Practically speaking (many more things than just ISIS on the box, data 
on same link as control)
you are of course right.  So far the only good link-state models I saw 
were limiting themselves to only
a single protocol on the box and albeit neat, the output of this kind of 
work was of academic
interest only (so far).

>quiescent, which is both uninteresting and misleading.  
>

>Routing protocols
Only if you deploy them, if you just hack them and other people deploy 
them for you, it's
like building planes, most of the time you have fun ;-)

>of issues instead (hopefully less catastrophic ones.)
I slowly start to see which corner of the world you are coming from. 
Yes, we are in a semi-agreement,
I am a little bit more tempered than you are in terms of conclusions you 
drew through the years (going from
no-priotization to all hellos always first) since from control theory I 
took with me that you should
build priotized systems but that you shall also avoid starvation of 
lower priority packets and you should start to
shed load way before you going into overload conditions. Given those 
kind of designs, hello
losses can signal upcoming overload way before you start to walk the 
chaos boundary (which as
you say strikes on unpredictably and in places one often doesn't expect) 
and
tell you possibly usefull things.

I deduct we are in full agreement that it is hard to actually tell 
'WHAT' this number is telling you and
whether the reasons Naiming/Cleve brings up makes it worthwile to twist 
the protocol in this direction.
And what troubles me more and more: is it even an 'interoperability' 
problem and therefore in the scope
of this group?

Speaking of which: what would be your alternative to measure the point 
at which you would decide
that the protocol 'melted down' and one should start to back-off timers, 
increase buffers or not run that
many adjacencies?

    -- tony

---

From: Naiming Shen <[email-masked]>
Date: Tue, 13 Aug 2002 15:43:15 -0700

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

---

From: Henk Smit <[email-masked]>
Date: Thu, 15 Aug 2002 05:12:32 +0200 (CEST)

> which really ought not be part of ISIS.

  Cool ! You must have changed your view on the issue of IGP and
 link quality detection. ;-)

  Can we now get rid of that fugly proposal for IS-IS and jumbo frames
 over GigE ? Or is it an RFC already ? I always have understood that
 the reason for that draft was that UUnet and Juniper thought IIHs
 *had* to be mtu-sized, or else the quality of the ethernet link was
 not guaranteed ? That draft added a lot of extra complexity, and all
 you get back is a little extra "link quality detection".

  So if we don't need "link quality detection" in our IGPs, then I assume
 we don't need jumbo ethernet frames for IS-IS either .....

  :p

     Henk.