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

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

On 8/9/11 3:13 PM, Les Ginsberg (ginsberg) wrote:
> Thanx for (at last) actually including the isis-wg on this thread.
>
You'll have to thank whomever changed your list so that IETF mailman
member posts don't bounce.


> I have attached an excellent review that Mike Shand provided for your 00
> draft - both as context and to insure that you have seen this (I did
> forward this to you once before but am not sure you ever received it).
>
It was not "excellent", nor was it worth responding.  There are other
things to do with my limited (and unfunded) time than trying to educate
somebody who either failed to read the entire draft or couldn't follow
explicit directions.


> After reviewing the latest version (02) it seems to me that you have not
> addressed any of the substance of Mike's remarks.
>
There was little substance to Mike's remarks.  He confused "ISHs" with
"IIHs" (rather remarkable, as I'd actually spelled out "IS-IS Hellos").
This led to misunderstanding of the technical details.  He may also have
failed to remember the meaning of "neighbor".


> None of this addresses the concerns that Mike raised in his review -
> specifically:
>
> 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
>
Apparently, you also need to refresh your memory on the meaning of
"neighbor", too.  Also, "source".  This document takes no position on
information already contained in the IS-IS specification.

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.


> 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.
After a power failure, they may very well change places.  No operator in
their right mind would buy a system that required a particular order for
booting their routers or bridges!!!

(Admittedly, there are operators not in their right mind -- and they buy
name brands regardless of the technical quality.)

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

This merely may be the first exercise of that provision.


> 3)In general avoiding gratuitous system-id changes
>
There are no "gratuitous" changes.  All changes SHOULD occur only to
resolve conflicts.  That's the section title: Resolving Conflicts.

Some might consider the optional capability to manually set it as
gratuitous.  At the very least, it's a security problem, which this
specification *does* address.

But the other known problem this specification addresses is the failure of
certain vendors to set the locally-defined bit on manually configured
system identifiers!  (Yes, I'm looking at you.)


> For this draft to go forward it would have to be demonstrated both that
> the problem needs to be addressed and that the solution is not worse
> than the original problem. The former is not borne out by field
> experience to date (IMHO).

Apparently a very humble opinion, as you have no field experience, or at
least not listed anywhere I've been able to find it. :-( If you do, now
might be the time to name the ISP where you worked, especially your front
line technical support experience.

Because your current (only?) employer, Cisco, has been one of the most
egregious producers of duplicate MACs in networking history....

Or you could peruse your own company's documentation:

===

Table 11-1. IS-IS Adjacency Problems/Causes

Problem 1: The IS-IS process is enabled, but some or all of the expected
adjacencies are not being formed, that is, some or all expected adjacencies
are not in the output of the show clns neighbors command at all.

Check that the interface is defined as passive under the IS-IS router configuration.

Other possibilities are as follows:

     Mismatched Level 1 and Level 2 interfaces or mismatched area addresses

     Incorrect IP subnet configuration

     Duplicate system ID in IS-IS area or backbone

===

Step 6: Check for Duplicate System IDs

If the previous steps checked out okay but a specific neighbor is not in
the show clns neighbor output, it is possible that adjacency is not
being formed because that neighbor has a duplicate system ID with the
local router. An IS-IS router will not form an adjacency with a router
in the same area that has a duplicate system ID. It also logs a
duplicate system ID error, as shown in Example 11-10. Use the show
logging command to display entries in the log. If duplicate system ID
errors are found, the source of the conflict can be determined from the
output of debug adj-packets, which points to the interface where the
hellos with the duplicate system ID are coming from. See Example 11-11.

===