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 ; 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 ; 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 ; 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 ; Mon, 8 Jul 2002 11:59:58 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 8 Jul 2002 11:59:57 -0400 Message-ID: <9FBD322B7824D511B36900508BF93C9C01AA4BED@zcard031.ca.nortel.com> From: "Gary Kenward" To: "'seamoby@ietf.org'" , "'NSIS'" Date: Mon, 8 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 X-BeenThere: seamoby@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C22698.7DF6A1F8 Content-Type: text/plain; charset="iso-8859-1" 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 ------_=_NextPart_001_01C22698.7DF6A1F8 Content-Type: text/html; charset="iso-8859-1" Re: draft-westphal-nsis-qos-mobileip-00.txt

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


------_=_NextPart_001_01C22698.7DF6A1F8-- _______________________________________________ Seamoby mailing list Seamoby@ietf.org https://www1.ietf.org/mailman/listinfo/seamoby