Subject: 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

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

On 3/12/07 9:57 AM, "ext The IESG" <[email-masked]> wrote:

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

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

---

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: Alexandru Petrescu <[email-masked]>
Date: Thu, 15 Mar 2007 12:15:05 +0100

Basavaraj Patil wrote:
> Alex,
> 
> 
> On 3/14/07 11:47 AM, "ext Alexandru Petrescu" <[email-masked]>
> wrote:
> 
>> Basavaraj Patil wrote:
>>> Hello,
>>>
> 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.

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.

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

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.

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

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.

---

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

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

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

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

Bert

---

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

Hi James,

Response inline:

On 3/14/07 11:14 AM, "ext James Carlson" <[email-masked]> wrote:

> Basavaraj Patil writes:

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.

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

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

-Raj

>-- 
>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: Basavaraj Patil <[email-masked]>
Date: Wed, 14 Mar 2007 11:52:34 -0500

Hi James,

Response inline:

-Raj

---

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

Alex,

Yes.

-Raj

---

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.