Re: [Isis-wg] draft-wei-isis-tlv-03 (Purge Originator Id)

Tony Li <tony.li@tony.li> Thu, 22 April 2010 06:40 UTC

Return-Path: <tony.li@tony.li>
X-Original-To: isis-wg@core3.amsl.com
Delivered-To: isis-wg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86B73A6B61 for <isis-wg@core3.amsl.com>; Wed, 21 Apr 2010 23:40:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.483
X-Spam-Level:
X-Spam-Status: No, score=-0.483 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0MaCddyFJ2-N for <isis-wg@core3.amsl.com>; Wed, 21 Apr 2010 23:40:02 -0700 (PDT)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by core3.amsl.com (Postfix) with ESMTP id DA4F13A6B50 for <isis-wg@ietf.org>; Wed, 21 Apr 2010 23:40:01 -0700 (PDT)
Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta06.westchester.pa.mail.comcast.net with comcast id 8WfN1e0040xGWP856WftfP; Thu, 22 Apr 2010 06:39:53 +0000
Received: from [10.21.126.91] ([128.107.239.233]) by omta12.westchester.pa.mail.comcast.net with comcast id 8WfR1e00452qHCY3YWfY6i; Thu, 22 Apr 2010 06:39:51 +0000
User-Agent: Microsoft-Entourage/12.24.0.100205
Date: Wed, 21 Apr 2010 23:39:23 -0700
From: Tony Li <tony.li@tony.li>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, lizhenqiang@chinamobile.com, Jie Dong <dongjie_dj@huawei.com>, "bruno.decraene@orange-ftgroup.co" <bruno.decraene@orange-ftgroup.com>, isis-wg@ietf.org, weifang@chinamobile.com
Message-ID: <C7F53D2B.D1DE%tony.li@tony.li>
Thread-Topic: [Isis-wg] draft-wei-isis-tlv-03 (Purge Originator Id)
Thread-Index: Acrh4FbhQCKXorU8IEyfaa52mhUZFAAAYm3QAAEqsOs=
In-Reply-To: <AE36820147909644AD2A7CA014B1FB520A9E2E79@xmb-sjc-222.amer.cisco.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: [Isis-wg] draft-wei-isis-tlv-03 (Purge Originator Id)
X-BeenThere: isis-wg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF IS-IS working group <isis-wg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isis-wg>
List-Post: <mailto:isis-wg@ietf.org>
List-Help: <mailto:isis-wg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isis-wg>, <mailto:isis-wg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Apr 2010 06:40:03 -0000

Hi Les,

> But hopefully we can comment on 01 anyway?? :-)

Of course!  ;-)

> I don't see the need for Section 3. It was interesting discussion
> material while we were debating the merits of making this a WG document,
> but I think it has drawbacks when it is included in what is intended to
> become a standards document.

Well, the point was to help document some of the field failures that we've
seen and motivate the changes.
 
> In the second set of three points, only the first (which documents the
> lamentable purge on checksum error experience) has value. The last two
> are anecdotal and could be translated as "there are some weird bugs out
> there". Interesting - but unnecessary. The first point could be
> mentioned in the introduction as part of the justification for the
> protocol extensions - but I think even that is unnecessary.

True, but without the background, these changes would seem like something
straight out of the Oort cloud.

Compromise: condense the text and move to the introduction?


> In Section 5 I would like to see language which says "hostname TLV
> SHOULD only be used in addition to the system ID TLV". As every IS MUST
> have a unique systemID but hostnames are optional I would prefer that if
> an implementation chooses to include the extra info in the purge that
> the system ID ALWAYS be there. (This is unenforceable of course)


Works for me.  Other folks?


> I think there needs to be language which makes clear that the absence or
> presence of this additional information has no impact on the acceptance
> of a purged LSP as valid i.e. no changes to the operation of the Update
> process are introduced by this draft.


Can't hurt.  I'm certain that this will break some conformance testers
regardless.  

Any other comments?

Tony