Subject: Re: [16NG] (2nd) WG LCon draft-ietf-16ng-ip-over-ethernet-over-802.16-05.txt

From: "Riegel, Maximilian (NSN - DE/Muenich)" <[email-masked]>
Date: Mon, 7 Apr 2008 23:51:52 +0200

Thanks for being patient for the responses to the specific issues. 
It took us some time to analyze all the comments thoroughly and find
appropriate remedies for the couple of places, which require small
adaptations in the text.

Overall, we were impressed by the careful review - and by the maturity
of our I-D. We will update the I-D incorporating the results of this
WGLC, and it seems, the IPoETHo802.16 specification is really ready for
going to the IESG.

Please find our detailed responses below.

Bye
Max

>-----Original Message-----From: [email-masked] [mailto:16ng-
>[email-masked]] On Behalf Of ext Burcak Beser Sent: Saturday, March
>22, 2008 3:00 AM To: gabriel montenegro; [email-masked] Subject: Re:
>[16NG] (2nd) WG LCon draft-ietf-16ng-ip-over-ethernet-over-802.16-
>05.txt
>...

>As for the specific issues:
>
>(section 4.3) "the succeeding EAP authentication phase" this is not
>true for [802.16 ]

This sentence has been introduced by a former review. Nevertheless your
statement is valid. Legacy 802.16 does not necessarily deploy EAP.
=> Replace 'EAP' by 'PKM'

>(section 4.3) "While MAC addresses are assigned to all the SSs as well
>as the BS, the forwarding of packets over the air is performed only on
>base of the CID value." As far as I can see this implies that the SS
>processes/forwards the packets based on CID not MAC address which I
>believe is not the case.

You may have a look into section 6.3 of [802.16] to discover that indeed
CID is used for forwarding packets over the air. Against rumors not the
whole MAC layer of 802.16 has been copied from DOCSIS.
=> No modification necessary.

>(section 4.3) "Not relying on the MAC addresses in the payload for
>reception of a radio frame allows for the transport of arbitrary
>source and destination MAC addresses in Ethernet frames between a SS  
>and its BS." Does this sentence imply that two attached hosts
>communicating between them will have spillover of communion to BS?

Not clear, what you are meaning. 'two attached hosts': attached where?
Indeed IEEE802.16 only provides communication links between SS and BS.
Any host to host communication is realized on top of IEEE802.16.
=> No modification necessary.

>(section 4.3) "Due to the managed assignment of the service flows and
>associated CID values to individual SSs, the BS is able to bundle all
>connections belonging to a particular SS into a single link on the
>network side..." this is only true if broadcast/multicast connections
>are not used otherwise this statement is not correct.

The I-D fully relies on unicast links. To make it more clear we will add
'unicast' in the sentence.
=> Amend '.. to bundle all unicast connections belonging ..'

>(section 5.2) "Current IEEE 802.16 [802.16][802.16e] does not define
>broadcast and multicast of IP packets." 802.16 defines broadcast and
>multicast of  IPv4oEth packets on downstream and is unicast on
>upstream. The proper terminology must be used.

802.16 defines classifiers, which can be used to forward IP packets
based on the IP destination address, but 802.16 does not specify how to
configure 802.16 to make IP broadcast and multicast according
RFC1112/RFC2460 happen. IMHO, the wording of the I-D is correct.
=> No modification necessary.

>(section 5.2) "Hence IP broadcast and multicast packets SHOULD be
>replicated and then carried   via unicast transport connections as
>IEEE 802.16 access link. " if the previous sentence is correct why
>this is a normative 'should'?

'SHOULD' because it is recommended behavior, but there are exceptions as
explained later in the I-D.
=> No modification necessary.

>(section 5.3.1) "In the Public Access scenario, direct communication
>between nodes is restricted because of security and accounting issues.
>" The word 'restricted' mmust be clarified. Restricted means different
>things to different people.

There is no normative statement around 'restricted'. And it is intention
not to provide further clarifications, because this is part of the
security policy of an operator.
BTW: Is there any normative text, which would be applicable?
=> No modification necessary.

>(section 5.3.1) "The AR MAY perform security filtering, ..." does this
>imply that BS cannot do security filtering, policing and accounting.
>If the answer is yes than we do not need to use normative language
>here.

The BSs would be able to perform security filtering, policing and
accounting, but there is good reason not to distribute the functions,
especially when there is mobility involved. Normative MAY is
appropriate.
=> No modification necessary.

>(section 5.3.2) "The enterprise LAN scenario assumes trust
>relationship between all hosts and thus enables hosts to directly
>communicate with each other without detouring." I certainly do not
>agree with the case that two enterprises will trust each other just
>because they connectto the same BS.

Are you somewhat familar with later developments in DOCSIS? If you take
a look e.g. into CM-SP-L2VPN-I07-080215.pdf, you will find the same
term. 'Enterprise LAN' describes a LAN operated by a single enterprise.
=> No modification necessary.

>(section 6) "Network-side bridge is based on [802.1D]" what is the
>functionalitythat is taken from [802.1D]?

You can find the mandatory requirements in [802.1D] Section 5.1.
=> As many are not so familar with the [802.1D] specification, I would
add this information to the end of the succeeding sentence: '... require
additional IP specific functionalities on the network-side bridge in
addition to the mandatory functions according to Section 5.1 of
[802.1D].'
 
>(section 6.1) "lower side port " undefined term.

Figure 5 explains, what 'lower side' and 'upper side' means.
=> No modification necessary.

>(section 6.1.1)  "all packets originated from a SS SHOULD be delivered
>to an AR." how about the packets originated from hosts behind the SS?

This statement refers to figure 5. Also packets from hosts behind the SS
are originating into the depicted system from the SS. But rephrasing may
improve understanding.
=> Replace 'originated from a SS' by 'send from a SS to the BS'

>(section 6.1.2) "IP unicast packets from either SSs or AR SHALL be
>forwarded by [802.1D] based bridging. " to me this requirement wis
>over "all packets originated from a SS SHOULD be delivered to an AR"
>requirement of section 6.1.1.

Please be aware that you are in a new section! 6.1.1 describes the
Public Access Scenario Case, while 6.1.2 describes the Enterprise LAN
Scenario Case, and there is a difference between the cases.
=> No modification necessary.

>(section 6.2.) IPv4CS will not carry VLAN packets. So the complete
>section "Segmenting the Ethernet into VLAN" should be deleted.

Burcak, you are in the IPoETH document, not in the IPv4-CS document!
Ethernet can support VLANs.
=> No modification necessary.

>(section 6.3) "All multicast and multicast control messages SHOULD be
>processed in the network-side bridge according to [RFC4605]. " why
>this is a 'should'? this must be a normative 'must'.

Deployment of [RFC4605] increases the efficiency, but it is not required
to make the system working. SHOULD seems to be appropriate.
=> No modification necessary.

>(section 6.3.1.) "Usually, bridges replicate the IP multicast packets
>and forward them into all of its available ports with the exception of
>the incoming port, like IP broadcast packets.  As a result, the IP
>mlticast packets would be transmitted even to SSs which do not
>participate in the corresponding multicast group. " I would like to
>state that this is a problem of the system defined. The use of filters
>for mapping traffic to CID prevents unwanted packets to be transmitted
>to SS'. he senetence should be deleted.

It is not a problem of the proposed architecture, it is a problem of
bridging, regardless whether the bridge is centralized or distributed.
And filters can be applied the same way in the centralized as well as in
the distributed network configuration. 'The use of filters for mapping
traffic to CID' is part of a particular implementation of bridging.
=> No modification necessary.

>(section 6.3.1) 'simple tree topology' must be defined.

'simple' is not the right term here. It should be 'basic' to make the
relation clear to the paragraph above.
=> Replace 'simple' by 'basic'

>(section 6.3.2) "The typical bridge floods the IP broadcast packets
>out of all connected ports except the port on which the packet was
>received" this is not correct, the sentence should be deleted.

We are in the 'Broadcast' section. I do not see, what is wrong here.
'typical' may be replaced by some more specific wording.
=> Replace 'typical' by 'ordinary'

>(section 6.4.1) "The network-side bridge SHOULD filter broadcast ARP
>Requests and  SHOULD respond to all the ARP Requests from lower side
>port with the access router's Ethernet MAC address so that all IPv4
>packets from SSs are forwarded to the access router." I am sure that
>standard routers will have a lot of fun, receiving packets within the
>same subnet. I do not understannd the reasoning.

Again, we are here in the 'Public Access Scenario'. All traffic has to
go through the router to allow application of customer profiles and
accounting.
=> No modification necessary.

>(section 6.4.2)  "The network-side bridge SHOULD maintain an ARP Cache
>large enough to accommodate ARP entries for all its serving SSs."
>Since this is a should what happens if it is not large enough and a
>MAC address needs to be dropped?

It is described in the following sentence. Please follow on:

>(section 6.4.2) "Otherwise, the network-side bridge MAY flood the ARP
>Requests." doe sthis mean that the bridge now has to multiply the
>packet as many as SS' and flood the metwork with many of the same
>packet, and send it to the AR as well.

If the bridge does not find the MAC address in its ARP Cache, it has to
find the appropriate port by other means. Flooding is the ultimative
method, but there are better ways to find the port and prevent resource
consuming flooding of all ports. It is an implementation issue, which
depends on the management method of the bridge ports.
=> No modification necessary.

>(section 7) "The Redirect message SHOULD be suppressed." why this is a
>'should', it must be a normative 'must'.

Agreed.
=> Replace 'SHOULD' by 'MUST'.

>(section 9.1.1) "Alternatively, the DHCP Relay Agent Information
>Option (option-82)   [RFC3046] MAY be used to avoid DHCP broadcast
>replies." As far as I remember the option 82 does not prevent the
>broadcasting of  broadcast offer messages.

[RFC3046] and [TR101] specify the two sub-options in 'option 82', which
can be
used for preventing DHCP's broadcast reply messages, which are
DHCP OFFER and ACK. You can ascertain it by seeing Section 3.2 in  
[RFC3046].
=> No modification necessary.

>(section 9.1.2) "SSs MUST use Address Resolution Protocol (ARP)
>[RFC0826] for finding an Ethernet MAC address of destination." after
>all normative 'should's why this is a 'must'? it should be anormative
>'should'.

ARP is an essential part for building the filter tables of the
net-bridge. 
=> No modification necessary.

>(section 9.2) "In this document, encapsulation of IPv6 packets into
>Ethernet frames and mapping rules for IPv6 address to Ethernet address
>(i.e.  MAC address) MUST follow [RFC2464]." This is a normative
>requirement for this document. why? the sentence should be deleted.

IPv6 Implementation MUST follow IPv6 rules, to make sure that the other
IPv6 standards in the document are working correctly.
=> No modification necessary.

>(section 9.3) As far as I can see this document states there is no MTU
>limitation. I understand the historical value but if this is a solved
>problem there is no need for discussion. The section 9.3 must be
>deleted.

The problem is solved if GRE is deployed and fragmentation on the link
between BS and bridge (ASN-GW) is acceptable. It is the aim of the
section, to explain the issues. The lengthy discussion in 16ng and the
conclusion for IPv4-CS shows that there is need to address the MTU topic
in the document.
=> No modification necessary.

>(section 9.3)  "Therefore, IEEE 802.16 frame SHOULD support for
>carrying 1518 bytes payload that includes 18 bytes Ethernet header and
>1500 bytes IP packet." first this is a requirement for 802.16 which is
>not the right place. Secod no matter what the SDU size is 802.16
>transport can communicate any size PDUs. I am not sure where this
>SDU/PDU mixup started but the same issue exists in other drafts as
>well.

It is not an requirement for IEEE802.16, it is an requirement for the
implementer of IEEE802.16 (or the group defining the profile for the
particular implementation). More clear wording may help to understand
the dependencies.
=> Rephrase text to 'The default MTU of IPv6 packets and IPv4 packets on
Ethernet over
IEEE 802.16 link SHOULD be 1500 bytes.'

>(section 9.3) "Therefore, the network operator should consider the
>size of stacked VLAN tags when implementing VLAN and setting the MTU
>of the link." the sentence must be deleted.

What is wrong with the sentence. This is a very valid statement, and we
should even add MAC-in-MAC, as it adds even some byte more.
=> No modification necessary.

>(appendix A) "While similar in nature to a bridging function, there is
>no appropriate forwarding model available." The whole Cable Access
>community begs to differ. The model exists and used by millions of not
>hundereds of million systems.

There is no IEEE802 specification to define bridging over unidirectional
broadcast media. It may be feasible to define a propriatary solution for
special applications, but all the IEEE802 bridging enhancements like
802.1Q are relying on the symmetrical model, which was finally also
adopted by DOCSIS, i.e. CM-SP-L2VPN-I07-080215.pdf makes use of the
802.1Q to enable more advanced Ethernet technologies like VLANs.
Interestingly CM-SP-L2VPN-I07-080215.pdf adopts a quite similar
architectural approach like the IPoETHo802.16 model to realize an access
network supporting multiple VLANs. 

>(appendix A) "[802.1D] cannot take advantage of the multicast CIDs
>because it relies on unicast connections or bidirectional broadcast
>connections" unitl now [802.1D] did not stop us from building a non-
>bridging network-bridge why worry about 802.1D now?

Because [802.1D] is the base standard for Ethernet bridging.

>(appendix A) "Furthermore, it should keep in mind that multicast CIDs
>are only efficient for a large number of subscribed SSs in a cell"
>this is true even for the large number of 2 SS'. The sentence must be
>deleted.

=> The statement is correct. No modification necessary.
Please read on before drawing conclusions.

>(appendix A) "Due to  incompatibility with advanced radio layer
>algorithms based on feedback information from the receiver side,
>multicast connections require much more radio resource for
>transferring the same information as a unicast connections" I really
>would like to see one example of this. I what is meant is ARQ schemes,
>there are many applications that will rather drop the packet than get
>it late. This is a choice but there is no reason for disabling
>multicast CIDs completely.

More information was available in the -02 version of this draft, but the
WG decided that such radio details are not appropriate for an IETF I-D.
There is a general rule behind the efficiency of multicast CIDs: as more
advanced the radio interface is becoming, as lower is the gain of a
multicast channel for small groups. Interestingly wireless is following
wired technologies. Initially Ethernet was based on a shared medium, but
since Ethernet has passed the 100 Mbit/s, shared medium is gone and only
unicast links are used anymore. We will see the same coming up in
wireless for the data connections.

Thanks for the careful review and the comprehensive feedback. It shows
that the I-D is ready for progressing to the IESG.

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