Subject: RE: [Isis-wg] Point to point adjacency down.

From: ramanathan ramasamy <[email-masked]>
Date: Fri, 11 Jan 2002 10:19:42 -0800

hi all,

     I agree with Mr. Jeff,  we could see the inconistency in the database 
because of delaying the SPF computation and it will lead to incorrect 
routing for the packets arriving during that period of time. So it is 
better to have a standard governing thinks like this. The same problem 
could occur in OSPF also, there is no mib variable governing the SPF 
calculation. If we introduce this variable in ISIS, we can improve the 
convergence in ISIS. If a service provider deploys ISIS routers from 
different vendors, this problem may be a big bottle neck.

Thanks
rams.

-----Original Message-----
From:	Jeff Parker [SMTP:[email-masked]]
Sent:	Friday, January 11, 2002 11:23 AM
To:	'Tony Przygienda'; Dave Katz
Cc:	[email-masked]
Subject:	RE: [Isis-wg] Point to point adjacency down.

> > This strays into the area of creative implementation possibilities.
> > I suspect that a MIB variable with a scalar value that is expected
> > to be stable does not accurately represent either of the dominant
> > implementations.
>
> It is superfluous, restricting and confusing to try to
> govern internal implementation details ...
> correct ISIS packets to the wire [is our only goal]
>
>     -- tony

Tony -
	I can accept that this is off task behavior, but I
must ask a clarifying question.

	Don't we have more to do that generate and consume
IS-IS packets?  Don't we also need to produce consistent
routing tables for the two letter protocol?

	If we let SPF computations run without check, or
delay SPF computations unduly, doesn't that effect
convergence adversly, through slow flooding in the
first case, and slow updates to our tables in the
second.

- jeff parker
- axiowave networks
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

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

---

From: Dave Katz <[email-masked]>
Date: Fri, 11 Jan 2002 14:15:28 -0800 (PST)

Sorry, no.  All you will do is either penalize the vendors who know
how to do this stuff well (and who will simply ignore the standard
based on competitive reasons) or you will penalize the vendors who
cannot do it well enough (who will ignore the standard based on
practical reasons.)  Smart vendors will provide enough configuration
flexibility to work well with the least common denominator.

Synchronized SPFs are a fiction in a network of any significant size
anyhow.

It is foolish to attempt fix *perceived* operational problems by
attempting to standarize out of them, when such a standard, if adhered
to, would create other operational problems.  Furthermore, as Dave
Oran was fond of noting, for every 100 possible random knob settings
in a router, only 1 actually results in a functional network.  Things
like this are best left to the operators to decide whether or not
they have a problem, and to work with their vendors to ameliorate
the problem if in fact one exists.

--Dave

---

From: Alex Zinin <[email-masked]>
Date: Fri, 11 Jan 2002 15:39:29 -0800

Just to make sure we're on the same page,
*specifying* how SPF should be scheduled is useless as Tony
and Dave explained. Giving clue in an informational form
might help people who are new to the topic do things not
as bad as they could be done (yes, there are much more places
besides this where one can stumble).

MIB-wise, if you don't know semantics of a specific value
from a specific vendor, it is useless at least in case
of that specific vendor, don't know how about others...
But again, I would care if I actually used MIBs to
configure routers :)

-- 
Alex Zinin

---

From: "David R. Oran" <[email-masked]>
Date: Wed, 16 Jan 2002 14:40:20 -0500

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dave Katz
> Sent: Friday, January 11, 2002 5:15 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Isis-wg] Point to point adjacency down.
>
[snip]

> It is foolish to attempt fix *perceived* operational problems 
> by attempting to standardize out of them, when such a 
> standard, if adhered to, would create other operational 
> problems.  Furthermore, as Dave Oran was fond of noting, for 
> every 100 possible random knob settings in a router, only 1 
> actually results in a functional network.  

For completeness, I feel compelled to state the full version of Oran's
law of tuning parameters:

"There are three types of tuning parameter:
1. Those for which all settings produce identical behavior
2. Those for which only one setting works
3. Those which control whether another tuning parameter operates as type
1 or type 2."

Dave O.

> Things like this 
> are best left to the operators to decide whether or not they 
> have a problem, and to work with their vendors to ameliorate

---

From: Dave Katz <[email-masked]>
Date: Wed, 16 Jan 2002 22:23:49 -0800 (PST)

Much more succinct than my version, thanks.  ;-)

   X-JNPR-Received-From: outside
   From: "David R. Oran" <[email-masked]>
   Cc: <[email-masked]>
   Date: Wed, 16 Jan 2002 14:40:20 -0500
   Organization: Cisco Systems
   Content-Type: text/plain;
	   charset="us-ascii"
   X-Priority: 3 (Normal)
   X-MSMail-Priority: Normal
   X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
   Importance: Normal
   X-OriginalArrivalTime: 16 Jan 2002 19:40:09.0609 (UTC) FILETIME=[9B679F90:01C19EC5]

   [snip]

   Dave O.