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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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: [e-mail] [mailto:[e-mail]] 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: [e-mail]
> Reply-To: [e-mail]
> To: [e-mail]
> 
> 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
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg

--- Begin Message ---

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/isis-wg
>
_______________________________________________
Isis-wg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/isis-wg

--- End Message ---