Re: [Isis-wg] New version of draft-wei-isis-tlv

Tony Li <tony.li@tony.li> Fri, 05 March 2010 17:09 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 8043E3A8A8F for <isis-wg@core3.amsl.com>; Fri, 5 Mar 2010 09:09:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.338
X-Spam-Level:
X-Spam-Status: No, score=-1.338 tagged_above=-999 required=5 tests=[AWL=1.262, BAYES_00=-2.599]
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 qrfJvNqh79M9 for <isis-wg@core3.amsl.com>; Fri, 5 Mar 2010 09:09:27 -0800 (PST)
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 739173A8FED for <isis-wg@ietf.org>; Fri, 5 Mar 2010 09:09:27 -0800 (PST)
Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta06.westchester.pa.mail.comcast.net with comcast id pU4l1d03p1HzFnQ56V9WRo; Fri, 05 Mar 2010 17:09:30 +0000
Received: from [10.21.124.84] ([128.107.239.233]) by omta14.westchester.pa.mail.comcast.net with comcast id pV931d00D52qHCY3aV98Gu; Fri, 05 Mar 2010 17:09:28 +0000
User-Agent: Microsoft-Entourage/12.23.0.091001
Date: Fri, 05 Mar 2010 09:09:01 -0800
From: Tony Li <tony.li@tony.li>
To: lizhenqiang@chinamobile.com, 'isis-wg' <isis-wg@ietf.org>
Message-ID: <C7B67AAD.4C5C%tony.li@tony.li>
Thread-Topic: [Isis-wg] New version of draft-wei-isis-tlv
Thread-Index: Acq8hoz1RtJ7U2JS602HzQ+c8SVQ0Q==
In-Reply-To: <OF97E5D0F0.BB1A9A9A-ON482576DD.004411A5-482576DD.004411B6@china.mobile>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Cc: rcallon@juniper.net, Chris Hopps <chopps@rawdofmt.org>, daniel@olddog.co.uk, adrian.farrel@huawei.com
Subject: Re: [Isis-wg] New version of draft-wei-isis-tlv
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: Fri, 05 Mar 2010 17:09:28 -0000

On 3/5/10 4:23 AM, "lizhenqiang@chinamobile.com"
<lizhenqiang@chinamobile.com> wrote:

> Hello ISIS fans,
> 
> A new version of draft-wei-isis-tlv was submitted to IETF just now. Comments
> are welcome. Thank you all for your discussion here.


Hi,

I've reviewed the new version of the draft and have a few comments:

1) I believe that we have some amount of agreement that the TLV for
backtracking purges is of some value.  However, the situations where it does
add value are all of the legitimate cases to initiate a purge.  As has been
noted, the implementations that generate a purge on a checksum error not
operating within the spec and should be repaired.  It is wholly unreasonable
to expect that an implementation that has this defect is going to
subsequently implement the new TLV.  Thus, the discussion of the purge on
checksum case is not a motivator for the addition of this TLV.  As such, I
recommend that the text discussing this case be removed.

2) You state "ISIS protocol is vulnerable to purge packet propagation."  The
use of the word "vulnerability" implies that there is a defect, and further
implies that there is a security defect.  Neither of these is true.  I
recommend that you reword this sentence to something like: "The IS-IS
protocol floods purges throughout an area, regardless of which IS initiated
the purge.  If a network operator would like to investigate the cause of the
purge, it is difficult to determine the origin of the purge."

3) Your section on security considerations is insufficient.  We need to
clearly specify how this TLV is used when constructing a purge.  What is
needed here is not very difficult.  Something similar to: "If this TLV is
used in conjunction with IS-IS authentication mechanisms, then the purge is
constructed by removing the original contents of the LSP, leaving only the
LSP header, adding this TLV and then adding the IS-IS authentication TLV.
This document amends the behavior of [RFC5304] and [RFC5310]."

4) Editorial stuff: you appear to be having some formatting issues, whereby
you only get one section per page.  May I recommend xml2rfc as a fine tool?
Also, your draft needs some extensive proofreading.

Regards,
Tony