RE: [16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-ipv6cs (IPv6 Over the IP Specific part of the Packet Convergence sublayer in 802.16 Networks) to Proposed Standard

qinxia <alice.Q@huawei.com> Thu, 22 March 2007 06:44 UTC

Return-path: <16ng-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUH23-0008Od-3O; Thu, 22 Mar 2007 02:44:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HUH21-0008OC-HA; Thu, 22 Mar 2007 02:44:17 -0400
Received: from szxga02-in.huawei.com ([61.144.161.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HUH1z-0001yB-Mj; Thu, 22 Mar 2007 02:44:17 -0400
Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JFA00FTILCHHB@szxga02-in.huawei.com>; Thu, 22 Mar 2007 14:43:29 +0800 (CST)
Received: from huawei.com ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0JFA00C9BLCGH0@szxga02-in.huawei.com>; Thu, 22 Mar 2007 14:43:29 +0800 (CST)
Received: from jys7010921 (dhcp-4009.ietf68.org [130.129.64.9]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JFA001J0LBNOU@szxml02-in.huawei.com>; Thu, 22 Mar 2007 14:43:28 +0800 (CST)
Date: Thu, 22 Mar 2007 07:43:52 +0800
From: qinxia <alice.Q@huawei.com>
Subject: RE: [16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-ipv6cs (IPv6 Over the IP Specific part of the Packet Convergence sublayer in 802.16 Networks) to Proposed Standard
In-reply-to: <C21DC170.3170A%basavaraj.patil@nokia.com>
To: 'Basavaraj Patil' <basavaraj.patil@nokia.com>, 'ext Alexandru Petrescu' <alexandru.petrescu@gmail.com>
Message-id: <000101c76c12$d3375b20$3d138182@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcdmdSKJYPyizdJoEduVIAARJNUNiAFnEPiw
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0
Cc: ipv6@ietf.org, ietf@ietf.org, 'IETF-Announce' <ietf-announce@ietf.org>, 16ng@ietf.org
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
Errors-To: 16ng-bounces@ietf.org

Hello all,

            My two cents. Please see inline.
Best wishes,
alice
> -----Original Message-----
> From: Basavaraj Patil [mailto:basavaraj.patil@nokia.com]
> Sent: Thursday, March 15, 2007 4:13 AM
> To: ext Alexandru Petrescu
> Cc: ipv6@ietf.org; ietf@ietf.org; IETF-Announce; 16ng@ietf.org
> Subject: Re: [16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-ipv6cs (IPv6
Over
> the IP Specific part of the Packet Convergence sublayer in 802.16
Networks)
> to Proposed Standard
> 
> 
> Alex,
> 
> 
> On 3/14/07 11:47 AM, "ext Alexandru Petrescu"
<alexandru.petrescu@gmail.com>
> wrote:
> 
> > Basavaraj Patil wrote:
> >> Hello,
> >>
> >> A slightly revised version of the I-D is now available at:
> >>
> http://people.nokia.net/~patil/IDs/draft-ietf-16ng-ipv6-over-ipv6cs-09.txt
> >>
> >> This revision incorporates changes based on some of the comments made
by
> the
> >> directorate. It will be submitted to the ID repository as soon as the
gates
> >> are opened.
> >
> > Raj, is there a plan to deal with the interoperability issue where the
> > AP tells the Station to auto-configure statelessly and the AR tells it
> > statefully?
> >
[qinxia] 
My question is what is the situation when AP select different address
configuration with AR?  IMHO, it is up to deployment.

> > The AP may send REG-RSP telling the Station to use DHCP.
> >
[qinxia]  address configuration is indicated over RA. This is enough.

> > The AR may send an RA telling the Station to use SLAAC.
> 
> The issue arises when we consider managed and unmanaged hosts as defined
by
> 802.16. Managed hosts are the ones that may use the secondary management
> connection. Secondary management connection is optional and as we have
> discussed in the past this is an option in the .16 specs that exists but
> very likely unused. I can tell you that in the case of Mobile WiMAX the
> secondary management connection is not used.
> 
> I agree that a BS and the AR should be synchronized in terms of what
method
> is indicated to the MS for address configuration.

[qinxia]  sure, SMC may not be exist. However, RA may be transported over
regular connection. RA could be used to indicate the address configuration. 
> 
> >
> > There may be an interoperability issue, if the two indicators are
different.
> 
> Yes.
> 
> >
> > This issue can of course be considered as a network management issue,
> > where advice could be given to network deployers of AR and AP to
> > configure their networks correctly.
> 
> Correct. A deployment should be able to ensure that the indication to the
MS
> in the REG-RSP and RA are synchronized. I can add some text in the I-D to
> ensure that this issue is noted in the address configuration section.
> 
> >
> > And this is a time when both 802.16 is changing (Corrigendum 2 under
> > discussion but still allows AP to indicate to MN what autoconf method to
> > use) and the RA definition is changing (draft-2462bis indicates 'M' flag
> > may not be used, but an 'autonomous' flag instead).
> >
> > What do you think?  Do I get this issue correctly?  Or is the issue
> > important, less important, etc.
> 
> This is a valid issue but I think it can be clarified in the I-D itself by
> recognizing it and recommending that the indication by the BS and AR are
> synced. We can also mention it to IEEE but that is about the scope of
things
> that we can do.
> 
> -Raj
> 
> >
> > Thanks,
> >
> > Alex
> >
> >
> > ______________________________________________________________________
> > This email has been scanned by the MessageLabs Email Security System.
> > For more information please visit http://www.messagelabs.com/email
> > ______________________________________________________________________
> 
> 
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf



_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng