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

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

Myung-Ki Shin wrote:
> 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