From mobopts-bounces@irtf.org Tue Aug 07 13:49:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IITBZ-0005ZT-US; Tue, 07 Aug 2007 13:49:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IITBY-0005ZM-Ml for mobopts@irtf.org; Tue, 07 Aug 2007 13:49:36 -0400 Received: from smtp.nokia.com ([131.228.20.172] helo=mgw-ext13.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IITBX-0005EN-0X for mobopts@irtf.org; Tue, 07 Aug 2007 13:49:36 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l77HgSbQ028263; Tue, 7 Aug 2007 20:42:54 +0300 Received: from daebh102.NOE.Nokia.com ([10.241.35.112]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 20:42:42 +0300 Received: from daebe103.NOE.Nokia.com ([10.241.35.24]) by daebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 7 Aug 2007 12:42:40 -0500 Received: from 10.241.59.91 ([10.241.59.91]) by daebe103.NOE.Nokia.com ([10.241.35.24]) with Microsoft Exchange Server HTTP-DAV ; Tue, 7 Aug 2007 17:42:40 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Tue, 07 Aug 2007 10:42:42 -0700 Subject: Re: [Mobopts] FW: Mobopts review From: Rajeev Koodli To: Rajeev Koodli , Message-ID: Thread-Topic: [Mobopts] FW: Mobopts review Thread-Index: AcfQiawc6nxDKjx8EdyNZwAWy5YJpwIkK69D In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 07 Aug 2007 17:42:40.0747 (UTC) FILETIME=[5A1B63B0:01C7D91A] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: ext John L , "mobopts@irtf.org" X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Hello, I have few more suggestions (editorial) to revise the document. Regards, -Rajeev Abstract: "To solve the problem, this draft defines nine kinds of L2 abstractions in the form of "primitive" to achieve fast handovers in the network.." ^^^^ primitives 1. Introduction In recent years, the execution environment around computers is not static and changes dynamically. Especially, when a mobile node moves to a different network, its communication environment considerably changes. For example, in the case of wireless communication, parameters such as radio strength largely changes depending on time or site. Replace above paragraph with the following: RK> Recent years have witnessed rapid proliferation of wireless networks as well as mobile devices accessing them. Unlike wired network environments, wireless networks are characterized by dynamically changing radio conditions, connectivity, and available bandwidth. RK> You may combine the following paragraph with the above to make it a single paragraph. For efficient network communication, it is vital for a protocol layer to know or utilize other layer's control information. Mobile IPv4 [1] and Mobile IPv6 [2] have been standerdized to support communication with mobile nodes. There are several proposals for seamless handovers in IPv6 network such as Fast Handovers for Mobile IPv6 (FMIPv6) [3] and Hierarchical Mobile IPv6 (HMIPv6) [4]. In FMIPv6, the network layer must know the indication of a handover from the link layer in advance to achieve seamless handovers. However, control information exchange between protocol layers is not allowed ^^ => typically not available because each protocol layer is designed independently. To solve the problem, this draft defines nine kinds of L2 abstractions in the form of "primitive" to achieve fast handovers ^^ primitives in the network layer. This mechanism is called "L3-driven fast handovers" because the network layer initiates L2 and L3 handovers by using the "primitives". 4.1. L2-LinkStatus (Type 1) The L2-LinkStatus.request primitive is sent to the link layer when an upper layer needs the current information of a link. The L2- LinkStatus.request primitive contains the "Network Interface ID" parameter (See Section 5.1). ^^^^^^^^^^ 6.1. PoA ^^^^ Expand PoA On 7/27/07 1:06 PM, "ext Rajeev Koodli" wrote: > > > Hello, > > Here is the IRSG review of L2 abstractions ID. I think the comments are > mostly editorial and very useful in improving the overall quality of the > document. > > Thanks John for your review. > > Authors: please take a look and respond. > > Regards, > > -Rajeev > -- > http://people.nokia.net/~rajeev > > > ------ Forwarded Message > From: ext John L > Date: Fri, 27 Jul 2007 16:00:06 -0400 (EDT) > To: Rajeev Koodli > Cc: Aaron Falk > Subject: Mobopts review > > I've read through draft-irtf-mobopts-l2-abstractions-03, and I find it > almost but not quite ready for publication. > > Keeping in mind that I am not particularly expert in mobile computing, > the content seems fine. It needs a careful copy-edit to fix some > language problems that are distracting and occasionally ambiguous. For > example, page 6 defines PoA as "the attachment point of a mobile node". > PoA presumably stands for Point of Attachment, and it just seems odd to > have the abbreviation and definition not match. More seriously, there are > places where the complexity of English syntax leads to confusion. For > example, on page 3 the last sentence of the first paragraph reads "a > layer can evenly communicate with each other", which I think is trying to > say that the communication between layers is symmetrical, but I'm not > sure. A careful copy edit, in consultation with the authors to be sure > the ambiguities are resolved correctly, should solve this. > > Appendix B appears to contain two paper examples and one report of an > experiment. They're all fine, but it would be helpful to explain either > why they tested the third example or why they didn't test the first two. > > None of these problems are major, and I expect all could be fixed in one > more editing pass. > > Regards, > John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for > Dummies", > Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor > "More Wiener schnitzel, please", said Tom, revealingly. > > ------ End of Forwarded Message > > > _______________________________________________ > Mobopts mailing list > Mobopts@irtf.org > https://www1.ietf.org/mailman/listinfo/mobopts -- http://people.nokia.net/~rajeev _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts From mobopts-bounces@irtf.org Fri Aug 31 18:12:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IREhC-00083Y-CS; Fri, 31 Aug 2007 18:10:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IRB6h-0001Ea-PP; Fri, 31 Aug 2007 14:20:35 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IRB6g-0007HS-Fg; Fri, 31 Aug 2007 14:20:35 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 31 Aug 2007 14:20:10 -0400 X-IronPort-AV: i="4.20,193,1186372800"; d="scan'208"; a="69777534:sNHT65952275316" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l7VIK92Y023542; Fri, 31 Aug 2007 14:20:09 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l7VIK25m011743; Fri, 31 Aug 2007 18:20:02 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 31 Aug 2007 14:19:55 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 31 Aug 2007 14:20:47 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Fwd: WGLC for draft-ietf-dna-protocol-06.txt] Thread-Index: AcfD0J5rK0240mUVSa+wcH+2tni9PwoE7nYAAAO5fiA= From: "Wes Beebee \(wbeebee\)" To: "Hemant Singh \(shemant\)" , "Suresh Krishnan" , , , , X-OriginalArrivalTime: 31 Aug 2007 18:19:55.0756 (UTC) FILETIME=[8830B2C0:01C7EBFB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5919; t=1188584409; x=1189448409; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=wbeebee@cisco.com; z=From:=20=22Wes=20Beebee=20\(wbeebee\)=22=20 |Subject:=20RE=3A=20[Fwd=3A=20WGLC=20for=20draft-ietf-dna-protocol-06.txt ] |Sender:=20 |To:=20=22Hemant=20Singh=20\(shemant\)=22=20, =0A=20=20 =20=20=20=20=20=20=22Suresh=20Krishnan=22=20 , =20, =0A=20=20=20=20=20=20=20=20, =20,=20; bh=jjWtRWiutsvwaXHV/ZxQzqj6hGQKOgKIMrCHOaFN8Rw=; b=afktPId0/o+15T1JFBxz5vI369qZY1xJ/lwrd3zJELKZybqxpBnJerj1R2hUhgAjYytaKa2M vBJf9Mg69sZSHVSExpKyx8te94KW2bT6DIC5kG5+qytHSwaLSUkhvLLv; Authentication-Results: rtp-dkim-2; header.From=wbeebee@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: -3.7 (---) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 X-Mailman-Approved-At: Fri, 31 Aug 2007 18:10:29 -0400 Cc: Subject: [Mobopts] RE: [Fwd: WGLC for draft-ietf-dna-protocol-06.txt] X-BeenThere: mobopts@irtf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Mobility Optimizations List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: mobopts-bounces@irtf.org Here's my review of the DNA I-D: One global concern:=20 I'm concerned that DNA may not be applicable to all networks. There seems to be some=20 implicit assumptions about the networks that must be true - and these assumptions are not necessarily going to be true on all of the networks that DNA seems to be targeting. In cases where DNA cannot automatically determine that the host is in such a network,=20 it should be possible to turn DNA off manually and resort to old-style ND. Specific concerns: 1) What track is this Internet Draft on - Standards? 2) I'm concerned about two major deployment scenarios, each of which is likely to affect millions of subscribers off of the same aggregation router: a) The router offers no PIO in the RA - thus, no prefix is available. This is currently being=20 discussed as a possible way to prevent poorly implemented host stacks which ignore the M and A bits=20 in the RA from doing SLAAC and force them to do DHCPv6 or not get online. Unfortunately, this case breaks DNA as there is no prefix available to identify the link. The "at least one router on a link MUST be configured with one prefix" is a limitation of DNA. b) The prefix for a neighborhood is the same for all access points in the neighborhood. This can happen if home users are off of bridge modems and they are all bridging the same prefix (which is defined=20 on a bundle interface of the aggregation router. This is done to conserve address space and simplify network configuration by MSO's. Unfortunately, this means that DNA will detect every AP in the neighborhood as the same link. Even worse, when DNA causes the node not to do DHCPv6 again, the aggregation router which understands which home corresponds to which addresses, causes source verify to reject traffic from the roaming laptop. What should happen is that the node should try to do DHCPv6 again when it roams even when the prefix is the same - this doesn't work in DNA. 3) The routers being able to advertise a prefix list as complete assumes that they know about all the routers on the link. However, one of the routers could be silent for a while, and a router may assume that it knows all of the prefixes on the link but may be wrong. 4) "Any future non-prefix link identifier MUST be 128 bits long." - Why? 5) Are the MAX_RTR_SOLICITATIONS and RTR_SOLICITATION_INTERVAL chosen to scale up to 100,000 hosts off of an=20 aggregation router? What if multiple interfaces startup at the same time? Will there be an RS storm and will the token bucket rate limiting cause RS's to be dropped as described in the security considerations case? I suspect that this case may be even more common than you might suspect... You may have to adjust UNICAST_RA_INTERVAL and MAX_UNICAST_RA_BURST to deal with interface bringups on the aggregation router. 6) "The router MUST pick the smallest prefix of all the prefixes configured on the routers on the link as the common prefix." What if there are 2 smallest prefixes? 7) "an absence of that overlap can be used to infer link change" in 5.1.8 is repeated again in 5.1.9, and 5.1.9.1 - please eliminate redundancy. 8) In 5.2.6.1, one of the IF statements is missing - "{ Link change has occurred. RETURN; }" but no IF, and occurred is spelled wrong. 9) Why do you need to infer upstream reachability? - Wes -----Original Message----- From: Hemant Singh (shemant)=20 Sent: Friday, August 31, 2007 11:40 AM To: Suresh Krishnan; ipv6@ietf.org; netlmm@ietf.org; mobopts@ietf.org; nemo@ietf.org Subject: RE: [Fwd: WGLC for draft-ietf-dna-protocol-06.txt] Suresh, I have few minor comments on this I-D. Wes Beebee will send more detailed comments sometime later today. He has reviewed the I-D. 1. While reading the Abstract, I'd like to know what is the maximum delay DNAv6 is ready to accept in a response from router? =20 2. Stateful has been deprecated for use. We should call it DHCPv6. Therefore section 5.2.7 should change statefully to DHCPv6. Hemant -----Original Message----- From: Suresh Krishnan [mailto:suresh.krishnan@ericsson.com] Sent: Wednesday, July 11, 2007 11:29 AM To: ipv6@ietf.org; netlmm@ietf.org; mobopts@ietf.org; nemo@ietf.org Subject: [Fwd: WGLC for draft-ietf-dna-protocol-06.txt] Hi Folks, We would like to hear your comments on this document as well. This document is a significant update to ipv6 neighbor discovery and we would like some more eyeballs. Please spare some time from your busy schedule to give it a look. Thanks Suresh -------- Original Message -------- Subject: WGLC for draft-ietf-dna-protocol-06.txt Date: Wed, 04 Jul 2007 15:47:24 -0400 From: Suresh Krishnan To: Dna CC: Greg Daley , Jari Arkko This mail starts a 2 week working group Last Call for comments for the following dna working group document draft-ietf-dna-protocol-06.txt to be sent to the IESG for consideration as a Standards Track RFC. Please review the document carefully, and send your feedback to the list. Please also indicate whether or not you believe that this document is ready to go to the IESG. The last call will end on 2007/07/18. Cheers Suresh & Greg -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- _______________________________________________ Mobopts mailing list Mobopts@irtf.org https://www1.ietf.org/mailman/listinfo/mobopts