Re: [NSIS] GIST updated from todays IESG call
Roland Bless <bless@tm.uka.de> Tue, 21 April 2009 09:34 UTC
Return-Path: <bless@tm.uka.de>
X-Original-To: nsis@core3.amsl.com
Delivered-To: nsis@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DC853A6AD3; Tue, 21 Apr 2009 02:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.059
X-Spam-Level:
X-Spam-Status: No, score=-6.059 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 HtXvO+zSJvWA; Tue, 21 Apr 2009 02:34:20 -0700 (PDT)
Received: from iramx2.ira.uni-karlsruhe.de (iramx2.ira.uni-karlsruhe.de [141.3.10.81]) by core3.amsl.com (Postfix) with ESMTP id 0C0923A6AE2; Tue, 21 Apr 2009 02:34:19 -0700 (PDT)
Received: from irams1.ira.uni-karlsruhe.de ([141.3.10.5]) by iramx2.ira.uni-karlsruhe.de with esmtps id 1LwCO3-0003Nt-Fa; Tue, 21 Apr 2009 11:35:34 +0200
Received: from i72ms.tm.uni-karlsruhe.de ([141.3.70.5] helo=smtp.ipv6.tm.uni-karlsruhe.de) by irams1.ira.uni-karlsruhe.de with esmtps id 1LwCO3-0000pS-96; Tue, 21 Apr 2009 11:35:31 +0200
Received: from vorta.tm.uka.de (vorta.ipv6.tm.uni-karlsruhe.de [IPv6:2001:638:204:6:21b:fcff:fe96:fe02]) by smtp.ipv6.tm.uni-karlsruhe.de (Postfix) with ESMTP id 2044C2FC018; Tue, 21 Apr 2009 11:35:31 +0200 (CEST)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by vorta.tm.uka.de (Postfix) with ESMTP id 0AE71101C2; Tue, 21 Apr 2009 11:35:31 +0200 (CEST)
Message-ID: <49ED9362.4050206@tm.uka.de>
Date: Tue, 21 Apr 2009 11:35:30 +0200
From: Roland Bless <bless@tm.uka.de>
Organization: Institute of Telematics, University of Karlsruhe
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.1) Gecko/20060111 Thunderbird/1.5 Mnenhy/0.7.3.0
MIME-Version: 1.0
To: gash5107@yahoo.com
References: <315481.66436.qm@web63602.mail.re1.yahoo.com>
In-Reply-To: <315481.66436.qm@web63602.mail.re1.yahoo.com>
X-Enigmail-Version: 0.95.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-ATIS-AV: ClamAV (irams1.ira.uni-karlsruhe.de)
X-ATIS-AV: ClamAV (iramx2.ira.uni-karlsruhe.de)
X-ATIS-AV: Kaspersky (iramx2.ira.uni-karlsruhe.de)
Cc: iesg@ietf.org, NSIS <nsis@ietf.org>
Subject: Re: [NSIS] GIST updated from todays IESG call
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/nsis>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Apr 2009 09:34:22 -0000
Hi Jerry and all, Gerald Ash wrote: > 1. IMO after 8 years of hard work on NSIS, the WG deserves more of an > explanation for downgrading GIST to experimental than “the IESG was > deadlocked”. What is the *technical* explanation for why the IESG > DISCUSS’s could not be resolved? After several years of IESG review, IMHO it's not the DISCUSSes that cannot be resolved. It's just that the majority of IESG members have changed several times over the long period, the WG chair has changed and major proponents of the NSIS approach have left the IESG. Therefore, IESG people seem to have pulled in different directions, esp. if you consider the RAO discussion. We couldn't get it right from the beginning since some people said: "Oh, please use RAO for interception" and others said "don't use it, it's broken". For some people, RAO is an already deployed (but poorly defined and badly implemented) means and more efficient than any other alternative, for others it's not usable in a general scope and will cause deployment problems. Any alternative, like the one specified now, seems to be disliked also, because it's not very efficient to process in the fast path. Gee, a *constructive* criticism or even *help* from the IESG would be really appreciated. > the main DISCUSS issue still appears to be how to detect GIST packets: > RAO is unacceptable (although it did pass an earlier IESG review); > port/magick is a “non starter”. There is no proposed resolution offered > in any of the DISCUSS comments. Is there no acceptable way (to the > IESG) to detect GIST packets? We are not privy to the discussion that > must have taken place. > Request: Perhaps an IESG member could write a “majority opinion” to > explain to the NSIS WG why this DISCUSS issue (and any others) could not > be resolved. I would go further: I think the IESG should really come up with a *constructive* proposal how to resolve the issue. As I said: the WG has done everything to get it right, but obviously the IESG has changed too quickly before we could get it right. :-) Furthermore, I want to mention that the path-coupled signaling MRM is only *one* method. GIST is flexible enough to use others. > 2. A couple of IESG comments cast doubt on the need/motivation for > NSIS. The NSIS BOF was held at IETF-50 (March 2001). Several comments > made at the BOF (documented at > http://www.ietf.org/proceedings/01mar/index.html, search “nsis”) > identify the perceived need for improvement in signaling protocols. Bob > Braden published an I-D proposing the 2-layer NSIS architecture at > http://www.watersprings.org/pub/id/draft-braden-2level-signal-arch-01.txt > (his CSTP became GIST). An analysis of existing signaling protocols was > published in RFC 4094 http://www.ietf.org/rfc/rfc4094.txt. Surely much > has changed over 8 years and problems may have been fixed and needs > vanished thus nullifying the original motivation? > > Request: Perhaps people with a long view could comment on the evolution > of problems/needs over this 8 year period. I still think that we need a flexible and new signaling solution and that RSVP is not really well suited for many signaling applications other than RSVP-TE. GIST supports mobility, provides Session-ID and Peer-IDs, various signaling routing methods, denial of service protection, flexible use of different transports, and security features. I guess it's more the lack of willingness to implement another signaling protocol into router software. Regards, Roland
- [NSIS] GIST updated from todays IESG call Magnus Westerlund
- Re: [NSIS] GIST updated from todays IESG call Martin Stiemerling
- Re: [NSIS] GIST updated from todays IESG call Georgios Karagiannis
- Re: [NSIS] GIST updated from todays IESG call Roland Bless
- Re: [NSIS] GIST updated from todays IESG call Xiaoming Fu
- Re: [NSIS] GIST updated from todays IESG call Gerald Ash
- Re: [NSIS] GIST updated from todays IESG call Roland Bless
- Re: [NSIS] GIST updated from todays IESG call Roland Bless
- Re: [NSIS] GIST updated from todays IESG call Magnus Westerlund
- Re: [NSIS] GIST updated from todays IESG call Ross Callon