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

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,

_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng