Re: GRE keys and seqnos (was: [16NG] Request for clarification on draft-ietf-16ng-ip-over-ethernet-over-802.16-00.txt)

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

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