[16NG] Re: Review of the ipv6-over-ipv6cs draft

Hi Pekka,

Thanks for the review. Comments inline:

>
>The editorial clarity could have been somewhat better.
>
>It is not obvious whether the scenarios where "MS" is a fixed station
>and/or a router has been adequately considered or whether this is an
>editorial issue.

The term SS as has been defined and proposed for inclusion in the
problem statement I-D (Ref: PSDOC in the I-D) is:

o Subscriber Station (SS): An end-user equipment that provides
connectivity to the 802.16 networks. It can be either fixed/nomadic
or mobile equipment. In mobile environment, SS represents the
Mobile Subscriber Station (MS) introduced in IEEE 802.16e
specification. 

The email on the terminology is at:
http://www1.ietf.org/mail-archive/web/16ng/current/msg00291.html

In the case the MS is a CPE type of device serving hosts attached to
it, then the behavior of the CPE in this I-D is the same as an MS/SS.

>
>The design implications of raising RA intervals (intead of, say, filtering
>extra RAs out) may not be fully understood.  How are other protocols (e.g.,
>periodic MLD reports, Neighbor Solicitations due to port scanning or
>pinging
>the all nodes multicast address, etc.) handled?

Filtering extra RAs is not an option. The MS expects an RA at
MaxAdvIntervals and filtering them would disrupt MS behavior.

The MS and AR are connected via a PtP link which is created via a
combination of the transport connection over the air interface and a
corresponding GRE tunnel between the BS and AR. Are there specific
issues w.r.t MLD reports etc. on a PtP link that you believe need to
be clarified?
Pinging the all-nodes multicast address is an interesting issue. Doing
so for example on the AR would result in flooding the access network
and causing congestion on the air-interface if you have a large number
of hosts attached to the network. Hence an AR may explicitly prevent
such pinging.  

>
>There seem to be some technical problems (e.g., GRE tunnel multiplexing,
>different MTU recommendation) with Appendices and an issue of
>clarity why the appendices are there to begin with.

The MTU recommendation in the apendix is specific to WiMAX because of
a profile that has been adopted which is a subset of the 802.16
specification. I dont understand the GRE tunnel multiplexing issue
that you mention.
Note that the appendix is informational only in the context of this
document. The reason why it is useful is because of the fact that
802.16 deployments today is primarily as WiMAX. Hence the appendix
shows the applicability of the spec to a specific realization of a .16
network. 

>
>It is not clear if traffic classification is adequately specified (or is
>it specified elsewhere?) and some miscellaneous issues.

Classification rules are specified in the 802.16 specification.

>
>substantial
>-----------
>
>==> looking at the other "IPv6 over foo" documents, this document doesn't
>specify or mention the following:
> - link-local address generation  (exactly as described in RFC2464, I
>suppose?)

Yes. 

> - unicast and multicast address mapping
>
>Maybe these don't require much text but an explicit note might be a good
>thing to have.

Okay. I can add a sentence in the text. But since there is no
variation from the IPv6 specifications for such addresses, I do not
know if it helps in adding such a statement.

>
>...
>
>The packet CS defines a set of classifiers that are
>   used to determine how to handle the packet.  The IP classifiers that
>   are used at the MAC operate on the fields of the IP header and the
>   transport protocol and these include the IP Traffic class, Next
>   header field, Masked IP source and destination addresses and,
>   Protocol source and destination port ranges.
>
>==> this is probably defined better in 802.16, but not all traffic may have
>a traffic class (v4 has DSCP which is similar), you don't define what is
>"masked {dst,src} address" (just some kind of prefix part of an address?),
>and there may not necessarily be any port ranges involved (non-TCP/UDP
>protocols).
>
>Is more precise specification of this required to create interoperable
>implementations?  Is it a problem if different hosts make different
>classifications for the same kind of traffic?

The classification rules operate on a set of fields defined in
802.16. Absence of such fields (for example ports in non TCP/UDP
protocols) in a packet are essentially ignored. To quote 802.16 for
the case of port numbers:
"
If this parameter is omitted the protocol destination port is
irrelevant. This parameter is irrelevant for protocols without port
numbers. 
"

Masked src/dest address classification rule is simply a means of specifying
address ranges via a mask.

I can try and clarify this section better and add a reference to the
802.16 spec for further details on the classification rules.

>
>   Hence the point-to-point link model
>   for IPv6 operation over the IP specific part of the Packet CS in
>   802.16 is recommended.  A unique IPv6 prefix(es) per link (MS) is
>   also recommended.
>
>==> you don't discuss what will happen if these recommendations are not
>followed, in fact, the whole document assumes they are adhered to.  Either
>this should be discussed or the recommendations should be made stronger
>(requirements).

Okay... I can make it a requirement.

>
>6.3.  Maximum transmission unit in 802.16
>
>[...]  The Max value of the IPv6 MTU for 802.16 is 2038
>   bytes and the minimum value of 1280 bytes.  The default MTU for IPv6
>   over 802.16 SHOULD be the same as specified in RFC2460 which is 1500
>   octets.  RFC2461 defines an MTU option that an AR can advertise to an
>   MN.  If an AR advertises an MTU via the RA MTU option, the MN should
>   use the MTU from the RA.
>
>==> Should the last sentence use uppercase keywords?

Yes.

>==> However, if the MS is a router, RA is basically ignored in this kind of
>context.  Hence, this approach of non-default MTU configuration seems
>applicable between host and a router only.

Okay... Do you have any suggestion or text that would help in this
context?

>
>8.1.  Router Solicitation
>   [...] Movement detection at the IP layer of an MS
>   in many cases is based on receiving periodic router advertisements.
>
>==> yet, in 8.3 you make the period much longer, to be counted in hours.
>That's not useful for movement detection, text above should probably be
>adjusted.

But if you see the sentence following the above in sec 8.1, I do state
that link-layer triggers can be used to send router solicitations
instead and not rely on periodic RAs. So the sentence when read by
itself is in conflict with Sec 8.3 but not when read with the
following sentences in Sec 8.1.

>
>8.3.  Router lifetime and periodic router advertisements
>
>==> it is not clear if the implications of the design decision to raise the
>default advertisement intervals has been adequately understood.  Will this
>mean that every single instance of protocols which use too low intervals
>will need to be modified?

What specific protocols would you be concerned in this case? I know
MIP6 for example uses a lower interval for RAs for movement
detection. But as I said, movement detection in the case of 802.16 can
be dealt with at the link layer and triggers to indicate such movement
to the IP layer.

> How do you deal with periodic MLD reports, for
>example?  

So what would break if periodic MLD reports are not sent.

>How do you prevent frequent port scanning from waking up the host
>every 5 minutes when the router wants to do Neighbor Solicititation for the
>address?

It does not make sense to do wake up the host every 5 mins. Is there a
reason for the AR to do NS periodically?
In case a packet for the MS arrives at the AR, paging is used wake up
and establish the link and deliver the packet to the host.

>
> The
>   granularity of the GRE tunnel should be on a per MS basis or on a per
>   service flow basis (an MS can have multiple service flows, each of
>   which are identified uniquely by a service flow ID).
>
>==> So, it's possible to have multiple GRE tunnels between AR and BS.  Yet,
>I do not see how different GRE tunnels are multiplexed/demultiplexed.  GRE
>header does not support this AFAICS -- you'd need to use different
>source/destination IP address pairs, or encode different flows as different
>'Protocol type' values (16 bits), but the latter would require
>modifications
>to GRE processing code at both endpoints of the tunnel.   Therefore I'm not
>sure if this approach is workable.

Let me send a separate explanation for this.

>
>Appendix D.  Maximum transmission unit in WiMAX
>
>   The WiMAX forum [WMF] has specified the Max SDU size as 1522 octets.
>   Hence the IPv6 path MTU can be 1500 octets.  However because of the
>   overhead of the GRE tunnel used to transport IPv6 packets between the
>   BS and AR and the 6 byte MAC header over the air interface, using a
>   value of 1500 would result in fragmentation of packets.  It is
>   recommended that the default MTU for IPv6 be set to 1400 octets for
>   the MS in WiMAX networks.  Note that the 1522 octet specification is
>   a WiMAX forum specification and not the size of the SDU that can be
>   transmitted over 802.16, which has a higher limit.
>
>==> This brings up multiple problems:
>
> 1) main body said SHOULD use 1500 bytes, yet this recommends 1400.

This recommendation is WiMAX specific and is in the appendix. The
recommendation in the main body is applicable to 802.16 in general.

> 2) there is no statement in the document how to treat the appendices,
>i.e.,
>why thet even exist in this document especially if they contain
>contradicting material.

Well... The appendix is informational only. It exists to demonstrate a
realization of a network based on 802.16 air interface. I can add
explicit clarification to this effect.

> 3) The text above seems technically incorrect.  The key point here is what
>is the MTU on the wired link between BS and AR.  If it supports MTUs higher
>than 1500 (for example, GE jumboframes, SDH, ATM, whatever), tunneling
>could
>possibly still be used.

True... But the fact is that for WiMAX, the profile specifies a MAX
SDU of 1522 octets. So the packets on the air-interface cannot be
greater than 1522 bytes. So the existence of links with higher MTU
capability on the link between the BS<->AR does not matter.

>
>
>editorial
>---------
>
>Abstract
>
>   IEEE Std 802.16 is an air interface specification.  IEEE has
>   specified several service specific convergence sublayers (CS) for
>   802.16 which are used by upper layer protocols.  The ATM CS and
>   Packet CS are the two main service specific convergence sublayers and
>   these are a part of the 802.16 MAC which the upper layers interface
>   to.  The packet CS is used for transport for all packet-based
>   protocols such as Internet Protocol (IP), IEEE Std. 802.3 (Ethernet)
>   and, IEEE Std 802.1Q (VLAN).  The IP specific part of the Packet CS
>   enables transport of IPv6 packets directly over the MAC.  This
>   document specifies the addressing and operation of IPv6 over the IPv6
>   specific part of the packet CS for hosts served by a network that
>   utilizes the IEEE Std 802.16 air interface.  It recommends the
>   assignment of a unique prefix (or prefixes) to each host and allows
>   the host to use multiple identifiers within that prefix, including
>   support for randomly generated identifiers.
>
>==> s/the assignment of/assigning/ ?
>==> abstract is a bit on the lengthy side.  Maybe shorten a bit from the
>beginning, e.g. leaving ATM CS and some more generic sublayer discussions
>out of the abstract?
>

Okay... Will attempt.

>2.  Introduction
>
>==> the introduction mentions "mobile station/host", yet I think there
>is no
>restriction that the endpoint be a) mobile (could be a fixed wireless link
>as well), and b) a host (could be a router as well).  Maybe some further
>clarification here is needed to make it clear that fixed/router scenarios
>are also to be addressed by this specification.

Okay. I can add further text to the definition of MS/SS to include
such hosts.

>
>==> it might be helpful to have a diagram in section 2, as there are at
>least four functional components (AR, BS, link, MS) and at least AR hasn't
>been spelled out.  This also seems to include some assumptions about
>connecting a host to a router (above).

Will consider if it would help.

>
>4.1.  IPv6 encapsulation over the IP CS of the MAC
>
>   The IPv6 payload when carried over the IP specific part of the Packet
>   CS is encapsulated by the 6 byte 802.16 MAC header.  [...]
>
>==> "encapsulated by" seems a bit strange.. also, later you use
>"encapsulated .. in".

I dont know if it is a problem. But I can rephrase. Do you have a
better term?

>
>   The IPv6 node requirements RFC RFC4294 [RFC4294] specifies [...]
>
>==> s/ RFC RFC4294//

Yes.

-Raj

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