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

From: Jeff Parker <[email-masked]>
Date: Fri, 11 Jan 2002 10:31:17 -0500

> Is there anything specified in 10589 regarding when to run 
> the decision process once an adjacency goes down?
> 
> rams.

The adjacency down event should trigger the regeneration
of LSPs by both IS's.  Either would trigger a new SPF.

Section 7.3.6 explicitly lists adjacency changes as a
trigger for new LSP generation.  See also 7.2.1, 7.3.1.

Typically you schedule an SPF run, and wait for a brief
period, so that related events (hearing indirectly that
the other side also thinks the link is down) don't 
cause multiple runs.  I've just run through 10589 and
don't see evidence of such a value.  I already have a 
note in my todo file to add such a variable to the MIB.  

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

---

From: Dave Katz <[email-masked]>
Date: Fri, 11 Jan 2002 09:13:00 -0800 (PST)

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.

--Dave

---

From: Alex Zinin <[email-masked]>
Date: Fri, 11 Jan 2002 11:05:59 -0800

Dave,

> to be stable does not accurately represent either of the dominant

BTW, this looks like another item for the document Vishwas proposed.

I'm also thinking: if I were using MIB to monitor/configure routers,
I guess I would like to see a variable/variables reflecting the SPF
back-off values. Unless implementations diverge dramatically (e.g.,
one is using exp, another sqrt ;), it seems to me there should be
a way to do so... In the worst scenario, we could have "opaque"
variables with well-defined syntax, but flexible semantics.

Alex.

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 11 Jan 2002 09:48:54 -0800

> to be stable does not accurately represent either of the dominant

taking the danger of repeating trivia,
yes, please do not forget that a protocol specification is governing
the _external_ behavior of the protocol, so basically what and when
you see on the wire (and some of the internal but
only to the extent that guarantees interoperability, e.g. due to hop-by-hop
paradigm everyone has to run an algorithm that delivers the same
forwarding decisions, in source-routed paradigms that may not be
necessary). It is superfluous, restricting and confusing to try to
govern internal implementation details as of how this behavior is
being achieved beside giving a reference model for description purposes.
Literally, if little green men carry things around in
water buckets in some implementations and manage to deliver
correct ISIS packets to the wire, that's ok (of course they must be paid
minimum wage but that's not our problem ;-) ....

       htanks

    -- tony

---

From: Dong Ha <[email-masked]>
Date: Fri, 11 Jan 2002 11:25:53 -0800 (PST)

Hi all,

Can anyone tell me what a router should do when it
receives a LSP with size bigger than the
ReceiveLSPBufferSize? Should it forward to other
routers or not? The ISO 10589 says the LSP should be
treated as if it has expired lifetime but I couldn't
find any information about wheather or not it should
be forwarded to other routers. Thanks.

-dong

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/
_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

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

Hey, who told you about my LGM algorithm?  Good thing I've got a patent.  ;-)

But seriously, thanks for stating this less curtly than I would.  The
IETF has a long history of being confused about what is subject to
standardization and what is not (the OSPF spec is a work of art in
that respect--it's a great implementation guide, but 90% of it is not
normative.  This turns out to be a competitive advantage, since the
implementation strategy it outlines has some serious scaling
limitations, so I don't complain.  Much.)

--Dave

   X-JNPR-Received-From: outside
   Date: Fri, 11 Jan 2002 09:48:54 -0800
   From: Tony Przygienda <[email-masked]>
   Sender: root@nodots-daemon
   Cc: [email-masked], [email-masked], [email-masked]
   Content-type: text/plain; charset=us-ascii
   X-Accept-Language: en
   X-OriginalArrivalTime: 11 Jan 2002 19:12:00.0000 (UTC) FILETIME=[D8410000:01C19AD3]

	  htanks

       -- tony

---

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

Exponential SPF backoff is a red herring, but that's a good over-beer
rant.

In general, there is no way in a MIB to generalize this sufficiently
to capture all the possibilities while actually being useful for
something.  At best, we'll just lie about the values.  I guarantee
that you won't capture my semantics that way, but that's fine, since I
won't tell you anyhow, and nobody but me needs to know.

But then if you're using a MIB to configure a router, please party on.  ;-)
(See previous rant.)

--Dave

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 11 Jan 2002 15:26:06 -0800

> But then if you're using a MIB to configure a router, please party on.  ;-)

there are things called vendor-specific MIBs and that's where this kind of
stuff goes into. If at all  ...

    - -tony

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 11 Jan 2002 16:24:15 -0800

> limitations, so I don't complain.  Much.)

yepp, implementation guidelines are something different from BCP and
we should stay out of those in this group, please.
Again, this group's goal is to specify/document aspect of the protocol that guarantee

    . interoperability
    . correctness
    . integrity (convergence is a sub-aspect of that)
    . some general aspects of robustness (e.g. self-stabilization) and
        scalability (e.g. keeping number of timer keyed pieces of state
        bound)
    . guidelines as to deployment scenarios of the protocol

We have no business to specify things that affect/improve

    . efficiency
    . fairness
    . predictability

those will be taken care of by good implementations. Things like
implementaion-guidelines groups for protocols have been tried and
mostly miserably failed. Too much vendor-specific knowledge on stake ...

        thanks

        -- tony

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 12 Jan 2002 14:35:27 -0500

On Friday, January 11, 2002, at 12:48  PM, Tony Przygienda wrote:
> necessary).

Tony,

	Moderation in all things.  Let us please try to include a bit more
documentation with IS-IS than IDR has (historically) done with BGP.  The
BGP specs are insufficiently complete for an otherwise clueful BGP
implementer to fully interoperate with the leading 2 deployed BGPs.
While that is financially beneficial for those small set of folks
  "in the know", it does not represent good protocol specification or
the best of the IETF.  (And yes, at least a couple folks here will have
sharp objection to these words, since a small few folks think BGP is 
already
at the right level of specification).

> It is superfluous, restricting and confusing to try to

	A clear and complete reference model is always helpful, provided it is
clearly marked as an informational reference model rather than a 
normative
implementation constraint.  If someone wants to publish an informational
document with some implementation hints, then that ought not be blocked
by this WG (and whether anyone else follows those hints ought to be left
as a personal decision for each reader of such a document).

	A feature of the revised IPsec documents was that Steve Kent added
such a reference model, without making it normative.  This made the 
intent
of the protocols much more clear.  Regrettably, other things were broken
in that editorial pass of IPsec, but adding the reference model was 
itself
a good thing (and adding it didn't break anything).

> minimum wage but that's not our problem ;-) ....

	IETF operates globally.  Not all locations have the concept of a
minimum wage, so that's an implementation choice outside our 
scope. :-) :-)

Ran
[email-masked]

---

From: Tony Przygienda <[email-masked]>
Date: Mon, 14 Jan 2002 12:19:30 -0800

> as a personal decision for each reader of such a document).

RJA, we agree in spirit here, however on the particular case of SPF
thresholds that led to that thread, it does not make sense to
make it normative or even include it in the reference model IMHO.
Good reference model follows Occam's razor in a good spec so it is
as simple as possible and only fleshed out to the point where the
spec becomes understandable. SPF thresholds are falling out from real
deployment and whether they do/do not make sense depends
heavily on the size and structure of the network as well as
how 'reactive' the network should be so it's not clear whether
certain implementations need it, need it configurable and what
to configure things to. As well, SPF thresholds are only one way
to apply hysterisis on flooding and following internal computations
and other ways are thinkable and doable.

    -- tony