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

William Allen Simpson <william.allen.simpson@gmail.com> Tue, 09 August 2011 14:27 UTC

Return-Path: <william.allen.simpson@gmail.com>
X-Original-To: pppext@ietfa.amsl.com
Delivered-To: pppext@ietfa.amsl.com
Received: from localhost (localhost []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) 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 <multiple recipients>; 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 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 []) by mx.google.com with ESMTPS id fu7sm5066902ibb.36.2011. (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 <william.allen.simpson@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: IETF PPP WG <pppext@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: IETF TRILL WG <rbridge@postel.org>, IETF ISIS WG <isis-wg@ietf.org>
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 <pppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pppext>, <mailto:pppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pppext>
List-Post: <mailto:pppext@ietf.org>
List-Help: <mailto:pppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Aug 2011 14:27:45 -0000


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:

Internet-Drafts are also available by anonymous FTP at:

This Internet-Draft can be retrieved at:
I-D-Announce mailing list
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt