[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
- [16NG] AD review of draft-ietf-16ng-ipv6-link-mod… Jari Arkko
- Re: [16NG] AD review of draft-ietf-16ng-ipv6-link… gabriel montenegro
- [16NG] Re: AD review of draft-ietf-16ng-ipv6-link… Jari Arkko