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

[William Allen Simpson <[e-mail]>]

On 8/9/11 9:23 PM, Les Ginsberg (ginsberg) wrote:
> 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.
>
Les,

You made a personal claim of "field experience".  You egregiously have
no field experience.  Your false claim was clearly unprofessional.

This is especially odious to me, as I've been involved in both the
networking and the operational community for some 35+ years, was an
original member of NANOG, and founded an ISP back in 1994.  This is
not the first time I've advocated that all would-be protocol designers
have operational experience.  You'll find my comments on this topic
going back to circa 1992 in the IETF.

In the IETF, we talk about actual products.  You obviously didn't know
about your own company's products and technical support documentation.
Your arrogance, condescension, and pretension violates the rules of
common courtesy to which all of us are expected to abide.

You've embarrassed yourself in this community.

Many months ago, I (twice) privately encouraged you to send me any nits.
Then, you lied about it, and I posted both your messages to the list.
You have yet to send anything substantive or useful.


> In regards to technical points...
>
Proof by repeated assertion is not a technical point.

I'd thought perhaps some folks had some difficulty in understanding
compound sentences, and took it upon myself as an editor to make it
more clear.  Now, I'm wondering whether you simply have some other
political agenda.

"It is difficult to get a man to understand something, when his salary
depends upon his not understanding it!" -- Upton Sinclair

[The rest of this detailed message is for the community record.]


> 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.

It is not commonplace for them to consider their own LSPs as coming
from a neighbor.


> ... 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.
>
Let's look at the text from -00 and -01, now clause (a) in -02:

    After detecting a conflicting System Identifier in a neighbor, or

Note that I used the term "conflicting" throughout, distinguishing it
from the IS-IS section 7.3.16.2 LSP Confusion, which deals with
previous incarnations.

Note this clearly requires that it be a "neighbor".  IS-IS has a formal
definition:

   3.6.2 neighbour: An adjacent system reachable by traversal of a
   single subnetwork by a PDU.

IS-IS has a lot of text about determining adjacency.  There's no need to
recapitulate IS-IS here.

Note the wording "a" neighbor.  (Not "one or more" neighbors plural.)

Of course, this also required the reader to know the meaning and usage of
"System Identifier", and the PDUs where it appears.

Note that no specific PDUs are mentioned.  Contrary the poor comments of
Mike Shand, this does not refer to ISHs, nor does it call out IIHs here.

[Sadly, folks tell me Shand is not a bad guy, but he cursorily skimmed
this draft and made some poorly thought-out off-hand comments.]

However, there was a suggestion that we slightly differentiate Hellos
from LSPs and SNPs.  There was some reasonable rationale.  And that gives
the ill-informed reader some hint of the names of the PDUs. ;-)

       (a) detecting a conflicting System Identifier in

       (a)(1) 1 IS-IS Hello from any neighbor, or

       (a)(2) 2 consecutive LSPs and/or SNPs from the same source;

Obviously, this is to more quickly and gracefully handle the case of a
router restart, without waiting for the full 10 seconds.  The reviewer
suggested "the same source" was clearer than "a" singular neighbor.

Note this requires the reader to know the meaning and usage of "source"
in IS-IS:

    6.8.4   Receive process
    The Receive Process obtains its inputs from the following sources

    7.3.14  [P]ropagation of LSPs
    ...
    (g) When a Intermediate system receives a Link State PDU from source S,

etc. etc. etc.

Certainly, we wouldn't want to recapitulate all this IS-IS detail here (and
there's much much more).

I repeat, this document changes *NOTHING* in the IS-IS specification.  It
uses a hook already present in IS-IS:

    7.3.6    Event driven LSP Generation:
    ...
    -    a change in systemID
    ...

That there are probably badly behaved systems out there that don't follow
the explicit requirements of the IS-IS specification is one of the reasons
this is Experimental.