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

["Syam Madanapalli" <[e-mail]>]

Hello Jari,

On 9/9/07, Jari Arkko <[e-mail]> wrote:
> Hi all,
[cut]
>
> 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...

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.

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

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

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

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.

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

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

>
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/16ng