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

From: Daniel Park <[email-masked]>
Date: Wed, 05 Sep 2007 11:43:33 +0900

reminding...

No show in the list for this WGLC. If you have any comments/feedbacks on
this call, please speak up now. Also, if you are ok with this version (no
changes), please show up your positive on this list. Otherwise, this WGLC
can't pass...!

Daniel Park

> -----Original Message-----
> From: Daniel Park [mailto:[email-masked]] 
> Sent: Thursday, August 16, 2007 3:50 PM
> To: [email-masked]
> 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/16ng
> 
> 

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

---

From: "Jongtaek Oh" <[email-masked]>
Date: Thu, 6 Sep 2007 13:05:17 +0900

I have some comment about the draft-ietf-16ng-ip-over-ethernet-over-802.16-02,
especially for broadcasting and multicasting issue.

1. Firstly, it describes the functionality of IEEE 802.16 network for MBS services, very pessimistically.
    As it mentioned, the specification and technology for MBS is not perfect. But it is under developing by NWG of WiMax forum,
    and the broadcasting and/or multicasting in the radio link could be possible, not impossible.
    This draft is for standard RFC, not for informative RFC, so only specification related matters must be defined in the draft
    and leave the room for new technology can come in.

2. MBS service is important for network operators and service providers to compete with the other cellular networks.
    For example, 3GPP Release99 can broadcast messages using cell broadcasting technology.
    WiMax forum is developing MCBCS related technologies and specifications which deals with the solution against the problems the appendix A cited.
    For example, the unicasting or the broadcasting methods are to be decided at the BS or AR according to the number of users in the cell.
    If all the IETF documents exclude the possibility of broadcasting and multicasting transmission method, then they could be useless to the WiMax industry.

In conclusion, I suggest to remove all the sentences which state the negative respects of  multicast/broadcast for 802.16 network including Appendix A.

Jongtaek Oh
Hansung Univ.
Seoul, Korea

---

From: "Riegel, Maximilian" <[email-masked]>
Date: Thu, 6 Sep 2007 11:47:56 +0200

Please do not mix up MBS services (MCBCS in the WiMAX Forum) with MBS in
the IEEE802.16 specification. MBS in the IEEE802.16 specification
describes the possibility to share a downlink connection with multiple
MSs/SSs.

MBS Services are fully supported by this I-D (please see chapter 6.1).

There are good reasons not to deploy IEEE802.16 MBS channels for
Ethernet broadcasts. Annex A lists purely for information some of the
issues coming up with deployment of IEEE802.16 MBS channels.

Indeed there is an ongoing activity in the WiMAX Forum on MCBCS, which
works on network solutions to increase the efficiency of MBS channels
especially at the cell edge. The issues listed in annex A will remain,
but the effects on the link capacity will become smaller. Unfortunately
new issues will appear for real deployments.

Is there any publication explaining the benefits and issues of
IEEE802.16 MBS channels more in detail? Annex A is little bit too much
radio and I would like to remove annex A if there is any reference we
can use instead.

Any hint for a reference?

Bye
Max

-----Original Message-----
From: ext Jongtaek Oh [mailto:[email-masked]] 
Sent: Thursday, September 06, 2007 6:05 AM
To: [email-masked]; Daniel Park
Cc: ?????; ?????; ??????; ?????
Subject: Re: [16NG] WGLC:
draft-ietf-16ng-ip-over-ethernet-over-802.16-02

I have some comment about the
draft-ietf-16ng-ip-over-ethernet-over-802.16-02,
especially for broadcasting and multicasting issue.

1. Firstly, it describes the functionality of IEEE 802.16 network for
MBS services, very pessimistically.
    As it mentioned, the specification and technology for MBS is not
perfect. But it is under developing by NWG of WiMax forum,
    and the broadcasting and/or multicasting in the radio link could be
possible, not impossible.
    This draft is for standard RFC, not for informative RFC, so only
specification related matters must be defined in the draft
    and leave the room for new technology can come in.

2. MBS service is important for network operators and service providers
to compete with the other cellular networks.
    For example, 3GPP Release99 can broadcast messages using cell
broadcasting technology.
    WiMax forum is developing MCBCS related technologies and
specifications which deals with the solution against the problems the
appendix A cited.
    For example, the unicasting or the broadcasting methods are to be
decided at the BS or AR according to the number of users in the cell.
    If all the IETF documents exclude the possibility of broadcasting
and multicasting transmission method, then they could be useless to the
WiMax industry.

In conclusion, I suggest to remove all the sentences which state the
negative respects of  multicast/broadcast for 802.16 network including
Appendix A.

Jongtaek Oh
Hansung Univ.
Seoul, Korea

----- Original Message ----- 
From: "Daniel Park" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 05, 2007 11:43 AM
Subject: RE: [16NG] WGLC:
draft-ietf-16ng-ip-over-ethernet-over-802.16-02

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 06 Sep 2007 12:10:03 +0200

> changes), please show up your positive on this list. Otherwise, this WGLC

Daniel, members,

Thanks for the WGLC on this draft.

I'm currently planning to review it but I can't remark on it right now 
because there are so many activities in this space on which I have to 
follow.

Is it possible to extend the WGLC period for IPoverEth maybe until next 
IETF?

I'm generally positive on this draft on this list.

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Burcak Beser <[email-masked]>
Date: Thu, 6 Sep 2007 10:28:28 -0700

Thanks Daniel, I missed this one.

I would like to repeat what Alexandra said; there are too many things are going for me to do a through read of the draft.

Having said that I will try to send another e-mail with some points that directly popped up.

-burcak

-----Original Message-----
From: Daniel Park [mailto:[email-masked]]
Sent: Tuesday, September 04, 2007 7:44 PM
To: [email-masked]
Subject: RE: [16NG] WGLC: draft-ietf-16ng-ip-over-ethernet-over-802.16-02

reminding...

No show in the list for this WGLC. If you have any comments/feedbacks on this call, please speak up now. Also, if you are ok with this version (no changes), please show up your positive on this list. Otherwise, this WGLC can't pass...!

Daniel Park

---

From: Daniel Park <[email-masked]>
Date: Fri, 07 Sep 2007 09:15:06 +0900

Alex, 

This WGLC solicitation is an honor of 16ng members 
following the last meeting consensus. First, let's see 
how many feedbacks/comments are shown on the list.
After that, chairs will make a decision whether or not 
we do more processes.

So far, I don't see strong supports on this WGLC 
unfortunately...:-(

Daniel Park

> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Thursday, September 06, 2007 7:10 PM
> To: Daniel Park
> Cc: [email-masked]

---

From: Burcak Beser <[email-masked]>
Date: Thu, 6 Sep 2007 21:26:28 -0700

[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

---

From: Burcak Beser <[email-masked]>
Date: Thu, 6 Sep 2007 21:56:39 -0700

[Bridge Issues]

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

---

From: Burcak Beser <[email-masked]>
Date: Thu, 6 Sep 2007 22:31:24 -0700

I did not hear any issues with 802.16 broadcast channel(s). If there were any issues, then the communication of IEEE 802.16 transmission management will have a lot of issues as well and the unicast service flows will not be utilized at all.

Lets make the assumption that all SS' but one can connect at 64QAM, and a single one can only connect with QPSK If we want to send multicast packets to some number of SS connected, the advantage of sending individual packets disappear with 4 SS (all of them being 64QAM) or 1 SS (connected through QPSK). More than that the broadcast through QPSK channel will be more advantageous.

For applications such as IPTV the use of Broadcast (or Multicast) Service Flows will almost always (practically always) be the most efficient.

I would like to understand better why Broadcast channels are not even considered.

Kind regards,
-burcak

-----Original Message-----
From: Riegel, Maximilian [mailto:[email-masked]]
Sent: Thursday, September 06, 2007 2:48 AM
To: Jongtaek Oh; [email-masked]
Cc: ?????; ?????; ??????; ?????
Subject: RE: [16NG] WGLC: draft-ietf-16ng-ip-over-ethernet-over-802.16-02

Please do not mix up MBS services (MCBCS in the WiMAX Forum) with MBS in the IEEE802.16 specification. MBS in the IEEE802.16 specification describes the possibility to share a downlink connection with multiple MSs/SSs.

There are good reasons not to deploy IEEE802.16 MBS channels for Ethernet broadcasts. Annex A lists purely for information some of the issues coming up with deployment of IEEE802.16 MBS channels.

Indeed there is an ongoing activity in the WiMAX Forum on MCBCS, which works on network solutions to increase the efficiency of MBS channels especially at the cell edge. The issues listed in annex A will remain, but the effects on the link capacity will become smaller. Unfortunately new issues will appear for real deployments.

Is there any publication explaining the benefits and issues of
IEEE802.16 MBS channels more in detail? Annex A is little bit too much radio and I would like to remove annex A if there is any reference we can use instead.

Bye
Max

-----Original Message-----
From: ext Jongtaek Oh [mailto:[email-masked]]
Sent: Thursday, September 06, 2007 6:05 AM
To: [email-masked]; Daniel Park
Cc: ?????; ?????; ??????; ?????
Subject: Re: [16NG] WGLC:

Jongtaek Oh
Hansung Univ.
Seoul, Korea

---

From: "Riegel, Maximilian" <[email-masked]>
Date: Sat, 8 Sep 2007 00:11:18 +0200

Hi Alex,

Please send your comments as soon as possible. There where a couple of
comments during the WGLC, which we will address in a new revision of the
I-D. It would be nice also to address your comments in the next edition.

Bye
Max

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Thursday, September 06, 2007 12:10 PM
To: Daniel Park
Cc: [email-masked]
Subject: Re: [16NG] WGLC:

Daniel, members,

Alex

---

From: "Riegel, Maximilian" <[email-masked]>
Date: Sat, 8 Sep 2007 00:11:17 +0200

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:[email-masked]] 
Sent: Friday, September 07, 2007 6:57 AM
To: Daniel Park; [email-masked]
Subject: RE: [16NG] WGLC:

[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:

And:

Moreover:

Further:

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

---

From: "Riegel, Maximilian" <[email-masked]>
Date: Sat, 8 Sep 2007 00:11:15 +0200

It seems the architectural issues are more implementation issues than
issues with the architecture.

First, there are a couple of possible implementation of the link between
BS and Bridge, and GRE and VLAN are mentioned because the WiMAX Forum
has chosen GRE for the mobile WiMAX architecture and VLANs look more
familiar to the Ethernet people. GRE works fine as shown in the WiMAX
Forum specifications and is able to carry any packet size as IP is able
to fragment and reassemble packets exceeding the MTU of the underlying
transport. VLAN has restrictions on the supported packet size - even
1500 byte ETH packets may fail.

Second, the protocol being used for establishing and releasing the links
between BS and Bridge depends on the implementation. For the GRE
solution, the WiMAX Forum has defined a well defined protocol called
'Data Path Function' and for VLAN a standardized solution like GVRP may
be deployed. It may be appropriate to mention the control protocols
together with the implementation examples.

Third, encapsulation and decapsulation of Ethernet packets going over
the link between BS and Bridge are functions of the particular tunneling
protocol deployed for the implementation. Again an implementation issue
with no relevance for the architecture.

Forth, the requirements on the functions performed by the AR should be
more elaborate. We will be put more specific information into this
section.

The architecture is showing a single bridge behind the BSs. It would be
possible to split the single bridge into a number of smaller bridges,
each directly connected to a BS. Such a distributed implementation would
be much less efficient in filtering packets to prevent unnecessary
forwarding and flooding and would be more vulnerable for security
threats. Therefore the centralized form was chosen for this
specification.
 
Thanks for providing feedback on the I-D.

Bye
Max

-----Original Message-----
From: ext Burcak Beser [mailto:[email-masked]] 
Sent: Friday, September 07, 2007 6:26 AM
To: Daniel Park; [email-masked]
Subject: RE: [16NG] WGLC:

[Architectural Issues]

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

---

From: "Riegel, Maximilian" <[email-masked]>
Date: Sat, 8 Sep 2007 00:11:15 +0200

Bye
Max

-----Original Message-----
From: ext Burcak Beser [mailto:[email-masked]] 
Sent: Friday, September 07, 2007 6:26 AM
To: Daniel Park; [email-masked]
Subject: RE: [16NG] WGLC:

[Architectural Issues]

Kind Regards,
-burcak

---

From: "Riegel, Maximilian" <[email-masked]>
Date: Sat, 8 Sep 2007 00:11:17 +0200

There are no issues with the broadcast/multicast channels with the
exception that they consume much more radio resource than unicast
channels for the same amount of information and they do not work well
with advanced power down modes of terminals.

If information has to be delivered concurrently to many terminals in a
cell like in the IPTV case during world soccer games, multicast channels
are well suited. If they are less than about 5 subscribers to a
particular data stream in a cell, the efficiency of multicast channels
becomes questionable. If broadcast/multicast information is intended for
only one terminal (like an ARP request) and there are other ways to find
the right link, it is much better not to use a multicast/broadcast
channel but deliver the packet on a unicast channel to the terminal.
And in a IEEE802.16e system there are quite a few alternatives to the
'brut-force' multicast channel, especially when the architecture enables
access to all of the configuration data.

Bye
Max

-----Original Message-----
From: ext Burcak Beser [mailto:[email-masked]] 
Sent: Friday, September 07, 2007 7:31 AM
To: Riegel, Maximilian; Jongtaek Oh; [email-masked]
Cc: ?????; ?????; ??????; ?????
Subject: RE: [16NG] WGLC:

I did not hear any issues with 802.16 broadcast channel(s). If there
were any issues, then the communication of IEEE 802.16 transmission
management will have a lot of issues as well and the unicast service
flows will not be utilized at all.

Lets make the assumption that all SS' but one can connect at 64QAM, and
a single one can only connect with QPSK If we want to send multicast
packets to some number of SS connected, the advantage of sending
individual packets disappear with 4 SS (all of them being 64QAM) or 1 SS
(connected through QPSK). More than that the broadcast through QPSK
channel will be more advantageous.

For applications such as IPTV the use of Broadcast (or Multicast)
Service Flows will almost always (practically always) be the most
efficient.

I would like to understand better why Broadcast channels are not even
considered.

Kind regards,
-burcak

-----Original Message-----
From: Riegel, Maximilian [mailto:[email-masked]]
Sent: Thursday, September 06, 2007 2:48 AM
To: Jongtaek Oh; [email-masked]
Cc: ?????; ?????; ??????; ?????
Subject: RE: [16NG] WGLC:

Bye
Max

-----Original Message-----
From: ext Jongtaek Oh [mailto:[email-masked]]
Sent: Thursday, September 06, 2007 6:05 AM
To: [email-masked]; Daniel Park
Cc: ?????; ?????; ??????; ?????
Subject: Re: [16NG] WGLC:

Jongtaek Oh
Hansung Univ.
Seoul, Korea

---

From: Burcak Beser <[email-masked]>
Date: Fri, 7 Sep 2007 16:16:52 -0700

[Sorry for dividing the discussion into pieces but othervise valuable information will be lost]

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

How does BS know all the host entries upon creation of the air-link?

Please keep in mind that the hosts does not need to be connected when the SS is connected to the bridge. At the same time it is possible and highly probable for enterprise scenarios that the host may disconnect from one SS and connect another SS attached to the same BS.

> What is missing in the description in the I-D?

The description you provided above :)

Kind Regards,
-burcak

---

From: "Riegel, Maximilian" <[email-masked]>
Date: Mon, 10 Sep 2007 17:45:42 +0200

The comment is valid. There may be hosts attached to bridges behind the
MS/SSs which are not visible to the bridge in the network when the MS/SS
connects, and further more, the hosts behind the MS/SSs may move to
another MS/SSs without giving notice to the bridge in the network.

This usually cant be handled by static configuration of the bridge table
entries but requires dynamic entries which are learned from the packets
going through the particular ports.
Some enhancements are possible, when the port behavior of the bridge
behind the BS can be switched from static to dynamic on the fly, or when
the hosts on the bridge behind the SS/MSs are authenticated by
IEEE802.1X.

Text will be added in the next revision to address this case more
thoroughly.

Bye
Max

-----Original Message-----
From: Burcak Beser [mailto:[email-masked]] 
Sent: Saturday, September 08, 2007 1:17 AM
To: Riegel, Maximilian; [email-masked]
Subject: [aged entries] draft-ietf-16ng-ip-over-ethernet-over-802.16-02

[Sorry for dividing the discussion into pieces but othervise valuable
information will be lost]

> As defined in 802.1D the bridge may have static as well as dynamic
entries.

Please keep in mind that the hosts does not need to be connected when
the SS is connected to the bridge. At the same time it is possible and
highly probable for enterprise scenarios that the host may disconnect
from one SS and connect another SS attached to the same BS.

Kind Regards,
-burcak

---

From: "Jongtaek Oh" <[email-masked]>
Date: Fri, 14 Sep 2007 11:28:32 +0900

Last night, I have met two KT members to discuss about MBS or MCBCS for IEEE 802.16e network.
Also, we talked about IETF 16ng issues.

We agreed on that the radio link of 802.16 network should support broadcasting/multicasting channel for MBS service,
even if unicasting channel could be used for MBS services. It should be up to service provider's decision, according to business and/or
service model.

And next, it would be better that IETF should deal with just on Internet protocol issues, not evolving radio technology.
That means, too much detailed description and restricting words about the functions of radio link are not proper to be included in RFCs.

Thank you for the discussion.

Jongtaek Oh
Hansung Univ.
Seoul, Korea

----- Original Message ----- 
From: "Riegel, Maximilian" <[email-masked]>
To: "Jongtaek Oh" <[email-masked]>; <[email-masked]>
Cc: "?????" <[email-masked]>; "?????" <[email-masked]>; "??????" <[email-masked]>; "?????" <[email-masked]>; "Daniel Park" <[email-masked]>
Sent: Thursday, September 06, 2007 6:47 PM
Subject: RE: [16NG] WGLC: draft-ietf-16ng-ip-over-ethernet-over-802.16-02

Bye
Max

-----Original Message-----
From: ext Jongtaek Oh [mailto:[email-masked]] 
Sent: Thursday, September 06, 2007 6:05 AM
To: [email-masked]; Daniel Park
Cc: ?????; ?????; ??????; ?????
Subject: Re: [16NG] WGLC:

Jongtaek Oh
Hansung Univ.
Seoul, Korea

---

From: "Riegel, Maximilian (NSN - DE/Germany - MiniMD)" <[email-masked]>
Date: Mon, 17 Sep 2007 17:57:24 +0200

Full agreement that deployment of IEEE802.16 MBS channels should be supported for multicast and broadcast services. The decision whether to use unicast channels or multicast channels is up to the operator and depends on the number of subscribers of a particular service per cell. This should be clearly mentioned in the annex.

Special link layer support of broadcasting Ethernet packets is a different topic and is not related to multicast and broadcast services. This distinction will be made more clear in the revised text of the annex. However I see some need to provide a little background on the rationale not to deploy MBS channels for realizing Ethernet behavior.

Bye
Max

-----Original Message-----
From: ext Jongtaek Oh [mailto:[email-masked]] 
Sent: Friday, September 14, 2007 4:29 AM
To: Riegel, Maximilian (NSN - DE/Germany - MiniMD); [email-masked]
Cc: Daniel Park; 김형규과장님; 차용주박사
Subject: Re: [16NG] WGLC: draft-ietf-16ng-ip-over-ethernet-over-802.16-02

Jongtaek Oh
Hansung Univ.
Seoul, Korea

----- Original Message ----- 
From: "Riegel, Maximilian" <[email-masked]>
To: "Jongtaek Oh" <[email-masked]>; <[email-masked]>
Cc: "?????" <[email-masked]>; "?????" <[email-masked]>; "??????" <[email-masked]>; "?????" <[email-masked]>; "Daniel Park" <[email-masked]>
Sent: Thursday, September 06, 2007 6:47 PM
Subject: RE: [16NG] WGLC: draft-ietf-16ng-ip-over-ethernet-over-802.16-02

Bye
Max

-----Original Message-----
From: ext Jongtaek Oh [mailto:[email-masked]] 
Sent: Thursday, September 06, 2007 6:05 AM
To: [email-masked]; Daniel Park
Cc: ?????; ?????; ??????; ?????
Subject: Re: [16NG] WGLC:

Jongtaek Oh
Hansung Univ.
Seoul, Korea

---

From: Burcak Beser <[email-masked]>
Date: Mon, 17 Sep 2007 13:43:00 -0700

Max,

I do not understand why link layer support of broadcast messages cannot be left to operator decision. There are both pro's and con's of the decision and the draft must not prefer only one type of solution.

Today, the draft disables the use of broadcast channels no matter what the operator wants.

-burcak

-----Original Message-----
From: Riegel, Maximilian (NSN - DE/Germany - MiniMD) [mailto:[email-masked]]
Sent: Monday, September 17, 2007 8:57 AM
To: Jongtaek Oh
Cc: 차용주박사; 김형규과장님; [email-masked]
Subject: RE: [16NG] WGLC: draft-ietf-16ng-ip-over-ethernet-over-802.16-02

Bye
Max

-----Original Message-----
From: ext Jongtaek Oh [mailto:[email-masked]]
Sent: Friday, September 14, 2007 4:29 AM
To: Riegel, Maximilian (NSN - DE/Germany - MiniMD); [email-masked]
Cc: Daniel Park; 김형규과장님; 차용주박사
Subject: Re: [16NG] WGLC: draft-ietf-16ng-ip-over-ethernet-over-802.16-02

We agreed on that the radio link of 802.16 network should support broadcasting/multicasting channel for MBS service, even if unicasting channel could be used for MBS services. It should be up to service provider's decision, according to business and/or service model.

Jongtaek Oh
Hansung Univ.
Seoul, Korea

----- Original Message -----
From: "Riegel, Maximilian" <[email-masked]>
To: "Jongtaek Oh" <[email-masked]>; <[email-masked]>
Cc: "?????" <[email-masked]>; "?????" <[email-masked]>; "??????" <[email-masked]>; "?????" <[email-masked]>; "Daniel Park" <[email-masked]>
Sent: Thursday, September 06, 2007 6:47 PM
Subject: RE: [16NG] WGLC: draft-ietf-16ng-ip-over-ethernet-over-802.16-02

Bye
Max

-----Original Message-----
From: ext Jongtaek Oh [mailto:[email-masked]]
Sent: Thursday, September 06, 2007 6:05 AM
To: [email-masked]; Daniel Park
Cc: ?????; ?????; ??????; ?????
Subject: Re: [16NG] WGLC:

Jongtaek Oh
Hansung Univ.
Seoul, Korea

---

From: "Riegel, Maximilian (NSN - DE/Germany - MiniMD)" <[email-masked]>
Date: Tue, 18 Sep 2007 11:40:27 +0200

Thanks Burcak for raising the issue with the current text on the Multicast and Broadcast Packet Processing. I agree with you that the decision about the deployment of MBS channels for MBS services should be left to the operators.
However it may take some time before such a choice can be provided. There are issues with the deployment of MBS channels, and a lot of additional issues will come up when deploying MBS radio channels in a dynamic and mobile environment. As mentioned, the MCBCS sub-team of the NWG in the WiMAX Forum will develop solutions to facilitate the usage of MBS radio channels in a dynamic and mobile environment.

IMHO, it does not make sense for the 16ng to compete with the MCBCS sub-team in defining a complete solution for the deployment of MBS radio channels for MBS services. Without the results of the MCBCS sub-team, the specification for the deployment of MBS channels would be very limited to static deployments (manual configuration) only.

With such restrictions, it may make sense to keep the text for deployment of MBS channels for MBS services in a separate section, which can more easily be upgraded to full functionality once the MCBCS sub-team has completed its tasks.

Bye
Max

-----Original Message-----
From: ext Burcak Beser [mailto:[email-masked]] 
Sent: Monday, September 17, 2007 10:43 PM
To: Riegel, Maximilian (NSN - DE/Germany - MiniMD); Jongtaek Oh
Cc: 차용주박사; 김형규과장님; [email-masked]
Subject: RE: [16NG] WGLC: draft-ietf-16ng-ip-over-ethernet-over-802.16-02

Max,

-burcak

-----Original Message-----
From: Riegel, Maximilian (NSN - DE/Germany - MiniMD) [mailto:[email-masked]]
Sent: Monday, September 17, 2007 8:57 AM
To: Jongtaek Oh
Cc: 차용주박사; 김형규과장님; [email-masked]
Subject: RE: [16NG] WGLC: draft-ietf-16ng-ip-over-ethernet-over-802.16-02

Bye
Max

-----Original Message-----
From: ext Jongtaek Oh [mailto:[email-masked]]
Sent: Friday, September 14, 2007 4:29 AM
To: Riegel, Maximilian (NSN - DE/Germany - MiniMD); [email-masked]
Cc: Daniel Park; 김형규과장님; 차용주박사
Subject: Re: [16NG] WGLC: draft-ietf-16ng-ip-over-ethernet-over-802.16-02

Jongtaek Oh
Hansung Univ.
Seoul, Korea

----- Original Message -----
From: "Riegel, Maximilian" <[email-masked]>
To: "Jongtaek Oh" <[email-masked]>; <[email-masked]>
Cc: "?????" <[email-masked]>; "?????" <[email-masked]>; "??????" <[email-masked]>; "?????" <[email-masked]>; "Daniel Park" <[email-masked]>
Sent: Thursday, September 06, 2007 6:47 PM
Subject: RE: [16NG] WGLC: draft-ietf-16ng-ip-over-ethernet-over-802.16-02

Bye
Max

-----Original Message-----
From: ext Jongtaek Oh [mailto:[email-masked]]
Sent: Thursday, September 06, 2007 6:05 AM
To: [email-masked]; Daniel Park
Cc: ?????; ?????; ??????; ?????
Subject: Re: [16NG] WGLC:

Jongtaek Oh
Hansung Univ.
Seoul, Korea