[16NG] AD review of draft-ietf-16ng-ipv6-link-model

Jari Arkko <jari.arkko@piuha.net> Mon, 29 January 2007 13:56 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBWzJ-0001rk-Bs; Mon, 29 Jan 2007 08:56:01 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HBWzH-0001rc-7e for 16ng@ietf.org; Mon, 29 Jan 2007 08:55:59 -0500
Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HBWzE-0006RN-Nn for 16ng@ietf.org; Mon, 29 Jan 2007 08:55:59 -0500
Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 48915198775; Mon, 29 Jan 2007 15:55:53 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 02C5D198630; Mon, 29 Jan 2007 15:55:52 +0200 (EET)
Message-ID: <45BDFCE9.2050804@piuha.net>
Date: Mon, 29 Jan 2007 15:55:53 +0200
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 1.5.0.9 (X11/20070104)
MIME-Version: 1.0
To: Syam Madanapalli <smadanapalli@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV using ClamSMTP
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955
Cc: 16ng@ietf.org
Subject: [16NG] AD review of draft-ietf-16ng-ipv6-link-model
X-BeenThere: 16ng@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: 16ng working group discussion list <16ng.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/16ng>
List-Post: <mailto:16ng@ietf.org>
List-Help: <mailto:16ng-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/16ng>, <mailto:16ng-request@ietf.org?subject=subscribe>
Errors-To: 16ng-bounces@ietf.org

Hi,

I have reviewed this document again.
Please see a few comments below:

> 3.1.  Shared IPv6 Prefix Link Model
This section should start with a definition of
the model.

> 3.1.4.5.  Changes to Host Implementation
>
>    This link model requires no other implementation changes except that
>    the hosts are required to perform duplicate address detection for all
>    addresses even if the host is reusing the interface identifier.
Is this a remnant from an earlier revision? If you employ
MLD snooping as opposed to looking at NAs, it would
appear that the above is not true.
>    802.16 [1] [2] is a connection oriented access technology for the
>    last mile without bi-directional native multicast support. 802.16 has
>    only downlink multicast support and there is no mechanisms defined
>    for mobile stations to be able to send multicast packets that can be
>    mapped to downlink multicast connection.  This could be a problem for
>    IP protocols (e.g.  ARP, IPv6 ND) that traditionally assume the
>    availability of multicast at the link layer. 
This statement may need to be revised according to DJ's
recent comments on the list.
>    3.  If neither PPP nor VLAN is used, the set of 802.16 connections
>        can be viewed as a virtual point-to-point link for the purpose of
>        neighbor discovery and address configuration.  For IPv6 CS, this
>        may be used to implement the point-to-point link.
The key issue is not what you do with ND, but rather
what the scope of the link local multicast is; that
determines what happens to RAs, NAs, etc.

>    When the p2p link model is used, the BS acts as a bridge.  For each
>    MS, the BS bridges the unique prefix or set of prefixes assigned by
>    the AR to the link between itself and the MS.  This means, in
>    particular, that the per MS prefix or set of prefixes are routed on
>    both sides (wireless and wired) of the BS, and that the BS needs to
>    participate in all 802 standard bridging protocols.
The expression "routed on both sides" may not be
appropriate here. The BS is not a router.

Question: why is it that the BS needs to participate in
all bridging protocols? From the perspective of the
MS it shouldn't even see the existence of a tunnel
behind the BS.

>    One way to construct an Ethernet like link is to implement bridging
>    [13] between BSs and AR like switched Ethernet.  In the Figure 4,
>    bridging performs link aggregation between BSs and AR.  Bridging also
>    supports multicast packet filtering.  Another way to implement this
>    model is by using VLAN function [11].

I do not understand how VLANs relate to this. Please explain or
remove.

>    In this model, an IPv6 prefix is shared by multiple MSs on top of
>    IEEE 802.16 point-to-multipoint links.  Also this model supports
>    multiple access routers and multiple hosts behind an MS as shown in
>    Figure 4.

Yes, but a question: should this be taken as a claim that the
other models do not support multiple hosts? The document
does not say anything about this.
>    conjunction with IP convergence sublyaer with IPv6 classifiers.
Typo.

Jari


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