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

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

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

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]

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

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

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

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

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

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

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 
> all-nodes multicast MAC address.
> 
> 
> 
> I am not sure why this restriction is in place.

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

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

_______________________________________________
16NG mailing list
16NG@ietf.org
https://www1.ietf.org/mailman/listinfo/16ng