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

["Riegel, Maximilian" <[e-mail]>]

It would be nice to have more clear references to the text of the I-D.
The statements are randomly pulled together out of different sections of
the draft, possibly describing alternative deployment options.

There are two deployment options: the public access scenario and the
enterprise LAN scenario. The behavior of the bridging function varies
depending of the scenario, and in one radio access network multiple
instances of each of the scenarios may co-exist in the same physical
bridge separated by VLANs.

What do you mean with a bridge: a physical box probably supporting VLANs
or the logical bridging function within one instance of the public
access scenario or enterprise LAN scenario?

The tunnel protocol of the link between the BS and the bridge does not
belong to the bridging function but may be implemented within the
physical bridge entity, e.g. a PC with LINUX deploying the bridge module
as well as GRE in its network stack.

As defined in 802.1D the bridge may have static as well as dynamic
entries. Static entries are made by configuration, e.g. when a new port
is established as result of a network entry and a successful
authentication of a new MS. Static entries do not age, while dynamic
entries will be learned by inspecting the packets going through the
port. What is missing in the description in the I-D?

Bye
Max



-----Original Message-----
From: ext Burcak Beser [mailto:[e-mail]] 
Sent: Friday, September 07, 2007 6:57 AM
To: Daniel Park; [e-mail]
Subject: RE: [16NG] WGLC:
draft-ietf-16ng-ip-over-ethernet-over-802.16-02

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

The Draft defines a Bridge which is define by IEEE802.1D and IEEE802.1K
with following exceptions:

   "The bridge SHOULD forward all packets
   received from any radio side port to all network side ports being in
   the forwarding state.  Peer-to-peer communication SHOULD NOT be
   supported by the bridge and all packets originated from a SS SHOULD
   be delivered to an AR.

And:

   "All multicast and multicast control messages SHOULD be processed in
   the bridge according to [RFC4605]."

Moreover:

   "Broadcasting messages to all
   radio side ports of the bridge SHOULD be prevented."

Further:

   "The Proxy ARP process is usually co-located with the
   bridge behind the BS."

Finally:

   "The bridge SHOULD filter these [since the bridge cannot know which
ones it has to filter all -burcak]
   broadcast DHCP OFFER and DHCP ACK messages and forwards the broadcast
   messages only to the host defined by the client hardware address in
   the chaddr information element.

As far as I can see the Bridge can only be connected to a single Access
Router. And on the BS side it may even put all the packets into a L3
tunnel to send it to the BS and strip them from the tunnel for packets
coming from the BS.

At a first glance this does look like anything but a bridge. I am sure
that I am missing something, what is it?

Since this is a IEEE802.1D bridge, it is not clear to me how does the
bridge re-learn a MAC address which has aged in its MAC table.

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


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