Subject: [16NG] Re: I-D ACTION:draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 15 Dec 2006 14:03:23 +0100

Hello to authors of draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt.

I realize I just remarked on the two previous constituent drafts, which
now became one - good they are joined.

I have several remarks on this new draft.

I think only section 8.2 should be kept in the document, "IPv6 over
Ethernet".  If this is done, all my subsequent remarks below do not
apply, so please ignore them.

This is only one member oppinion.  I think other members in the WG have
oppinions, please express them with respect to this document, thanks.

Alex

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories. This draft is a work item of the IP over IEEE 802.16 
> Networks Working Group of the IETF.
> 
> Title		: Transmission of IP over Ethernet over IEEE 802.16 Networks 
> Author(s)	: H. Jeon, et al. Filename	: 
> draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt Pages		: 17 Date 
> : 2006-12-14
> 
> This document describes the behavior of the Ethernet emulation on top
>  of IEEE 802.16 to efficiently support the transmission of IPv4 as 
> well as IPv6 packets over IEEE 802.16 radio links.

When reading this I was immediately struck that the document scope is
too wide.  I was afraid IETF may try to specify IEEE behaviour, but went
on reading, and unfortunately my expectation was confirmed.

It's IEEE's business how to specify that Ethernet emulation.  If IETF
wants to describe it then it's for informational purposes only, for
learning, reference, etc.  Not an IETF STds Trck to be implemented.

The section 8 is a spec of the _interface_ between 802.16 Ethernet CS
and the IP stack, not a spec of how that ETH CS should behave.

This may be terminology though, but clarification may be needed.

> 4.4.  Discovery of MAC addresses
> 
> The 48-bit unique MAC address of a SS is used during the initial 
> ranging process for the identification of a SS and verified by the 
> succeeding PKMv2 authentication phase.

What's PKMv2.  Please don't explain, but realize that explaining it may
take too much time, and I'm not sure it's needed in this document.

> 5.  The IEEE 802.16 Network Model for Ethernet

This is informative.  However, I don't think it's needed here.  The IPv6
over  Ethernet document (rfc 2464) doesn't go into that much description
of what the 802.3 Ethernet is.

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

Capitalizing that "SHALL" sounds too much as 16ng is defining what the
BS should do.  It's wrong, wrong place for that.  I think this entire
section doesn't belong here.

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

Again, a stds track document won't tell people how to deploy networks.
An informative document may inform people how other people done it, or
wanted to do it.

> 7.2.  Packet Filtering
> 
> The bridge SHALL have the ability to enable or disable any filtering
>  functionality defined herein.

A bridge "SHALL"... same thing.

> 7.3.  Identification Cache Table

This is an interesting section.  It describes the ICT data structure on
the BS for the purpose of a new 'proxy' to run: ND Relay.  While the
description seems coherent to me (I can understand it), I don't think -
again - it belongs here.

Not sure what to recommend where to develop this: v6ops, IEEE, or netlmm
(they do 'proxy' and other 'relay' stuff).

But for sure not in a document for an implementer doing IPv6 over ETH CS
on a mobile node.

> The AR SHALL have packet-relay functionality.  The AR relays packets
>  destined for IP broadcast address and link-local scoped multicast 
> addresses to incoming interface again.

I was thinking it must relay them to all other interfaces, not
necessarily to the interface where it came?

Anyways, AR being a router isn't it sufficient to forward IP packets?

If you think it should  make its p2p links look as Ethernet multicast,
then it should indeed relay packets, but that's link-layer behaviour,
can't be described here, no?

Alex

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 15 Dec 2006 15:06:17 +0100

Also, I would like to suggest separation of the IPv4 section 8.1 "IPv4
over Ethernet" from the document, and title the document "IPv6 over...".

The reason is simple - simplicity, easier to deal with shorter documents.

For example, the current section 8.1 suggests that it is sufficient to
implement IPv4 over 802.16 ETH CS by looking at RFC 894 and RFC 826
(IPv4 over Ethernet and ARP specs, respectively).

However, when writing an implementation of IPv4 over ETH CS an important
parameter is the Ether type.  For IPv6 it's simple - it's 0x86DD for
_all_ IPv6, ND included, spec'd in rfc2464.  But for IPv4 it's 0x800
(spec'ed in rfc894) and ARP it's 0x806.  This latter figure doesn't
figure neither in RFC 894 nor 826.  So one would have to dig the
ethertypes on the Internet find out that type.  The draft spec would be
insufficient.

Another major difference between IPv6 and IPv4 is in the tratment of
link-layer multicast.  For example, IPv4 doesn't take into account
link-layer multicast, and only cares about broadcast link-layer
addresses (0xff...).  IPv6 on the contrary, only considers multicast
link-layer addresses (0x33...).  These are aspects that should be
accounted for in the IPv-over documents. I don't think mixing them
together in one document is simple enough.

Alex

[email-masked] wrote:
> : 2006-12-14  This document describes the behavior of the Ethernet 
> emulation on top of IEEE 802.16 to efficiently support the 
> transmission of IPv4 as well as IPv6 packets over IEEE 802.16 radio 
> links.  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.
> 
> 
> 
> A URL for this Internet-Draft is: 
> http://www.ietf.org/internet-drafts/draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt
> 
> 
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [email-masked] with the word unsubscribe in the body 
> of the message. You can also visit 
> https://www1.ietf.org/mailman/listinfo/I-D-announce to change your 
> subscription settings.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the 
> username "anonymous" and a password of your e-mail address. After 
> logging in, type "cd internet-drafts" and then "get 
> draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt".
> 
> A list of Internet-Drafts directories can be found in 
> http://www.ietf.org/shadow.html or 
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to: [email-masked]. In the body type: "FILE 
> /internet-drafts/draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt".
>  NOTE:	The mail server at ietf.org can return the document in 
> MIME-encoded form by using the "mpack" utility.  To use this feature,
>  insert the command "ENCODING mime" before the "FILE" command.  To 
> decode the response(s), you will need "munpack" or a MIME-compliant 
> mail reader.  Different MIME-compliant mail readers exhibit different
>  behavior, especially when dealing with "multipart" MIME messages 
> (i.e. documents which have been split up into multiple messages), so 
> check your local documentation on how to manipulate these messages.
> 
> Below is the data which will enable a MIME compliant mail reader 
> implementation to automatically retrieve the ASCII version of the 
> Internet-Draft.
> 
> 
> ------------------------------------------------------------------------
> 
> 
> 
> _______________________________________________ I-D-Announce mailing 
> list [email-masked] 
> https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: "Riegel, Maximilian" <[email-masked]>
Date: Mon, 18 Dec 2006 09:37:32 +0100

There is reason to keep both versions in one document. As you can figure
out, most of the document applies to both IPv4 as well as IPv6 and only
small parts are IP version specific. This will become more visible when
we are fully leveraging RFC4541 for IPv6 transmission in the next
version.
And even in the combined version the ducument is very handy; less than
20 pages do not qualify a split.
The I-D does not intend to replace RFC2464 or RFC894 but provides 'lower
layer' additions to make Ethernet over 802.16 looking like standard
Ethernet to the IP layer, even when not all messages are going over the
air like in 'plain' Ethernet.

Bye
Max

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Friday, December 15, 2006 3:06 PM
To: [email-masked]
Subject: [16NG] Re: suggest separation of IPv4 from document (was:
I-DACTION:draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt)

The reason is simple - simplicity, easier to deal with shorter
documents.

Alex

> A URL for this Internet-Draft is: 
http://www.ietf.org/internet-drafts/draft-ietf-16ng-ip-over-ethernet-ove
r-802.16-00.txt

---

From: "Riegel, Maximilian" <[email-masked]>
Date: Mon, 18 Dec 2006 09:37:34 +0100

The I-D addresses IP specific functions in an 802.16 specific
implementation of Ethernet. No showing the particular behavior of
Ethernet on top of 802.16 misses the foundation for an understandable
specification.

The I-D does not describe the interface between IP and Ethernet CS, but
between IP and an Ethernet running over 802.16 air links. There is a
important difference between Ethernet and Ethernet CS. The Ethernet CS
just provides the encapsulation and classification on point to point
links over the air, but not the Ethernet behavior. The Ethernet behavior
is realized by a bridge on top of the 802.16 PHY and MAC (and Ethernet
CS). This bridge has some extensions to make IP running less resource
consuming (radio resource and terminal power) over an radio link.
Such IP specifics fully belong to the scope of the IETF.

Please be aware that there are different scenarios covered in this I-D.
One is the plain Ethernet case with all messages being forwarded in the
link layer to all destined hosts, and this is the easy one not requiring
any additional specification. There are other scenarios where the link
layer prohibits direct host-to-host communication or intercepts
broadcast and multicast messages for good reasons. The I-D mainly
addresses all these other scenarios to allow interoperable
implementations.

Bye
Max

-----Original Message-----
From: Alexandru Petrescu [mailto:[email-masked]] 
Sent: Friday, December 15, 2006 2:03 PM
To: [email-masked]
Subject: [16NG] Re:
I-DACTION:draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt

Alex

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 18 Dec 2006 12:02:37 +0100

Riegel, Maximilian wrote:
> There is reason to keep both versions in one document. As you can 
> figure out, most of the document applies to both IPv4 as well as IPv6
>  and only small parts are IP version specific. This will become more 
> visible when we are fully leveraging RFC4541 for IPv6 transmission in
>  the next version. And even in the combined version the ducument is 
> very handy; less than 20 pages do not qualify a split.

Maximilian, thanks for the email.

If you think there is reason to keep both versions in one document, and
your co-authors too and the WG too - then I'm fine.

I do not know of any other IP over foo document that treats both IPv4
and IPv6.  This may be the first one.  I think it can be too complex,
but I will not insist on this.

> The I-D does not intend to replace RFC2464 or RFC894 but provides 
> 'lower layer' additions to make Ethernet over 802.16 looking like 
> standard Ethernet to the IP layer, even when not all messages are 
> going over the air like in 'plain' Ethernet.

I think this is lower layer additions that are not IP, and that should
be suggested to IEEE, not at IETF.  I mean, a ND Relay only pertains to
802.16.  And so I think it should be part of IEEE, or at most
informational track at IETF.

Do you see any other link using ND Relay?  (other than 802.16)?

Thanks,

Alex

> 
> 
> Bye Max
> 
> -----Original Message----- From: Alexandru Petrescu 
> [mailto:[email-masked]] Sent: Friday, December 15, 
> 2006 3:06 PM To: [email-masked] Subject: [16NG] Re: suggest separation
>  of IPv4 from document (was: 
> Also, I would like to suggest separation of the IPv4 section 8.1 
> "IPv4 over Ethernet" from the document, and title the document "IPv6 
> over...".
> 
> For example, the current section 8.1 suggests that it is sufficient 
> to implement IPv4 over 802.16 ETH CS by looking at RFC 894 and RFC 
> 826 (IPv4 over Ethernet and ARP specs, respectively).
> 
> However, when writing an implementation of IPv4 over ETH CS an 
> important parameter is the Ether type.  For IPv6 it's simple - it's 
> 0x86DD for _all_ IPv6, ND included, spec'd in rfc2464.  But for IPv4 
> it's 0x800 (spec'ed in rfc894) and ARP it's 0x806.  This latter 
> figure doesn't figure neither in RFC 894 nor 826.  So one would have 
> to dig the ethertypes on the Internet find out that type.  The draft 
> spec would be insufficient.
> 
>>  links.  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 
>> To remove yourself from the I-D Announcement list, send a message 
>> to [email-masked] with the word unsubscribe in the 
>> body of the message. You can also visit 
>> MIME-encoded form by using the "mpack" utility.  To use this 
>> feature, insert the command "ENCODING mime" before the "FILE" 
>> command.  To decode the response(s), you will need "munpack" or a 
>> MIME-compliant mail reader.  Different MIME-compliant mail readers 
>> exhibit different behavior, especially when dealing with 
>> "multipart" MIME messages (i.e. documents which have been split up 
>> into multiple messages), so check your local documentation on how 
>> to manipulate these messages.
>> 
>> _______________________________________________ I-D-Announce 
>> mailing list [email-masked] 
> _______________________________________________ 16NG mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/16ng
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 18 Dec 2006 18:49:03 +0100

Hi Maximilian,

Riegel, Maximilian wrote:
> The I-D does not describe the interface between IP and Ethernet CS, 
> but between IP and an Ethernet running over 802.16 air links. There 
> is a important difference between Ethernet and Ethernet CS. The 
> Ethernet CS just provides the encapsulation and classification on 
> point to point links over the air, but not the Ethernet behavior. The
>  Ethernet behavior is realized by a bridge on top of the 802.16 PHY 
> and MAC (and Ethernet CS).

Not sure what you mean by 'is realized'.

I think if you mean IEEE designed ND Relay to be what your document
shows it to be then either IEEE is wrong, or IEEE is using that within
very limited scope.

If you mean that 16ng needs to specify an Ethernet behaviour by means of
specifying a bridge then I think again it's wrong.

I don't think 16ng should specify _how_ the ETH CS manages to offer a
multicast interface to the IP stack.  But it should specify _what_ that
multicast interface should look like: what are the link-layer multicast
addresses that should be supported by that ETH CS, what should be the
MTU of that interface, etc.

In short, I'm not sure a bridge behaviour can or should be specified at
IETF.

> This bridge has some extensions to make IP running less resource 
> Please be aware that there are different scenarios covered in this 
> I-D. One is the plain Ethernet case with all messages being forwarded
>  in the link layer to all destined hosts, and this is the easy one 
> not requiring any additional specification.

Yes.  Clarification may be needed though.

It's very good to have a document that states that IPv6 runs over ETH CS
exactly as over EThernet, that MTU is 1280, that link-layer multicast
addresses are so and so, etc.  Very short and to the point.  When we do
that we may realize there may be issues, and we can document these
issues - but not a solution to them (ND Relay is a solution to them).

I think you're missing the potentially great value of this potentially
simple document.  I think there may be a risk to fall in a temptation
where we think that without big functionalities a presumably picky group
of experts will not accept it.  I think doing a draft IPv6 over ETH CS
without ND Relay is just great.  We can see about ND Relay later, in
more detail, and better understood.

> There are other scenarios where the link layer prohibits direct 
> host-to-host communication or intercepts broadcast and multicast 
> messages for good reasons. The I-D mainly addresses all these other 
> scenarios to allow interoperable implementations.

Maximilian, I'm trying to understand this.  Let us talk ND Relay
functionality.  I stick to my position that ND Relay agent should be
specified elsewhere than this doc.

draft over ETH CS:
> In the case of IPv6 over Ethernet, the AR sends periodically Router 
> Advertisement and the Router Advertisement messages can be relayed by
>  the ND Relay Agent of the bridge.  The ND Relay Agent unicasts the 
> Router Advertisement via all the already established a point-to-point
>  connections between bridge and SSs.

I do sense the necessity of this, and I do believe it is needed to
achieve this effect (send one RA and multicast it to all SSs).  But.

What is the src IP address of the relayed RA?  Is it derived from the BS
MAC address?  Or from AR MAC address.  Because it is this address that
all mobiles will use as a default route.  What is the link-layer src
address of the relayed RA?  BS's or AR's?  BEcause the IP stack needs it
in its neighbour cache.  Is that RA have a ETH MAC header or a .16 MAC
header.

Security implications of 'relaying' ND IP packets in this way are not
very clear either.

Discussing along this may show we need clarification of how ND Relay
works.  You may think that we don't need further discussion on this
topic, but I believe ND Relay needs much more work.  So, instead of
delaying IPv6-over-ETH-CS document, we could separate them.

What do you think?

Alex

---

From: [email-masked]
Date: Thu, 14 Dec 2006 15:50:02 -0500

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the IP over IEEE 802.16 Networks Working Group of the IETF.

	Title		: Transmission of IP over Ethernet over IEEE 802.16 Networks
	Author(s)	: H. Jeon, et al.
	Filename	: draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt
	Pages		: 17
	Date		: 2006-12-14
	
   This document describes the behavior of the Ethernet emulation on top
   of IEEE 802.16 to efficiently support the transmission of IPv4 as
   well as IPv6 packets over IEEE 802.16 radio links.  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.

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

---

From: "Narvaez, Paolo \(Paolo\)" <[email-masked]>
Date: Thu, 21 Dec 2006 11:13:54 -0600

Some comments on this draft.

Paolo

-----------------

Section 5.3 - 

"When performing bridging, any packets destined for one of the
   addresses in the Filtering Database SHALL be forwarded directly to
   that port, if appropriate for the particular scenario, and all
   packets received from a port, for which the packet's destination MAC
   address is also an entry for that port in the Filtering Database,
   SHALL be silently discarded."

1) What does "if appropriate for the particular scenario" mean? Are
there some cases where the bridge does something other than forwarding
directly to the port?

2) It does not mention what happens to packets with a MAC DA equal to
the MAC address of a SS. These should not be forwarded.

3) It might be easier to read if the description of the behavior of the
bridge at the SS were separated from the description of the behavior of
the modified "bridge" in the network.

Section 6.1 -

"Figure 3 depicts an IEEE 802.16 network deployment scenario without
   direct host-to-host communication.  In the general public access
   case, direct communication between nodes is restricted because of
   security and accounting issues.  In this scenario, the bridge SHALL
   forward all packets received from any radio side port to a network
   side port.  Peer-to-peer communication is not supported by the bridge
   and all packets originated from a SS should be delivered to an AR."

3) In the case where the MAC DA of a packet corresponds to the MAC of a
SS, why does the packet have to be forwarded to the AR? Why can't it be
simply dropped? This is an illegal packet. As long as the packet is not
forwarded to the SS, both behaviours should be acceptable. Dropping it
might save bandwidth.

4) What is the behavior of the bridge in the public access scenario when
the Ethernet frame arriving over the air (or from the AR) has one or
more VLAN tags? Is the VLAN tag stripped off? Is it ignored? Are SSs and
ARs forbidden from sending VLAN-tagged frames to the bridge?

Section 6.2 -

5) The bridge described in this scenario seems to behave more like an
enterprise switch than a carrier Ethernet switch (with support of
802.1ad and 802.1ah) offering VLAN services. I believe Max is going to
be rewording this section.

Section 7.1 -

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

6) Who is doing the replication? The bridge? Or does the AR have to send
multiple copies of the packet to the bridge? I believe the intent is the
former. It would help if it were made clear.

Section 7.2 -

"The bridge SHALL support filtering of all packets received from a
   network side port to a destination MAC address or Multicast IP
   address not existing in the ICT or expired address."

7) What happens if there are multiple network side ports? In that case,
I think you would want to filter broadcasting to the air interfaces, but
you will still want to broadcast on the remaining network ports.

Section 7.6 -

"The AR SHALL have packet-relay functionality.  The AR relays packets
   destined for IP broadcast address and link-local scoped multicast
   addresses to incoming interface again.  When relaying, AR does not
   decrease the value of TTL or Hop Limit."

8) Can this on-link packet-relay functionality be performed at the
bridge instead of the AR? Since the bridge already has several
IP-snooping capabilities (ARP-proxy, ND-relay) and has knowledge of IP
addresses, it seems that it could also perform this function. In this
case, the AR would not require any modifications and would behave like a
standard AR. The bridge requires modifications anyways.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Thursday, December 14, 2006 3:50 PM
To: [email-masked]
Cc: [email-masked]
Subject: [16NG]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the IP over IEEE 802.16 Networks Working
Group of the IETF.

	Title		: Transmission of IP over Ethernet over IEEE
802.16 Networks
	Author(s)	: H. Jeon, et al.
	Filename	:
draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt
	Pages		: 17
	Date		: 2006-12-14

Send a message to:
	[email-masked].
In the body type:
	"FILE
	
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers

---

From: "Hongseok Jeon" <[email-masked]>
Date: Fri, 22 Dec 2006 19:30:32 +0900

Hi Paolo, 

Please find responses to your comments inline:

Thanks,
Hongseok 

> From: Narvaez, Paolo (Paolo) [mailto:[email-masked]] 
> Sent: Friday, December 22, 2006 2:14 AM
> To: [email-masked]
> Subject: [16NG] Comments 
> ondraft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt 
> 
> 
> 
> 
> 1) What does "if appropriate for the particular scenario" 
> mean? Are there some cases where the bridge does something 
> other than forwarding directly to the port?

Our document considers two deployment scenarios. One is a public access
scenario, 
where all traffics from SS should be transmitted to AR. The other is a VLAN
scenario 
allowing SS to communicate each other SSs. 

Generally, wireless access providers prefers to monitor packets from its SSs

and prevents SSs from communicating each other because of security and
accounting issues.
Above the first scenario, public access scenario, satisfies the preference.

The mentioned "particular scenario" indicates the last VLAN scenario.

> 
> 2) It does not mention what happens to packets with a MAC DA 
> equal to the MAC address of a SS. These should not be forwarded.

It depends on the scenario. In case of public access scenario, the packets 
should be transmitted to AR and then relayed to the intended SS by relaying 
function on AR. In VLAN scenario, the packets are directly forwarded to the 
intended SS by bridge. 

> 
> 3) It might be easier to read if the description of the 
> behavior of the bridge at the SS were separated from the 
> description of the behavior of the modified "bridge" in the network.

I agree. 

> 3) In the case where the MAC DA of a packet corresponds to 
> the MAC of a SS, why does the packet have to be forwarded to 
> the AR? Why can't it be simply dropped? This is an illegal 
> packet. As long as the packet is not forwarded to the SS, 
> both behaviours should be acceptable. Dropping it might save 
> bandwidth.

As above mentioned, in public access scenario, the packets from SS to other 
SS are transmitted to AR and then relayed to the destination SS. So, the 
packets should not be dropped. 

> 
> 4) What is the behavior of the bridge in the public access 
> scenario when the Ethernet frame arriving over the air (or 
> from the AR) has one or more VLAN tags? Is the VLAN tag 
> stripped off? Is it ignored? Are SSs and ARs forbidden from 
> sending VLAN-tagged frames to the bridge?

Public access scenario does not consider Ethernet frames embedded with VLAN
tag.
Ethernet frames with VLAN tag are handled in VLAN scenario and we will
provide 
the detail procedures in next version document. 

> 
> 
> Section 6.2 -
> 
> 5) The bridge described in this scenario seems to behave more 
> like an enterprise switch than a carrier Ethernet switch 
> (with support of 802.1ad and 802.1ah) offering VLAN services. 
> I believe Max is going to be rewording this section.
> 
> 
> Section 7.1 -
> 
> 6) Who is doing the replication? The bridge? Or does the AR 
> have to send multiple copies of the packet to the bridge? I 
> believe the intent is the former. It would help if it were made clear.

Yes, the replication is performed by the bridge. 

> 7) What happens if there are multiple network side ports? In 
> that case, I think you would want to filter broadcasting to 
> the air interfaces, but you will still want to broadcast on 
> the remaining network ports.

Filtering in this document focuses on multicast data, and broadcasting 
data destined for sleep mode SSs.  Broadcast data for wake-up SSs does 
not be filtered. Hosts in network side always wake up and thus broadcast 
data for the host does not need to be filtered. 

> 8) Can this on-link packet-relay functionality be performed 
> at the bridge instead of the AR? Since the bridge already has 
> several IP-snooping capabilities (ARP-proxy, ND-relay) and 
> has knowledge of IP addresses, it seems that it could also 
> perform this function. In this case, the AR would not require 
> any modifications and would behave like a standard AR. The 
> bridge requires modifications anyways.

The position of packet-relay functionality on AR is based on the assumption
which 
all traffics from SS should be transmitted to AR in the public access
scenario. 

> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> To remove yourself from the I-D Announcement list, send a 
> message to [email-masked] with the word 
> unsubscribe in the body of the message. 
> Internet-Drafts are also available by anonymous FTP. Login 
> with the username "anonymous" and a password of your e-mail 
> address. After logging in, type "cd internet-drafts" and then 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
>

---

From: Bruno Miguel Sousa <[email-masked]>
Date: Sat, 23 Dec 2006 13:20:25 +0000

Dears,

Since the 67th IETF meeting a lot as going on...

Regarding this draft, here is my contribution:

1) Section 4.2
"
   Optionally the convergence sublayer performs a packet header
   suppression reducing static parts of the header to a single byte
   value.  With the application of the packet header suppression
   function there is mostly no difference in header overhead over the
   air for Ethernet encapsulated IP packets in comparison to plain IP
   packets.
"
If there is mostly no difference on the packet header suppression to the 
plain IP packets.
Why referring packet header suppression here?
My suggestion is to remove the sentence comparing the header overhead of 
packet header suppression and plain IP packets.

2) Section 4.4

I also find the link local address construction performed by the BS 
confusing.
But this has already been commented.

3) Section 5.3

the term "particular scenario" refers to the VLAN scenario. But I know 
this after your comments.
I would suggest to substitute the term "particular scenario" by the VLAN 
scenario, since this one is demonstrated ahead on the document.

4) Section 5.2 and Section 7.1

The term MBS is not expanded on the text, but is "somehow" explained.
What to you mean with "to allow a full control over the reaction of SSs 
to broadcast messages" ?
Is this related with the point-to-point connections referred ahead on 
the memo.

5) Section 6.2.

When do you mean with "configurable direct host-to-host communication"?

6) Informative References.

I don't Know if this is important or not, but here goes: Some RFCs cited 
along the text are not in informative references section. In this 
situation I can point, at least RFC 3315, RFC 2462,

Kindly,
Bruno Sousa