[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Fw: [16NG] Review draft-ietf-v6ops-802-16-deployment-scenarios-02
FYI...
Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.
----- Original Message -----
From: "Bruno Miguel Sousa" <bmsousa@dei.uc.pt>
To: <16ng@ietf.org>
Sent: Tuesday, January 30, 2007 8:01 AM
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
>
>