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

["Junghoon Jee" <[e-mail]>]

----- Original Message -----
From: "Junghoon Jee" <[e-mail]>
To: "Jari Arkko" <[e-mail]>; <
[e-mail]>; <[e-mail]>
Sent: Tuesday, September 11, 2007 11:41 AM
Subject: 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" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>
> 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.2Point-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
>>
>>

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