Subject: [trill] Fwd: I-D Action: draft-chen-trill-isis-purge-01.txt

From: GangChen <[email-masked]>
Date: Wed, 17 Jul 2013 14:27:44 +0800

wg,

I have updated the draft according to the received comments
This draft intended to help root cause analysis in a trill environment

Your comments are appreciated

BRs

Gang
---------- Forwarded message ----------
From: [email-masked]
Date: Mon, 15 Jul 2013 08:02:10 -0700
Subject: I-D Action: draft-chen-trill-isis-purge-01.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Extension to Purge Initiator Identification TLV for
ISIS in TRILL
	Author(s)       : Gang Chen
	Filename        : draft-chen-trill-isis-purge-01.txt
	Pages           : 4
	Date            : 2013-07-15

Abstract:
   This memo specified an extension of ISIS TLV for identifying purge
   initiator in TRILL environments.  With the extension, it's beneficial
   for operators to nail down the root cause when there is a corrupted
   Link State Protocol (LSP) data unit spread within a layer-2 network.
   The defined TLV is expected to record Nickname and impacted VLAN
   information.  RBridge should propagate the TLV information without
   changes in order to flood the information.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-chen-trill-isis-purge

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-chen-trill-isis-purge-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-chen-trill-isis-purge-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
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: Donald Eastlake <[email-masked]>
Date: Mon, 22 Jul 2013 20:25:07 -0400

Hi Gang,

> This draft intended to help root cause analysis in a trill environment

Thanks for your contribution.

Perhaps I am confused but I don't really see how this proposed TLV
helps very much. Here are a few comments:

- Why is it useful to use nickname rather than System ID? System ID is
the fundamental and unique identification of an IS-IS router within an
area. I think of a nickname as just an abbreviation for the System ID.
While very unlikely, it is possible for the nickname to change. So
using the IS-IS System ID, as the Purge Originator Identification
(POI) TLV (RFC 6232) does, seems like a better idea.

- The draft seems to assume that you might use this new TLV when you
initiate a purge on receiving a corrupted LSP as well as on receiving
a purge without the TLV. I believe that you were supposed to initiate
a purge on receiving a corrupt LSP under the 1992 version of ISO 10589
but this was changed by Corrigendum 1 issued in 1993 and is no longer
in the 2002 standard which says to just drop received corrupt LSPs. If
you are proposing a change in the handling of a received corrupt LSP,
I would think that should go through the ISIS WG, not the TRILL WG.

- If the idea is to help trace problems and this TLV is used in
connection with the receipt of an LSP (whether that LSP is a purge or
is corrupted or whatever), then it would seem useful to add the
identity of the IS from which the LSP was received, as the POI TLV
does. Wording in your draft indicates that this should be done but the
actually data format you give doesn't seem to provide for it.

- The TLV provides an optional slot for one VLAN ID. But if the TLV is
supposed to relate to one LSP, while that LSP might have been relevant
to zero or one VLANs it might just as well have been relevant to a
dozen or more. In any case, if this TLV is somehow supposed to be used
in response to a corrupt LSP, how would you know what VLAN it was
relevant to? Any VLAN IDs in a corrupt LSP might themselves be
corrupt.

Anyway, those are the first things that come to mind on reading your draft.

I think the existing POI TLV, specified in RFC 6232, should be used in
TRILL and do not see a need for the new TLV described in your current
draft.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill