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

From: Jari Arkko <[email-masked]>
Date: Sun, 09 Sep 2007 18:40:52 +0300

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...

>    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?

>    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...

> 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?

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

>    [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.

> 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 ...

Also, s/this/these/

> 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.

Jari

_______________________________________________
16NG mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/16ng

---

From: "Syam Madanapalli" <[email-masked]>
Date: Sun, 9 Sep 2007 22:48:38 +0530

Hello Jari,

> Hi all,
[cut]
> case? There is no native multicast over a set of wires...

As far as Ethernet is concerned, I think, running IEEE 802.1D is obvious.
The intention here is to explicitly mention that the native multicast is not
available and may need mechanisms like IEEE 802.1D.

> document (ipv6-over-ipv6cs). Would blocking NDP packets

A host using IPCS cannot send ARP packets over IEEE 802.16 connections.
Of course, ARP is not required in this case.

> Why would you need the source address? This is the point-to-point

Earlier, we have been thinking about shared link model. Also, IEEE 802.16
requires IP address for establishing MAC connections. To overcome this,
WiMAX forum defined Initial Service Flow (ISF) which can be used for NDP.

> How can you have multiple devices at the end, if this is a

Now, point-to-point link model is chosen, so this does not hold good.

And yes, we need to rewrite the text for these.

Thanks,
Syam

---

From: Jari Arkko <[email-masked]>
Date: Sun, 09 Sep 2007 21:23:23 +0300

Syam,

Thanks for your quick response.

> available and may need mechanisms like IEEE 802.1D.

Yes -- please state so in the document instead of referring to
fundamental problems that in the end aren't true problems.

> Of course, ARP is not required in this case.

Then first you have to take the IPv6 part out.

Secondly, I recall some discussion months ago about DNAv4
and ARP filtering. What was the conclusion?

> Earlier, we have been thinking about shared link model. 

Yes, but this is under Section 5.2 (point to point model).

> Also, IEEE 802.16

That's OK, but if that is so, there does not seem to be any problem
with the RS.

> Now, point-to-point link model is chosen, so this does not hold good.

Ok, lets change the document so it correspond to the current
model.

> And yes, we need to rewrite the text for these.

Thanks.

Jari

---

From: Daniel Park <[email-masked]>
Date: Mon, 10 Sep 2007 09:23:28 +0900

Jari, 

> a review in IEEE 802.16 through our liaison.

Yep, DJ Johnston had reviewed this document twice (or more)
and the editor added his feedbacks into the document. I guess
his review represents IEEE 802.16 review.  

Do we need to solicit another request for review to IEEE 802.16 ?

> ensure that you have at least two additional reviews

Unfortunately, we skipped over several meetings due to lack
of authors' efforts on this document. But, chairs did officially
request two exerts (DJ and Phil) for their reviews several
month back and refelected on this document accordingly.

Sorry for the delay and hope this helps.

Daniel Park

---

From: "Junghoon Jee" <[email-masked]>
Date: Tue, 11 Sep 2007 11:41:24 +0900

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

----- Original Message ----- 
From: "Jari Arkko" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Monday, September 10, 2007 12:40 AM
Subject: AD review of draft-ietf-16ng-ps-goals

> 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
***.
"

> document (ipv6-over-ipv6cs). Would blocking NDP packets

It could be dealt by the separate thread.

> Why would you need the source address? This is the point-to-point 

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.
"
  
> How can you have multiple devices at the end, if this is a

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. 
"

>>    assigning transmit-direction SDUs (originating from a higher layer

Okay.
> needs to be implemented by SS itself in an implementation specific

Thank you, it will be amended following the suggestion.

> multicast and broadcast packets ...

Thank you.

> Also, s/this/these/

Yes.

> Remove this section and reference if the keywords are not used.

Right. it will be removed.

Best Regards,
Junghoon