Subject: [16ng] Phil Roberts' Review on 16ng problem statement

From: gabriel montenegro <[email-masked]>
Date: Thu, 7 Dec 2006 07:44:07 -0800 (PST)

> I would appreciate it if you posted it on my behalf as I don't subscribe
>  there.  Please find the review attached.:

Thanks, Phil. Folks here is his review:

-gabriel

-------------------------
802.16 Problem Statement and Goals draft review

In summary this document needs a lot of work.  It could better be reorganized around a few themes:
1) who are the organizations setting network architecture for the use of this and what network
architecture models have they chosen?
2) what is the subnet model that you are trying to support?
3) what is the relationship between the convergence sublayers and ethernet, and what are the
implications of it?
4) are there wireless specific (apart from protocols) that govern anything the IETF does?

The big question it seems to me that must be addressed is what does a subnet look like on a
network consisting of 802.16 subscriber stations and base stations.  Before that question is
answered it would seem to be hard to talk about how to build IP functionality, and afterwards it
should be fairly straightforward.  This is identified as a big issue, but this is The Big Issue.
There is so much text in the document where I wrote, it depends on the subnet model that I really
think you need to rewrite the document with this as the big question, or decide the answer to it
and then produce a problem statement for what needs to be done.

Having said that here are specific comments:

Introduction, para 2: it would be nice to have a public reference for the standards that NWG and
WiBro have produced, or are producing.  The reference at the end of the WiBro sentence is back to
.16e, which we already have, and where we would like to have a reference to WiBro.

Para 3: it would be better to talk about how the session is started actually rather than talking
about how at some point in the sequence there are things you can't do.  So what does it do?  A one
or two paragraph description of how it actually works would be useful here.

Para 4:
s/lacking/lack
Reword the last two sentences

Terminology
Is this terminology unified across the ieee specs, the wimax forum specs, the wibro specs?
Would it be helfpul to have a diagram to show the relationship between PDU and SDU in this
context?
Does connection identifier need its own entry (it's sort of defined under transport connection).
Do you want to define BSid in this section?  Convergence sublayer?
There are references in the document to an IP gateway, but I don't know what that is.

Sec 4.3
This section seems to need more explanation about how this works and a reference to that description.

The last sentence says that the convergence sublayer type actually defines the type of interface
presented to an application.  I don't think this is quite correct.  It describes a kind of framing,
but I don't believe it means that if you are using Ethernet CS, for example, the 802.16 link
necessarily behaves exactly like an Ethernet.

Sec 5.1 - section titled point to multipoint
I think this section needs to be reworded quite a bit, as I'm not sure I follow the argument.  IP
works over point to point links.  In most of those it doesn't need ARP, for example.  This should
be the line of reasoning behind this discussion.

Sec 5.2
Each of these big sections (5.2, 5.3) need text describing what the section in general is about;
this one I gather is specifics about IP CS

5.2.1
- paragraph under DHCPv4
s/static method is configured by manual though/but it is possible to configure static addresses manually

re: "However, it still requires multicast/broadcast ...."  Maybe this should say expects, but this
can operate over a point to point link, no?

- ARP resolution
I wouldn't say there is no need for address resolution.  The device needs to figure out how to forward
the packeet.  It doesn't need to put a MAC address in the lower layer PDU because there isn't one and
there isn't a need for one, but the base station still needss to figure out how to get the packet to the
right place.  I'm not sure how much text is needed to say this.

- Address resolution and neighbor cache:
sort of the same thought as above

- Next hop
"may always"  is this really a may, or should it be "is always?"

sec 5.3
I think you need to make clear that ethernet cs doesn't mean that .16 nets are behaving as ethernet.
I think in that context you can then say that it is assumed that the ethernet frame sent by the SS
arrives at the IP gateway unchanged.
Should one question that assumption?  Is there an entity between the SS and the IP gateway that could
change it, and if so, why is it safe to assume that it is unchanged?

sec 6

3gpp recommendation
It perhaps should be made clear the recommendation is for IPv6?
Also there is little use made of PPP in GPRS networks.  So it should be clear to what extent the
use or not of ppp impacts the gap analysis.

LAN model
I don't have enough context of the discussion to understand what this is talking about.  More preamble
about what the proposal is might help understand why you don't think it will work.

Goals
Where did some of these goals come from?
Goal #2 - I thought this was wireless broadband, what are we doing talking about scarce resources here?
Where was this described as part of a problem?

Goal #3 - where did this come from?  It depends on what kind of device you are talking about and how it
is powered.  This wasn't discussed in the problem section.

Goal #5 - is this a goal?  for whom?  The relationship between Ethernet CS and what the highler layers
expect may be problematic, but is it really a goal for this working group to make an 802.16 network with
802.16 CS support function like an Ethernet.  That sounds like a task maybe for IEEE but not for IETF.

Security
I'm assuming there is a threat model item somewhere that is what should really be referenced here?

_______________________________________________
16ng mailing list
[email-masked]
http://eeca16.sogang.ac.kr/mailman/listinfo/16ng

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 07 Dec 2006 17:58:00 +0100

A few comments inline... sorry for heavy snipping portions that I mainly
agree with it.

gabriel montenegro wrote:
phil roberts wrote:
>> I would appreciate it if you posted it on my behalf as I don't 
>> subscribe there.  Please find the review attached.:
> 
> 802.16 Problem Statement and Goals draft review sec 5.3 I think you 
> need to make clear that ethernet cs doesn't mean that .16 nets are 
> behaving as ethernet. I think in that context you can then say that 
> it is assumed that the ethernet frame sent by the SS arrives at the 
> IP gateway unchanged. Should one question that assumption?  Is there
>  an entity between the SS and the IP gateway that could change it,
> and if so, why is it safe to assume that it is unchanged?

Not sure how safe is that.  In some architectures  I've seen
intermediary BSs change the src MAC address in the Ethernet header of
packet comingfrom SS to gateway, which is not necessarily good or bad,
but to say frame changes may occur... if the context is so set.

But probably nothing else changes than that src address.

> Goal #5 - is this a goal?  for whom?  The relationship between 
> Ethernet CS and what the highler layers expect may be problematic, 
> but is it really a goal for this working group to make an 802.16 
> network with 802.16 CS support function like an Ethernet.  That 
> sounds like a task maybe for IEEE but not for IETF.

Indeed link-layer related tasks are surely IEEE-bound, more than IETF-bound.

I do think however that it is possible to have a set of goals for
running a multiaccess-link capable IPv6 stack (ND, IPv6/Ethernet) over
an 802.16 CS.  The set of goals is extremely simple and very well
understood, coming from existing stacks running over Ethernet multiple
access links.  They may be considered by IEEE CS designers.

A few I can quickly come up with are: IP MTU 1280, use a 48bit MAC
addresses for each addressable end, use 0x86dd Ether type, use 14-byte
Ethernet headers like src-dst-type, receive frames addressed to
link-layer multicast 33:33:0:0:1 (maybe only after MLD JOIN - but that's
not b/w).

If this kind of goals have been already considered in ETH CS design,
then it's ok.  Some statement is needed though towards clarification of
that.  Its effect could go as far as removing the item IPv6-over-ETHCS
from the 16ng Charter.

Alex