[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
- [Isis-wg] draft-ietf-isis-genapp Ilya Varlashkin
- Re: [Isis-wg] draft-ietf-isis-genapp Les Ginsberg (ginsberg)