Subject: Re: draft..ospf-congestion-control-00.txt : 4.1.1

From: "Manral, Vishwas" <[email-masked]>
Date: Fri, 26 Apr 2002 08:11:41 -0400

Hi Mitchell,

Thanks a lot for the comments. My comments are inline prefixed with a "VM>".

Thanks,
Vishwas

-----Original Message-----
From: Erblichs [mailto:[email-masked]]
Sent: Friday, April 26, 2002 12:45 AM
To: [email-masked]
Subject: draft..ospf-congestion-control-00.txt : 4.1.1

  My comment on section 4.1.1

  1) "router goes down and comes back up again"
  A) If the new state of the neighbor is "down", then the RFC specifies
  to discard the resources associated with the neighbor.

  A new possible state of "zombie" (inherited from the UNIX OS)
  could keep some information from this now dead neighbor could be
  used to identify that this neighbor went down or is possibly
  unstable.

  Yes, additional CLI configuration commands and a timer would then be
  necessary to free the zombie neighbors after they have been down
  for x period of time. You could also do some special processing of
  router neighbors that return from the zombie state.

VM> The section generally talks about throttling setup of adjacencies, so
the talk may not be absolutely relevent here. However not continuously
allocing neighbour resources and freeing certainly helps in case we know the
link/neighbor is flapping, we could however instead try to curtail effects
neighbor flaps/link flaps at a lower layer itself. I however know some
implementations, that keep the neighbors for some time before deleting them.

By the way is the reference to discard neighbor resources RFC2328. Could you
point me to the section this information is there?

  B) If the new state is lesser than the oldstate, then new fields
  would be necessary to identify whether the oldstate was FULL or
  2-WAY.. And again todo the necessary work in the future. It is
  possible to then only mark some type of work and being delayed
  until some time in the future (assuming that the 2-way or full
  will return in just a short period of time).

  MAX_ADJ_BUILD_COUNT
  1) My suggestion is to use a time field here to identify if and when
  this value was reached and how long it is relevent. This time
  field will determine whether this just a burst (transient) of new
  adjs (2-way or full ) or a sustained problem.

VM> Yes, we can do that, however we have tried to get maximum mileage by
doing the minimum.;-)

  2) Low Watermark value:
  With most threshold values, it is sensible to impliment a low-watermark
  type value that may be derived from the high-watermark value. This
  could be imlimented here by waiting for the MAX_ADJ_BUILD_CNT to
  drop to the low-watermark value before allowing new building of
  adjs back to the high watermark value. Then if the transition moves
  from high to low and back to high, the router would then know that
  there is still a sustained amount of work involved to finish building
  all the adjs.
VM> This sounds like a good idea. I will study the idea further and add it
to the draft.

  nit within 4.1.2 right now--
  [RFC2474] :::: I don't see it listed in the section 8 referenes..

VM> We will add it as reference.

Thanks again.