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

[Alexandru Petrescu <[e-mail]>]

Basavaraj Patil wrote:
> Alex,
> 
> 
> On 3/14/07 12:52 PM, "ext Alexandru Petrescu" <[e-mail]>
> wrote:
> 
>> Basavaraj Patil wrote:
>>> On 3/14/07 12:04 PM, "ext James Carlson" <[e-mail]> wrote:
>>>
>>>> Basavaraj Patil writes:
>>>>> On 3/14/07 11:14 AM, "ext James Carlson" <[e-mail]> 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.
> To quite the IEEE spec:
> " A  classification rule is a set of matching criteria applied to each
> packet entering the IEEE std  802.16 network. It consists of some
> protocol-specific packet matching criteria (destination IP address, for
> example), a classification rule priority, and a reference to the CID.
> "
> 
> PHS is optional. A packet after classification may be mapped to a specific
> PHS rule. If there is a PHS rule, there is the 8 bit PHSI (index) in the MAC
> SDU. 
> 
> So I do not think that classifiers exist solely for the purpose of PHS.

Right, I wrote "mainly", add IMHO.

>> 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 think we are digressing when we start to discuss why IEEE chose PHS and
> not ROHC or something else. I don't see the relevance of discussing IEEE
> design decisions in the IETF.

Raj, I think too it sounds indeed far-fetched, and can't be discussed 
here IEEE document evolution, IEEE design decisions, etc. not my 
intention to disgress.

But at the same time, I think since some time now, that every other use 
(other than classifiers) of IPv6 in the IEEE spec is superfluous.  For 
example all the IEEE entry procedure that specifies IPv6 steps is 
superfluous (requires TFTP, TIME protocol, SS management connections, 
slaac/dhcp etc).

For classifiers themselves: if PHS classifiers list _some_ IPv6 header 
field (Protocol, DSCP, src, dst, ports - that's all) - how can one make 
sure that _all_ existing IPv6 headers and extensions get listed in these 
IEEE IPv6 classifiers?  How can one make IEEE PHS work with Mobility 
Header of Mobile IPv6 for example?

You have said at some point that although IEEE spec requires IPv6 to be 
established on a Secondary Management Connection, we're somehow free to 
ignore that.  Which is a good practical way forward.  But shows we do 
have some privileges to ignore some IEEE IPv6 features, and not others.

I agree with that, just that sometimes it simply doesn't make much sense 
to me, that's all.

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng