Subject: FW: Review on v6ops 802.16 deployment scenario (J Kim of AT&T Labs)

From: Daniel Park <[email-masked]>
Date: Fri, 15 Dec 2006 12:14:25 +0900

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 
[email-masked] 
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]======================

---

From: Fred Baker <[email-masked]>
Date: Thu, 14 Dec 2006 20:18:01 -0800

Thanks very much

---

From: Myung-Ki Shin <[email-masked]>
Date: Fri, 15 Dec 2006 15:40:37 +0900

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,

---

From: Myung-Ki Shin <[email-masked]>
Date: Fri, 15 Dec 2006 16:06:17 +0900

In addition,
if we want to see how 802.16 is deployed,
there will be other WiMAX NWG or 16ng documents.

Please see the 16ng charter
http://www.ietf.org/html.charters/16ng-charter.html

- Produce "IP deployment over IEEE 802.16 Networks" to illustrate the
IP deployment scenarios including IP CS and Ethernet CS considerations
over IEEE 802.16 networks based on the WiMAX and WiBro. [Informational
RFC]

Thanks,
Myung-Ki,