Subject: Last Call: draft-ietf-16ng-ipv6-over-ipv6cs (IPv6 Over the IP Specific part of the Packet Convergence sublayer in 802.16 Networks) to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 12 Mar 2007 10:57:57 -0400

The IESG has received a request from the IP over IEEE 802.16 Networks WG
(16ng) to consider the following document:

- 'IPv6 Over the IP Specific part of the Packet Convergence sublayer in 
   802.16 Networks '
   <draft-ietf-16ng-ipv6-over-ipv6cs-08.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2007-03-31. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-16ng-ipv6-over-ipv6cs-08.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15298&rfc_flag=0

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 12 Mar 2007 17:35:28 -0500

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.

-Basavaraj

---

From: James Carlson <[email-masked]>
Date: Wed, 14 Mar 2007 12:14:04 -0400

> http://people.nokia.net/~patil/IDs/draft-ietf-16ng-ipv6-over-ipv6cs-09.txt

I've read through the document as well as (most of) the mailing list
discussion, and I don't see anything that directly addresses one
possible issue here.

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?

Can't both run on the same link?

(I'm also a bit concerned that this proposal will end up rediscovering
RFC 1547 over time, as other unnegotiated point-to-point mechanisms
have in the past, and the reasons why PPP's negotiation exists.  I'm
certainly not arguing for the use of PPP over Ethernet CS -- that'd be
worse still -- but I think the IEEE may have made a mistake in
defining an IP Packet CS rather than a PPP Packet CS.)

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 1 Network Drive         71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 14 Mar 2007 12:33:07 -0400

> -----Original Message-----
> From: James Carlson [mailto:[email-masked]] 

> Can't both run on the same link?

For that matter, why was this same segregation standardized for
Ethernet? I always wondered about that.

Bert

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 14 Mar 2007 17:47:57 +0100

> directorate. It will be submitted to the ID repository as soon as the gates

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.

There may be an interoperability issue, if the two indicators are different.

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.

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.

Thanks,

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 14 Mar 2007 11:52:34 -0500

Hi James,

Response inline:

> conclusively whether you're looking at IPv4 or IPv6, so why is strict

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.

> Can't both run on the same link?

I guess you mean both IPv4 and IPv6 packets on the same transport connection
(CID), right? Why would you want to do that even if you could? It is cleaner
to setup separate transport connections and use specific classifiers for
each of these which gives you more control over the type of QoS or bearer
for each. But to answer your question more specifically:
No. When the transport connection is established there is a parameter which
specifies the CS that the connection will use and it is specified in Sec
11.13.19.1 of IEEE P802.16-REVd/D5-2004. The options in the table indicate
that the connection will support only IPv4 (1) or IPv6 (2) etc.

> defining an IP Packet CS rather than a PPP Packet CS.)

IEEE is specifying what is called as GPCS (generic packet CS) and I think
that some of these will be addressed therein.

-Raj

---

From: James Carlson <[email-masked]>
Date: Wed, 14 Mar 2007 13:04:39 -0400

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

I'm noting that you don't need to make a given Packet CS instance
exclusively IPv4 or IPv6, and I'm asking why this wasn't discussed.
Is it because segregation by way of CID is seen as being a superior
mechanism?  If so, that's fine, but I think it'd be good to document.

> (CID), right?

Yes.

> Why would you want to do that even if you could?

Because it's simple ... ?

> It is cleaner
> for each.

That's interesting.  Would one expect IPv4 and IPv6 to get different
QoS treatment?

> But to answer your question more specifically:

Right; I'm asking why it's being done that way.  (Or, more
specifically, why there doesn't seem to have been any discussion.
Perhaps the discussion was held at the IEEE?)

> that some of these will be addressed therein.

OK.

In that case, my concern would be for interoperability.  Having three
or four ways to do something is much worse than having one.

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 14 Mar 2007 12:21:14 -0500

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

> mechanism?  If so, that's fine, but I think it'd be good to document.

The 802.16 group in IEEE made such a choice and design. So I really do not
know the reasoning why this mechanism was chosen. I don't know if it makes
sense to document here the reasons why IPv4 and IPv6 CS' are segregated,
because it is more of an L2 issue and this document is only specifying
operation over what has been defined at L2.

> Because it's simple ... ?

Agree.

> That's interesting.  Would one expect IPv4 and IPv6 to get different

Possible. Both the connections could have the same QoS or request that the
radio bearers for v4 and v6 CIDs be different. It depends on what type of
QoS is requested for each connection.

> Perhaps the discussion was held at the IEEE?)

I guess this is an IEEE specific question and maybe people who were involved
in the design (DJ?  et al.) can comment.

> or four ways to do something is much worse than having one.

This has been raised as a concern previously as well (I believe there was a
draft by Bernard Aboba expressing concerns about this as well). At the
present time however IP CS is the default mode/CS for transporting IP and as
such is being built in base stations and hosts. GPCS is not complete yet.

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 14 Mar 2007 18:52:20 +0100

> 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

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 14 Mar 2007 13:07:41 -0500

Alex,

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

> 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

---

From: James Carlson <[email-masked]>
Date: Wed, 14 Mar 2007 14:15:52 -0400

> operation over what has been defined at L2.

OK; knowing that the higher level classification is forced here is
enough.

> such is being built in base stations and hosts. GPCS is not complete yet.

I see.  It sounds to me like some sort of warning might be warranted.
The point of IETF documents is to achieve interoperability, and if we
know in advance that this could be problematic, I think we should
mention that.  In other words, include GPCS as a possible future
consideration, alongside the separate Ethernet and VLAN CSes.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 14 Mar 2007 19:55:40 +0100

> So I do not think that classifiers exist solely for the purpose of PHS.

Right, I wrote "mainly", add IMHO.

> 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

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 14 Mar 2007 15:12:48 -0500

Alex,

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

I agree that a BS and the AR should be synchronized in terms of what method
is indicated to the MS for address configuration.

Yes.

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

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

-Raj

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 15 Mar 2007 12:15:05 +0100

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

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

> synced. We can also mention it to IEEE but that is about the scope of things

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

---

From: qinxia <[email-masked]>
Date: Mon, 19 Mar 2007 07:19:11 +0800

Hello folks,
       Sorry for the following code, because my outlook is Chinese version,
please see inline straight.
Thanks
Alice

> 发件人: Alexandru Petrescu [mailto:[email-masked]]
> 发送时间: 2007年3月15日 19:15
> 收件人: Basavaraj Patil
> 抄送: ext Alexandru Petrescu; [email-masked]; [email-masked]; IETF-Announce;
> [email-masked]
> 主题: Re: [16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-ipv6cs
> 
> Basavaraj Patil wrote:
> > Alex,
> >
> >
> >>> This revision incorporates changes based on some of the comments made
by
> the
[qinxia] SMC is used for network management in 16d, we may ignore it in 16e,
RA could be transported over general connection. 

> > Correct. A deployment should be able to ensure that the indication to
the
> MS
[qinxia]  It is odd to indicate address configuration via REG-RSP such Layer
2 signaling, IMHO, I do not think that there is any requirement to adopt
other method to inform address configuration. RA is enough.

> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf

---

From: qinxia <[email-masked]>
Date: Thu, 22 Mar 2007 07:43:52 +0800

Hello all,

            My two cents. Please see inline.
Best wishes,
alice
> From: Basavaraj Patil [mailto:[email-masked]]
> Sent: Thursday, March 15, 2007 4:13 AM
> To: ext Alexandru Petrescu
> Cc: [email-masked]; [email-masked]; IETF-Announce; [email-masked]
> Subject: Re: [16NG] Re: Last Call: draft-ietf-16ng-ipv6-over-ipv6cs (IPv6
Over
> the IP Specific part of the Packet Convergence sublayer in 802.16
Networks)
> to Proposed Standard
by
> > AP tells the Station to auto-configure statelessly and the AR tells it
[qinxia] 
My question is what is the situation when AP select different address
configuration with AR?  IMHO, it is up to deployment.

> > The AP may send REG-RSP telling the Station to use DHCP.
[qinxia]  address configuration is indicated over RA. This is enough.

> is indicated to the MS for address configuration.

[qinxia]  sure, SMC may not be exist. However, RA may be transported over
regular connection. RA could be used to indicate the address configuration.