RE: [NSIS] NSLP versioning
"Robert Hancock" <robert.hancock@roke.co.uk> Sun, 11 June 2006 23:53 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZkS-0006Gf-7B; Sun, 11 Jun 2006 19:53:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpZkR-0006GV-1f for nsis@ietf.org; Sun, 11 Jun 2006 19:53:39 -0400
Received: from rsys002x.roke.co.uk ([193.118.201.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpZkM-0004Qs-C7 for nsis@ietf.org; Sun, 11 Jun 2006 19:53:39 -0400
Received: from rsys005a.comm.ad.roke.co.uk (rsys005a [193.118.193.85]) by rsys002x.roke.co.uk (8.13.1/8.13.1) with ESMTP id k5BNrJSX015615; Mon, 12 Jun 2006 00:53:23 +0100
Received: from ac78840 ([193.118.192.66]) by rsys005a.comm.ad.roke.co.uk with Microsoft SMTPSVC(6.0.3790.1830); Mon, 12 Jun 2006 00:53:19 +0100
From: Robert Hancock <robert.hancock@roke.co.uk>
To: john.loughney@nokia.com, stiemerling@netlab.nec.de, bless@tm.uka.de
Subject: RE: [NSIS] NSLP versioning
Date: Mon, 12 Jun 2006 00:53:18 +0100
Message-ID: <000601c68db2$36bfc370$f40a7356@comm.ad.roke.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <BAA65A575825454CBB0103267553FCCC39C930@esebe199.NOE.Nokia.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
Importance: Normal
X-OriginalArrivalTime: 11 Jun 2006 23:53:19.0192 (UTC) FILETIME=[36EE4D80:01C68DB2]
X-MailScanner-roke.co.uk: Found to be clean
X-MailScanner-roke.co.uk-SpamCheck:
X-MailScanner-From: robert.hancock@roke.co.uk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
Cc: nsis@ietf.org
X-BeenThere: nsis@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Next Steps in Signaling <nsis.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:nsis@ietf.org>
List-Help: <mailto:nsis-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/nsis>, <mailto:nsis-request@ietf.org?subject=subscribe>
Errors-To: nsis-bounces@ietf.org
hi all, the problem here is that if the NSLP version is encoded in the NSLPID, version negotation becomes quite hard and incremental deployment of a new version very hard. example: *) node A supports versions 1 and 2; *) it issues a query for version 1; *) it gets a response from node B which supports version 1 and 2, but: the only version they will ever use is version 1 unless A re-Queries for version 2 (the routing state is tied to the NSLP version). second attempt: *) node A supports versions 1 and 2; *) it issues a query for version 2; *) the Query is seen by node B' which only supports version 1, so it has to bypass the Query to the next node down the path. i think there is a relatively simple class of solutions to this problem, where a single NSLPID defines a family of versions, and NSLP messages include a version number. you signal your highest supported version by replying to messages about an unsupported version with an error. you can even put NSLP data in the query to conduct version negotiation as part of route setup. (of course, there are loads of other solutions on the same general pattern. the principle point is not to use different NSLP IDs for different versions.) r. > -----Original Message----- > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com] > Sent: 09 June 2006 14:22 > To: stiemerling@netlab.nec.de; bless@tm.uka.de > Cc: nsis@ietf.org > Subject: RE: [NSIS] NSLP versioning > > > > >>> There is still a not completely solved issue back from > the old days > >>> (2004) about NSLP versioning. It is about wether an NSLP can have > >>> multiple versions or not. > >> > >> I would say yes, naturally it can. The question is > probably what can > >> be considered as an appropriate demultiplexer. > >> So what is the issue exactly? Whether there should be an > >NSLP version > >> field in the NSLP protocol itself? The current alternative > >is to use a > >> different NSLP ID for each version, thus using the NSLP ID > >in GIST as > >> demultiplexing value. Since the NSLP ID is 16bit I guess > that there > >> are no issues here. So as long as we assume GIST as underlying > >> transport (or some other protocol at least carrying > session ID, MRM, > >> NSLPID and so on) there is no problem here. There is only > trouble if > >> all you have is the NSLP data packet alone. > > > >The issue here is whether an NSIS initiator should have the > >ability to ask with a single request message for multiple, > >different NSLP version. > >This would require a single general NSLP-ID per NSLP and a > >version information with the NSLP itself. > > > >I do not know if this issue is solvable by now or if it should > >be handled in the NSLP extensibility draft. Since we have only > >a single version anyway of each NSLP. > > Is there anyone requesting this feature, it sounds extremely messy to > actually get working. > > John > > _______________________________________________ > nsis mailing list > nsis@ietf.org > https://www1.ietf.org/mailman/listinfo/nsis > _______________________________________________ nsis mailing list nsis@ietf.org https://www1.ietf.org/mailman/listinfo/nsis
- [NSIS] NSLP versioning Martin Stiemerling
- Re: [NSIS] NSLP versioning Roland Bless
- Re: [NSIS] NSLP versioning Martin Stiemerling
- RE: [NSIS] NSLP versioning john.loughney
- RE: [NSIS] NSLP versioning Robert Hancock
- Re: [NSIS] NSLP versioning Roland Bless
- [NSIS] partly-decoupled signalling work Robert Hancock
- RE: [NSIS] partly-decoupled signalling work Ash, Gerald R (Jerry), ALABS
- RE: [NSIS] partly-decoupled signalling work john.loughney
- Re: [NSIS] partly-decoupled signalling work Hannes Tschofenig
- RE: [NSIS] partly-decoupled signalling work john.loughney
- Re: [NSIS] partly-decoupled signalling work Magnus Westerlund
- Re: [NSIS] partly-decoupled signalling work Hannes Tschofenig
- RE: [NSIS] partly-decoupled signalling work Robert Hancock
- Re: [NSIS] partly-decoupled signalling work Magnus Westerlund