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

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC56C8.7AB2BB88
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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=20

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 protected] [mailto:[email protected]] 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
>=20
> https://tools.ietf.org/rfcdiff?url2=3Ddraft-simpson-isis-ppp-unique-
> 02.txt
>=20
> 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.
>=20
> 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.
>=20
> 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!
>=20
> 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.
>=20
> 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....
>=20
> 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.
>=20
> 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.)
>=20
> 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.
>=20
> Explicitly state that remote management is beyond the scope.
>=20
> Any other nits?
>=20
>=20
> -------- Original Message --------
> Subject: I-D Action: draft-simpson-isis-ppp-unique-02.txt
> Date: Mon, 08 Aug 2011 09:21:50 -0700
> From: [email protected]
> Reply-To: [email protected]
> To: [email protected]
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>=20
> 	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
>=20
>     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.
>=20
>     Additionally, the extension automatically resolves conflicts
> between
>     System Identifiers.
>=20
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-simpson-isis-ppp-unique-
> 02.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> 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 protected]
> 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
>=20
> _______________________________________________
> Isis-wg mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/isis-wg

------_=_NextPart_001_01CC56C8.7AB2BB88
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit

x-mimeole: Produced By Microsoft Exchange V6.5
Received: from xbh-sjc-211.amer.cisco.com ([171.70.151.144]) by xmb-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 04:18:32 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Received: from xbh-rcd-101.cisco.com ([72.163.62.138]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 04:18:31 -0700
Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 26 Apr 2011 06:18:30 -0500
Received: from mtv-core-2.cisco.com ([171.68.58.7])  by sj-iport-1.cisco.com with ESMTP; 26 Apr 2011 11:18:23 +0000
Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3QBILdR007152; Tue, 26 Apr 2011 11:18:23 GMT
Received: from mail.ietf.org ([64.170.98.30])  by sj-inbound-f.cisco.com with ESMTP; 26 Apr 2011 11:18:23 +0000
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5462E072B; Tue, 26 Apr 2011 04:17:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1B71E0728 for <[email protected]>; Tue, 26 Apr 2011 04:17:13 -0700 (PDT)
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lD2wDfkGghNI for <[email protected]>; Tue, 26 Apr 2011 04:17:13 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id AED34E0723 for <[email protected]>; Tue, 26 Apr 2011 04:17:12 -0700 (PDT)
Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 26 Apr 2011 11:17:11 +0000
Received: from [10.61.95.73] (ams3-vpn-dhcp8010.cisco.com [10.61.95.73]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3QBHBYJ008642 for <[email protected]>; Tue, 26 Apr 2011 11:17:11 GMT
Content-class: urn:content-classes:message
Subject: Re: [Isis-wg] draft-simpson-isis-ppp-unique-00
Date: Tue, 26 Apr 2011 04:17:11 -0700
Message-ID: <[email protected]>
In-Reply-To: <[email protected]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Isis-wg] draft-simpson-isis-ppp-unique-00
Thread-Index: AcwEA60MKITARKCzQLK3YQts4HvItw==
References: <[email protected]>
List-Help: <mailto:[email protected]?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>,<mailto:[email protected]?subject=subscribe>
List-Unsubscribe: <https://www.ietf.org/mailman/options/isis-wg>,<mailto:[email protected]?subject=unsubscribe>
From: "Mike Shand (mshand)" <[email protected]>
Sender: <[email protected]>
To: <[email protected]>

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

------_=_NextPart_001_01CC56C8.7AB2BB88
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Pppext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pppext

------_=_NextPart_001_01CC56C8.7AB2BB88--