Re: [Pppext] [Isis-wg] Fwd: I-D Action: draft-simpson-isis-ppp-unique-02.txt

["Les Ginsberg (ginsberg)" <[e-mail]>]

William -

The majority of your reply consists of bashing - which is simply rude
and unprofessional and violates the rules of common courtesy to which
all of us are expected to abide. I won't respond further to any of those
remarks other than to say that this should stop immediately.

In regards to technical points...

> > 1)How to distinguish between benign cases (receiving your own LSP
> and/or
> > receiving a hellos from yourself if you have multiple ports on the
> same
> > LAN) from genuine doppelgangers
> >
> Indeed, I've repeatedly rejected suggestions from various folks to
> provide extraneous explanation.  This draft has only 5 or 6 sentences
> of
> protocol.  It's one of the simplest I've ever written.

The fact that it is simple does not mean it is correct. It is
commonplace for an IS to receive copies of its own LSPs during the
operation of the update process. In cases of router restart it is
commonplace for a router to receive copies of its LSPs from the previous
incarnation which may not be in any way identical to LSPs generated by
the new incarnation. Such cases are benign and are handled correctly by
the protocol today - but your proposal makes no distinction between
these cases and the case you are actually trying to solve. This is one
example of a "gratuitous system-id change" which could occur under your
proposed rules.

> 
> 
> > 2)How to prevent the introduction of a new system with a duplicate
> > system ID from causing an existing system which has been using that
> > system ID from having to change its ID (which is highly undesirable)
> >
> (Says you.)  The randomization of the delay jitter is explicitly for
> ensuring that neither new nor old has any advantage over the other.

I don't believe that a network operator wants the system-id of an IS
that has been operating in a stable network to be changed because of the
introduction of a new IS into the network that has (by accident or
maliciously) used the same system-id. So the premise that it is equally
desirable for the new or the old IS to change its system-id is flawed.
Yet another example of gratuitous change which could occur under your
proposed rules.

What is most relevant about gratuitous changes is that rather than
stabilizing the network they will do just the opposite - introducing
churn where none is desired or needed.

> IS-IS has explicit support for changing System Identifiers on the fly.
> See 7.3.6 Event driven LSP Generation:
> 
>     In addition to the periodic generation of LSPs, an Intermediate
>     system shall generate an LSP when an event occurs which would
cause
>     the information content to change. The following events may cause
>     such a change.
>     ...
>     -    a change in systemID

Here you confuse robustness with advocacy. There is nothing in the
specification which recommends changing the system-id of an IS once it
becomes operational. However, for correctness and completeness the
specification states that in the event that a system-id change occurs
LSP Generation SHALL be triggered.

There are really two parts to your draft.

1)A proposal for an alternate way of generating a unique identifier that
could be used as a system-id by an IS. This in fact requires no
standardization. Vendors could choose to adopt this if they believe it
is desirable. The IS-IS specification does not impose a system-id
assignment scheme - it simply requires that IDs be unique within an area
for L1 and within a domain for L2. The current common convention for
using MAC addesses is suggested in ISO 10589:2002 Annex B 1.1.3 (with
some substantive reasons) - but that section is explicitly labeled as
informative.

I have yet to hear from anyone (other than yourself) - either within the
context of discussing this draft or outside of it - who feels that we
have encountered deployment issues to date which would require the
proposal you make. If there are such advocates I would appreciate
hearing from them. Absent that this seems to be a solution in search of
a problem.

2)Protocol extensions which require dynamic changes to the system-id
used by a given IS under given conditions. This indeed would require a
standard - and it is this functionality to which most of the comments
have been focused. The concerns regarding filtering out false positives
need to be addressed before I would consider your proposal to be
deployable. Otherwise, as Mike states:

"accidentally invoking a changed system ID would seem to make the cure
worse than the disease..."

   Les