Re: [16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-ipv6cs
Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 15 March 2007 11:15 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 1HRnvS-0001PT-8q; Thu, 15 Mar 2007 07:15:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.43)
id 1HRnvO-0001NY-RL; Thu, 15 Mar 2007 07:15:14 -0400
Received: from mail153.messagelabs.com ([216.82.253.51])
by ietf-mx.ietf.org with smtp (Exim 4.43)
id 1HRnvM-0006Oa-E5; Thu, 15 Mar 2007 07:15:14 -0400
X-VirusChecked: Checked
X-Env-Sender: alexandru.petrescu@gmail.com
X-Msg-Ref: server-13.tower-153.messagelabs.com!1173957307!5103290!1
X-StarScan-Version: 5.5.10.7.1; banners=.,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 25536 invoked from network); 15 Mar 2007 11:15:07 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8)
by server-13.tower-153.messagelabs.com with SMTP;
15 Mar 2007 11:15:07 -0000
Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133])
by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l2FBF6M8019636;
Thu, 15 Mar 2007 04:15:06 -0700 (MST)
Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117])
by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l2FBF5CP002705;
Thu, 15 Mar 2007 06:15:05 -0500 (CDT)
Message-ID: <45F92AB9.6020802@gmail.com>
Date: Thu, 15 Mar 2007 12:15:05 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Thunderbird 1.5.0.10 (Windows/20070221)
MIME-Version: 1.0
To: Basavaraj Patil <basavaraj.patil@nokia.com>
Subject: Re: [16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-ipv6cs
References: <C21DC170.3170A%basavaraj.patil@nokia.com>
In-Reply-To: <C21DC170.3170A%basavaraj.patil@nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5
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
Basavaraj Patil wrote: > 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? >> >> The AP may send REG-RSP telling the Station to use DHCP. >> >> 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. Ok. I'm wondering whether IEEE can mention to Mobile WiMax that the secondary management connection seems mandatory. Sure that's not IETF matter, but IETF does IPv6, and for IEEE IPv6 config happens only on the SMC (secondary management connection)... complicated. > I agree that a BS and the AR should be synchronized in terms of what method > is indicated to the MS for 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. Right, this is what I meant. I think it's a good way forward for the IPv6-CS draft until Mobile WiMax and IEEE figure out. >> 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. I agree. I have a list of such issues that could be mentioned to IEEE. I'm not talking put requirements to IEEE, just mention the potential issues. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ 16NG mailing list 16NG@ietf.org https://www1.ietf.org/mailman/listinfo/16ng
- [16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-i… Basavaraj Patil
- [16NG] Last Call: draft-ietf-16ng-ipv6-over-ipv6c… The IESG
- [16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-i… James Carlson
- Re: [16NG] Re: Last Call: draft-ietf-16ng-ipv6-ov… Alexandru Petrescu
- [16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-i… Basavaraj Patil
- [16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-i… James Carlson
- [16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-i… Basavaraj Patil
- Re: terminology (was: [16NG] Re: Last Call: draft… Alexandru Petrescu
- Re: terminology (was: [16NG] Re: Last Call: draft… Basavaraj Patil
- [16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-i… James Carlson
- Re: terminology (was: [16NG] Re: Last Call: draft… Alexandru Petrescu
- [16NG] RE: Last Call: draft-ietf-16ng-ipv6-over-i… Manfredi, Albert E
- Re: [16NG] Re: Last Call: draft-ietf-16ng-ipv6-ov… Basavaraj Patil
- RE: [16NG] RE: Last Call: draft-ietf-16ng-ipv6-ov… Riegel, Maximilian
- Re: [16NG] Re: Last Call: draft-ietf-16ng-ipv6-ov… Alexandru Petrescu
- re: [16NG] Re: Last Call: draft-ietf-16ng-ipv6-ov… qinxia
- RE: [16NG] Re: Last Call: draft-ietf-16ng-ipv6-ov… qinxia