[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [16NG] Fw: Review on v6ops 802.16 deployment scenario
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.
Daniel Park wrote:
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.
Agreed, we already received the same comment. We will remove this.
- The introduction section needs to be reworked to just focus on what
this document is discussing instead of speculations about
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.
- 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.
Yes, this kind of statement in this draft will be removed.
- 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.
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.
- 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.
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.
- 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.
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.
- 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.
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.
- 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.
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.
- Why the reference to WiMAX and Wibro in sec 2.2.1? This is supposed
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.
- Section 2.2.1.1 talks about upgrading the MS, BS, AR and ER to dual
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 ?
- 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.
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.
- 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.
This is (just) a generic statement for IPv6 transition (v6ops).
- 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.
Sec 2.2.2 Fixed/Nomadic scenario considers this variants.
We will consider it in Mobile access deployment case too.
- 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.
Could you explain more ?
So, what's suggestion in this section ?
- 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?
We will remove this statement too.
- 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.
No, I said it above.
Thaks,
Myung-Ki,