Re: terminology (was: [16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-ipv6cs)

Alexandru Petrescu <alexandru.petrescu@gmail.com> Wed, 14 March 2007 17:54 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 1HRXgG-0000HP-DZ; Wed, 14 Mar 2007 13:54:32 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HRXgD-0000GZ-Nt; Wed, 14 Mar 2007 13:54:29 -0400
Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HRXeB-00008Q-Jd; Wed, 14 Mar 2007 13:52:24 -0400
X-VirusChecked: Checked
X-Env-Sender: alexandru.petrescu@gmail.com
X-Msg-Ref: server-9.tower-119.messagelabs.com!1173894742!18891635!1
X-StarScan-Version: 5.5.10.7.1; banners=.,-,-
X-Originating-IP: [129.188.136.8]
Received: (qmail 8521 invoked from network); 14 Mar 2007 17:52:22 -0000
Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-119.messagelabs.com with SMTP; 14 Mar 2007 17:52:22 -0000
Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l2EHqMqW008608; Wed, 14 Mar 2007 10:52:22 -0700 (MST)
Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id l2EHqLGb025321; Wed, 14 Mar 2007 12:52:21 -0500 (CDT)
Message-ID: <45F83654.4050107@gmail.com>
Date: Wed, 14 Mar 2007 18:52:20 +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: terminology (was: [16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-ipv6cs)
References: <C21D993A.316CD%basavaraj.patil@nokia.com>
In-Reply-To: <C21D993A.316CD%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: 0a7aa2e6e558383d84476dc338324fab
Cc: ipv6@ietf.org, 16ng@ietf.org, ext James Carlson <james.d.carlson@sun.com>
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:
> 
> On 3/14/07 12:04 PM, "ext James Carlson" <james.d.carlson@sun.com> wrote:
> 
>> Basavaraj Patil writes:
>>> On 3/14/07 11:14 AM, "ext James Carlson" <james.d.carlson@sun.com> wrote:
>>>> That issue is the exclusive use of IPv4 or IPv6 on Packet CS.  Why
>>>> must it be exclusive?  The first four bits of the datagram tell you
>>>> conclusively whether you're looking at IPv4 or IPv6, so why is strict
>>>> segregation needed?
>>> Not sure I understand what you mean by segregation... The same packet CS is
>>> used for IPv4 as well as IPv6. There are no separate CS' per se.
>>> The classification rules segregate an IPv4 packet from an IPv6 packet and
>>> map it to the appropriate transport connection (CID) over the air interface.
>> That's not what I meant.
>>
>> A single CID using just Packet CS could handle both IPv4 and IPv6
>> traffic on the same interface.
>>
>> You'd do this (on the receiver side) by looking at the first four bits
>> of the inbound IP datagram.  They're '4', then it's IPv4.  If they're
>> '6', then it's IPv6.  If it's anything else, discard.
> 
> Okay.. I see what you mean. I don't really have a comment about it.

Sorry for interfering here, sorry if I misunderstand anything.  Just one 
thought: terminology.

I think this boils down again to that terminology issue, that longer 
IEEE definition of what IETF calls "IPv6 CS".  By IEEE, it's actually 
"the IPv6 classifiers of the IP specific part of Packet CS".  So this 
document could be named "Prefix Assignment, Router Discovery, MTU and 
IPv6 Addressing for the IPv6 classifiers of the IP specific part of the 
Packet CS".  Which doesn't make much sense, because one wouldn't run 
Router Discovery over some classifiers.

We need that "IPv6 _over_ foo" tint.  And these IPv6 classifiers aren't 
_a_ foo.

Throughout the IEEE spec these IPv6 specific classifiers are mainly used 
for PHS (packet header suppression) and recomposing.  This is the most 
use of these IPv6 classifiers.

In this context I'd comment on why IEEE is using this PHS, and not ROHC, 
an IETF standardized protocol, for various link-layers.  Or maybe any 
other IETF-specified header compression (for ppp and for others).

I mean what if a Station uses ROHC and the link-layer does PHS - will 
this result in inefficiency.

Just a thought on terminology...

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