[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [16NG] FW: Review on v6ops 802.16 deployment scenario (J Kim of AT&T Labs)

Thanks, J Kim and Daniel,

Authors guess most reviewers are confused with the title -
IPv6 Deployment Scenarios in 802.16(e) Networks.

It seems to me that reviewers want to see how to deploy 802.16,
not how to deploy IPv6 in 802.16 in this draft.
Definitely, there is a gap.

We don't think this draft can cover all the issues
for 802.16 deployment. (This is not a scope of this draft).

In abstract, the scope and goal are as follows -

In this document we will discuss main components of IPv6 IEEE
802.16 access network and its differences 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. 

Anyway, authors will do the best to resolve the comments below.
Sec 1, 2.1 terms, and 2.3 problem statements will be reworded or,
removed, at least.

Thanks for the efforts, reviewers and Daniel.
Myung-Ki,

Daniel Park wrote:

To v6ops working group,

Here is a J Kim's review on the 802.16 deployment
scenario.

As promised, the 16ng working group has made
several reviews on the 802.16 deployment scenario
with pleasure. Hope this helps and specially thanks
to all reviewers, DJ Johnston, Basavaraj Patil and
Byoung-Jo Kim.

That's it.

Chairs, 16ng working group

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

=========================================================
Hi, Daniel. Here is my review.. Bests. Byoung-Jo "J" Kim macsbug@research.att.com AT&T Labs - Research http://macsbug.googlepages.com/ ===================[BEGIN]====================== * Overall: The purpose and the content of this ID are mismatched and the coverage is very restricted to a small set. I don't see significant value in publishing this ID and fear unnecessary confusions if so. If it needs to be published, the title and the scope should be limited to the suitable subset of deployment models, instead of implying comprehensive coverage. Also, too many irrelevant statements and unsubstantiated claims are there, some of which I tried to point out.
* Section 1: Largely unnecessary content for ID. Does not state its scope and intent clearly. * Section 2.1: - The content before the definitions of MS are irrelevant. - Per 802.16e-2005, MS is always SS, thus often referred to as SS/MS. - In the BS definition: The following is getting ahead of the flow. "Sometimes there can be alternative IEEE 802.16 network deployment where a BS is integrated with an access router, composing one box in view of implementation." * Section 2.2: - Synchronize issues list with the 16ng problem statement - Bullet 3: The following is not the function of CS: "5) Forwarding the PDUs to the corresponding AR." * Section 2.2.1: - Lose the following. Irrelevant for this ID if not true: "This use case will be implemented only with the licensed spectrum. " - What's the point of this section in an IEFT ID if "All original IPv6 functionalities [RFC2461], [RFC2462] will not survive."? Why discuss IPv6 operation at all then? * Section 2.2.1.1: - What's the purpose of this paragraph and why does it matter in this ID? - If "IEEE 802.16 BSs have only MAC and PHY layers without router function and operates as a bridge.", then why "upgrading the following devices to dual-stack: MS, BS, AR and ER"? as BS is unaware of the IP layer? * Section 2.2.1.2 - Bullet 2: what's the point of this describing this particular DHCP arrangement. For all MS cares, a DHCP exists on the local subnet. Using relay/proxy is deployment decision. * Section 2.2.1.3 - The following statement is unsubstantiated: " when supported consumes air bandwidth as well as it would have adverse effect on MSs that were in the dormant mode." This is for allegedly broadband systems and the actual BW consumption for ND has never been quantified to justify the above. If the consumption is not too bad, it may be worth the overhead to keep the layering and protocols clean. Also, it is not clear that ND cannot be delivered as part of housekeeping MAC messages while in dormant mode. Also, as an implementation, all that can be combined with BS conservatively filtering based on its local knowledge, which often extends into IP layers of its SS/MS's. Some examples of this in 802.11 land. - The following is stated without justification as PHS makes this point moot, while the presence of Ethernet headers can be useful in shared prefix subnets, multiple hosts behind SS/MS, compatibility with metro-Ethernet backhaul, and so on, regardless of mobility levels. "Note that in this scenario 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 ." - Everything from the "Simple or complex network equipments may constitute.." till the end of section is irrelevant for this ID and can be found in other ID and RFCs in far more details. Remove or just refer. * Section 2.2.1.4: Irrelevant to this ID. Normal stuff and other ways exist. * Section 2.2.2: - In the first sentence, which "end-to-end"? - The following is out of place, and why can't these usages be mobile as well? There is no car/bike/bus in campuses? "Many wireless Internet service providers (Wireless ISPs) have planned to use IEEE 802.16 for the purpose of high quality broadband wireless service. A company can use IEEE 802.16 to build up mobile office. Wireless Internet spreading through a campus or a cafe can be also implemented with it." - This distinction of license and unlicensed spectrum for fixed model is not correct nor relevant. "The distinct point of this use case is that it can use unlicensed (2.4 & 5 GHz) band as well as licensed (2.6 & 3.5GHz) band." * Section 2.2.2.1: - See comments for section 2.2.1.1. - I don't think this is standard bridge behavior or is this describing something special? "The Ethernet bridge relays all traffic received through BS to its network side port(s) connected to BRAS. Any traffic received from BRAS is relayed to appropriate BS." How does the bridge know which one is "appropriate BS"? * Section 2.2.2.3: - In the first sentence, which "end-to-end"? - How? Another tunneling? Is it relevant then? "the IPv6 CS can also be supported." Just because you can does not mean it is a good idea. - Any reference or description of "Relay DAD"? there are earlier occurrences * Section 2.2.2.4: Remove. Irrelevant * Section 2.2.2.5: Remove. MIP should be usable on any normal IP networks as long as the user/MS has an HA to talk to and it is reachable. * Section 2.3: Remove. Does not add any content and all speculative (the ID admits that!) * Section 2.5: - "an MS is authenticated by the AAA server located at its service provider network." should read " an MS is authenticated by a AAA server.", kinda Duh? The location of AAA is irrelevant, as this ID lacks discussions of access network sharing, wholesale, roaming, etc.. - ?? "The AAA server authenticates the MSs and once authenticated." - Remove. Irrelevant. "IPsec is a fundamental part of IPv6. Unlike IPv4, IPsec for IPv6 may be used within the global end-to-end architecture. But, we don't have PKIs across organizations and IPsec isn't integrated with IEEE 802.16 network mobility management." * Section 2.6 - Lose the first sentence. Irrelevant - The second paragraph may be wrong, and at least irrelevant. - The last paragraph is irrelevant. ===================[END]======================