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

Basavaraj Patil <basavaraj.patil@nokia.com> Fri, 12 January 2007 17:20 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Q5L-00014Y-Us; Fri, 12 Jan 2007 12:20:59 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H5Q5K-00014S-DR for 16ng@ietf.org; Fri, 12 Jan 2007 12:20:58 -0500
Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1H5Q5H-0000Qn-RE for 16ng@ietf.org; Fri, 12 Jan 2007 12:20:58 -0500
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l0CHJRRu003595; Fri, 12 Jan 2007 19:19:31 +0200
Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 19:20:49 +0200
Received: from daebe101.NOE.Nokia.com ([10.241.35.113]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 12 Jan 2007 11:20:46 -0600
Received: from 172.19.244.117 ([172.19.244.117]) by daebe101.NOE.Nokia.com ([10.241.35.113]) with Microsoft Exchange Server HTTP-DAV ; Fri, 12 Jan 2007 17:20:46 +0000
User-Agent: Microsoft-Entourage/11.3.2.061213
Date: Fri, 12 Jan 2007 11:22:25 -0600
Subject: Re: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [2]
From: Basavaraj Patil <basavaraj.patil@nokia.com>
To: ext Alexandru Petrescu <alexandru.petrescu@motorola.com>
Message-ID: <C1CD1FF1.2C110%basavaraj.patil@nokia.com>
Thread-Topic: [16NG] Resolutions to issues raised during 2nd WGLC of I-D draft-ietf-16ng-ipv6-over-ipv6cs-04 [2]
Thread-Index: Acc2bjn0eK79aaJhEduv0AARJNUNiA==
In-Reply-To: <45A7BDEB.1000306@motorola.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-OriginalArrivalTime: 12 Jan 2007 17:20:46.0831 (UTC) FILETIME=[FF7177F0:01C7366D]
X-eXpurgate-Category: 1/0
X-eXpurgate-ID: 149371::070112191931-0DC7ABB0-1E8BFAC4/0-0/0-1
X-Nokia-AV: Clean
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
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

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.
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.
>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. 

-Raj

> 
> Alex


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