[Seamoby] Re: draft-westphal-nsis-qos-mobileip-00.txt

"Gary Kenward" <gkenward@nortelnetworks.com> Mon, 08 July 2002 16:06 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21759 for <seamoby-archive@odin.ietf.org>; Mon, 8 Jul 2002 12:06:12 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27798; Mon, 8 Jul 2002 12:00:39 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27690 for <seamoby@optimus.ietf.org>; Mon, 8 Jul 2002 12:00:33 -0400 (EDT)
Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21319 for <seamoby@ietf.org>; Mon, 8 Jul 2002 11:59:37 -0400 (EDT)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g68Fxw920523 for <seamoby@ietf.org>; Mon, 8 Jul 2002 11:59:58 -0400 (EDT)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <NYVCA0CX>; Mon, 8 Jul 2002 11:59:57 -0400
Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BED@zcard031.ca.nortel.com>
From: Gary Kenward <gkenward@nortelnetworks.com>
To: "'seamoby@ietf.org'" <seamoby@ietf.org>, 'NSIS' <nsis@ietf.org>
Date: Mon, 08 Jul 2002 11:59:51 -0400
Sensitivity: Company-Confidential
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22698.7DF6A1F8"
Subject: [Seamoby] Re: draft-westphal-nsis-qos-mobileip-00.txt
Sender: seamoby-admin@ietf.org
Errors-To: seamoby-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Context Transfer, Handoff Candidate Discovery, and Dormant Mode Host Alerting <seamoby.ietf.org>
X-BeenThere: seamoby@ietf.org

I finally managed to find time to read through Cedric's and Hemant's draft.
Overally, I think it is a good description of one possible integrated
approach.

The one general comment I would like to offer up at this time, is that while

the draft does a good job of integrating MIP, CT and NSIS concepts, the 
proposed solutions for QoS negotiation between MN and AN (e.g. the use of
the 
CIN message) is NSIS not CT.

CT is concerned with the transfer of forwarding service context between
ANRs. 
NSIS is concerned with the signalling of service requirements. Thus, the
issue
is not how to interwork the "CT" CIN, for example, with NSIS signalling, but
how 
the CIN, etc., form part of the NSIS solution.

This is not simply an issue of adherence to Seamoby/NSIS models or charters.
The intention has always been that CT work as a context transfer mechanism
with a variety of mobility and service signalling solutions. There is a
significant 
benefit in the real world to be realized in keeping the context transfer
solution
(CT) independent from the service signalling solution (NSIS) (and the
mobility 
solution - MIP or whatever). I would think that there is also a benefit to
keeping
the MN to AR service signalling independent of CT.

Stated a different way, do we really need two separate solutions for over
the air 
(MN to AN) service signalling? 

Regards,
Gary Kenward