RE: [16NG] WGLC: draft-ietf-16ng-ip-over-ethernet-over-802.16-02

[Burcak Beser <[e-mail]>]

[Architectural Issues]

First of all, I have to admit that the Draft is very hard to read, and could be improved a lot by a careful re-write.

Let me try to summarize what I understood:

The Host devices are connected to a bridge SS which is through 802.16 links (Service Flows) connected to BS. BS assumes that each SS is connected to a port and though an undefined mechanism connects these ports to "the Bridge" that does not bridge; which in turn aggregates these links to one Access Router or aggregates other BS to the Access Router.

Each time a new SS connects the BS creates a new port and opens a new undefined link that connects this port to the Bridge. Each time an SS disconnects from the BS, the undefined link is destroyed between the BS.

First, the link between the BS and the Bridge is left as an exercise. The examples given as the undefined link are: VLANs or GRE tunnels. The original "-0" draft was using the GRE tunnels and now this interface is left undefined. Since the GRE tunnel method has many issues which were described in detail on the -0 feedback e-mail dated 1/8/2007 with subject line "Request for clarification on draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt", so I do not understand why it is given even as an example. One example with GRE tunnels is the fact that they restrict the maximum packet size to less than 1500 bytes for IP packets. There are other problems with VLANs as well but since these are given as example I will not go in detail with these problems.

The second issue is that there needs to be an defined protocol between the BS and the Bridge which enables the BS to create and destroy the undefined links. This protocol is not just undefined but is not even mentioned within the Draft.

The third issue with the undefined link is the fact that no matter which transport method is being used the Bridge will be encapsulating the packets that are being forwarded to BS and decapsulating from the packets that are coming from the BS. For GRE this means that the Bridge will be putting the MAC packets into L3 tunnel. Since the undefined mechanism is undefined I am not so sure.

The Fourth issue is even though the Draft is skimpy on the BS to the Bridge connectivity, it is not shy on putting vague restrictions on the Access Router that the Bridge is connected. One example is the statement "The AR SHOULD perform security filtering, policing and accounting of all traffic from hosts, e.g. like a NAS (Network Access Server)."

I have many other issues on the architectural side but these are the major ones.

I have a simple question: Why there is a need to separate the BS and the Bridge? The merging of the BS and the Bridge will free you from the interface that is undefined now, will make a lot of sense from the architectural view since there is no reason given for the separation. If one wants to divide a BS as air interface module and bridging module, they can still do it but this draft does not need to define that detail.

Moreover, the merging of the BS and the Bridge will enable the focus to be given to SS and BS. Personally I find unnecessary to put restrictions on the Access Routers and put network restrictions that should be provider decisions.

Kind Regards,
-burcak

> -----Original Message-----
> From: Daniel Park [mailto:[e-mail]]
> Sent: Thursday, August 16, 2007 3:50 PM
> To: [e-mail]
> Subject: [16NG] WGLC: draft-ietf-16ng-ip-over-ethernet-over-802.16-02
>
> Folks,
>
> This is a WGLC on draft-ietf-16ng-ip-over-ethernet-over-802.16-02
> "Transmission of IP over Ethernet over IEEE 802.16 Networks".
>
> o Intended publication: Proposed Standard RFC
>
> The latest version can be found at:
> http://www.ietf.org/internet-drafts/draft-ietf-16ng-ip-over-et
> hernet-over-80
> 2.16-02.txt
>
> Due to vacation period, it will expire on September 7 2007.
>
> -------------------------------------------------------
> Daniel Park & Gabriel Montenegro
> Chairs, 16NG Working Group
>
>
>
> _______________________________________________
> 16NG mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/16ng
>
>



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