[16NG] Review comments on draft-ietf-16ng-ip-over-ethernet-over-802.16-00

Hi,

I have read this (draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt)
document and have the following comments.

Meta comments:

1. I have rather difficulty in understanding this document, may be
 because the way the document has been organised. I think it is a
 good idea to follow the format similar to IP/IPv6 over foo documents.
 I understand in this document we may need to specify little
 more on how the Ethernet is emulated over 802.16. In the current
 format this is not clear and crisp to me

2. After reading the entire I could not understand where the Bridging
needs to be implemented in BS, AR or a box between BS and AR.

3. There is great deal of explanation on packet filtering and forwarding,
but I could not understand whether this is some thing new that is being
recommended or it has already been defined e.g. in 802.1D.

4. This document defines a new tunnel between BS and Bridge, so what the
relation to R6 tunnel between BS and AR?

5. Section 7.6 specifies that the AR should perform packet relay
functionality. =Is this different from the bridging that is being
talked in the document? I am confused now, why we need Bridging
when AR is doing the packet relay.

6. I think lots of text repetition across the documents in sections 4, 5
and 6.

7. And I expected lots of usage of RFC 4541 in this draft , but it
   has just been limited to References section.

Specific comments:

> Abstract
>
>  Due to resource
>    constraints of radio transmission systems and the limitations of the
>    IEEE 802.16 MAC layer for the emulation of Ethernet, the transmission
>    of IP over an emulated LAN on top of IEEE 802.16 may considerably
>    benefit by adding IP specific support functions within the Ethernet
>    emulation on top of IEEE 802.16.

I could not understand this. May be you should rewrite this text by
splitting into multiple sentences.

>
>
> 1.  Introduction
>    IEEE 802.16e [IEEE802.16e] amends the
>    base specification with PHY and MAC functions for supporting mobile
>    terminals by adopting the same data link principles also for mobile
>    networking systems.
>

may be you can say "mobile terminals and mobile networking systems
by adopting the same data link principles.".

>
> 4.  The IEEE 802.16 Link Model

May be repetition, this text should be available in 16ng PS draft.

>
> 4.4.  Discovery of MAC addresses
>

I could not figure out in the document the context for BS discovering
the MAC addresses

>    BS can construct link local address of each SS from adding prefix
>    "FE80::/64" to last 24 bits of MAC address corresponding to the each
>    SS

I think this is incorrect. Rather simply refer to RFC 3513.

>
>
> 5.  The IEEE 802.16 Network Model for Ethernet
>
> 5.1.  IEEE 802.16 Ethernet Link Model
...
>     Ethernet is realized on
>    top of IEEE 802.16 by implementing bridging between all SSs with IEEE
>    802.16 providing the links between the hosts and the bridge behind
>    the BS like the twisted pair wires used in today's switched Ethernet.

The second half the sentence (and the bridge behind ....), I think,
did not fit well here. Either rewriting, or simply deleting it may help.

>
> 5.2.  Ethernet without Native Broadcast and Multicast Support
>
>    Ethernet is emulated on top of IEEE 802.16 without making use of MBS
>    as defined in 6.3.23 of [IEEE802.16e] to allow full control over the
>    reaction of SSs to broadcast messages.  Instead of using MBS,
>    broadcast and multicast messages are transferred in a unicast manner.

Which element does this transfer of multicast packets?

> 5.3.  Default Processing of Ethernet Frames
>
>    The BS SHALL forward all the radio connections belonging to one SS to
>    a port of a bridge between all ports on the radio side and the
>    interfaces towards the network side.

I could not understand this, may be required to rewritten.

>    If the SS functions as a bridge
>    then it SHALL support a bridging between all its LAN ports and the
>    airlink.

Does this document need to care about bridging at SS?

>
> 6.  Deployment Scenarios for IP over Ethernet over IEEE 802.16

May be we should think about referring to
draft-ietf-v6ops-802-16-deployment-scenarios

> 6.1.  Public Access Scenario

I think we need to be careful when saying Peer-to-peer/direct
communication is not possible between hosts. It is possible but
the communication should always happen through the AR.
>
> 7.  Filtering and Forwarding
>
> 7.1.  IP Broadcast and Multicast Support
>
>    IP broadcast and multicast data are replicated and then transferred
>    in a unicast manner without using native MBS support as explained in
>    Section 5.2.

The same question here, who does this?

>
>    Unicast 802.16 transport connections are extended to a bridge by any
>    tunneling mechanism such as GRE tunnel between BSs and the bridge.
>    As a result, point-to-point connections have been established between
>    a bridge and each SSs.

What's the relation between this GRE tunnel and WiMAX forum defined
R6 tunnel? Will the R6 tunnel be inside this GRE tunnel?

>
> 7.2.  Packet Filtering

I think we should state whether this document defines this functionality
newly or just describes which has been defined elsewhere e.g. may be
in 802.1D or RFC 4541.
>
> 7.4.  Address Resolution Protocol Proxy Function
>
> 7.5.  Neighbor Discovery Relay Function

I could not understand why we need these two functions,
when we are implementing bridging to emulate Ethernet
functionality.

>
>
> 7.6.  Access Router Behavior
>
>    In the case of the VLAN scenario, direct communication between SSs
>    may be enabled for all SSs belonging to a particular VLAN.  In this
>    case, no special handling is required.

As long as we use R6 tunnel, even the in this scenario, the packets should
go through the AR.

>
> 8.1.1.  Address Resolution

Is this some thing new that this document recommending?

- Syam

_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng