From: Bruno Miguel Sousa <bmsousa@dei.uc.pt>
Date: January 29, 2007 3:01:42 PM PST
To: 16ng@ietf.org
Subject: [16NG] Review draft-ietf-v6ops-802-16-deployment-scenarios-02
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
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng