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