Re: [16NG] AD review of draft-ietf-16ng-ip-over-ethernet-over-802.16

["Riegel, Maximilian (NSN - DE/Muenich)" <[e-mail]>]

Thanks Jari for your quick response. And in particular showing the
possibility to make use of RFC4541 instead of RFC4605.

We will create and submit a new revision of the I-D addressing all the
issues. 

Bye
Max

-----Original Message-----
From: ext Jari Arkko [mailto:[e-mail]] 
Sent: Tuesday, July 22, 2008 14:18
To: Riegel, Maximilian (NSN - DE/Muenich)
Cc: [e-mail]; Hongseok Jeon; Sangjin Jeong;
[e-mail]; W. Mark
Townsley
Subject: Re: [16NG] AD review of
draft-ietf-16ng-ip-over-ethernet-over-802.16


Max,

> Getting a review from a DSL expert is welcome, even when the public
> access model mentioned in the IPoETHo802.16 I-D is both a sub-set and
an
> extension of the DSL model; a sub-set because DSL deploys different
> models up to putting each subscriber on its own link (VLAN), and an
> extension because DSL has not yet fully covered the particularities of
> supporting  IPv6 over Ethernet in the access.
>   

Right, but they are in the process of doing so.

>> 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.
>>     
>
> 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.
>
>
>   
>> Why was RFC 4605 used instead of RFC 4541?
>>     
>
> 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.
>   

We can do that. It just has to be called out during IETF Last Call as an

exception.

>> What can this spec mandate about the behavior of hosts connected 
>> via a regular Ethernet and a bridge to the 802.16 network?
>>     
>
> 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.
>   

Right.

>> 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.
>>     
>
> 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
> It looks that such a structure can be introduced with just shuffling
> around the chapters of the document with some new text necessary for
the
> description of the public access scenario.
>   

Ok.

>> Detailed comments below.
>>
>> Technical:
>>
>>     
>>> Those IP specific support
>>> functions are preferably realized in a centralized device containing
>>> a bridge for aggregation of traffic from all the BSs to provide a
>>> more straightforward management solution and allow for effectively
>>> commoditized BSs, which may be deployed in the IEEE 802.16 based
>>> access network in a large volume.
>>> The IEEE 802.16 Ethernet
>>> link model MUST interconnect each point-to-point connections
assigned
>>> to SSs at a centralized point, a.k.a. network-side bridge, as shown
>>> in Figure 2.  This is equivalent to today's switched Ethernet with
>>> twisted pair wires connecting the hosts to a bridge ("Switch").  The
>>> single and centralized network-side bridge allows best control of
the
>>> broadcasting forwarding behavior and prevents potential security
>>> threats coming up with cascaded bridges.
>>>       
>> 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.)
>>     
>
> 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 collocate 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.
> I would propose to rephrase the sentence into:
> "The IEEE 802.16 Ethernet link model MUST interconnect each
> point-to-point connections assigned to SSs by a network-side bridging
> function, as shown in Figure 2."
>   

As long as you do not require it to be in one box, I'm fine. So far I 
have not seen evidence of anything that wouldn't work with normal bridge

chaining.

>>>    IEEE 802.16g [802.16g] defines a GPCS (Generic Packet Convergence
>>>    Sublayer), which may be used to transfer Ethernet frames over
IEEE
>>>    802.16 as well.
>>>       
>> s/may be used to transfer/may be used by future specifications to
>>     
> define 
>   
>> how to transfer/
>>     
> 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.
>   

Ok. But I would like your explanation or some other words to appear in 
the draft, so that this would be clearer for other readers.

>>> In the Public Access scenario, direct communication between nodes is
>>> restricted because of security and accounting issues.
>>>       
>> And presumably mere volume of traffic as well?
>>     
>
> What is the thinking behind this statement? 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.
>   

OK

>>> 6.1.1. Public Access Scenario Case
>>>
>>> The network-side bridge SHOULD forward all packets received from any
>>> lower side ports to all upper side ports being in the forwarding
>>> state.  Direct communication between SSs SHOULD NOT be supported by
>>> the network-side bridge and all packets sent from a SS to the BS
>>> SHOULD be delivered to an AR.
>>>       
>> 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.
>>     
>
> I am not sure about the meaning of the comment. What is 'very system
> oriented' in the sentence above?

Your spec. It focus on a large number of issues, and the "IP over Foo" 
is just a tiny part of it.

> That forwarding of IP packets is
> performed by a router and not by multipoint-to-multipoint L2
> connectivity. Interestingly the desired Ethernet behavior for public
> access is resembling the behavior of the unique prefix per MS of the
> plain IP solution.
> Nevertheless I assume that the description will fit much better into
the
> 'Recommendations for public access' part of the new structure.
>   

Yes.

>>> All multicast and multicast control messages SHOULD be processed in
>>> the network-side bridge according to [RFC4605].
>>>       
>> I would like to understand the decision to use 4605 instead of 4541 
>> which seems more suited to bridged environment.
>>     
>
> RFC 4541 is Informational. RFC 4605 is Standard. Making normative
> statements to Informational RFCs looked not appropriate to us.
>   

See above. If 4541 is the right tool, please use it.


>>> The IEEE 802.16 Ethernet link model in Section 5.1 has a basic tree
>>> topology and [RFC4541] provides an application guide how bridge,
>>> non-IP device, to examine and learn group membership.  Hence,
>>> [RFC4605] can be applied to the IEEE 802.16 Ethernet link model to
>>> reduce the multicast packet flooding.
>>>
>>> The network-side bridge in the IEEE 802.16 Ethernet link model
SHOULD
>>> play a role in proxying IGMP/MLD messages as specified in [RFC4605].
>>> The network-side bridge SHOULD perform the host portion of IGMP/MLD
>>> process on its upper side port and the router portion of IGMP/MLD
>>> process on its all lower side ports.
>>>       
>> I do not understand how the first paragraph can state that bridges
are 
>> non-IP devices and then the second paragraph goes on to talk about
the 
>> application of IP layer processes such as acting as a host.
>>     
>
> Agreed. The challenge is to define a system by normative statements
> based on RFC 4605 to resemble the behavior of RFC 4541. The most easy
> solution would be a normative statement to RFC 4541, but this is
> inappropriate for a standards path document (?). So we will tweak the
> text to get this ambiguity removed. Some more text may help.
>   

See above.

>>> The network-side bridge in the IEEE 802.16 Ethernet link model
SHOULD
>>> discard all IP broadcast packets except ARP, DHCP (DHCPv4 and
>>> DHCPv6), IGMP, and MLD related traffic.  The ARP, DHCP, IGMP and MLD
>>> related packets SHOULD be forwarded with special rules specified in
>>> this specification.
>>>       
>> 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.
>>     
>
> 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).
>   

Good.

>> 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.
>>     
>
> The distinction between normative requirements and operational hints
> should be much clearer in the new structure. But where is the border
> line? Is usage of MLD snooping an operational hint or a normative
> recommendation to make the system working?
>   

I think MLD snooping is part of the operational advice.

Here is a simple test that you can employ to decide if mechanism X is a 
part of IP over Foo core functionality: if packets can flow correctly 
over the link without X, then X is not a part of core functionality.

>>> Note that packets destined for permanently
>>> assigned multicast addresses such as 224.0.0/24 in IPv4 or FF02::1
in
>>> IPv6 are also regarded as broadcast data.
>>>       
>> All permanently assigned addresses? Even all-routers, for instance?
Be 
>> more specific.
>>     
>
> Thanks for showing the shortage. We will provide a more comprehensive
> description.
>   

OK.

>>> 6.4. Proxy ARP
>>>
>>> Proxy ARP provides a process where a device on the link between
hosts
>>> answers ARP Requests instead of the remote host.  In this
>>> specification, the Proxy ARP mechanism is used to force all traffic
>>> from hosts to the access router or to avoid broadcasting ARP
Requests
>>> over the air depending on the particular deployment scenario.  The
>>> Proxy ARP process is usually co-located with the network-side
bridge.
>>>       
>> 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.
>>     
>
> 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.
>   

OK.

>>> In the public access scenario, all packets between SSs will always
be
>>> relayed via access router.  In this scenario, the access router
>>> SHOULD forward packets via the same interface on which the access
>>> router received the packets, if the source and destination addresses
>>> are reachable on the same interface.  This would result in a
Redirect
>>> message from the access router [RFC0792][RFC4861].  The Redirect
>>> message MUST be suppressed.
>>> 8.1. Public Access Scenario Case
>>>
>>> Unique IPv6 prefix per SS SHOULD be assigned because it results in
>>> layer 3 separation between SSs and it forces all packets from SSs to
>>> be transferred to an AR. 
>>>       
>> If we are employing per-SS prefixes, what is the point of the
Redirect 
>> discussion above?
>>     
>
> Usually the ICMP redirect function is implemented such that a ICMP
> redirect  
> message is issued when packets are forwarded via a incoming interface.
> This requirement is copied from Req#179 in TR 101 (Migration to
> Ethernet-Based DSL Aggregation) to make the behavior consistent with
> widely deployed public access networks.
>   

Hmm. I'm not sure I understand the response, but maybe this becomes 
clearer when I get Mark involved looking at this spec as well. Again, on

IPv6 and with per-SS prefixes, there will not be any redirects.

>>> In this
>>> specification, SSs perform above the discovery process by solicited
>>> Router Advertisement messages because periodic Router Advertisement
>>> messages are discarded on the network-side bridge following the
>>> Broadcast Data Forwarding Rules in Section 6.1.2.
>>>       
>> 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.)
>>     
>
> Thanks for bringing this up. We will add
>   

Add what?

>>> 9.2.2. Address Configuration
>>> SS SHOULD derive its global IPv6 addresses based on prefix and EUI-
>>> 64-derived interface identifier
>>>       
>> And similar other sections.
>>
>> Again, given that this must work with regular Ethernet-attached
hosts, 
>> to what extent are these statements useful?
>>     
>
> Normative language is not appropriate in this section, but it may be
> helpful to explain what is expected from hosts attached to the
Ethernet.
>   

OK. Please make it clear that you are only illustrating what is 
happening on the other side. And do not imply that any particular 
address allocation scheme has to be used.

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

>> select an address which is not on the link. According to your 
>> explanation above, this would be flooded to every port.
>>     
>
> You are right, this text is buggy. Malicious ARP requests cant be
> defended just by a concentrated bridging function.
>
>
>   
>> 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?
>>     
>
> What do you mean with flooding only to the upstream port?

If you know where this IP address is, forward the ARP request there. If 
you do not know, the current text says flood every port. However, if you

assume you know the situation in every port towards the SSes, you could 
forward the ARP request (multicast) to the upstream port, i.e., towards 
the higher level bridges. Those would in turn inspect their own local 
ports and forward it unicast to the right one. Or, if no one knew where 
it came from, it would eventually be sent to the AR and go unanswered.

This would avoid the need to say that there is one centralized box that 
holds the ARP proxy function.

> Do you assume
> that there is a centralized Proxy ARP function located in the AR?
> In the generic case there is no upstream port, the AR may reside on
any
> of the port. The preference for a centralized bridging function arises
> out of the more generic Enterprise LAN 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.
>   
My point is that requiring a centralized, one-device solution is not 
very compatible with the way corporate networks are usually switched. 
You may have a point about configuration for the upstream port being 
undesirable as well. But the end result is that I'm not sure we have a 
solution that fits the purpose that its intended for.

Jari

_______________________________________________
16NG mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/16ng