Subject: Re: [rbridge] [Isis-wg] Fwd: I-D Action: draft-simpson-isis-ppp-unique-02.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
> 
> 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
> 
> _______________________________________________
> 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
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

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

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

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

---

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

William -

<snip>

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

   Les

since
in
are
is

	Mike