From william.allen.simpson@gmail.com Tue Aug 9 07:27:45 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C1521F8B87; Tue, 9 Aug 2011 07:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.455 X-Spam-Level: X-Spam-Status: No, score=-3.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KmEu3oA6z1j; Tue, 9 Aug 2011 07:27:44 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 262E521F87C7; Tue, 9 Aug 2011 07:27:44 -0700 (PDT) Received: by iye1 with SMTP id 1so59151iye.27 for ; Tue, 09 Aug 2011 07:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=uDbsmIMZNtXg8Qc3ERWsTpe3U+8QwyDGvH32lh6gh7c=; b=Jism5KPaYX6hepnVLSx87mOvsu7v7rbu6DJIlpa2Mh+s2jMZ+sTdn7pP/nJXZCOTG7 +0RqL6vWmGHs95wJCJtBnbA9574h5K//Xzr4EpL6OinqRadqiKSvTsZi3SWloM2Su5/6 XZ9t/PeC9Ow9pq1auxxv4sc1hU9pm/Ift+Z24= Received: by 10.231.74.13 with SMTP id s13mr7562711ibj.78.1312900092779; Tue, 09 Aug 2011 07:28:12 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id fu7sm5066902ibb.36.2011.08.09.07.28.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 07:28:11 -0700 (PDT) Message-ID: <4E4143FA.1000307@gmail.com> Date: Tue, 09 Aug 2011 10:28:10 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: IETF PPP WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF TRILL WG , IETF ISIS WG Subject: [Pppext] Fwd: I-D Action: draft-simpson-isis-ppp-unique-02.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 14:27:45 -0000 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: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org 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 I-D-Announce@ietf.org 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 ginsberg@cisco.com Tue Aug 9 12:13:27 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D205311E80F6; Tue, 9 Aug 2011 12:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.845 X-Spam-Level: X-Spam-Status: No, score=-2.845 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOAPgbT3k+oH; Tue, 9 Aug 2011 12:13:26 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5B30111E80F1; Tue, 9 Aug 2011 12:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ginsberg@cisco.com; l=14606; q=dns/txt; s=iport; t=1312917236; x=1314126836; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=Son4AzeYahhvAxrjZyLMVcFW4ha3IorU3SdqeAD3tIo=; b=L7YmNAT8isAlzaPQP8NghzXNBestYpiXC4NiCSLCvkB4spl3VQEYTX6n urv5B+NVumqLjRzH/aj1qz+2AMoa5V77hUFwxLLknWJnKecB5U52fgx/1 l3zD2lusirU56KzZWLQmbszh5RiGveKp5Zvz+UsHivQZxPQARbqoZ82MP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAKGFQU6rRDoI/2dsb2JhbABCl2CPXneBQAEBAQEDAQEBDwEJFDsDCwwEAgEIEQMBAQEBCgYXAQYBJh8JCAEBBAESCAESB4dPnnwBnmKFZ18Ehy0vkDuEXocb X-IronPort-AV: E=Sophos;i="4.67,344,1309737600"; d="scan'208";a="11441097" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-8.cisco.com with ESMTP; 09 Aug 2011 19:13:55 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p79JDsNN024308; Tue, 9 Aug 2011 19:13:54 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 12:13:54 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC56C8.7AB2BB88" Date: Tue, 9 Aug 2011 12:13:52 -0700 Message-ID: In-Reply-To: <4E4143FA.1000307@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Fwd: I-D Action: draft-simpson-isis-ppp-unique-02.txt Thread-Index: AcxWoJf9xRzMhpGdRkK47der37aY4AAJQ0kg References: <4E4143FA.1000307@gmail.com> From: "Les Ginsberg (ginsberg)" To: "William Allen Simpson" , "IETF PPP WG" X-OriginalArrivalTime: 09 Aug 2011 19:13:54.0508 (UTC) FILETIME=[7B1148C0:01CC56C8] Cc: IETF TRILL WG , IETF ISIS WG Subject: Re: [Pppext] [Isis-wg] Fwd: I-D Action: draft-simpson-isis-ppp-unique-02.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 19:13:28 -0000 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): 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. 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: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] 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: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=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 > I-D-Announce@ietf.org > 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 > Isis-wg@ietf.org > 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 ; 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 ; 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 ; 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 ; 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: <4DB6A9B7.9010808@cisco.com> In-Reply-To: <4DB5AE7D.3020108@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] draft-simpson-isis-ppp-unique-00 Thread-Index: AcwEA60MKITARKCzQLK3YQts4HvItw== References: <4DB5AE7D.3020108@cisco.com> List-Help: List-Subscribe: , List-Unsubscribe: , From: "Mike Shand (mshand)" Sender: To: 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 > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg ------_=_NextPart_001_01CC56C8.7AB2BB88-- From william.allen.simpson@gmail.com Tue Aug 9 14:27:41 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8E211E80F7; Tue, 9 Aug 2011 14:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.471 X-Spam-Level: X-Spam-Status: No, score=-3.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjbIPxpJVGe1; Tue, 9 Aug 2011 14:27:40 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A6C5411E80F0; Tue, 9 Aug 2011 14:27:40 -0700 (PDT) Received: by gwb20 with SMTP id 20so337899gwb.31 for ; Tue, 09 Aug 2011 14:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8G3Arvak18xSdOXdLqBbk6W2PZv7XAN7/w1tTqCNcvA=; b=KpBz7oe1dxE3mHg5e+4PevdyEzNHNbAV4hb1qj3v4NTEhiOfmjsGuq/33lPouBQ67Z elYHzm2JBRaxxBbTYuhOVHn0jKA0Hi0st8xORe/+8YN8ifYL6+PAy97IciFJmEE1LaKf QNSD2lPe1ma+nxP8Fmo++8z8mwNn8rfaSYi5Q= Received: by 10.42.153.136 with SMTP id m8mr814066icw.472.1312925289285; Tue, 09 Aug 2011 14:28:09 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id f14sm385113icm.15.2011.08.09.14.28.07 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 14:28:08 -0700 (PDT) Message-ID: <4E41A666.4090200@gmail.com> Date: Tue, 09 Aug 2011 17:28:06 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: IETF PPP WG References: <4E4143FA.1000307@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF TRILL WG , IETF ISIS WG Subject: Re: [Pppext] [Isis-wg] Fwd: I-D Action: draft-simpson-isis-ppp-unique-02.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2011 21:27:41 -0000 On 8/9/11 3:13 PM, Les Ginsberg (ginsberg) wrote: > 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. > 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). > 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. > After reviewing the latest version (02) it seems to me that you have not > 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". > 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 > 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. > 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) > (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.) > 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). 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 ginsberg@cisco.com Tue Aug 9 18:23:05 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8457821F8B5A; Tue, 9 Aug 2011 18:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.034 X-Spam-Level: X-Spam-Status: No, score=-3.034 tagged_above=-999 required=5 tests=[AWL=-0.435, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcKxx+StkUdh; Tue, 9 Aug 2011 18:23:04 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E262821F8B56; Tue, 9 Aug 2011 18:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ginsberg@cisco.com; l=4623; q=dns/txt; s=iport; t=1312939414; x=1314149014; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=7WR8Dw+MDJm/dcbke8sUQIlL2R0KxIIyqT5tyIjAUZM=; b=D9JL5logWcsUIQ5QM9Cyh7NyR4Qc4UeWF0Ya509xBugWv+byJpjZGHJS F/MA+VVLcjHNsAkvmqS6kkyrMjvaL5y/JXvb/zVXqEDYWjw7yBjLdSYIW WkNFPkgDAjlUFTYZvtFxHor0spMSWcD3zrF2yzfMazjHIzAJEs7My8ZMC o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOHcQU6rRDoG/2dsb2JhbABBp0B3gUABAQEBAgESAR0KPwULAgEIIgYYBgFWAQEEARoTB4dLnBABnjmFZ18Eh12QPYt5 X-IronPort-AV: E=Sophos;i="4.67,347,1309737600"; d="scan'208";a="11565671" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by rcdn-iport-9.cisco.com with ESMTP; 10 Aug 2011 01:23:33 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p7A1NXDC005773; Wed, 10 Aug 2011 01:23:33 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 18:23:33 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Aug 2011 18:23:29 -0700 Message-ID: In-Reply-To: <4E41A666.4090200@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Fwd: I-D Action: draft-simpson-isis-ppp-unique-02.txt Thread-Index: AcxW20IwWgnv6pXiR5iA2NxNltXg+QAFvlkw References: <4E4143FA.1000307@gmail.com> <4E41A666.4090200@gmail.com> From: "Les Ginsberg (ginsberg)" To: "William Allen Simpson" , "IETF PPP WG" X-OriginalArrivalTime: 10 Aug 2011 01:23:33.0139 (UTC) FILETIME=[1E8FCE30:01CC56FC] Cc: IETF TRILL WG , IETF ISIS WG Subject: Re: [Pppext] [Isis-wg] Fwd: I-D Action: draft-simpson-isis-ppp-unique-02.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 01:23:05 -0000 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... > > 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 > > > 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. >=20 >=20 > > 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) > > > (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: >=20 > 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 william.allen.simpson@gmail.com Tue Aug 9 20:45:25 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4187E21F8A58; Tue, 9 Aug 2011 20:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BQJ1crdIh5qX; Tue, 9 Aug 2011 20:45:24 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id 32D7021F8A57; Tue, 9 Aug 2011 20:45:24 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 94DAA7B800B; Wed, 10 Aug 2011 05:47:12 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 7F655738009; Wed, 10 Aug 2011 05:47:12 +0200 (CEST) Received: from ftrdsmtp4.rd.francetelecom.fr ([10.192.128.49]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 05:43:46 +0200 Received: from mail pickup service by ftrdsmtp4.rd.francetelecom.fr with Microsoft SMTPSVC; Wed, 10 Aug 2011 01:55:51 +0200 Received: from omfeda08.si.francetelecom.fr ([10.98.3.82]) by ftrdsmtp4.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 16:28:19 +0200 Received: from omfeda10.si.francetelecom.fr (unknown [10.98.77.162]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id C4DB438403A; Tue, 9 Aug 2011 16:28:19 +0200 (CEST) Received: from omfeda10.si.francetelecom.fr (localhost.localdomain [127.0.0.1]) by omfeda10.si.francetelecom.fr (ESMTP service) with SMTP id 938763743DD; Tue, 9 Aug 2011 16:28:19 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by relais-inet.francetelecom.com (ESMTP service) with ESMTP id 20A2F3743D9; Tue, 9 Aug 2011 16:28:19 +0200 (CEST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1093621F8B88; Tue, 9 Aug 2011 07:27:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1312900067; bh=SYktTj60Nr4pxpBs09zjMI+bjHcNa4FvxT5VH6hpsy8=; h=Message-ID:Date:From:MIME-Version:To:Cc:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Transfer-Encoding:Content-Type:Sender; b=DU8sGlll3EkMuq+pCtVDYkNX37vpz2zkyPcMtq2FAJGANSgDHHVt7uyPjVixQfw4G FSxbwJkvAIuTcZ+VVGH7x1X1hOoFYdLu+GUerCBDqjf2XqyndVdGrin5INXRCdtZ1r +r9ia+eApphhCieGQyqSL33C8o/cSTi5JTtEWpvI= X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C1521F8B87; Tue, 9 Aug 2011 07:27:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KmEu3oA6z1j; Tue, 9 Aug 2011 07:27:44 -0700 (PDT) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by ietfa.amsl.com (Postfix) with ESMTP id 262E521F87C7; Tue, 9 Aug 2011 07:27:44 -0700 (PDT) Received: by iye1 with SMTP id 1so59151iye.27 for ; Tue, 09 Aug 2011 07:28:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=uDbsmIMZNtXg8Qc3ERWsTpe3U+8QwyDGvH32lh6gh7c=; b=Jism5KPaYX6hepnVLSx87mOvsu7v7rbu6DJIlpa2Mh+s2jMZ+sTdn7pP/nJXZCOTG7 +0RqL6vWmGHs95wJCJtBnbA9574h5K//Xzr4EpL6OinqRadqiKSvTsZi3SWloM2Su5/6 XZ9t/PeC9Ow9pq1auxxv4sc1hU9pm/Ift+Z24= Received: by 10.231.74.13 with SMTP id s13mr7562711ibj.78.1312900092779; Tue, 09 Aug 2011 07:28:12 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id fu7sm5066902ibb.36.2011.08.09.07.28.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 07:28:11 -0700 (PDT) Message-ID: <4E4143FA.1000307@gmail.com> Date: Tue, 09 Aug 2011 10:28:10 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: IETF PPP WG X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.9.142122 X-OriginalArrivalTime: 09 Aug 2011 14:28:19.0982 (UTC) FILETIME=[96181AE0:01CC56A0] Cc: IETF TRILL WG , IETF ISIS WG Subject: [Pppext] [Isis-wg] Fwd: I-D Action: draft-simpson-isis-ppp-unique-02.txt X-BeenThere: pppext@ietf.org List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 03:45:25 -0000 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: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org 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 I-D-Announce@ietf.org 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 Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From william.allen.simpson@gmail.com Wed Aug 10 03:21:23 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFDE421F861E; Wed, 10 Aug 2011 03:21:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.772 X-Spam-Level: X-Spam-Status: No, score=-2.772 tagged_above=-999 required=5 tests=[AWL=-0.523, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Suqt-gwL5Bvm; Wed, 10 Aug 2011 03:21:23 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id CD92421F863A; Wed, 10 Aug 2011 03:21:22 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 311A77B800F; Wed, 10 Aug 2011 12:23:13 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 22304738006; Wed, 10 Aug 2011 12:23:13 +0200 (CEST) Received: from ftrdsmtp4.rd.francetelecom.fr ([10.192.128.49]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 11:57:40 +0200 Received: from mail pickup service by ftrdsmtp4.rd.francetelecom.fr with Microsoft SMTPSVC; Wed, 10 Aug 2011 02:20:41 +0200 Received: from omfedm07.si.francetelecom.fr ([10.98.84.131]) by ftrdsmtp4.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 23:28:15 +0200 Received: from omfedm13.si.francetelecom.fr (unknown [10.98.62.21]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 215D14C088; Tue, 9 Aug 2011 23:28:15 +0200 (CEST) Received: from omfedm13.si.francetelecom.fr (localhost.localdomain [127.0.0.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with SMTP id 108A13245B2; Tue, 9 Aug 2011 23:28:15 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by relais-inet.francetelecom.com (ESMTP service) with ESMTP id A6DB33245A4; Tue, 9 Aug 2011 23:28:14 +0200 (CEST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37F911E80FA; Tue, 9 Aug 2011 14:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1312925263; bh=YiRTkEoXGYG5Qf8ZD6z5J1xbdk0KusX5Qw6kKSganf4=; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To:Cc: Subject:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help: List-Subscribe:Content-Transfer-Encoding:Content-Type:Sender; b=KiuThhI8oTpznbK5wHlTmcYVu4t+VVo6NE/T1DnjSHTDh07B83tYcOH2yxTFtovh3 jKhB6Owm+cBDFgQD4vXbGdp+561H6dO/+kcIvXsqQ4z+wy0Tk4CGTGgnGFlHK5JBQW D7lr6v6hO0C1DCk7juJJme/oHGpTtwuXU4ovipPE= X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8E211E80F7; Tue, 9 Aug 2011 14:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zjbIPxpJVGe1; Tue, 9 Aug 2011 14:27:40 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id A6C5411E80F0; Tue, 9 Aug 2011 14:27:40 -0700 (PDT) Received: by gwb20 with SMTP id 20so337899gwb.31 for ; Tue, 09 Aug 2011 14:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=8G3Arvak18xSdOXdLqBbk6W2PZv7XAN7/w1tTqCNcvA=; b=KpBz7oe1dxE3mHg5e+4PevdyEzNHNbAV4hb1qj3v4NTEhiOfmjsGuq/33lPouBQ67Z elYHzm2JBRaxxBbTYuhOVHn0jKA0Hi0st8xORe/+8YN8ifYL6+PAy97IciFJmEE1LaKf QNSD2lPe1ma+nxP8Fmo++8z8mwNn8rfaSYi5Q= Received: by 10.42.153.136 with SMTP id m8mr814066icw.472.1312925289285; Tue, 09 Aug 2011 14:28:09 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id f14sm385113icm.15.2011.08.09.14.28.07 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 14:28:08 -0700 (PDT) Message-ID: <4E41A666.4090200@gmail.com> Date: Tue, 09 Aug 2011 17:28:06 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: IETF PPP WG References: <4E4143FA.1000307@gmail.com> In-Reply-To: X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.9.211514 X-OriginalArrivalTime: 09 Aug 2011 21:28:15.0217 (UTC) FILETIME=[3F9FDE10:01CC56DB] Cc: IETF TRILL WG , IETF ISIS WG Subject: Re: [Pppext] [Isis-wg] Fwd: I-D Action: draft-simpson-isis-ppp-unique-02.txt X-BeenThere: pppext@ietf.org List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 10:21:24 -0000 On 8/9/11 3:13 PM, Les Ginsberg (ginsberg) wrote: > 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. > 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). > 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. > After reviewing the latest version (02) it seems to me that you have not > 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". > 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 > 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. > 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) > (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.) > 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). 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. === _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg From ginsberg@cisco.com Wed Aug 10 03:45:28 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF3021F8658; Wed, 10 Aug 2011 03:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.472 X-Spam-Level: X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnr+1AbnUOJG; Wed, 10 Aug 2011 03:45:16 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAE921F863C; Wed, 10 Aug 2011 03:45:16 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 847F395800D; Wed, 10 Aug 2011 12:54:16 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 772D06FCC0F; Wed, 10 Aug 2011 12:54:16 +0200 (CEST) Received: from ftrdsmtp4.rd.francetelecom.fr ([10.192.128.49]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Aug 2011 12:01:58 +0200 Received: from mail pickup service by ftrdsmtp4.rd.francetelecom.fr with Microsoft SMTPSVC; Wed, 10 Aug 2011 01:55:47 +0200 Received: from omfedm08.si.francetelecom.fr ([10.98.84.132]) by ftrdsmtp4.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 21:14:10 +0200 Received: from omfedm09.si.francetelecom.fr (unknown [10.98.62.17]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C6BCE238084; Tue, 9 Aug 2011 21:14:10 +0200 (CEST) Received: from omfedm09.si.francetelecom.fr (localhost.localdomain [127.0.0.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with SMTP id B6D522DC32E; Tue, 9 Aug 2011 21:14:10 +0200 (CEST) Received: from mail.ietf.org (mail.ietf.org [12.22.58.30]) by relais-inet.francetelecom.com (ESMTP service) with ESMTP id 2AD952DC29F; Tue, 9 Aug 2011 21:14:10 +0200 (CEST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E841311E80FC; Tue, 9 Aug 2011 12:13:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1312917209; bh=TohpVyfoXG6VoYC2PKWaJleOCj/vOThukkncnxy3Rkk=; h=MIME-Version:Content-Type:Date:Message-ID:In-Reply-To:References: From:To:Cc:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:Sender; b=VK8MkVwRT66/mgsRn7ili/malnZ5RTPzqmpg5BgRnRgqk5hlqUOOhGGAaW4HfKTwt VR6Y7i15F+9heJ6i8bDJ3dF5cEZxZFLXxk8zcacyl2fACQ9R3YAwwmhDLiIG+Hxxk7 o5UTFoDoCNUPYpL4idV+buBGqlmrnFfv4zeaqUfM= X-Original-To: isis-wg@ietfa.amsl.com Delivered-To: isis-wg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D205311E80F6; Tue, 9 Aug 2011 12:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aOAPgbT3k+oH; Tue, 9 Aug 2011 12:13:26 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 5B30111E80F1; Tue, 9 Aug 2011 12:13:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ginsberg@cisco.com; l=14606; q=dns/txt; s=iport; t=1312917236; x=1314126836; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=Son4AzeYahhvAxrjZyLMVcFW4ha3IorU3SdqeAD3tIo=; b=L7YmNAT8isAlzaPQP8NghzXNBestYpiXC4NiCSLCvkB4spl3VQEYTX6n urv5B+NVumqLjRzH/aj1qz+2AMoa5V77hUFwxLLknWJnKecB5U52fgx/1 l3zD2lusirU56KzZWLQmbszh5RiGveKp5Zvz+UsHivQZxPQARbqoZ82MP s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAKGFQU6rRDoI/2dsb2JhbABCl2CPXneBQAEBAQEDAQEBDwEJFDsDCwwEAgEIEQMBAQEBCgYXAQYBJh8JCAEBBAESCAESB4dPnnwBnmKFZ18Ehy0vkDuEXocb X-IronPort-AV: E=Sophos;i="4.67,344,1309737600"; d="scan'208";a="11441097" Received: from mtv-core-3.cisco.com ([171.68.58.8]) by rcdn-iport-8.cisco.com with ESMTP; 09 Aug 2011 19:13:55 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p79JDsNN024308; Tue, 9 Aug 2011 19:13:54 GMT Received: from xmb-sjc-222.amer.cisco.com ([128.107.191.106]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Aug 2011 12:13:54 -0700 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CC56C8.7AB2BB88" Date: Tue, 9 Aug 2011 12:13:52 -0700 Message-ID: In-Reply-To: <4E4143FA.1000307@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] Fwd: I-D Action: draft-simpson-isis-ppp-unique-02.txt Thread-Index: AcxWoJf9xRzMhpGdRkK47der37aY4AAJQ0kg References: <4E4143FA.1000307@gmail.com> From: "Les Ginsberg (ginsberg)" To: "William Allen Simpson" , "IETF PPP WG" X-OriginalArrivalTime: 09 Aug 2011 19:13:54.0508 (UTC) FILETIME=[7B1148C0:01CC56C8] X-BeenThere: isis-wg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Sender: isis-wg-bounces@ietf.org Errors-To: isis-wg-bounces@ietf.org X-PMX-Version: 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.8.9.190614 Cc: IETF TRILL WG , IETF ISIS WG Subject: Re: [Pppext] [Isis-wg] Fwd: I-D Action: draft-simpson-isis-ppp-unique-02.txt X-BeenThere: pppext@ietf.org List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 10:45:28 -0000 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): 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. 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: isis-wg-bounces@ietf.org [mailto:isis-wg-bounces@ietf.org] 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: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=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 > I-D-Announce@ietf.org > 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 > Isis-wg@ietf.org > 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 ; 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 ; 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 ; 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 ; 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: <4DB6A9B7.9010808@cisco.com> In-Reply-To: <4DB5AE7D.3020108@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Isis-wg] draft-simpson-isis-ppp-unique-00 Thread-Index: AcwEA60MKITARKCzQLK3YQts4HvItw== References: <4DB5AE7D.3020108@cisco.com> List-Help: List-Subscribe: , List-Unsubscribe: , From: "Mike Shand (mshand)" Sender: To: 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 > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg > _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org 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 _______________________________________________ Isis-wg mailing list Isis-wg@ietf.org https://www.ietf.org/mailman/listinfo/isis-wg ------_=_NextPart_001_01CC56C8.7AB2BB88-- From william.allen.simpson@gmail.com Wed Aug 10 06:32:16 2011 Return-Path: X-Original-To: pppext@ietfa.amsl.com Delivered-To: pppext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B872221F85C7; Wed, 10 Aug 2011 06:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.407 X-Spam-Level: X-Spam-Status: No, score=-3.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoS6CFXyMESk; Wed, 10 Aug 2011 06:32:16 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id 04BC021F84BF; Wed, 10 Aug 2011 06:32:11 -0700 (PDT) Received: by yie12 with SMTP id 12so753105yie.31 for ; Wed, 10 Aug 2011 06:32:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=+b+YLK5Pp6QvfvG72RSeD6LzpsEhLVKhRrw9C4iDd7A=; b=jviDkZ0BhGlm3xtx0xl8mLIsw7LYA4fua9kohsuRWJ1OZIVLvxRWOcnrVeHpXtAUs7 EwZEMbZ7Nv6MUa6GER4qodTw1/ZY+FUo1e5k4Ot7kZVPsswIO6ODrv5nl4ILF08+0rYI PUMMkVcjBeC/ErBYAa7C0d+wiEFJpeywQC8aE= Received: by 10.42.28.10 with SMTP id l10mr8731618icc.299.1312983163158; Wed, 10 Aug 2011 06:32:43 -0700 (PDT) Received: from Wastrel-3.local (c-68-40-194-239.hsd1.mi.comcast.net [68.40.194.239]) by mx.google.com with ESMTPS id o8sm1512473icc.17.2011.08.10.06.32.40 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 10 Aug 2011 06:32:41 -0700 (PDT) Message-ID: <4E428876.4080109@gmail.com> Date: Wed, 10 Aug 2011 09:32:38 -0400 From: William Allen Simpson User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: IETF PPP WG References: <4E4143FA.1000307@gmail.com> <4E41A666.4090200@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IETF TRILL WG , IETF ISIS WG Subject: Re: [Pppext] [Isis-wg] Fwd: I-D Action: draft-simpson-isis-ppp-unique-02.txt X-BeenThere: pppext@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: PPP Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2011 13:32:16 -0000 On 8/9/11 9:23 PM, Les Ginsberg (ginsberg) wrote: > 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. > 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.] > 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. It is not commonplace for them to consider their own LSPs as coming from a neighbor. > ... 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. > Let's look at the text from -00 and -01, now clause (a) in -02: After detecting a conflicting System Identifier in a neighbor, or 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. ;-) (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; 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.