Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [2]

Alexandru Petrescu <alexandru.petrescu@motorola.com> Fri, 12 January 2007 17:52 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QaE-0004BT-Mt; Fri, 12 Jan 2007 12:52:54 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5QaD-0004AW-HV for 16ng@ietf.org; Fri, 12 Jan 2007 12:52:53 -0500
Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1H5QaC-0007aS-4t for 16ng@ietf.org; Fri, 12 Jan 2007 12:52:53 -0500
X-VirusChecked: Checked
X-Env-Sender: alexandru.petrescu@motorola.com
X-Msg-Ref: server-8.tower-128.messagelabs.com!1168624370!5119429!1
X-StarScan-Version: 5.5.10.7; banners=-,-,-
X-Originating-IP: [129.188.136.7]
Received: (qmail 11812 invoked from network); 12 Jan 2007 17:52:51 -0000
Received: from motgate7.mot.com (HELO motgate7.mot.com) (129.188.136.7) by server-8.tower-128.messagelabs.com with SMTP; 12 Jan 2007 17:52:51 -0000
Received: from az33exr02.mot.com ([10.64.251.232]) by motgate7.mot.com (8.12.11/Motorola) with ESMTP id l0CHqkfC007481; Fri, 12 Jan 2007 10:52:50 -0700 (MST)
Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l0CHqiA2014562; Fri, 12 Jan 2007 11:52:45 -0600 (CST)
Message-ID: <45A7CAEB.5080906@motorola.com>
Date: Fri, 12 Jan 2007 18:52:43 +0100
From: Alexandru Petrescu <alexandru.petrescu@motorola.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: Basavaraj Patil <basavaraj.patil@nokia.com>
Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [2]
References: <C1CD1FF1.2C110%basavaraj.patil@nokia.com>
In-Reply-To: <C1CD1FF1.2C110%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: 0fa76816851382eb71b0a882ccdc29ac
Cc: 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,
> 
> Inline:
> 
> 
> On 1/12/07 10:57 AM, "ext Alexandru Petrescu" 
> <alexandru.petrescu@motorola.com> wrote:
> 
>> Hi, please allow me to interfere with clarifications.
>> 
>> Basavaraj Patil wrote:
>>> Comments by Bruno Sousa:
>> [skip parts I agree]
>>>> 4) IPv6 link in 802.16 " In 802.16, there exists an L2 
>>>> Transport Connection between an MS and a BS which is used to 
>>>> transport user data, i.e IPv6 packets in this case.  A 
>>>> Transport Connection is represented by a CID (Connection 
>>>> Identifier) and multiple Transport Connections can exist 
>>>> between an MS and BS. " I think the first sentence is somehow 
>>>> contradictory with the rest of the paragraph. It is possible to
>>>>  have more then one transport connection between MS and BS. 
>>>> These transport connections are defined on the MAC layer (L2), 
>>>> so why refer "there exists an L2 Transport Connection?!"
>>>> 
>>>> (If my thoughts are correct) I propose to change the first 
>>>> sentence to:
>>>> 
>>>> In 802.16, the Transport Connection between an MS and a BS is 
>>>> used to transport user data, i.e. IPv6 packets in this case.
>>> Agreed. Incorporated the proposed sentence.
>> But there are IPv6 packets that are sent on the Secondary 
>> Management Connection as well (RS/RA at least) 6.3.9.10 
>> 802.16e-2005.  I suggest saying that only _some_ of the IPv6 
>> packets are transported on some Transport Connection, or along 
>> these lines.
> 
> The secondary management connection is typically not used for user 
> data. As the .16 spec says it can be used for address configuration, 
> TFTP etc.

Not only that it can but it must, by that spec.

> Also to be noted is the fact that secondary management connections 
> are not mandatorily required. The usage for which it has been defined
>  can be accomplished via a regular transport connection.

I don't think the 802.16 spec says anywhere that RS/RA could be sent on
anything else than Secondary Management Connection.  Do you?

>> From a practical standapoint, I do not see hosts or BS' 
>> implementing or using the secondary management connection. So I can
>>  mention it in the text of the I-D, but it would not be very
>> useful.
>> 
> 
>> Probably best for reader would be to enumerate the different types 
>> of Connections the SS can handle and where do IPv6 packets appear. 
>> What do you think?
> 
> I don't think we should get into the details of the various types of
>  connections in the I-D. The reference to the .16 spec is sufficient
>  for that. But I can mention that there does exist the secondary 
> management connection which may be used for host configuration with a
>  caveat that for all practical purposes it is better to use a 
> transport connection for the same.
> 
> The reason why the secondary management connection does not make 
> sense is because it is limited in its capability. Establishing a 
> transport connection instead allows you to do the same host 
> configuration as well as use it for user traffic.

I am afraid the 802.16 spec clearly says RS/RA only happen on the
Secondary Management Connection and we can't suggest do it otherwise.

Alex


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