[16NG] Re: AD review of draft-ietf-16ng-ps-goals

Dear Jari,
Thank you for the review and valuable comments.
Please find inline replies.

----- Original Message ----- 
From: "Jari Arkko" <jari.arkko@piuha.net>
To: <draft-ietf-16ng-ps-goals@tools.ietf.org>; <16ng@ietf.org>
Sent: Monday, September 10, 2007 12:40 AM
Subject: AD review of draft-ietf-16ng-ps-goals

> 
> Hi all,
> 
> I have made my AD review of this document. The document is
> in relative good shape and I fully agree with the goals. However,
> there were a few substantial issues and a number of editorial
> issues that I discovered.
> 
> Please discuss these issues and/or revise the document
> accordingly. Also, I would like to ask the chairs to initiate
> a review in IEEE 802.16 through our liaison.
> 
> Also, from my review of the archives I did not see enough
> review of this document. I also did not see actual discussion
> about this document recorded in the minutes of last three
> IETFs. When you send the document back to me, please
> ensure that you have at least two additional reviews
> from WG members.
> 
> Substantial:
> 
>> This Ethernet like link model assumes that underlying
>> link layer provides the equivalent functionality like Ethernet, for
>> example, native broadcast and multicast.  It seems feasible to apply
>> the 802.16's Ethernet CS to configure this link model.  However,
>> there exists a discrepancy between the assumption from the Ethernet
>> like link model and the 802.16's MAC feature which is connection-
>> oriented and not providing multicast and broadcast connection for IP
>> packet transfer. 
> 
> Why would this be any different traditional wired & switched ethernet
> case? There is no native multicast over a set of wires...

Right, current texts are little bit misleading just mentioning the fundamental problems.
Please check the following amended texts and suggest any enhancement.

"
In the second Ethernet like link model, all SSs under an AR reside on the same IP Subnet.
This also applies when SSs are connected with different BSs. 
This Ethernet like link model assumes that underlying link layer provides the equivalent functionality like Ethernet, for example, native broadcast and multicast.
It seems feasible to apply the 802.16's Ethernet CS to configure this link model.  
***
However, the 802.16's MAC feature is still connection-oriented not providing multicast and broadcast connection for IP packet transfer. 
There needs mechanisms like IEEE 802.1D to realize multicast and broadcast to realize Ethernet like link model for Ethernet CS.
Moreover, the frequent IP multicast and broadcast signaling within the IP subnet like Ethernet needs to be avoided not to wake up sleep/idle [IEEE802.16e] SSs
***.
"

>>    Blocking ARP or the address resolution of NDP needs to be implemented
>>    by SS itself in an implementation manner.
> There is no mention of such blocking in the 16ng's IPv6
> document (ipv6-over-ipv6cs). Would blocking NDP packets
> break IPv6 NUD?

It could be dealt by the separate thread.

>>    Because MAC address is not used for transmission in case of IP CS, it
>>    is unclear whether source link layer address need to be carried in
>>    the RS (Router Solicitation).  The RS may need to have source IP
>>    address specified so that the RA (Router Advertisement) can be sent
>>    back.  This may require the completion of the link local address
>>    configuration before sending an RS. 
> Why would you need the source address? This is the point-to-point 
> link model...

Yes, there is no need to include the source link layer address because here the link model is point-to-point.
Therefore, the Router Discovery part for 5.2 Point-to-Point Link model for IP CS: Problems would be the following:

"
 -Router Discovery:
   BS needs to send the RA with separate IP prefix in unicast manner for each SS explicitly to send periodic router
   advertisements in 802.16 Networks.
"

>> If there
>>    exists multiple ARs (so the default routers), it is unknown if the
>>    NUD is required if an AR is not serving any 802.16 MAC connection.
> 
> How can you have multiple devices at the end, if this is a
> point-to-point link?

Right, there also does not exist multiple ARs. 
Therefore, the Neighbor Unreachability Detection (NUD) part for 5.2 Point-to-Point Link model for IP CS: Problems would be the following:

"
 - Neighbor Unreachability Detection (NUD):
   Because SS always see an AR as the next hop, the NUD is required only
   for that AR.  Also the requirement of NUD may depend on the existence
   of a connection to the BS for that particular destination. 
"

> 
> Editorial:
> 
>>    sublayer (CS) is at the uppermost of the MAC that is responsible for
> 
> ... uppermost part ...
> 
>>    assigning transmit-direction SDUs (originating from a higher layer
> 
> Expand the acronym SDU

Okay.
> 
>>    [I-D.thaler-intarea-multilink-subnet-issues].
> 
> RFC 4903.
> 
>>    Blocking ARP or the address resolution of NDP needs to be implemented
>>    by SS itself in an implementation manner
> 
> This probably should read: Blocking ARP or NDP address resolution packets
> needs to be implemented by SS itself in an implementation specific
> fashion.

Thank you, it will be amended following the suggestion.

> 
>> To acquire that address, the
>>    address resolution should be performed throughout conventional
>>    broadcast and multicast based ARP or NDP.  However, this multicast
>>    and broadcast packets results in the problem of waking up the sleep/
>>    idle [IEEE802.16e] SSs.
> Yes, but you should probably say ... if not filtered (e.g., RFC 4541), these
> multicast and broadcast packets ...

Thank you.

> 
> Also, s/this/these/

Yes.

> 
>> 2.  Requirements
>>
>>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>>    document are to be interpreted as described in [RFC2119] .
>>   
> 
> Remove this section and reference if the keywords are not used.

Right. it will be removed.

Best Regards,
Junghoon

> Jari
> 
>