Hi Bruno,
I agree on most of your comments.
I'm preparing revision now. Thanks.
See inline.
Bruno Miguel Sousa wrote:
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.
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.
[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.
Ok.
"
There is alwayes ...
"
Minor typo, always
Correct.
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].
Agreed.
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.
Yes.
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.
I think it is better to remove the paragraph in sec 2.2.1.3 to avoid
confusion.
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?!
AR is correct.
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.
It seems to be fine with me.
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?
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.
S7)
Section 2.2.1.5
"
Also, IEEE 802.16g which is ...
"
I would add an informative reference regarding 802.16g. It is missing!
I'll add it.
"
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).
Ok. e.g., IPv6 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.
Right, I'll update it.
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.
Ok.
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.
Ok, I'll try to rephase it and add the reference.
Thanks for your valuable comments.
Myung-Ki,