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

From: Fred Baker <[email-masked]>
Date: Mon, 29 Jan 2007 15:18:38 -0800

Begin forwarded message:

> From: Bruno Miguel Sousa <[email-masked]>
> Date: January 29, 2007 3:01:42 PM PST
> To: [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/16ng

---

From: Myung-Ki Shin <[email-masked]>
Date: Tue, 30 Jan 2007 14:36:13 +0900

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
> 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.
> WiMAX Network reference model, at least in the appendix. As done by the

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.
> 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

Ok.

> Minor typo, always

Correct.

> My suggestion is to remove this and consequent sentences and introduce the
> following:

Agreed.

> In a IPv6 subnet, there are...

Yes.
>   the classification.  It also decides where to send the packet or just
> 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
> 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

AR is correct.

> If you are referring the 802.16 PHS, shouldn't you state Payload Header

It seems to be fine with me.

> 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.

> I would add an informative reference regarding 802.16g. It is missing!

I'll add it.

> 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.
> And the Ethernet Bridge should also support IPv6 to build the authoritative
>   The bridge builds its authoritative address cache by parsing the IPv6
> I think in this section there should be a reference to the required IPv6

Right, I'll update it.

> 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
> 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,

---

From: Bruno Miguel Sousa <[email-masked]>
Date: Tue, 30 Jan 2007 07:23:30 +0000

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