Subject: [16NG] Review draft-ietf-v6ops-802-16-deployment-scenarios-02

From: Bruno Miguel Sousa <[email-masked]>
Date: Mon, 29 Jan 2007 23:01:42 +0000

Dear v6ops group.

I've reviewed the IPv6 Deployment Scenarios in 802.16(e) Networks version
02. Where are my comments:

[General]
I think the document introduces different issues related with IPv6 in the
IEEE 802.16 networks and presents the on going work to overcome  the same.
And quite interesting scenarios.
Nevertheless I think the document needs improvements.
1) If talking about deployment scenarios, does make sense to refer the
WiMAX Network reference model, at least in the appendix. As done by the
IPv6 over Packet CS in 802.16 specification.
2) The differences from IPv4 don't seem to explicit in the text. When in
the abstract is defended such goal for the document.

[Specific]

S1)
Section 2.2.1
"
Unlike IEEE 802.11, IEEE 802.16 BS can offer mobility function as
   well as fixed communication.
"
In my opinion I would not make the comparison with the 802.11. Furthermore
on the previous section (section 2.2) there is already a mention to the
cellular system. I suggest the following text:
The IEEE 802.16 BS can provide mobility functions and fixed
communications.

"
There is alwayes ...
"
Minor typo, always

S2)
Section 2.2.1.1
"
The BS does not need to support IPv6.
"
I think this sentence might not be aligned to the scope and with other
sections of the document.
If the BS does not support IPv6, at least it should support IPv6
classifiers (as presented on the section 2.2.1.3).
My suggestion is to remove this and consequent sentences and introduce the
following:
The BS should support IPv6 classifiers as specified in [IEEE 802.16].

S3)
Section 2.2.1.3
"
In a subnet, there are always two underlying links:
"
I suggest to use :
In a IPv6 subnet, there are...

Just for clarification.

S4)
Section 2.2.1.3
"
   BS generates the flow based on
   the classification.  It also decides where to send the packet or just
   forward the packet to the ACR, since IEEE 802.16 connection always
   ends at BS while IPv6 connection terminates at the AR.
"
To these sentences I want to remark the following:
1) If the document as implicit the service flows created by the BS, then
this should be more explicit. For instance the document refers the mesh
mode of the standard but states that only focuses the PMP mode (section
2.2). So I suggest to add to section 2.2 the following text:
The [IEEE802.16] supports MS initiated service flows and BS initiated
service flows. The document only focuses the BS initiated service flows.

2) The term ACR is not defined in the document (and sorry) I don't know
what does it mean. Do you intend to say AR?!

S5)
Section 2.2.1.3
"
However PHS (Packet Header Compression)
"
If you are referring the 802.16 PHS, shouldn't you state Payload Header
Suppression. I suggest a rephrasing:
When PHS (Payload Header Suppression) is deployed it mitigates this
overhead through the compression of packet headers.

S6)
Section 2.2.1.4
"
Therefore, no routing protocols are needed on the MS.
"
Just for clarification. This sentence also applies when the MS has a
network behind it? The default routes are enough in such cases?

S7)
Section 2.2.1.5
"
Also, IEEE 802.16g which is ...
"
I would add an informative reference regarding 802.16g. It is missing!

"
convergence sublayers [I-D.iab-link-encaps], the mobile access
   scenarios need solutions about how roaming will work when forced to
   move from one CS to another.
"
Just for clarification. I would add an example of the CS roaming (e.g. from
IPv4 CS to Ethernet CS).

S8)
Section 2.2.2.1
The text in this section refers that MS, AR, and ER should support IPv6.
The S2 applies also here.
And the Ethernet Bridge should also support IPv6 to build the authoritative
address cache (as referenced in section 2.2.2.3).
"
   The bridge builds its authoritative address cache by parsing the IPv6
   Neighbor Discovery messages used during address configuration (DAD).
"
I think in this section there should be a reference to the required IPv6
support by the Ethernet Bridge.

S9)
Section 2.4
"
 The QoS has different semantics with IP QoS
"
I suggest to change this sentence:
The 802.16 supported QoS has different semantics from IP QoS.

S10)
Section 2.6
I think this section does not fulfill the intended purpose. It does not
refer how to make IPv6 Network Management.
And besides this, I think there should be a reference to the 802.16f  the
amendment that includes the management information base for IEEE 802.16
networks.

For the moment, this is my input to the document.

Kindly,
Bruno Sousa

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

---

From: Myung-Ki Shin <[email-masked]>
Date: Tue, 30 Jan 2007 14:36:13 +0900

Hi Bruno,

I agree on most of your comments.
I'm preparing revision now. Thanks.

See inline.

> IPv6 over Packet CS in 802.16 specification.

Actually, this draft covers the typical scenarios based on IPv6 link
models for 802.16, draft-ietf-16ng-ipv6-link-model-analysis.
Authors believe that we don't need to add any specific scenarios for
WiMAX or WiBro in appendix or elsewhere. We just refer to
draft-ietf-16ng-ipv6-link-model-analysis or 802.16 specification.

And, all the suggestions below are valid.
> The IEEE 802.16 BS can provide mobility functions and fixed

Ok.

> Minor typo, always

Correct.

> The BS should support IPv6 classifiers as specified in [IEEE 802.16].

Agreed.

> In a IPv6 subnet, there are...

Yes.
> service flows. The document only focuses the BS initiated service flows.

I think it is better to remove the paragraph in sec 2.2.1.3 to avoid
confusion.

> what does it mean. Do you intend to say AR?!

AR is correct.

> overhead through the compression of packet headers.

It seems to be fine with me.

> network behind it? The default routes are enough in such cases?

That's good point.

In sec 2.2.1.4, we should consider the case - the MS has a
network behind it, too.  We'll rephrase it and add this case.

> I would add an informative reference regarding 802.16g. It is missing!

I'll add it.

> Just for clarification. I would add an example of the CS roaming (e.g. from

Ok. e.g., IPv6 CS to Ethernet CS

> support by the Ethernet Bridge.

Right, I'll update it.

> The 802.16 supported QoS has different semantics from IP QoS.

Ok.

> amendment that includes the management information base for IEEE 802.16

Ok, I'll try to rephase it and add the reference.

Thanks for your valuable comments.
Myung-Ki,

---

From: Bruno Miguel Sousa <[email-masked]>
Date: Tue, 30 Jan 2007 07:23:30 +0000

Hi Myung-Ki

Thanks for taking account my comments.

Yesterday I forgot to mention the title of the document.
"IPv6 Deployment Scenarios in 802.16(e) Networks"

In my opinion I would remove the (e) version. Since the document 
specifies the fixed and mobile
802.16 access networks. Just put:
"IPv6 Deployment Scenarios in 802.16 Networks".

Kindly,
Bruno Sousa