[Isis-wg] draft-ietf-isis-genapp

"Ilya Varlashkin" <Ilya.Varlashkin@de.easynet.net> Mon, 01 September 2008 16:08 UTC

Return-Path: <isis-wg-bounces@ietf.org>
X-Original-To: isis-archive@megatron.ietf.org
Delivered-To: ietfarch-isis-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C8FED3A6894; Mon, 1 Sep 2008 09:08:32 -0700 (PDT)
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 3DE123A6816 for <isis-wg@core3.amsl.com>; Mon, 1 Sep 2008 09:08:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level:
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001]
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 wpQzRsZuGHf3 for <isis-wg@core3.amsl.com>; Mon, 1 Sep 2008 09:08:31 -0700 (PDT)
Received: from softy.ision.net (softy.ision.net [194.163.250.97]) by core3.amsl.com (Postfix) with ESMTP id 7501F3A6A2D for <isis-wg@ietf.org>; Mon, 1 Sep 2008 09:06:28 -0700 (PDT)
Received: from paul.de.easynet.net ([195.180.208.152] helo=paul.adoffice.de.easynet.net) by softy.ision.net with esmtp (Exim 4.50) id 1KaBvE-0001lT-Ui for isis-wg@ietf.org; Mon, 01 Sep 2008 18:06:33 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 1 Sep 2008 18:06:32 +0200
Message-ID: <7000E71D8C525042A815432358B2F1240138D679@paul.adoffice.local.de.easynet.net>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: draft-ietf-isis-genapp
Thread-Index: AckMTLNnAlJoySDjSVmfT0NksyZpeQ==
From: "Ilya Varlashkin" <Ilya.Varlashkin@de.easynet.net>
To: "IETF IS-IS" <isis-wg@ietf.org>
Subject: [Isis-wg] draft-ietf-isis-genapp
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/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: isis-wg-bounces@ietf.org
Errors-To: isis-wg-bounces@ietf.org

Hi All,

I've went once more through the draft and have few questions. 

1) What correct implementation should do if it received GENINFO TLV when
specific node doesn't have a client for arbitrary Application ID or when
it has given AppID but expected different format of the address?

2) Should address info really belong to GENINFO TLV itself and not to
e.g. "Additional Application Specific Info"? Consider GENAPP is used to
carry info about multiple AFI (e.g. IPv4, IPv6, VPNv4) for given node.
Wouldn't it be better to pack address along with AFI info either in
sub-TLV or in App-Specific info section of the TLV? Such approach could
avoid confusion as to which AFI address belong to when same application
(AppID) is used with multiple AFI.

3) Section 3.3 restricts usage of GENAPP for experimental and
propriatory usage. Does it have to be so? Considering that GENAPP
doesn't really care what's inside App-Specific info, then anyone could
potentially put any sort of info to it (and take responsibility within
his/her realm for doing so), is it really bad? For example, I may want
to experiment with distribution of some network information using GENAPP
but I'm not yet sure whether it will benefit community at large or only
specific part of it, so this is sort of experiment. Doing so do I make
implementation non-compliant?

4) To section 4.1: it may sometimes be desirable to do selective
downwards leaking based on either AppID or even app-specific info (e.g.
I want some App's be leaked across whole Level1-level2-level1 path,
while others only Level1-Level2 and no further). Would it make sense to
add a word that this is valid thing to do? This is mostly to prevent
problems when one implementation provides such selective leaking
facility, while the other one (found on the same network) assumes that
is somebody leaked something then information was complete (and use it
for any sort of integrity/sanity) checking.

5) To section 5: while it's definetely desirable to use multiple
instances, does it have to be restricted at the implementation level or
could choice be left to network operator (with defaulting to multiple
instances if GENAPP extentions are enable)?

6) Should or should not GENAPP extention be turned off by default and
enabled only by explicit knob (as follow-up on item (5) above)?

Kind regards,
iLya
_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www.ietf.org/mailman/listinfo/isis-wg