AD%20Review%20of%20IP%20over%20Ethernet%20over%20802.16%20[draft-ietf-16ng-ip-over-ethernet-over-802.16-06.txt]

1
AD Review ofIP over Ethernet over
802.16draft-ietf-16ng-ip-over-ethernet-over-802.
16-06.txt

• IETF-72, Dublin, July 08
• Max Riegel (NSN), Sangjin Jeong (ETRI), Hongseok
  Jeon (ETRI)

2
Status

• draft-ietf-16ng-ip-over-ethernet-over-802.16-06.tx
  t was published on April 4th incorporating a
  couple of refinements out of the second WG LC
• The I-D was forwarded to IESG end of June.
• Jari Arkko came back with a detailed list of
  review comments on July 7th.
• The following slides are listing the comments and
  the proposed remedies of the authors.
• Response of authors was send to the 16ng list
  on Jul 20th.
• Updated I-D will be published after IETF-72
  incorporating the remedies.

3
General comment

• AD Overall, there are a number of issues or at
  least question marks. Not surprisingly the part
  of this document that defines how to carry IP
  over Ethernet in 802.16 is in pretty good shape.
  But I do have multiple concerns about the way
  that this draft handles some of the optimizations
  related to IP layer behavior. For instance, some
  of the filtering rules seem more appropriate as
  operational suggestions than parts of the
  normative spec. There are inconsistencies with
  regards to IPv6 and redirects need to be handled.
  The centralized bridge model does not appear to
  be either necessary or sufficient to handle the
  task it was designed for.
• R Your comments are valid concerns and will be
  addressed in the next revision of the document.
  But the main issue leading to the comments is the
  mixture of different deployment scenarios
  throughout the document. It is not easy to follow
  which of the statements are relevant for which of
  the deployment models. Furthermore the
  predominant deployment model 'Public Access' is a
  special case of the generic 'Enterprise LAN'
  model.

4
Comments 1

• AD Why was RFC 4605 used instead of RFC 4541?
• R RFC 4541 is Informational, RFC 4605 is
  Standards Path. Making normative references to an
  Informational document is not appropriate, even
  if it would have been simpler. Being able to make
  normative references to RFC 4541 would make our
  task much easier.
• AD What can this spec mandate about the behavior
  of hosts connected via a regular Ethernet and a
  bridge to the 802.16 network?
• R The spec can only mandate that the hosts
  connected to the Ethernet are following the
  generic specifications like RFC 894 and RFC 2464
  for IP over Ethernet. And the spec has to mandate
  that the Ethernet over 802.16 does behave like
  standard Ethernet, e.g. does not introduce any
  additional restrictions for the MTU size.
  Probably we missed to state the prerequisite very
  clearly in the I-D.

5
Comments 2

• AD One discussion that we should have is what
  parts of the document are operational advice on
  techniques that can be employed to reduce extra
  traffic, and what parts are fundamental parts of
  IP over 802.16/Ethernet without which no
  interoperability can be achieved.
• R Fundamental parts are using 'MUST' statements,
  while operational advise is usually marked by
  'SHOULD' statements. And operational hints are
  provided in two layers hints for the generic
  deployment model and special hints for the public
  access scenario.
• The I-D adopted a functional approach and listed
  the operational hints for the generic case and
  the special case directly following the
  introduction of the function. We found that this
  mixture of generic case and special case is not
  working well, and a structure where all the
  generic statements are kept together clearly
  separated from the special statements for public
  access scenario may be much better to follow.
• We will change the structure of the I-D and
  split out all the special requirements for the
  public access scenario in a dedicated section
  after introducing the generic case. The new
  structure may look like
• Mandatory requirements for interoperability
• Optimizations for the generic deployment case
• Recommendations for the public access scenarios

6
I-D Restructuringcurrent --gt new

• 1. Introduction
• 2. Requirements
• 3. Terminology
• 4. The IEEE 802.16 Link Model
• 4.1. Connection Oriented Air Interface
• 4.2. Feeding User Data into the Appropriate
  Connections
• 4.3. MAC addressing in IEEE 802.16
• 5. Ethernet Network Model for IEEE 802.16
• 5.1. IEEE 802.16 Ethernet Link Model
• 5.2. Ethernet without Native Broadcast and
  Multicast Support
• 5.3. Deployment Scenarios for IP over
  Ethernet over IEEE802.16
• 5.3.1. Public Access Scenario
• 5.3.2. Enterprise LAN Scenario
• 6. Network-side Bridge Considerations
• 6.1. IEEE 802.16 Ethernet Link Model
  Considerations
• 6.1.1. Public Access Scenario Case
• 6.1.2. Enterprise LAN Scenario Case
• 6.2. Segmenting the Ethernet into VLAN
• 6.3. Multicast and Broadcast Packet
  Processing

• 1. Introduction
• 2. Requirements
• 3. Terminology
• 4. The IEEE 802.16 Link Model
• 4.1. Connection Oriented Air Interface
• 4.2. Convergence Sublayer
• 4.3. MAC addressing in IEEE 802.16
• 5. Ethernet Network Model for IEEE 802.16
• 5.1. IEEE 802.16 Ethernet Link Model
• 5.2. Segmenting the Ethernet into VLAN
• 5.3. Ethernet without Native Broadcast and
  Multicast Support
• 6. Transmission of IP over Ethernet over
  IEEE802.16
• 6.1. IPv4 over Ethernet
• 6.2. IPv6 over Ethernet
• 6.3. Maximum Transmission Unit
  Consideration
• 7. Operational Enhancements
• 7.1. Network-side Bridging Considerations
• 7.1.1. Bridging Topology
• 7.1.2. Multicast Transmission

7
Comments 3

• gtgt Those IP specific support
• gtgt functions are preferably realized in a
  centralized device containing
• gtgt a bridge for aggregation of traffic from all
  the BSs to provide a
• gtgt more straightforward management solution and
  allow for effectively
• gtgt commoditized BSs, which may be deployed in the
  IEEE 802.16 based
• gtgt access network in a large volume.
• gtgt The IEEE 802.16 Ethernet
• gtgt link model MUST interconnect each
  point-to-point connections assigned
• gtgt to SSs at a centralized point, a.k.a.
  network-side bridge, as shown
• gtgt in Figure 2. This is equivalent to today's
  switched Ethernet with
• gtgt twisted pair wires connecting the hosts to a
  bridge ("Switch"). The
• gtgt single and centralized network-side bridge
  allows best control of the
• gtgt broadcasting forwarding behavior and prevents
  potential security
• gtgt threats coming up with cascaded bridges.
• AD This appears to be an implementation
  consideration this is inappropriate for an IETF
  IP over Foo specification. (See also below on my
  comments on Appendix B.)
• R It looks like an implementation consideration,
  but it is not. As mentioned in both, the first
  sentence taken from the introduction and the
  later sentence in the second paragraph, there is
  functional reason to co-locate all the forwarding
  decisions of a switched LAN (bridging function)
  in a single device.
• The real issue with the statement above is the
  'centralized point'. Such wording is
  inappropriate for a MUST requirement. Better

8
Comment 4

• gtgt IEEE 802.16g 802.16g defines a GPCS
  (Generic Packet Convergence
• gtgt Sublayer), which may be used to transfer
  Ethernet frames over IEEE
• gtgt 802.16 as well.
• AD s/may be used to transfer/may be used by
  future specifications to define how to transfer/
• R There is no need for future specifications to
  deploy GPCS for IPoETHo802.16. GPCS can be used
  for transferring ETH frames as well as native IP
  packets (as well as PPP and MPLS) over 802.16.
  When carrying Ethernet, GPCS is interoperable
  with ETH CS as it uses the same packet formats
  over the air as ETH CS. The difference is the
  non-existence of classification rules for GPCS,
  i.e. it is not defined by IEEE802.16 by which
  filtering of packet headers payload packets are
  assigned to particular service flows.
• IMHO, the proposed change is not appropriate. We
  will add explicit statement that the I-D applies
  to GP-CS as well.

9
Comment 5

• gtgt In the Public Access scenario, direct
  communication between nodes is
• gtgt restricted because of security and accounting
  issues.
• AD And presumably mere volume of traffic as
  well?
• R Traffic volume is usually not an issue when
  the operator is able to charge for it. Enforcing
  that all traffic is passing through the control
  point of the operator ensures that all packets
  are accounted.
• gtgt 6.1.1. Public Access Scenario Case
• gtgt
• gtgt The network-side bridge SHOULD forward all
  packets received from any
• gtgt lower side ports to all upper side ports being
  in the forwarding
• gtgt state. Direct communication between SSs
  SHOULD NOT be supported by
• gtgt the network-side bridge and all packets sent
  from a SS to the BS
• gtgt SHOULD be delivered to an AR.
• AD The document comes across as a very system
  oriented. This is unusual for an IETF IP over Foo
  specification, and I suspect that over time we'll
  regret too tight bindings to particular
  deployment situations. I think the spec would be
  better recast as a the key IP over
  802.16/Ethernet, followed by a set of
  recommendations for different situations. You can
  even specify cleanly separated optional functions
  (such as preventing direct communication) that
  deployers can choose to use in a particular
  situation.
• R The description is addressing different
  aspects particular to a deployment model. The
  description will fit much better into the
  'Recommendations for public access' part of the
  new structure.

10
Comment 6

• gtgt All multicast and multicast control messages
  SHOULD be processed in
• gtgt the network-side bridge according to
  RFC4605.
• AD I would like to understand the decision to
  use 4605 instead of 4541 which seems more suited
  to bridged environment.
• R RFC 4541 is Informational. RFC 4605 is
  Standard. Making normative statements to
  Informational RFCs looked not appropriate to us.
• gtgt The IEEE 802.16 Ethernet link model in Section
  5.1 has a basic tree
• gtgt topology and RFC4541 provides an application
  guide how bridge,
• gtgt non-IP device, to examine and learn group
  membership. Hence,
• gtgt RFC4605 can be applied to the IEEE 802.16
  Ethernet link model to
• gtgt reduce the multicast packet flooding.
• gtgt
• gtgt The network-side bridge in the IEEE 802.16
  Ethernet link model SHOULD
• gtgt play a role in proxying IGMP/MLD messages as
  specified in RFC4605.
• gtgt The network-side bridge SHOULD perform the
  host portion of IGMP/MLD
• gtgt process on its upper side port and the router
  portion of IGMP/MLD
• gtgt process on its all lower side ports.

11
Comment 7

• gtgt The network-side bridge in the IEEE 802.16
  Ethernet link model SHOULD
• gtgt discard all IP broadcast packets except ARP,
  DHCP (DHCPv4 and
• gtgt DHCPv6), IGMP, and MLD related traffic. The
  ARP, DHCP, IGMP and MLD
• gtgt related packets SHOULD be forwarded with
  special rules specified in
• gtgt this specification.
• AD This is inappropriate. First, you stated
  earlier that this Section (6.3) also applies to
  the enterprise deployment. In that environment,
  turning off broadcast may be inappropriate.
• R You are right, and thanks for pointing to this
  mistake. We will revise the text to ensure that
  broadcast is not impacted for the generic case
  (Enterprise LAN scenario).
• AD Secondly, i think you are mixing the
  specification of IP over Foo with a particular
  filtering requirement in a specific deployment.
  Its fine to state operational advice, but do not
  cast it as a part of the normative specification.
• R The distinction between normative requirements
  and operational hints should become much clearer
  in the new structure. We will keep such
  operational hints in a separate section.
• gtgt Note that packets destined for permanently
• gtgt assigned multicast addresses such as
  224.0.0/24 in IPv4 or FF021 in
• gtgt IPv6 are also regarded as broadcast data.
• AD All permanently assigned addresses? Even
  all-routers, for instance? Be more specific.

12
Comment 8

• gtgt 6.4. Proxy ARP
• gtgt
• gtgt Proxy ARP provides a process where a device on
  the link between hosts
• gtgt answers ARP Requests instead of the remote
  host. In this
• gtgt specification, the Proxy ARP mechanism is used
  to force all traffic
• gtgt from hosts to the access router or to avoid
  broadcasting ARP Requests
• gtgt over the air depending on the particular
  deployment scenario. The
• gtgt Proxy ARP process is usually co-located with
  the network-side bridge.
• AD Another part of the specification that should
  be cast as an operational advice of other
  techniques that can be used to combat excessive
  traffic? Please consider a separate section for
  these.
• R Agreed. There is a mode of operation of Proxy
  ARP, which is applicable to all scenarios, and
  there is a special treatment of Proxy ARP in the
  public access scenario. We will separate the two
  aspects in different sections.

13
Comment 9

• gtgt In the public access scenario, all packets
  between SSs will always be
• gtgt relayed via access router. In this scenario,
  the access router
• gtgt SHOULD forward packets via the same interface
  on which the access
• gtgt router received the packets, if the source and
  destination addresses
• gtgt are reachable on the same interface. This
  would result in a Redirect
• gtgt message from the access router
  RFC0792RFC4861. The Redirect
• gtgt message MUST be suppressed.
• gtgt 8.1. Public Access Scenario Case
• gtgt
• gtgt Unique IPv6 prefix per SS SHOULD be assigned
  because it results in
• gtgt layer 3 separation between SSs and it forces
  all packets from SSs to
• gtgt be transferred to an AR.
• AD If we are employing per-SS prefixes, what is
  the point of the Redirect discussion above?
• R The redirect discussion applies to both IPv4
  and IPv6. Unique prefixes per MS are only
  feasible for IPv6. The redirect requirements is a
  fall-back function when unique IPv6 prefixes are
  not deployed.We will restructure the statements
  making redirect and unique prefixes alternate
  solutions for IPv6.

14
Comment 10

• gtgt In this
• gtgt specification, SSs perform above the discovery
  process by solicited
• gtgt Router Advertisement messages because periodic
  Router Advertisement
• gtgt messages are discarded on the network-side
  bridge following the
• gtgt Broadcast Data Forwarding Rules in Section
  6.1.2.
• AD Hmm. Given that there can be regular Ethernet
  bridges and 802.16 unaware hosts at the
  subscriber side, where does that leave hosts that
  are relying on RAs? (E.g., hosts complying with
  RFC 3775.)
• R Thanks for bringing this up. The statements in
  section 9 must be converted into statements for
  network behaviors. As you mention, the host may
  not be aware of the IEEE802.16 connection on the
  link.
• gtgt 9.2.2. Address Configuration
• gtgt SS SHOULD derive its global IPv6 addresses
  based on prefix and EUI-
• gtgt 64-derived interface identifier
• AD And similar other sections. Again, given that
  this must work with regular Ethernet-attached
  hosts, to what extent are these statements
  useful?
• R Normative language is not appropriate in this
  section, but it may be helpful to explain what is
  expected from hosts attached to the Ethernet.
  Nevertheless the whole section requires rewording
  to make clear, that only general IPv6
  requirements can be asserted to hosts for
  IPoETHoIEEE802.16.
• AD Also, this document should not make any
  recommendations on what particular address
  assignment mechanism should be employed (4862,
  3041, etc).

15
Comment 11

• gtgt The Proxy ARP function described in Section
  6.4 prevents that ARP
• gtgt broadcast messages have to be forwarded to
  each of the associated
• gtgt SSs, when the ARP proxy is aware of the
  existence of the queried IP
• gtgt address at one of the bridge ports. If the
  queried IP address is not
• gtgt known to the ARP proxy, the bridge has to
  flood all its ports with
• gtgt the ARP request.
• gtgt
• gtgt Distributing the bridging function into the
  BSs would imply that the
• gtgt Proxy ARP function is split into multiple
  Proxy ARP functions each
• gtgt knowing only about the subset of the IP
  addresses, which are directly
• gtgt connected by the BS. IP addresses
  belonging to the same link but
• gtgt being connected to other BSs would not be
  known to the Proxy ARP
• gtgt functions and would cause ARP requests for
  these IP addresses to be
• gtgt broadcast to all SSs. This causes a waste
  of radio resources for
• gtgt transmitting ARP requests and potentially
  more critical even, it
• gtgt would waste scarce battery power in the
  SSs.
• gtgt
• gtgt A malicious user would be able to deploy
  this behavior for denial of
• gtgt service attacks by exhausting the batteries
  of SSs by sending

16
Comment 11 cont.

• AD Second, if you really wanted to make this
  work, wouldn't flooding only to the upstream port
  achieve what you want to do, without requiring
  one centralized device?
• R Flooding upstream means that the downstream
  bridge assumes that the upstream bridge has the
  queried IP address in its ARP cache. This is
  indeed likely when the cache is large enough to
  capture all the IP addresses used in the
  Ethernet. Essentially the upstream bridge acts as
  centralized Proxy ARP function.
• In the generic case (Enterprise LAN scenario)
  there is no upstream port and the AR may reside
  on any of the port. The preference for a
  centralized bridging function arises out of the
  generic scenario, where no indication is
  available about the position of the AR.
• Indeed there is not much difference between
  concentrated and distributed bridging for the
  public access scenario when there is a proxy ARP
  function upstream able to capture all the
  MAC-IP-address associations.
• We think, a more comprehensive description of
  the issues of particular bridging topologies for
  the Net-bridge may be helpful.

17
Editorials

• AD Term PKM used before expanded or introduced.
• R o-.k.
• gtgt The IEEE 802.16 standards define a packet CS
  (Convergence Sublayer)
• gtgt for interfacing with all packet-based
  protocols. IEEE 802.16g
• gtgt 802.16g, also, specifies a generic packet CS
  to provide an upper-
• gtgt layer protocol independent interface. This
  document describes
• gtgt transmission of IPv4 over Ethernet as well as
  IPv6 over Ethernet via
• gtgt the CSs in the IEEE 802.16 based access
  network.
• AD This paragraph is confusing. I cannot tell
  what CS you are using. I think you are using the
  Ethernet CS, but the paragraph fails to mention
  this.
• R o.k. This paragraph gets more clear text about
  ETH-CS and the applicability of the GP-CS.
• gtgt forwarding of packets over the air is
  performed
• gtgt only on base of the CID value
• AD s/base/based/
• R only based on the CID value, o.k.
• gtgt This is beneficial when Ethernet frames with
  arbitrary
• gtgt MAC addresses have to be forwarded to a SS in
  the case that the SS is
• gtgt interconnected to another network.
• AD s/.../This is required for bridging./
• R o.k.

18
Conclusion

• The AD review brought up two major deficiencies
  of the I-D
• Overall structure mixing interoperability with
  operation with particular deployment models
• Being not clear that host may not be aware of
  IEEE802.16 on the link
• I-D has to be revised adopting a more clear
  structure and keeping the role of the host
  agnostic to the IEEE802.16 link
• also addressing the other issues found in the
  review.