Subject: [RTG-DIR] RtgDir review: draft-simpson-isis-ppp-unique-01.txt

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 29 Jul 2011 08:53:41 -0400

Hello Bill,

I have been selected as the Routing Directorate reviewer for this draft. 
The Routing Directorate seeks to review all routing or routing-related 
drafts as they pass through IETF last call and IESG review, and 
sometimes on special request. The purpose of the review is to provide 
assistance to the Routing ADs. For more information about the Routing 
Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it 
would be helpful if you could consider them along with any other IETF 
Last Call comments that you receive, and strive to resolve them through 
discussion or by updating the draft.

Document: draft-simpson-isis-ppp-unique-01.txt
Reviewer: Joel M. Halpern
Review Date: 29-July-2011
IETF LC End Date: N/A
Intended Status: Independent, Experimental

Summary:
     I have significant concerns about this document and recommend that 
the Routing ADs discuss these issues further with the authors.

Major Issues:
     The modification to the IS-IS message exchange behavior which is 
section 3 of this document should be removed.  It is not necessary for 
the primary goal that the document states it is concerned with. 
Existing practice already recognizes that collision can occur, and 
provides for what responses should be taken.  More importantly, the 
specification provided does not actually solve the problem it claims to 
solve.
     1) It claims to handle System-ID collision, but in fact describes 
only the case of detecting a collision with a neighbor.
     2) The text does not describe how to actually detect collision, 
since return of ones own LSAs is valid and expected behavior under 
various circumstances.
     3) It then replaces the collision problem with a proxy "failing to 
resolve participation in an area within 10 seconds", which is not itself 
well defined.  And which is NOT the same as a System-ID collision.  In 
fact, a System-ID collision does not cause a result that can reasonably 
be mapped to "failure to resolve participation in an area"

Minor Issues, which still need attention:
     In defining the construction of the system I-D this draft specifies 
that the "locally-assigned" and "broadcast/multicast" bits are to be set 
in the system I-D.  As far as I know, the first of these is correct. 
The second one, setting the group bit in the OUI, seems to be an 
inappropriate use of that bit, in the hope that no one else will have 
made the same abuse.

     Given that existing behavior allows a system to specify its 
system-ID in a local fashion, that dimension of the spec does not 
violate the existing documents.  However, the description in the 
document would lead the reader to conclude that there were no existing 
solutions to the problem of an IS-IS participant without a usable MAC 
address.  While one might well dislike the existing practice of manual 
configuration, it does exist and does address the problem.  This 
document should recognize that.

Re-summarizing:  If section 3 is removed, and the lesser issues are 
addressed, this would appear to be an acceptable experimental 
independent submission.

---

From: William Allen Simpson <[email-masked]>
Date: Fri, 29 Jul 2011 12:18:48 -0400

Thanks.  It's about (beyond) time!  This was sent to the Routing ADs in April,
and entered the IESG TimeOut (30 days) in May (expired June 22nd).

While I appreciate that Joel took the time to read this, and do a bit of
writeup, it would also help had he had a lot more implementation and
operational experience.  He makes a number of egregious mistakes.

Sadly, this response is longer than the original internet-draft.  It's just
about the shortest and simplest draft I've ever written.  I'd prefer not to
clutter it with minutiae.

On 7/29/11 8:53 AM, Joel M. Halpern wrote (and it would have been nicer with
folded lines, so I didn't have to fold them manually):

> Major Issues:
> The modification to the IS-IS message exchange behavior which is section 3 of this document should be removed. It is not necessary for the primary goal that the document states it is concerned with.

This is not true.  The "primary goal" is clearly indicated by the title and
abstract:
   "Generation of Unique IS-IS System Identifiers"

   "When no unique MAC is available,
    this document specifies automatic generation of identifiers."

   "Additionally, the extension automatically resolves conflicts between
    System Identifiers."

Section 3 is intimately concerned with such generation, as it detects they
are "unique".  Without section 3, conflicts will not be automatically
resolved.  Any protocol specification that does not handle conflict
resolution is incomplete, and demonstrates poor error recovery.

The only mention in ISO10589 merely says:

    If the ID is chosen from the ISO 8802 48-bit address space (represented
    as a sequence of 6 octets as specified in ISO/IEC 10039), the ID is
    known to be globally unique.

This is well known to be false, as mentioned in my document!

    ... drastically reduces the possibility of duplicate NSAP addresses,
    which are illegal, difficult to diagnose, and often extremely
    difficult to isolate.

While we don't use NSAPs, this is also true of System Identifiers!

The existing ISO10589 document does not autonomously resolve conflicts,
resulting in the need for this document.

> Existing practice already recognizes that collision can
> occur, and provides for what responses should be taken.

Please point to the exact document(s) and section(s) that specifies where
"collisions can occur", automatically resolves the conflict, or details any
response what-so-ever.

As shown above, the ISO document blithely assumes that IEEE addresses are
unique.  They are not.  They never have been (going back to thicknet cables).
Problems have been made worse by multimedia bridges and huge multi-thousand
device cable network nodes.

As I mentioned on the PPP list, last summer it took me a very long time to
diagnose a conflict between D-Link devices over a Comcast network.  The
political campaign had no way to know why their stuff didn't work (worked
intermittently).  It was an irritating mess.  There's no reason that
non-technical staff should have to know any of this!

I have high hopes that TRILL will fix these problems.  This document was
written with PPP and TRILL in mind.  It may help other groups, too, but
that is not my principle concern.

> More importantly, the specification provided does not actually solve the problem it claims to solve.

> 1) It claims to handle System-ID collision, but in fact describes only the case of detecting a collision with a neighbor.

Joel is r-e-a-l-l-y stretching on this item.  Semantic silliness.

Detecting a collision with a neighbor is the only case that matters.  Obviously,
there is no desire nor intent to generate unique identifiers for nodes that are
on the other side of the world or entirely disconnected from the 'net.

<sarcasm>
I suppose this objection could be handled by expanding the title:

    Generation of Unique IS-IS System Identifiers
                within a routing area,
         where the routing area is limited to
           adjacent nodes or bridged nodes

Not!
</sarcasm>

> 2) The text does not describe how to actually detect collision, since return of ones own LSAs is valid and expected behavior under various circumstances.

This comment assumes that "ones own LSAs" will not be recognized.  If that
were the case, then multiple interfaces per node would fail on the same link,
across different bridge's links, and across L1 and L2 areas.

Perhaps Joel could refresh his memory on the meaning of "neighbor".  (Speaking
as the original author of "Neighbor Discovery".)  Also, I refer him to the
many uses of "neighbor" in ISO10589, RFC-3277, RFC-5305, RFC-6213, etc.  They
all manage to use the term without an explicit definition, because we all know
what the word means in a networking context.

> 3) It then replaces the collision problem with a proxy "failing to resolve participation in an area within 10 seconds", which is not itself well defined. And which is NOT the same as a System-ID collision. In fact, a System-ID collision does not cause a
> result that can reasonably be mapped to "failure to resolve participation in an area"
>
At this point, I call bullshit!

The paragraph reads in its entirety:

    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.

In fact, the two clauses taken together are exactly the test needed.  There
is a "tell me 3 times" and a timeout.  Indeed, the lack of them both is
often an indicator of poor protocol design.

Instead of detailing all possible current (which are already in many other
documents) and _future_ error conditions, the test relies on the one thing
that all IS devices *MUST* follow: 3 Hellos in 10 seconds.

In my first (private) draft, I'd used 30 seconds, to cover all ES devices.
But early reviewers indicated that was not necessary.

> In defining the construction of the system I-D this draft specifies that the "locally-assigned" and "broadcast/multicast" bits are to be set in the system I-D. As far as I know, the first of these is correct. The second one, setting the group bit in the
> OUI, seems to be an inappropriate use of that bit, in the hope that no one else will have made the same abuse.
>
Currently, there are a number of ISIS devices that have manual assignment,
but do not set the locally-defined bit.  This existing behavior is wrong.
This specification mandates correct behavior.  Thanks for noticing.

The usual IETF method of assigning unique OUIs that are not sources or
destinations on the network use the "group" bit in addition to the
locally-defined bit.  It's a practice that *I* started circa 1992, so I'm
fairly familiar with it.

I know it's impossible to keep up with all the RFCs.  But I'd kinda expected
that Joel would know about techniques we've used for 20 years....

> Given that existing behavior allows a system to specify its system-ID in a local fashion, that dimension of the spec does not violate the existing documents. However, the description in the document would lead the reader to conclude that there were no
> existing solutions to the problem of an IS-IS participant without a usable MAC address. While one might well dislike the existing practice of manual configuration, it does exist and does address the problem. This document should recognize that.
>
The "Configurable System Identifier" section is devoted to manual
configuration.  Did Joel actually read the entire document?

However, manual configuration does not address the problem of detecting
conflicts nor ensuring uniqueness.  That is also mentioned in the Security
Considerations.  Did Joel actually read the entire document?

> Re-summarizing: If section 3 is removed, and the lesser issues are addressed, this would appear to be an acceptable experimental independent submission.
>

---

From: William Allen Simpson <[email-masked]>
Date: Fri, 29 Jul 2011 12:23:03 -0400

> what the word means in a networking context.
Correction.  I missed ISO10589 section 3.6.2:

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

Radia was really thorough as always.... :-)