Subject: Fw: Review on v6ops 802.16 deployment scenario

From: Daniel Park <[email-masked]>
Date: Wed, 13 Dec 2006 14:08:08 +0900

Here is one more comment on the draft-ietf-v6ops-802-16-deployment-scenarios-01.txt

Thanks much Basavaraj Patil.

Hope this helps too.

Daniel (Soohong Daniel Park)
Mobile Convergence Laboratory, SAMSUNG Electronics.

> My review comments:
> 
> 
> Review of I-D: draft-ietf-v6ops-802-16-deployment-scenarios-01.txt
> 
> General:
> 
> The document is poorly written and makes a lot of assumptions. It also
> does not take into consideration the fact that IPv6 can be transported
> directly over the MAC (IP specific part of the packet CS), over 802.3
> of the packet CS or 802.1Q part of the packet CS. Given the variants,
> the deployment models vary. The fact is that IEEE std 802.16 has
> specified the means to transport IPv6 over the air interface between a
> host and a BS. The network models and deployments that are possible
> are numerous and this document does not do justice in explaining
> this. 
> The document is not really useful from a deployment of IPv6
> perspective at all.
> 
> - The introduction section mentions 802.16 as applicable for
>  stationary networks only. It is better to clarify the variants of
>  IEEE 802.16 specifications (i.e .16d, .16e and possibly others in
>  the future). Comments such as "IEEE 802.16e is one of the most
>  promising access technologies...." are unnecessary in the context of
>  this document.
> 
> - The introduction section needs to be reworked to just focus on what
>  this document is discussing instead of speculations about
>  deployments and capabilities.
> 
> - The title of Section 2 and the text in that section appear to be
>  mismatched. 
> 
> - In section 2.1:
> "   The IEEE 802.11 access network (WLAN) has driven the revolution of
>   wireless communication.  However, the more people use it the more its
>   limitations such as short range and lack of mobility support arose.
>   Compared with such IEEE 802.11 network, IEEE 802.16 supports enhanced
>   features such as wider coverage and mobility.  So it is expected that
>   IEEE 802.16 network could be the next step of IEEE 802.11 network.
> "
> 
>  This statement is irrelevant and speculative. Is of no value here.
> 
> - Statement: 
>  "   The mechanism of transporting IP traffic over IEEE 802.16 networks is
>   outlined in [IEEE802.16],"
> 
>  IEEE 802.16 std only specifies the convergence sublayers and the
>  ability to transport IP over the air interface. Beyond that it does
>  not specify anything about the network for either IPv4 or IPv6. The
>  statement above gives the impression that only IPv6 operation is not
>  specified by 802.16 specs.
> 
> - The definition of MS is not clear. "In motion or during halts" needs
>  to be better explained. It is better to refer to the terms in the
>  16NG problem statement I-D.
> 
> - Definition of BS leaves much to be desired. Again recommend the use
>  of the definition from the 16NG PS I-D.
> 
> - Figure 1 is just an example. There are many different models for
>  802.16 technology. As an example, the BS can be connected directly
>  to a BRAS which then provides IP connectivity. IP is transported
>  over Ethernet between the MS and BS and to the BRAS. So only showing
>  the figure 1 implies that this is the only model which is not true.
> 
> - In section 2.2, the description of the issue about the PMP nature of
>  the 802.16 link and the issue as applicable to IPv6 is not
>  clear. Lack of multicast capability on the uplink is not considered
>  an issue for IPv6. It just implies a different link model.
> 
> - The reasoning why the IETF should specify IPv6 operation is
>  vague. In section 2.2, bullet 2, there is mention of classifiers,
>  MAC payload and other terms which do not make sense without a proper
>  explanation. 
> 
> - There is a claim that IEEE 802.16 is different as compared to 802.11
>  or 3G. How is it different? After all 802.16 is just another
>  air-interface specification.
> 
> - In bullet 3 the statement:
> "The specification of IEEE 802.16 defines several
>   CSs for carrying IP packets, but does not provide a detailed
>   description of how to carry them.  The several CSs are generally
>   classified into two types of CS: IPv6 CS and Ethernet CS.
> "
> 
>  802.16 describes how IP payload is transported over the air
>      interface. This is the scope of the spec and that is all that is
>      needed. So the above claim is incorrect. Also there is only the
>      ATM CS and the Packet CS. IP(v4/v6), Ethernet and 802.3 are all part
>      of the packet CS. There is no IPv6 CS and Eth CS.
> 
> - In section 2.2.1 there is the statement:
>  "This use case will be implemented only with the licensed spectrum."
> 
>  It refers to the mobility support. I do not understand why mobility
>  will be supported only in the licensed spectrum. This is an invalid
>  statement. 
> 
> - Why the reference to WiMAX and Wibro in sec 2.2.1? This is supposed
>  to be a document describing generic .16 deployment models.
> 
> - Section 2.2.1.1 talks about upgrading the MS, BS, AR and ER to dual
>  stack. Why? Does not make any sense.
>  
> - Sec 2.2.1.3 mentions that IPv6 should be transported directly over
>  the 802.16 MAC and not over Ethernet. There is no proper
>  justification. Both are possible and are options for IPv6
>  deployment.
> 
> - In Sec 2.2.1.3:
> "Native IPv6 should be preferred over tunneling
>   mechanisms as native IPv6 deployment option might be more scalable
>   and provide required service performance.
> " 
>  Not clear why this recommendation.
> 
> - Sec 2.2.1.4 should take into consideration hosts such as CPEs which
>  can act as routers. There are many variants of an MS.
> 
> - In Section 2.2.1.5 the statement:
> "   As for mobility management, the movement between BSs is handled by
>   Mobile IPv6 [RFC3775], if it requires a subnet change.  Also, in
>   certain cases (e.g., fast handover [I-D.ietf-mipshop-fmipv6-
>   rfc4068bis]) the link mobility information must be available for
>   facilitating layer 3 handoff procedure.
> "
> 
>  The authors are making a very long-shot judgement about the mobility
>  models that are possible.
> 
> - In sec 2.2.2
> "Many wireless
>   Internet service providers (Wireless ISPs) have planned to use IEEE
>   802.16 for the purpose of high quality broadband wireless service
> "
>  Is this even needed?
> 
> - Sec 2.2.2.1 again mentions infrastructure changes. What
>  infrastructure is intended to be upgraded? The dual-stack
>  requirement is invalid. It depends on the deployment environment.
> 
> 
> -Basavaraj

---

From: Myung-Ki Shin <[email-masked]>
Date: Thu, 14 Dec 2006 11:14:25 +0900

Thanks Basavaraj and Daniel,

First of all, I think Basavaraj misunderstood this v6ops draft.
The goal of the draft is not to describe IPv6 operation (protocol) over
802.16 (like WiMAX NWG IPv6 subgroup or 16ng doc)., but to present IPv6
deployment and integration methods and scenarios in coexistence with
deployed IPv4 services.

Also, this draft extends works of draft-ietf-v6ops-bb-deployment-
scenarios (e.g., broadband cable, DSL, PLC, WLAN, etc.) as one of new
access technologies, and follows the structure of existing 
draft-ietf-v6ops-bb-deployment-scenarios.

draft-ietf-v6ops-bb-deployment-scenarios has been already approved and
is now in RFC-Editor's Queue. Please see the draft carefully first.

As for the scenarios, this draft covers just *Mobile Access Deployment*
and *Fixed/Nomadic Deployment* Scenarios.
We also know there are so many use cases (sometimes, they are
implementation-dependent), but we already discussed about them at 16ng 
interim meeing (in Sep.). So, we fixed the scenarios in confirmity to
link model analysis draft of 16ng.

In addition, most of comments below seems to be non-technical issues.
we don't want to make a *white paper - like document* for
IPv6 over IEEE 802.16 networks. As I mentioned, the goal is different.
For example, CS issues and each solution should be discussed in 16ng,
not v6ops.

Please see inline.

>> promising access technologies...." are unnecessary in the context of

Agreed, we already received the same comment. We will remove this.

>> deployments and capabilities.

Okay, authors will try to rephrase this section to avoid 
misunderstanding. We will focus on v6ops's goal - main
components of IPv6 IEEE 802.16 access network and its changes
from IPv4 IEEE 802.16 networks and how IPv6 is deployed and
integrated in each of the IEEE 802.16 technologies using tunneling
mechanisms and native IPv6.

>> This statement is irrelevant and speculative. Is of no value here.

Yes, this kind of statement in this draft will be removed.

>> specified by 802.16 specs.

No, misunderstood.

We will rephrase this like -.

The mechanism of transporting IP traffic over IEEE 802.16 networks is
outlined in [IEEE802.16].  [IEEE802.16] only specifies the convergence 
sublayers and the ability to transport IP over the air interface.
The details of IPv6 (and IPv4) operations over IEEE 802.16 are being
discussed now in 16ng WG.

>> of the definition from the 16NG PS I-D.

When we published this draft -00, 16ng terms were not fixed yet, and
PS I-D was not accepted too. We will use the definition from the 16NG PS
I-D accordingly.

>> the figure 1 implies that this is the only model which is not true.

Fig 1 show a typical (high-level) abstract model for 802.16 deployment.
We don't want to describe implementation-dependent models. (i.e.,
BS-AR integration or separation, etc.)
We will just mention it like that -
"Figure 1 illustrates the key elements of typical mobile 802.16
deployment" in confirmity to previous DJ' comment.

>>     of the packet CS. There is no IPv6 CS and Eth CS.

Comments above are related to 16ng PS I-D. We will remove the problem
statements in this draft and just refer to PS I-D.

>> will be supported only in the licensed spectrum. This is an invalid

Sec 2.2.1 covers mobile access deployment scenarios like Mobile WiMAX or
WiBro. At this time, this use case will be implemented with the licensed 
spectrum. But, anyway we will remove this kind of speculation statement.

>> to be a document describing generic .16 deployment models.

Authors think we can just mention an deployment example of each
scenario. This is a v6ops - informatinal draft.

>> stack. Why? Does not make any sense.

As for the IPv6 infrastructure changes (IPv4 -> IPv6),
In general, IPv6 should be enabled on MS, BS, AR and (ER) for IPv6 
transition. E.g., WiBro-IPv6 implementations (MS, BS, AR) have 
dual-stack.

Could you explain your claim technically more ?

>> justification. Both are possible and are options for IPv6

This case is for Mobile Access Deployment Scenario.
In this case, we recommend IPv6 CS may be more appropriate than
Ethernet CS to transport IPv6 packets, since there are some overhead
of Ethernet CS (e.g., Ethernet header) under mobile access
environments.

>> Not clear why this recommendation.

This is (just) a generic statement for IPv6 transition (v6ops).

>> can act as routers. There are many variants of an MS.

Sec 2.2.2 Fixed/Nomadic scenario considers this variants.
We will consider it in Mobile access deployment case too.

>> models that are possible.

Could you explain more ?
So, what's suggestion in this section ?

>>  802.16 for the purpose of high quality broadband wireless service

We will remove this statement too.

>> requirement is invalid. It depends on the deployment environment.

No, I said it above.

Thaks,
Myung-Ki,