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

From: William Allen Simpson <[email-masked]>
Date: Tue, 09 Aug 2011 10:28:10 -0400

https://tools.ietf.org/rfcdiff?url2=draft-simpson-isis-ppp-unique-02.txt

It's been months since the last update, and I'd thought we'd long since
be in the edit queue.  Here's the few (mostly editorial) changes.

Although I've tried mightily to keep extraneous explanatory text to a
minimum, some folks failed to actually read the entire document.  So,
I've duplicated a little of the abstract and various section content in
the Introduction.  Hopefully, that will skirt problems with folks who
think they become "expert" by skimming specifications -- without
understanding, operating, or implementing.

One reader thought that Resolving Conflicts is optional.  Wrong!  The
body text clearly said, "an implementation conforming with this
specification MUST generate...."  Moreover, that kind of thing is
obvious to all competent protocol designers and implementers.  In
today's IETF, we have professional meeting goers instead.  So, I've
added an explicit statement right at the *top* of the section for the
skimmers.  It's REQUIRED!

Also, some readers had difficulty understanding a compound sentence.
I've divided it into labeled clauses.  And here's the only substantive
change: the test for conflicts has been tightened slightly, while the
timing test has been loosened.

In previous drafts, Hellos, LSPs, and SNPs were all treated the same;
finding a conflict in any of them led to action.  That's how things are
specified in ISIS itself (in excruciating detail).  But one reviewer
thought we should require consecutive LSP/SNP conflicts.  That's more
IETF-like: be liberal in what you receive....

However, I left the Hello conflict test as 1.  There's no reason to
hope/wait for a change, it's a fast test, and in many cases clears up
the problem before we ever exchange LSPs/SNPs.

In previous drafts, IS-IS Hellos were used in the timing test.  Hellos
are sent periodically, so it's very conservative design.  But one
reviewer thought we should use Sequence Number increments instead.  It
may speed the conflict resolution slightly, and is a bit more
conservative in what we send -- assuming the implementation stops
sending as it waits the full 10 seconds for old/other LSPs to clear.
(I'm not sure all/any implementations will actually wait, but that's a
good experiment.)

A very confused reader thought this should handle more than 1 area,
because my *TITLE* is more universal.  That's just silly.  Heck, it goes
against the IS-IS principle (violated in practice) that each system is
only in one area.  Added a note on inter-area conflicts.

Explicitly state that remote management is beyond the scope.

Any other nits?

-------- Original Message --------
Subject: I-D Action: draft-simpson-isis-ppp-unique-02.txt
Date: Mon, 08 Aug 2011 09:21:50 -0700
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Generation of Unique IS-IS System Identifiers
	Author(s)       : William Allen Simpson
	Filename        : draft-simpson-isis-ppp-unique-02.txt
	Pages           : 9
	Date            : 2011-08-08

    The IS-IS routing protocol (Intermediate System to Intermediate
    System, ISO 10589) requires unique System Identifiers at the link
    layer.  A common practice has been to use an existing IEEE 802 MAC
    link-layer interface identifier.  When no unique MAC is available,
    this document specifies automatic generation of identifiers.  It is
    fully interoperable with systems that do not support this extension.

    Additionally, the extension automatically resolves conflicts between
    System Identifiers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-simpson-isis-ppp-unique-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-simpson-isis-ppp-unique-02.txt
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 9 Aug 2011 12:13:52 -0700

William -

Thanx for (at last) actually including the isis-wg on this thread.

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

After reviewing the latest version (02) it seems to me that you have not
addressed any of the substance of Mike's remarks.

The most relevant changes in the 02 version consist of the revision to 

Section 3 Resolving Conflicts

As rewritten this section now says (in part):

<snip>
An implementation conforming with this specification MUST generate a
   replacement System Identifier using one of the techniques specified
   above, upon:

      (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;

      (b) failing to resolve participation in an area after

      (b)(1) incrementing its Sequence Number 3 or more times, and

      (b)(2) 10 seconds.
<end snip>

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

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)

3)In general avoiding gratuitous system-id changes

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). In its present state the proposed solution
fails the second test as well.

If you are serious about moving this draft forward please address the
substance of the review points which have been made.

   Les

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of William Allen Simpson
> Sent: Tuesday, August 09, 2011 7:28 AM
> To: IETF PPP WG
> Cc: IETF TRILL WG; IETF ISIS WG
> Subject: [Isis-wg] Fwd: I-D Action: draft-simpson-isis-ppp-unique-
> 02.txt
> 
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

Subject: Re: [Isis-wg] draft-simpson-isis-ppp-unique-00
From: "Mike Shand (mshand)" <[email-masked]>
To: <[email-masked]>
Date: Tue, 26 Apr 2011 04:17:11 -0700

I have some comments on this draft.

    If a duplicated MAC is used as a System Identifier within an IS-IS
    area, this leads to the condition colloquially called "LSR War".
    Currently, IS-IS has no method to detect or resolve such conflicts.

It is something of an exaggeration to say that IS-IS has NO method to
detect this situation. It will result in the affected systems persistently
increasing the sequence numbers of their LSPs, in an attempt to assert
their own LSPs over the duplicates. Most implementations will detect this
condition and raise appropriate system warning messages. Admittedly,
the consequences, while this persists, are quite serious.

    After detecting a conflicting System Identifier in a neighbor, or
    receiving 3 or more IS-IS Hellos and failing to resolve participation
    in an area within 10 seconds, an implementation conforming with this
    specification MUST generate a replacement System Identifier using one
    of the techniques specified above.

I don't understand this paragraph. It talks about detecting the conflicting
system IDs in the neighbor using ISHs. But the problem arises across an entire
flooding domain (a single level 1 area or the level 2 domain). It is possible,
and indeed probable that the offending system IDs are not adjacent, but will
still cause the same level of disruption.

I also don't understand what is meant by "failing to resolve participation in
an area within 10 seconds". Surely this doesn't mean a simple mismatch of area
address, or any other reason for failing to bring up an L1 adjacency. I'm guessing
the author means receiving a hello with the same system ID as itself? But this can
occur benignly when a system has multiple interfaces onto the same LAN ( either
deliberately or by some bridging misconfiguration), and it is indeed hearing its own
hellos.

So this seems to make no sense at all, and clearly wouldn't work.

For it to work, it would have to be based on receiving an LSP which somehow indicated
the conflict. But receiving your own LSPs (with your own system ID) is a normal
occurrence, especially when rejoining a domain after a crash etc. So a means needs to
be provided to distinguish the common benign case, from a genuine  doppelganger.

Other that using some other "more unique" id to distinguish really different
system (which just punts the problem), it seems that some variant of the
normal detection method (i.e. detecting a persitent sequence number increment), is
the only viable alternative. Yet this draft says nothing about such a mechanism.

Whatever method were chosen, it would have to be proof against false positives, since
accidentally invoking a changed system ID would seem to make the cure worse than the disease.

Indeed, there seems to be a danger that bringing up a new system with an incorrectly
assigned system ID (the usual case is accidentally joining a test network to
the production network) would cause the existing (and previously stable) system to change
its ID.

Note that gratuitously changing a system ID can affect things other that the
operation of IS-IS itself. For example the system ID is often used as the
key in the hash function for preventing polarisation in hop by hop forwarding ECMP
paths, so changing the system ID is likely to affect traffic patterns adversely.

This whole thing needs to be MUCH, more carefully thought out, if indeed a solution
is to be attempted.

	Mike

On 25/04/2011 18:25, Stewart Bryant wrote:
> ISIS WG
>
> It seems likely that draft-simpson-isis-ppp-unique-00 will
> be submitted as an experimental submission on the
> independent stream.
>
> Please look out for it.
>
> If you have any views on this document please make them known.
>
> - Stewart
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg
>
_______________________________________________
Isis-wg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/isis-wg

---

From: William Allen Simpson <[email-masked]>
Date: Tue, 09 Aug 2011 17:28:06 -0400

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

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

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

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

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

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

===

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 9 Aug 2011 18:23:29 -0700

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

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

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

>     the information content to change. The following events may cause

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

---

From: William Allen Simpson <[email-masked]>
Date: Wed, 10 Aug 2011 09:32:38 -0400

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

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

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

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.