Subject: [16NG] Request for clarification on draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt

From: "Burcak Beser" <[email-masked]>
Date: Mon, 8 Jan 2007 11:37:17 -0800

I have to admit that at this point of time I am confused. The draft has
some details and a lot of information that I am not sure how these
interconnect.

Let me start from the beginning:

(The below described usage is the WiMAX mandatory supported transport of
packets and all the descriptions and especially normative language has
to deal with these details.)

Per WiMAX specifications (see
http://www.wimaxforum.org/technology/documents/WiMAX_End_to_End_Network_
Systems_Architecture.zip) each "connection" between SS and BS indicated
by a unique CID within a single BS domain is mapped into a GRE tunnel in
and in some other cases all CID's coming from a single SS is mapped into
a GRE tunnel identified by a "GRE key". Now, it is important to note
that the  "connections" per IEEE 802.16 specifications is left very
liberal in the means that they may be used. It is possible that there is
a single uplink "connection" which has associated multiple downlink
"connections". If there are no limitations on the CPE generated packets
it is possible that the CPE packets will be fragmented as in the case of
IPSEC tunnels, and will be fragmented again on the GRE level.

      SS_A CID1 BS GRE-key1

CPE -----|------|------------\

         |      |             \

CPE------| CID2 |  GRE-key2    \

CPE -----|------|---------------\

                |                \      GRE

.               |                /========================

.               |               /

                |              /

CID3  SS_Z CID* |   GRE-keyn  /

---------|------|------------/

The BS sends these packets through the GRE tunnel to the ASN-GW which is
a layer-3 device and designated in the draft as Access Router (AR). Per
WiMAX specifications the ASN-GW actually can be divided into two as
being serving ASN-GW which is the entity that the BS is connected
(through the draft defined bridge) which re-maps the packets (GRE
payloads) to another GRE tunnel to the anchored ASN-GW (again through
the draft defined bridge). Where the final figure looks like as below:

      CID         GRE_1        GRE_2           GRE_3          GRE_3
GRE_4

SS ---------- BS ------ Bridge ------ serving ----- arbitrary -----
Bridge -------- anchored

                       (serving)      ASN-GW         network
(anchored)         ASN-GW

We can say that for each CID there is a GRE tunnel where GRE_1 and GRE_2
are the same tunnel and GRE_3 and GRE_4 are the same tunnel further the
GRE_1/2 and GRE_3/4 are one-to-one mapped.

This brings the draft introduced "Bridge", which has different
interpretations; for the sake of taxonomy I think the bridge as having 3
layers:

i. Layer 0: This is the 802.1d-2004 defined layer where the physical
interfaces are the interfaces. It is very easy to decide where a packet
is received and which interface you can send a packet. On this level the
bridge supports a limited number of traffic:

* GRE tunnel: This is the traffic between the BS(s) and the ASN-GW(s).
All BS(s) are sending packets to serving ASN-GW(s).

* ASN Control packets: These are packets exchanged between BS and ASN-GW
for various purposes.

* Inter BS communications: This is the R8 interface of the WiMAX
specification although it is not specified it may exist.

It is important to note that any packets generated by SS or any CPE
behind it is send through the GRE tunnel which will always have the
serving ASN-GW's MAC address for destination and  BS' MAC address for
source, and all the downstream packets destined for the SS or CPE's are
send by the ASN-GW via the GRE tunnel with the source MAC address of the
serving ASN-GW and destination MAC address of the BS.

For the anchored "bridge" even though the packets look almost the same
on level-0 they are different. Since the packets are coming through an
arbitrary network it is safe to assume that multiple GRE tunnels from
different serving ASN-GW's will be connected through a single physical
router port. In which case multiple GRE tunnels will have the same
source and destination depending on the direction the packets are
traversing. Since all the GRE packets are traversing arbitrary network
it is possible that these packets being received out of sequence of some
of these packets being dropped.

ii. Layer 1: This is the GRE aware layer of the "bridge" on this level
the "bridge" knows the individual GRE flows most probably via the IP
addresses. This layer is defined for the sake of completeness only and
hopefully there will not be any need to use this layer.

On this level the bridge has as many ports/interfaces as BS's and
serving ASN-GW's. It is further assumed that the bridge loop detection
will be performed on this level.

iii. Layer 2: On this layer each "GRE key" acts as an port/interface. On
this level the "bridge" can see the GRE payload and sees the MAC address
of the source and destination for the SS or CPE packets. For the sake of
taxonomy a bridge working on this level will be referred as
"hyper-bridge" to make the distinction from the bridges that generally
work on level-0.

Since the "connection" to GRE-key mapping has two forms it is important
look these cases separately:

iii.a. Per SS GRE-key: In this scheme the BS merges all the
"connections" that are coming from a specific SS and send them using the
same GRE-key. For the reverse direction the BS upon receiving a packet
by applying the per flow classifiers as defined in 802.16 series.

This case is the simplest of two, for which each SS will have an
interface at level_2 "hyper-bridge" with symmetric operations.

iii.b. Per connection GRE-key: In this scheme the BS uses a GRE-key for
each connection in both directions. Since there are no restrictions on
how the "connection" classifiers are to be set it is not possible to
predict how they will look like. Even in this case the "hyper-bridge"
needs the information regarding the paired ingress and egress ports.
This is due to the fact that the packets may be send and received
through different GRE-keys and the bridge has no means of automatically
figuring how to pair ingress and egress GRE sub-tunnels.

To give some examples and their implication at "hyper-bridge" level: 

iii.b.I. There is a specific "connection" for one or many CPE's
(including SS) in both directions. 

The fact that the GRE sub-tunnels can be paired helps a lot, but the
fact that there are interface bundles that belong to the same broadcast
group makes the broadcast and multicast decisions very hard on the
"hyper-bridge" level.

iii.b.II. There is one upstream "connection" and a number of downstream
"connections". 

In this case the "hyper-bridge" needs to decide which connection the
"hyper-bridge" generated packets is to be sent, meaning that the ingress
port and egress ports will be different for the "hyper-bridge" in other
words the connection classifier information is to reside in the
"hyper-bridge".

iii.b.III. There are a number of upstream and downstream "connections".

This is the most general case that the "hyper-bridge" generated packets
needs to be applied to the same classifiers as the connections meaning
that the information is to reside in the "hyper-bridge" as well.

Above levels can be summed as illustrated below:

                                      Hyper-bridge

                                        Level_2

         Level_0   Level_1             _________             Level_1
Level_0

Physical | GRE_1        |   GRE_1-Key1 |        |GRE_1-Key1    | GRE_1
|

Port     |/=============|==------------|
|------------==|=============\| Physical

=========| GRE_2        |  |GRE_1-Key2 |        |GRE_1-Key2 |  | GRE_2
| Port

BS       |==============|  \-----------|        |-----------/
|==============|======== AR

or       |  ...         |  ...         |        |   ...        |  ...
|      ASN-GW

Router   | GRE_n        | GRE_n_Key_m  |        | GRE_n-Keym   | GRE_n
|

Port     |\=============|--------------|
|--------------|=============/|

Carrying |              |              ----------              |
|

Multiple |              |                                      |
|

GRE      |              ----------------------------------------
|

flows    |                               level_1 "bridge"
|

from
|--------------------------------------------------------------------|

many              Level_0 "bridge"

BS's.

 

Coming to normative requirements stated in the draft:

1. Section 5.3 states that: "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 guess this means that if BS has multiple interfaces it will send all
the packets through the physical interface that is connected to "the
bridge". I have trouble to understand this requirement, is it desired
that all the packets send through the same GRE tunnel? 

2. Section 5.3 further states: "If the SS functions as a bridge then it
SHALL support a bridging between all its LAN ports and the airlink."

I am not sure why we have this as a requirement, as a principle I am
against mandating unnecessary behavior. Further, I would like to point
out that bridging is not defined. I am surprised to find that
802.1d-2004 is referenced as an informative.

3. The last paragraph/sentence of the section 5.3 states: "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."

First since it is not explicitly clear where it is applicable I assume
that this behavior is applicable to both SS as a bridge and the
"bridge". What is missing is the behavior when an entry is deleted from
the Dynamic Filtering Entry. In the non-normative section the
BRIDGETIMEOUT is used without a default value or definition. There is a
non-normative shall that defines the use of BRIDGETIMEOUT that uses the
term traffic but does not describe whether this is for bi-directional
traffic or not.

It is not clear at which level this bridge operates: level_0, level_1 or
level_2? Since the usage of SS (I would like the term CPE and would like
to see CPE to include SS) implies that this is a behavior of
"hyper-bridge". 

If the behavior is for a "hyper-bridge", the issue of interfaces as
discussed in iii.b. is applicable.

4. Section 6.1 states: "In this scenario, the bridge SHALL forward all
packets received from any radio side port to a network side port."

First of all the applicability of this normative statement is not clear,
and second I am missing the difference between this statement and
statement discussed in bullet 1. Having said that, I miss the need for
this requirement.

It is not clear at which level this bridge operates: level_0, level_1 or
level_2? The only evidence is against the level_0 is the fact that this
defined behavior completely disables R8 interface of WiMAX
specifications.

5. Section 7.2 states: "The bridge SHALL have the ability to enable or
disable any filtering functionality defined herein."

It is not clear whether this is a flow specific or not. At this point of
time my interpretation is that this is a global switch.

6. Section 7.2 further states: "If a packet is filtered it SHALL be
silently discarded."

It is not clear at which level this bridge operates: level_0, level_1 or
level_2? The context implies that this is a level_2 functionality
thereby the bridge is actually a "hyper-bridge".

One of the side-effects of being a "hyper-bridge" is the fact that
whenever a packet is dropped it, it will not be send through the GRE
tunnel, and whenever a new packet is to be send by the "hyper-bridge"
needs to insert an additional packet into the GRE tunnel with relevant
GRE-key. 

The insertion/removal of GRE packets make the case that the GRE sequence
numbers cannot be used without making the "hyper-bridge" a kind of
back-to-back GRE relay that re-sequences.

If there are no re-sequencers in the "bridge" and sequence numbers are
being used there needs to be either a dummy packet insertion or a
missing packet within the GRE tunnel. Due to the fact that the missing
sequence numbers has the impact of delaying the packets out of the
tunnel, it is assumed that the dummy packet generation method is being
suggested. For the sake of compatibility the dummy packet is to be
defined clearly.

7. Section 7.2 states that: "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."

If this sentence is taken to its face value, there is no way that an
expired address to be reached by an external communication. 

As usual it is not clear at which level this bridge operates: level_0,
level_1 or level_2. 

It is important to point out that all the wording suggests that this is
a bridge operating at level_2 "hyper-bridge". On this level the
"hyper-bridge" receives a MAC packet through a physical port, if the
packet is a GRE packet it opens the GRE packet, looks at the inner MAC
address, and than makes a lookup against its Identification Cache Table,
if the entry does match it sends the GRE packet to the port stated in
the ICT.

8. Section 7.2 states that: "The bridge SHALL support filtering of all
packets received from a network side port to a broadcast or all-nodes
multicast MAC address."

What this requirement does is disabling the all means of communication
from the network if the CPE MAC address has expired. When the fact that
there are no normative requirements on the "bridge" to learn is added,
it is very hard to have a predictable behavior between the "bridges"
that are within this draft.

As usual it is not clear at which level this bridge operates: level_0,
level_1 or level_2.

It is important to point out that all the wording suggests that this is
a bridge operating at level_2 "hyper-bridge". On this level the
"hyper-bridge" receives a MAC packet through a physical port, if the
packet is a GRE packet it opens the GRE packet, looks at the inner MAC
address, if the inner MAC address is broadcast, removes the packet and
sends the next packet with next sequence number (if sequence numbers are
being used) to the ASN-GW thereby creating a hole in the GRE sequence.  

One question regarding the requirement is that some DHCP Offers are send
as MAC broadcast messages, and this requirement prevents these hosts to
get an IP address.

9. Section 7.2 further states: "The bridge SHALL support filtering of
all packets received from a network side port to a broadcast or
all-nodes multicast MAC address.

I am not sure why this restriction is in place. 

As usual it is not clear at which level this bridge operates: level_0,
level_1 or level_2.

It is important to point out that all the wording suggests that this is
a bridge operating at level_2 "hyper-bridge". On this level the
"hyper-bridge" receives a MAC packet through a physical port, if the
packet is a GRE packet it opens the GRE packet, looks at the inner MAC
address, and if the packet is coming from a radio side level_2 interface
and the MAC address is broadcast the "hyper-bridge" deletes the packet
and sends the next packet with next sequence number (if sequence numbers
are being used) to the ASN-GW thereby creating a hole in the GRE
sequence.

10. The last paragraph/sentence on section 7.2 states that: "If
filtering is enabled the bridge SHALL permit all Address Resolution
Protocol messages to pass to the ARP Proxy Agent and all Neighbor
Discovery messages to pass to the Neighbor Discovery (ND) Relay Agent
for additional processing as specified in following section."

As usual it is not clear at which level this bridge operates: level_0,
level_1 or level_2.

It is important to point out that all the wording suggests that this is
a bridge operating at level_2 "hyper-bridge". It is important to note
that the proxy ARP referred receives packets that are within GRE tunnel
and send packets through GRE tunnel.

11. The Section 7.3 states: "For IPv4 over Ethernet, ICT contains MAC
address and Port Map, which constitute a filtering entry in Filtering
Database, tunnel ID, lifetime, and one or more unicast and multicast
IPv4 addresses."

The mentioning of the tunnel ID strongly suggests a "hyper-bridge"
operation. The problem of ingress and egress tunnel-ID has no solution
offered and has to be mentioned using two tunnel ID's.

12. Section 7.4 states that: "The AR SHALL have packet-relay
functionality."

The packet-relay is not defined within this document and since document
only as informational references this is a hard to test item if not
impossible.

13. Section 8.1.1 states that: "The bridge SHALL support an ARP Proxy."

As usual it is not clear at which level this bridge operates: level_0,
level_1 or level_2.

It is important to point out that all the wording suggests that this is
a bridge operating at level_2 "hyper-bridge". On this level the
"hyper-bridge" receives a MAC packet through a physical port, if the
packet is a GRE packet it opens the GRE packet, looks at the inner
packet, if the inner packet is ARP, it passes the packet to the proxy
ARP. The Proxy ARP resolves a return MAC address which is set by an
undetermined method. Than it will construct an ARP Reply packet and
through an undetermined method decides which GRE sub-tunnel (GRE-key)
will be used (see iii for issues). Next it will construct a GRE
encapsulation, the GRE sequence number has to be recalculated, and than
send it to the proper BS. 

These are some of the issues that has to be cleared before a through
reading of the draft can be carried out.

-burcak

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Jan 2007 12:00:42 +0100

Hi Burcak, I'm not author of the document. I agree with some points in
your mail. The authors' point of view (when expressed) should be taken
as clarification to your request.

In what follows I snipped the bridge description you provide (layer0,1,2
and hyperbridge) and responded to the points I agree in your mail,
giving my motivation.

Overall, I don't think IPv6/ETHCS should use GRE keys, nor GRE seq no,
and that this document shouldn't specify at all link-layer behaviour
(the 'SHALL' statements on bridge behaviour are useless here).  A
clarification on DHCP/broadcast and router behaviour is in too.

Burcak Beser wrote:
> (The below described usage is the WiMAX mandatory supported transport
>  of packets and all the descriptions and especially normative 
> language has to deal with these details.)

Allow me to just suggest that some discussion may be raised to you about
this point, in that it may be suggested to you that this group doesn't
do WiMax at all but 802.16. It's also been pointed out that WiMax is the
only user of 802.16, as well as it's too early to know which will get
widespread acceptance WiMax or 802.16 (Ethernet vs 802.3 for IP took
like 10years to clear out, was said).

> http://www.wimaxforum.org/technology/documents/WiMAX_End_to_End_Network_Systems_Architecture.zip)
>  each “connection” between SS and BS indicated by a unique CID within
>  a single BS domain is mapped into a GRE tunnel in and in some other
>  cases all CID’s coming from a single SS is mapped into a GRE tunnel
>  identified by a “GRE key”.

Just a note that the most recent GRE spec (rfc2784) deprecates the use
of GRE key (rfc2784). The GRE header is also changed - optional parts
disappeared. I don't know why WiMax would continue use GRE keys to
identify the tunnels. Other ways can be done, with the short rfc2784
GRE header.

[skipping description of layer 0, 1, 2 of bridges and hyper-bridges,
  check the original poster's mail]

> 1. Section 5.3 states that: “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 guess this means that if BS has multiple interfaces it will send 
> all the packets through the physical interface that is connected to 
> “the bridge”. I have trouble to understand this requirement, is it 
> desired that all the packets send through the same GRE tunnel?

I think it shouldn't be required for BS to send all packets through the
same GRE tunnel.

I think some deployments may use a full bridge instead of a simple BS.
Or even a full access router instead of a dumb BS.  In these cases GRE
tunnels won't be needed.

> 2. Section 5.3 further states: “If the SS functions as a bridge then
>  it SHALL support a bridging between all its LAN ports and the 
> airlink.”
> 
>  against mandating unnecessary behavior. Further, I would like to 
> point out that bridging is not defined. I am surprised to find that 

I think that requirement is not necessary, but not because bridging is
not defined.  It's simply because this document shouldn't specify a
link-layer behaviour.  This is an IETF document and can't define
link-layer behaviour in such strong terms.  It should interpret the
link-layer behaviour as defined outside IETF and see how IP runs on it,
but not define it.

> 3. The last paragraph/sentence of the section 5.3 states: “When 
>  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.”
> 
> First since it is not explicitly clear where it is applicable I 
> assume that this behavior is applicable to both SS as a bridge and 
> the “bridge”. What is missing is the behavior when an entry is 
> deleted from the Dynamic Filtering Entry. In the non-normative 
> section the BRIDGETIMEOUT is used without a default value or 
> definition. There is a non-normative shall that defines the use of 
> BRIDGETIMEOUT that uses the term traffic but does not describe 
> whether this is for bi-directional traffic or not.

Same thing for this paragraph.  I don't agree this draft can use the
word "SHALL" to define how an entity performs bridging.  It's simply not
the place to do that here.  This is about networking behaviour not
link-layer behaviour.

> It is not clear at which level this bridge operates: level_0, level_1
>  or level_2? Since the usage of SS (I would like the term CPE and 
> would like to see CPE to include SS) implies that this is a behavior
>  of “hyper-bridge”.

What does CPE stand for?  Customer Premises? (sorry I don't know).

> 4. Section 6.1 states: “In this scenario, the bridge SHALL forward 
> all packets received from any radio side port to a network side 
> port.”
> 
> First of all the applicability of this normative statement is not 
> clear, and second I am missing the difference between this statement
>  and statement discussed in bullet 1. Having said that, I miss the 
> need for this requirement.

Yes, they look the same to me, and redundant.  I agree I think there's
no need for this requirement.  IEEE can require a bridge to forward
packets and this document will use this behaviour.

> It is not clear at which level this bridge operates: level_0, level_1
>  or level_2? The only evidence is against the level_0 is the fact 
> that this defined behavior completely disables R8 interface of WiMAX
>  specifications.

In this context here I don't care about the R8 interface of the WiMax
spec.  If this draft proposal breaks a WiMax spec then it's to be solved
between this draft's authors and WiMax.

> 5. Section 7.2 states: “The bridge SHALL have the ability to enable 
> or disable any filtering functionality defined herein.”
> 
> It is not clear whether this is a flow specific or not. At this point
>  of time my interpretation is that this is a global switch.

I think I do not agree with adding filtering functionalities to a bridge
in the context of making IPv6 work over EthCS.

> 6. Section 7.2 further states: “If a packet is filtered it SHALL be 
> silently discarded.”
> 
> It is not clear at which level this bridge operates: level_0, level_1
>  or level_2? The context implies that this is a level_2 functionality
>  thereby the bridge is actually a “hyper-bridge”.

Well, the sentence is not very clear to me either.

> One of the side-effects of being a “hyper-bridge” is the fact that 
>  tunnel, and whenever a new packet is to be send by the
> “hyper-bridge” needs to insert an additional packet into the GRE
> tunnel with relevant GRE-key.
> 
> 
> 
> The insertion/removal of GRE packets make the case that the GRE 
> sequence numbers cannot be used without making the “hyper-bridge” a 
> kind of back-to-back GRE relay that re-sequences.

The GRE seq number is also deprecated in the newer GRE spec.  So why
would one use it.

> If there are no re-sequencers in the “bridge” and sequence numbers 
> are being used there needs to be either a dummy packet insertion or a
>  missing packet within the GRE tunnel. Due to the fact that the 
> missing sequence numbers has the impact of delaying the packets out 
> of the tunnel, it is assumed that the dummy packet generation method
>  is being suggested. For the sake of compatibility the dummy packet
> is to be defined clearly.

I agree.  I think that there may be a need to define clearly how GRE
works in 802.16.  Probably 802.16 already done that (I don't know).
Don't know either whether GRE for 802.16 should be done in this IPv6
over ETHCS document.  Especially knowing that one could use 802.16
between the mobile and the network but not use GRE at all.

But, GRE is a generic encapsulation method, a GRE header is added
between the IP header and the link-layer header.  There may be a need to
specify what is the used link-layer header, what is the Protocol Type
field in the GRE header, etc.

> 7. Section 7.2 states that: “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.”
> 
> 
> 

I personally think this is not the place to specify link-layer behaviour
on the bridge.

> 8. Section 7.2 states that: “The bridge SHALL support filtering of 
> all-nodes multicast MAC address.”
> 
> 
> 
> What this requirement does is disabling the all means of 
> communication from the network if the CPE MAC address has expired. 
> When the fact that there are no normative requirements on the 
> “bridge” to learn is added, it is very hard to have a predictable 
> behavior between the “bridges” that are within this draft.

I personally think this is not the place to specify link-layer behaviour
on the bridge.

> As usual it is not clear at which level this bridge operates: 
> level_0, level_1 or level_2.
> 
> It is important to point out that all the wording suggests that this
>  is a bridge operating at level_2 “hyper-bridge”. On this level the 
> “hyper-bridge” receives a MAC packet through a physical port, if the
> MAC address, if the inner MAC address is broadcast, removes the 
> packet and sends the next packet with next sequence number (if 
> sequence numbers are being used) to the ASN-GW thereby creating a 
> hole in the GRE sequence.
> 
> One question regarding the requirement is that some DHCP Offers are 
> send as MAC broadcast messages, and this requirement prevents these 
> hosts to get an IP address.

Well, DHCP offers aren't sent as broadcast but unicast.  DHCP discover
are.  And indeed if link-layer broadcast for IPv4 doesn't work, or if
link-layer multicast for IPv6 doesn't work, then DHCP doesn't work.

> 9. Section 7.2 further states: “The bridge SHALL support filtering of

I'm not sure this is the place to specify link-layer filtering for a bridge.

> 10. The last paragraph/sentence on section 7.2 states that: “If 
>  for additional processing as specified in following section.”
> 
> 
> 
> As usual it is not clear at which level this bridge operates: 
> level_0, level_1 or level_2.

To me, it is not clear what's the necessity of ND Relay Agent in first
place.

> It is important to point out that all the wording suggests that this
>  is a bridge operating at level_2 “hyper-bridge”. It is important to
>  note that the proxy ARP referred receives packets that are within
> GRE tunnel and send packets through GRE tunnel.
> 
> 
> 
> 11. The Section 7.3 states: “For IPv4 over Ethernet, ICT contains MAC
>  address and Port Map, which constitute a filtering entry in 
> Filtering Database, tunnel ID, lifetime, and one or more unicast and
>  multicast IPv4 addresses.”
> 
> The mentioning of the tunnel ID strongly suggests a “hyper-bridge” 
> operation. The problem of ingress and egress tunnel-ID has no 
> solution offered and has to be mentioned using two tunnel ID’s.

I have much more problems with that spec of the ICT (Identification
Cache Table).  I can rely separately.

> 12. Section 7.4 states that: “The AR SHALL have packet-relay 
> functionality.”
> 
> The packet-relay is not defined within this document and since 
> document only as informational references this is a hard to test item
>  if not impossible.

(Maybe authors wanted to say packet forwarding functionality.  But
  because the 'relay' and 'proxy' words are such a buzz (no pun intended)
  in this context then everything looks as a relay and a proxy.)

That said, I do have other issues with section 7.6 Access Router
behaviour.  For example this:

draft:
> In the Public Access scenario, all unicast packets originated from a 
> SS should be delivered to an AR even though the SS sends packets to 
> on-link SSs.  Therefore, it is necessary for the AR to relay the on- 
> link packets.

The first phrase makes think that packets from SS to SS are
unnecessarily flying through AR.  So one immediately thinks the solution
would be for packets to fly directly from SS to SS.  But no, authors
propose that AR relays on-link packets; well this is already the case,
router will put packets from link to same link if addresses indicate so.

That's why that paragraph is confusing.

> 13. Section 8.1.1 states that: “The bridge SHALL support an ARP 
> Proxy.”
> 
> As usual it is not clear at which level this bridge operates: 
> level_0, level_1 or level_2.

Well, to me it's not clear why should we have both IPv4 and IPv6 in the
same document.  If this document is to become IPv6 only then it
shouldn't talk ARP at all.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 10 Jan 2007 17:21:17 +0100

Just a note that I've been notified privately that GRE Keys were
reinstated then by rfc2890.  In which case the use by WiMax of GRE keys
would be ok, so please discard my comments on GRE keys and seqnos.

Alex

Alexandru Petrescu wrote:
> Hi Burcak, I'm not author of the document. I agree with some points 
> in your mail. The authors' point of view (when expressed) should be 
> taken as clarification to your request.
> 
> In what follows I snipped the bridge description you provide 
> (layer0,1,2 and hyperbridge) and responded to the points I agree in 
> your mail, giving my motivation.
> 
> Overall, I don't think IPv6/ETHCS should use GRE keys, nor GRE seq 
> no, and that this document shouldn't specify at all link-layer 
> behaviour (the 'SHALL' statements on bridge behaviour are useless 
> here).  A clarification on DHCP/broadcast and router behaviour is in 
> too.
> 
> Burcak Beser wrote:
>> (The below described usage is the WiMAX mandatory supported 
>> transport of packets and all the descriptions and especially 
>> normative language has to deal with these details.)
> 
> Allow me to just suggest that some discussion may be raised to you 
> about this point, in that it may be suggested to you that this group 
> doesn't do WiMax at all but 802.16. It's also been pointed out that 
> WiMax is the only user of 802.16, as well as it's too early to know 
> which will get widespread acceptance WiMax or 802.16 (Ethernet vs 
> 802.3 for IP took like 10years to clear out, was said).
> 
>> each “connection” between SS and BS indicated by a unique CID 
>> within a single BS domain is mapped into a GRE tunnel in and in 
>> some other cases all CID’s coming from a single SS is mapped into a
>>  GRE tunnel identified by a “GRE key”.
> 
> Just a note that the most recent GRE spec (rfc2784) deprecates the 
> use of GRE key (rfc2784). The GRE header is also changed - optional 
> parts disappeared. I don't know why WiMax would continue use GRE keys
>  to identify the tunnels. Other ways can be done, with the short 
> rfc2784 GRE header.
> 
> I think it shouldn't be required for BS to send all packets through 
> the same GRE tunnel.
> 
> I think some deployments may use a full bridge instead of a simple 
> BS. Or even a full access router instead of a dumb BS.  In these 
> cases GRE tunnels won't be needed.
> 
>> 2. Section 5.3 further states: “If the SS functions as a bridge 
>> then it SHALL support a bridging between all its LAN ports and the 
>> airlink.”
>> 
>> I am not sure why we have this as a requirement, as a principle I 
>> am against mandating unnecessary behavior. Further, I would like to
>>  point out that bridging is not defined. I am surprised to find 
>> that 802.1d-2004 is referenced as an informative.
> 
> I think that requirement is not necessary, but not because bridging 
> is not defined.  It's simply because this document shouldn't specify 
> a link-layer behaviour.  This is an IETF document and can't define 
> link-layer behaviour as defined outside IETF and see how IP runs on 
> it, but not define it.
> 
>> 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.”
>> 
>  word "SHALL" to define how an entity performs bridging.  It's simply
>  not the place to do that here.  This is about networking behaviour 
> not link-layer behaviour.
> 
>> It is not clear at which level this bridge operates: level_0, 
>> level_1 or level_2? Since the usage of SS (I would like the term 
>> CPE and would like to see CPE to include SS) implies that this is a
>>  behavior of “hyper-bridge”.
> 
>> clear, and second I am missing the difference between this 
>> statement and statement discussed in bullet 1. Having said that, I 
>> miss the need for this requirement.
> 
> Yes, they look the same to me, and redundant.  I agree I think 
> there's no need for this requirement.  IEEE can require a bridge to 
> forward packets and this document will use this behaviour.
> 
>> It is not clear at which level this bridge operates: level_0, 
>> level_1 or level_2? The only evidence is against the level_0 is the
>>  fact that this defined behavior completely disables R8 interface
>> of WiMAX specifications.
> 
>  spec.  If this draft proposal breaks a WiMax spec then it's to be 
> solved between this draft's authors and WiMax.
> 
>> It is not clear whether this is a flow specific or not. At this 
>> point of time my interpretation is that this is a global switch.
> 
> I think I do not agree with adding filtering functionalities to a 
> bridge in the context of making IPv6 work over EthCS.
> 
>> It is not clear at which level this bridge operates: level_0, 
>> level_1 or level_2? The context implies that this is a level_2 
>> functionality thereby the bridge is actually a “hyper-bridge”.
> 
>> whenever a packet is dropped it, it will not be send through the 
>> GRE tunnel, and whenever a new packet is to be send by the 
>> are being used there needs to be either a dummy packet insertion or
>>  a missing packet within the GRE tunnel. Due to the fact that the 
>>  of the tunnel, it is assumed that the dummy packet generation 
>> method is being suggested. For the sake of compatibility the dummy 
>> packet is to be defined clearly.
> 
> between the IP header and the link-layer header.  There may be a need
>  to specify what is the used link-layer header, what is the Protocol 
> Type field in the GRE header, etc.
> 
>> If this sentence is taken to its face value, there is no way that 
>> an expired address to be reached by an external communication.
> 
> I personally think this is not the place to specify link-layer 
> behaviour on the bridge.
> 
> I personally think this is not the place to specify link-layer 
> behaviour on the bridge.
> 
>> It is important to point out that all the wording suggests that 
>> this is a bridge operating at level_2 “hyper-bridge”. On this level
>>  the “hyper-bridge” receives a MAC packet through a physical port, 
>> if the packet is a GRE packet it opens the GRE packet, looks at the
>>  inner MAC address, if the inner MAC address is broadcast, removes 
>> the packet and sends the next packet with next sequence number (if 
>>  send as MAC broadcast messages, and this requirement prevents 
>> these hosts to get an IP address.
> 
> Well, DHCP offers aren't sent as broadcast but unicast.  DHCP 
> discover are.  And indeed if link-layer broadcast for IPv4 doesn't 
> work, or if link-layer multicast for IPv6 doesn't work, then DHCP 
> doesn't work.
> 
>> 9. Section 7.2 further states: “The bridge SHALL support filtering 
>> of all packets received from a network side port to a broadcast or 
>> Discovery messages to pass to the Neighbor Discovery (ND) Relay 
>> Agent for additional processing as specified in following section.”
>> 
>> 
>> 
>> 
>> 
> To me, it is not clear what's the necessity of ND Relay Agent in 
> first place.
> 
>> It is important to point out that all the wording suggests that 
>> this is a bridge operating at level_2 “hyper-bridge”. It is 
>> important to note that the proxy ARP referred receives packets that
>>  are within GRE tunnel and send packets through GRE tunnel.
>> 
>> 
>> 
>> 11. The Section 7.3 states: “For IPv4 over Ethernet, ICT contains 
>> MAC address and Port Map, which constitute a filtering entry in 
>> Filtering Database, tunnel ID, lifetime, and one or more unicast 
>> and multicast IPv4 addresses.”
>> 
>> document only as informational references this is a hard to test 
>> item if not impossible.
> 
> because the 'relay' and 'proxy' words are such a buzz (no pun 
> intended) in this context then everything looks as a relay and a 
> proxy.)
> 
>> In the Public Access scenario, all unicast packets originated from 
>> a SS should be delivered to an AR even though the SS sends packets 
>> to on-link SSs.  Therefore, it is necessary for the AR to relay the
>>  on- link packets.
> 
> unnecessarily flying through AR.  So one immediately thinks the 
> solution would be for packets to fly directly from SS to SS.  But no,
>  authors propose that AR relays on-link packets; well this is already
>  the case, router will put packets from link to same link if
> addresses indicate so.
> 
> Well, to me it's not clear why should we have both IPv4 and IPv6 in 
> the same document.  If this document is to become IPv6 only then it 
> _______________________________________________ 16NG mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/16ng
>