From nemo-bounces@ietf.org Mon May 01 11:43:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaaYy-0000I0-Qv; Mon, 01 May 2006 11:43:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaaYx-0000Hv-MC for nemo@ietf.org; Mon, 01 May 2006 11:43:51 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaaYx-0007zd-3R for nemo@ietf.org; Mon, 01 May 2006 11:43:51 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id IAA02259; Mon, 1 May 2006 08:43:49 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k41FhmG10155; Mon, 1 May 2006 10:43:48 -0500 (CDT) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 May 2006 08:43:46 -0700 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 Subject: RE: [nemo] Rewording of RO work in the charter Date: Mon, 1 May 2006 08:43:46 -0700 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BFD2@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: <20060430223551.s7jlv1ysxd0kscc0@webmail.grc.nasa.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Rewording of RO work in the charter Thread-Index: AcZsx/1um7uS6SRoQby92hIxAEnVTgAa9Ldw From: "Davis, Terry L" To: X-OriginalArrivalTime: 01 May 2006 15:43:46.0981 (UTC) FILETIME=[08CAD550:01C66D36] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: ml-nemo WG , "T.J. Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Will Comments below... Also thoughts on Marcelo's suggestion for an ID? Take care Terry > -----Original Message----- > From: ivancic@grc.nasa.gov [mailto:ivancic@grc.nasa.gov] > Sent: Sunday, April 30, 2006 7:36 PM > To: Davis, Terry L > Cc: T.J. Kniveton; ml-nemo WG > Subject: RE: [nemo] Rewording of RO work in the charter >=20 > Terry, >=20 > You forgot two. >=20 > Low cost. >=20 > Zero delay. :-) >=20 We are considering contracting with Stephen Hawking to re-write some of the basic laws of physics to solve this problem with geo-stationary satellite links; FTL communications! ;-) >=20 > Actually, I was at the last Internation Civil Aeronautics Organization > (ICAO) working group meeting on IPv6. I may be very possible that a > combination of routing using OSPFv3 for IPv6 and NEMO with MONAMI > policy based routing can get most of what is required by aeronautics - > actually perhaps all if some requirements are modified to match the > paricular flight portions. As it is today, many of the delay > requirement cannot be met by satellite because the delay requirements > are the same for take-off and landing (surface area) as the are for > enroute (plane in general flight at 30,000 ft). Obviously these > requirments should not be the same. >=20 Are you going to be in Copenhagen on the 15th at that meeting? > Today, most of the requirment are not met for all conditions and have > never really been adequately tested under all conditions and all loads. > For example, make-before-break is not really done as one has to > reset frequency on the radio during some handover situations. This is > a break before make situation. > If the normal state of the aircraft becomes having two ATC/AOC capable links available at most times, make-before-break is not necessarily a requirement as the traffic can be routed over the other link during a handoff. =20 > > The requirment to send Air Traffic Control (ATC) over one link and Air > Operations Control (AOC) over another is also not done - to the best > of my knowledge. If I got the story right, much of the AOC was done > before the ATC and then the ATC started using AOC links. The airlines > don't want to pay for multiple links and generally do not operate > multiple links. So what are requirements established years ago is > actually not done in practice. > Will, I see this being done by using separately addressed networks carried over the same links. I don't see any of us using entirely different links for ATC, AOC, and Passenger services. I do see some of the links being reserved for ATC/AOC use essentially the limited capacity bands. =20 >=20 > Will >=20 >=20 >=20 >=20 > Quoting "Davis, Terry L" : >=20 > > T.J. > > > > You'll probably wish that you hadn't asked for this... > > > > These would be our ideal mobility solution. I realize that meeting all > > of these is probably an extreme stretch. > > > > Take care > > Terry > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Generally the aviation mobility requirements are: > > > > 1- Ability to "dock" with numerous Internet service providers utilizing > > different media; satellite (KU & L), EVDO, 802.11/802.16 airport; > > hardwired Ethernet "gatelink". > > > > 2- Ability to be multihomed to different providers over different links > > simultaneously. The desired aircraft state will be to have two links > > active always. > > > > 3- Ability to assign traffic for specific providers links only (safety > > or operational certified providers) > > > > 4- Ability to re-profile traffic to match available link capacity and > > constraints when handing off between links. > > > > 5- Ability to seamlessly hand off existing network connections without > > dropping the session (we do this today). > > > > 6- Ability to maintain security through link hand off. > > > > 7- Ability to continue to receive multicast traffic after hand off. > > > > 8- Route optimization such that on hand off to a new link, > > connection/session routing is optimized to the new ground site. > > > > 9- Ability to maintain QoS on hand off with the capacity of the new link > > (You may hand off to a link with a smaller capacity or higher error rate > > or from an EVDO low latency link to a satellite high latency link) > > > > 10- Ability to support both IP-v6 and IP-v4 mobile platforms from an > > IP-v6 network. > > > > 11- Ability to receive priority multicast/broadcast messages. > > > > 12- Ability to establish connections to multiple onboard networks over a > > single link and hand off them simultaneously. (We expect the aircraft > > to have at three independent onboard isolated networks; air traffic > > control, airline operations, and passenger services. > > > > 13- Ability to initiate encrypted tunnels on all links with IPSec before > > passing traffic. > > > > > >> -----Original Message----- > >> From: T.J. Kniveton [mailto:tj@kniveton.com] > >> Sent: Friday, April 21, 2006 3:13 AM > >> To: ml-nemo WG > >> Subject: [nemo] Rewording of RO work in the charter > >> > >> Folks, > >> > >> I have been watching the conversation started by Marcelo a couple of > >> weeks ago, regarding the rewording of the (n,n,n) item in the > >> charter. (Sorry I haven't been commenting lately). > >> > >> We need to figure out how to massage the concepts being batted around > >> so that we have something tractable that we can work on and complete. > >> From the discussion so far, I tend to think: > >> > >> 1) We need somewhat more concrete idea of the requirements for the > >> type of situation we want to solve. I agree with Andrew that we don't > >> want to get bogged down in this, and I do believe Terry gave us a > >> list for the Conexion scenario quite a while ago. Perhaps he or > >> Andrew could give an updated list. > >> > >> 2) We need a bit more analysis still on the RO problem space, based > >> on some idea of requirements for the solution to be worked out > >> (according to charter items). Specifically, the effects of having a > >> "Mobile ISP" vs. "ISP-independent mobile home networks", the > >> implications of that for the global BGP tables, how likely it is to > >> get custom agreements between a mobility provider and ISPs it (or its > >> customers) uses, etc. > >> > >> 3) Route optimization - "Performance" as Marcelo called it - avoiding > >> long tunneling (geographically) - or avoiding expensive links. This > >> is what we have discussed so far, and we need a stronger boundary so > >> that we can define what is to be solved in these specific > >> circumstances. Otherwise this walks down the road toward many other > >> long-standing issues. My view is that having a good list of > >> requirements for the RO situation of interest would be helpful here. > >> > >> 4) Aviation - question of "if" to use Mobile IP... NEMO base does use > >> it because it made sense. It's possible we have another deployment > >> case where it does not make sense, but we still want a solution for > >> Network Mobility. However, we have to be careful here. > >> There are some general network mobility problems.. such as > >> multiple ISPs, having high-cost links, and how/whether to inject > >> routes into the BGP tables. I believe Terry already gave us a list of > >> requirements for this type of situation - can we review that? > >> > >> 5) Regarding HAHA - As Pascal mentioned, this wasn't supposed to be > >> "the only" or even "the" solution for RO. It is simply something that > >> addressed a shown need, and so I considered it to be something that > >> could be added for future work. But according to the list items > >> above, the group is not including or excluding any certain solution > >> at this point. We need more definition of what and how to solve, and > >> the implications of various approaches first. I would like to hear > >> the RO-analysis authors chime in on this one. > >> > >> Besides Aviation, I have asked numerous times for anyone who is > >> actually deploying NEMO or NEMO-like technology to give us industry > >> input for requirements. Aside from aviation, I have heard a little > >> bitregarding Japanese auto makers, but not much else. I also used to > >> know things about some large cell phone makers that might be doing > >> these things, but never enough to make a good list of requirements. > >> > >> Remember, our goal here is to reshape the charter to solve problems > >> so that NEMO can be deployed. If there are deployments that are > >> facing these issues, they can be brought forward to be studied at > >> this phase. > >> > >> In conclusion, I would like to have a bit more discussion, and then > >> maybe people can offer suggestions on how specifically to reword > >> charter language and/or change milestones so that these things can be > >> accomplished. > > > > > > >=20 From nemo-bounces@ietf.org Mon May 01 12:23:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FabB5-0007ME-C0; Mon, 01 May 2006 12:23:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FabB4-0007M9-K0 for nemo@ietf.org; Mon, 01 May 2006 12:23:14 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FabB3-0001m7-Ui for nemo@ietf.org; Mon, 01 May 2006 12:23:14 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id E5DD6D4B21; Mon, 1 May 2006 18:23:12 +0200 (CEST) Received: from [163.117.203.225] (unknown [163.117.203.225]) by smtp01.uc3m.es (Postfix) with ESMTP id 7E26FD4AD1; Mon, 1 May 2006 18:23:09 +0200 (CEST) In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> References: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Rewording of RO work in the charter Date: Mon, 1 May 2006 19:23:09 +0300 To: "Davis, Terry L" X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Cc: ml-nemo WG , "T.J. Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Terry, I have been reading the email that you sent to the ppml list about=20 aviation requirements and PI addressing (which was very clarifiyng BTW)=20= and i have another question about the requirements below. In=20 particular, you seem to have 3 different networks on board... does all=20= the requirements affect all the three networks? because i mean for=20 instance in the case of the closed network, i guess that it is easier=20 to provide some of the features since the peers are clearly located and=20= cannot be anywhere in the global internet and any solution would only=20 affect the close network/routing system... thanks, it is a really interesting problem statement this one that you=20= have here regards, marcelo El 29/04/2006, a las 7:45, Davis, Terry L escribi=F3: > T.J. > > You'll probably wish that you hadn't asked for this... > > These would be our ideal mobility solution. I realize that meeting = all > of these is probably an extreme stretch. > > Take care > Terry > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Generally the aviation mobility requirements are: > > 1- Ability to "dock" with numerous Internet service providers = utilizing > different media; satellite (KU & L), EVDO, 802.11/802.16 airport; > hardwired Ethernet "gatelink". > > 2- Ability to be multihomed to different providers over different = links > simultaneously. The desired aircraft state will be to have two links > active always. > > 3- Ability to assign traffic for specific providers links only (safety > or operational certified providers) > > 4- Ability to re-profile traffic to match available link capacity and > constraints when handing off between links. > > 5- Ability to seamlessly hand off existing network connections without > dropping the session (we do this today). > > 6- Ability to maintain security through link hand off. > > 7- Ability to continue to receive multicast traffic after hand off. > > 8- Route optimization such that on hand off to a new link, > connection/session routing is optimized to the new ground site. > > 9- Ability to maintain QoS on hand off with the capacity of the new=20 > link > (You may hand off to a link with a smaller capacity or higher error=20 > rate > or from an EVDO low latency link to a satellite high latency link) > > 10- Ability to support both IP-v6 and IP-v4 mobile platforms from an > IP-v6 network. > > 11- Ability to receive priority multicast/broadcast messages. > > 12- Ability to establish connections to multiple onboard networks over=20= > a > single link and hand off them simultaneously. (We expect the aircraft > to have at three independent onboard isolated networks; air traffic > control, airline operations, and passenger services. > > 13- Ability to initiate encrypted tunnels on all links with IPSec=20 > before > passing traffic. > > >> -----Original Message----- >> From: T.J. Kniveton [mailto:tj@kniveton.com] >> Sent: Friday, April 21, 2006 3:13 AM >> To: ml-nemo WG >> Subject: [nemo] Rewording of RO work in the charter >> >> Folks, >> >> I have been watching the conversation started by Marcelo a couple of >> weeks ago, regarding the rewording of the (n,n,n) item in the >> charter. (Sorry I haven't been commenting lately). >> >> We need to figure out how to massage the concepts being batted around >> so that we have something tractable that we can work on and complete. >> =46rom the discussion so far, I tend to think: >> >> 1) We need somewhat more concrete idea of the requirements for the >> type of situation we want to solve. I agree with Andrew that we don't >> want to get bogged down in this, and I do believe Terry gave us a >> list for the Conexion scenario quite a while ago. Perhaps he or >> Andrew could give an updated list. >> >> 2) We need a bit more analysis still on the RO problem space, based >> on some idea of requirements for the solution to be worked out >> (according to charter items). Specifically, the effects of having a >> "Mobile ISP" vs. "ISP-independent mobile home networks", the >> implications of that for the global BGP tables, how likely it is to >> get custom agreements between a mobility provider and ISPs it (or its >> customers) uses, etc. >> >> 3) Route optimization - "Performance" as Marcelo called it - avoiding >> long tunneling (geographically) - or avoiding expensive links. This >> is what we have discussed so far, and we need a stronger boundary so >> that we can define what is to be solved in these specific >> circumstances. Otherwise this walks down the road toward many other >> long-standing issues. My view is that having a good list of >> requirements for the RO situation of interest would be helpful here. >> >> 4) Aviation - question of "if" to use Mobile IP... NEMO base does use >> it because it made sense. It's possible we have another deployment >> case where it does not make sense, but we still want a solution for >> Network Mobility. However, we have to be careful here. >> There are some general network mobility problems.. such as >> multiple ISPs, having high-cost links, and how/whether to inject >> routes into the BGP tables. I believe Terry already gave us a list of >> requirements for this type of situation - can we review that? >> >> 5) Regarding HAHA - As Pascal mentioned, this wasn't supposed to be >> "the only" or even "the" solution for RO. It is simply something that >> addressed a shown need, and so I considered it to be something that >> could be added for future work. But according to the list items >> above, the group is not including or excluding any certain solution >> at this point. We need more definition of what and how to solve, and >> the implications of various approaches first. I would like to hear >> the RO-analysis authors chime in on this one. >> >> Besides Aviation, I have asked numerous times for anyone who is >> actually deploying NEMO or NEMO-like technology to give us industry >> input for requirements. Aside from aviation, I have heard a little >> bit regarding Japanese auto makers, but not much else. I also used to >> know things about some large cell phone makers that might be doing >> these things, but never enough to make a good list of requirements. >> >> Remember, our goal here is to reshape the charter to solve problems >> so that NEMO can be deployed. If there are deployments that are >> facing these issues, they can be brought forward to be studied at >> this phase. >> >> In conclusion, I would like to have a bit more discussion, and then >> maybe people can offer suggestions on how specifically to reword >> charter language and/or change milestones so that these things can be >> accomplished. > > From nemo-bounces@ietf.org Mon May 01 14:13:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Facu6-0008Bu-JX; Mon, 01 May 2006 14:13:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Facu4-0008Bp-Ov for nemo@ietf.org; Mon, 01 May 2006 14:13:48 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Facu2-0005q8-Bc for nemo@ietf.org; Mon, 01 May 2006 14:13:48 -0400 Message-ID: <01f301c66d4b$b920d7f0$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: Date: Mon, 1 May 2006 11:19:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [nemo] Comments on Proposed New Charter X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Comments on the proposed new charter. I'm sorry it has taken so long. The first five paragraphs seem like they are taken more or less from the old charter with very little thought given to what the WG intends to accomplish in the future. For example, >The WG will take a stepwise approach by standardizing some basic >support mechanisms based on the bidirectional tunneling approach, and >at the same time study the possible approaches and issues with >providing more optimal routing than can be had with (potentially > nested) tunneling. However, the WG is not chartered to actually > standardize a solution to such route optimization for mobile networks > at this point in time. But later the text says that a route optimization will, in fact, be standardized. The introduction to the charter should be more specific to what the WG intends to accomplish in the next phase. It can have some words about what was accomplished and how the WG intends to build on that, but it shouldn't include any constraints or assumptions under which the previous charter was developed, if those constraints or assumptions have changed. IMO, I think it would be useful at this time to lift the constraint that the WG only study bidirectional tunneling based solutions which utilize MIP signaling. In particular, there is at least one deployment case (Connexion) that needs a route optimized solution which might not be best served by RFC 3963. In general, I think it would be worthwhile to explicitly state which cases of route optimization are considered to be sufficiently well-enough understood that they will be included in work and which cases are still imperfectly understood and are rather topics for IRTF. This would not only help focus the charter, but also give some impetus to researchers to help understand these cases. The list of WG Goals seems mostly to consist of completion of WG drafts that are currently underway. This is OK, and probably no more need be said about them since the current versions speak for themselves. There are in addition three new drafts that are listed in the Goals, one on route optimization, one on MNN visibility, and one on (n,n,n) ingress filtering. But the body of the charter says very little about what these drafts are about. The discussion of route optimization is, as mentioned, contradictory and somewhat vague, the discussion of MNN visibility is fairly generic, and AFICT, there is no discussion of (n,n,n) ingress filtering. I am very much in favor of making WG charters very specific. It helps to avoid ambiguity about what the WG is intending to accomplish, and also helps focus the energy of the WG and avoid having it become distracted by other proposals that tend to pop up, until the originally promised work is completed. Therefore, I would recommend that the charter include a bulleted list with three items corresponding to each of these new drafts, with each item giving a concise but complete description of what the promised draft is intended to accomplish. If there are existing individual drafts that cover these, the descriptions can be based on the individual drafts. Also, it might be helpful to be more specific about the goals and their timing. Rather than just a single goal, have a list that correspond to the process: 00 WG draft selected by this time, WG last call by this time, submission to IESG by this time. Hope that helps. jak From nemo-bounces@ietf.org Mon May 01 14:24:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fad4c-00069e-Bu; Mon, 01 May 2006 14:24:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fad4a-00067I-LR for nemo@ietf.org; Mon, 01 May 2006 14:24:40 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fad4Y-000617-8d for nemo@ietf.org; Mon, 01 May 2006 14:24:40 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id NAA01137; Mon, 1 May 2006 13:24:30 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k41IOTr28663; Mon, 1 May 2006 11:24:29 -0700 (PDT) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 May 2006 11:24:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Rewording of RO work in the charter Date: Mon, 1 May 2006 11:24:28 -0700 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21BFDB@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Rewording of RO work in the charter Thread-Index: AcZtPRifRXJ/vC3YQiuf4FZtt/aTIQADnsTA From: "Davis, Terry L" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 01 May 2006 18:24:28.0822 (UTC) FILETIME=[7BC70360:01C66D4C] X-Spam-Score: 0.0 (/) X-Scan-Signature: cdb443e3957ca9b4c5b55e78cfcf4b26 Cc: ml-nemo WG , "T.J. Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Marcelo To me it is preferable to be able to use one consistent design approach = regardless of the onboard domain (air traffic control, airline = operations, passenger services). But it is certainly conceivable that = for instance multi-homing and seamless hand off could be relaxed for = airline operations and passenger services. And definitely the routing solutions may be different (i.e. the = relatively small size of a closed aviation network allows consideration = of technologies that may scale adequately for the global Internet). Take care Terry > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] > Sent: Monday, May 01, 2006 9:23 AM > To: Davis, Terry L > Cc: ml-nemo WG; T.J. Kniveton > Subject: Re: [nemo] Rewording of RO work in the charter >=20 > Hi Terry, >=20 > I have been reading the email that you sent to the ppml list about > aviation requirements and PI addressing (which was very clarifiyng = BTW) > and i have another question about the requirements below. In > particular, you seem to have 3 different networks on board... does all > the requirements affect all the three networks? because i mean for > instance in the case of the closed network, i guess that it is easier > to provide some of the features since the peers are clearly located = and > cannot be anywhere in the global internet and any solution would only > affect the close network/routing system... >=20 >=20 > thanks, it is a really interesting problem statement this one that you > have here >=20 > regards, marcelo >=20 > El 29/04/2006, a las 7:45, Davis, Terry L escribi=F3: >=20 > > T.J. > > > > You'll probably wish that you hadn't asked for this... > > > > These would be our ideal mobility solution. I realize that meeting = all > > of these is probably an extreme stretch. > > > > Take care > > Terry > > > > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > Generally the aviation mobility requirements are: > > > > 1- Ability to "dock" with numerous Internet service providers = utilizing > > different media; satellite (KU & L), EVDO, 802.11/802.16 airport; > > hardwired Ethernet "gatelink". > > > > 2- Ability to be multihomed to different providers over different = links > > simultaneously. The desired aircraft state will be to have two = links > > active always. > > > > 3- Ability to assign traffic for specific providers links only = (safety > > or operational certified providers) > > > > 4- Ability to re-profile traffic to match available link capacity = and > > constraints when handing off between links. > > > > 5- Ability to seamlessly hand off existing network connections = without > > dropping the session (we do this today). > > > > 6- Ability to maintain security through link hand off. > > > > 7- Ability to continue to receive multicast traffic after hand off. > > > > 8- Route optimization such that on hand off to a new link, > > connection/session routing is optimized to the new ground site. > > > > 9- Ability to maintain QoS on hand off with the capacity of the new > > link > > (You may hand off to a link with a smaller capacity or higher error > > rate > > or from an EVDO low latency link to a satellite high latency link) > > > > 10- Ability to support both IP-v6 and IP-v4 mobile platforms from an > > IP-v6 network. > > > > 11- Ability to receive priority multicast/broadcast messages. > > > > 12- Ability to establish connections to multiple onboard networks = over > > a > > single link and hand off them simultaneously. (We expect the = aircraft > > to have at three independent onboard isolated networks; air traffic > > control, airline operations, and passenger services. > > > > 13- Ability to initiate encrypted tunnels on all links with IPSec > > before > > passing traffic. > > > > > >> -----Original Message----- > >> From: T.J. Kniveton [mailto:tj@kniveton.com] > >> Sent: Friday, April 21, 2006 3:13 AM > >> To: ml-nemo WG > >> Subject: [nemo] Rewording of RO work in the charter > >> > >> Folks, > >> > >> I have been watching the conversation started by Marcelo a couple = of > >> weeks ago, regarding the rewording of the (n,n,n) item in the > >> charter. (Sorry I haven't been commenting lately). > >> > >> We need to figure out how to massage the concepts being batted = around > >> so that we have something tractable that we can work on and = complete. > >> From the discussion so far, I tend to think: > >> > >> 1) We need somewhat more concrete idea of the requirements for the > >> type of situation we want to solve. I agree with Andrew that we = don't > >> want to get bogged down in this, and I do believe Terry gave us a > >> list for the Conexion scenario quite a while ago. Perhaps he or > >> Andrew could give an updated list. > >> > >> 2) We need a bit more analysis still on the RO problem space, based > >> on some idea of requirements for the solution to be worked out > >> (according to charter items). Specifically, the effects of having a > >> "Mobile ISP" vs. "ISP-independent mobile home networks", the > >> implications of that for the global BGP tables, how likely it is to > >> get custom agreements between a mobility provider and ISPs it (or = its > >> customers) uses, etc. > >> > >> 3) Route optimization - "Performance" as Marcelo called it - = avoiding > >> long tunneling (geographically) - or avoiding expensive links. This > >> is what we have discussed so far, and we need a stronger boundary = so > >> that we can define what is to be solved in these specific > >> circumstances. Otherwise this walks down the road toward many other > >> long-standing issues. My view is that having a good list of > >> requirements for the RO situation of interest would be helpful = here. > >> > >> 4) Aviation - question of "if" to use Mobile IP... NEMO base does = use > >> it because it made sense. It's possible we have another deployment > >> case where it does not make sense, but we still want a solution for > >> Network Mobility. However, we have to be careful here. > >> There are some general network mobility problems.. such as > >> multiple ISPs, having high-cost links, and how/whether to inject > >> routes into the BGP tables. I believe Terry already gave us a list = of > >> requirements for this type of situation - can we review that? > >> > >> 5) Regarding HAHA - As Pascal mentioned, this wasn't supposed to be > >> "the only" or even "the" solution for RO. It is simply something = that > >> addressed a shown need, and so I considered it to be something that > >> could be added for future work. But according to the list items > >> above, the group is not including or excluding any certain solution > >> at this point. We need more definition of what and how to solve, = and > >> the implications of various approaches first. I would like to hear > >> the RO-analysis authors chime in on this one. > >> > >> Besides Aviation, I have asked numerous times for anyone who is > >> actually deploying NEMO or NEMO-like technology to give us industry > >> input for requirements. Aside from aviation, I have heard a little > >> bit regarding Japanese auto makers, but not much else. I also used = to > >> know things about some large cell phone makers that might be doing > >> these things, but never enough to make a good list of requirements. > >> > >> Remember, our goal here is to reshape the charter to solve problems > >> so that NEMO can be deployed. If there are deployments that are > >> facing these issues, they can be brought forward to be studied at > >> this phase. > >> > >> In conclusion, I would like to have a bit more discussion, and then > >> maybe people can offer suggestions on how specifically to reword > >> charter language and/or change milestones so that these things can = be > >> accomplished. > > > > >=20 From nemo-bounces@ietf.org Mon May 01 14:44:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FadO4-00059X-Ev; Mon, 01 May 2006 14:44:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FadO2-00059S-Va for nemo@ietf.org; Mon, 01 May 2006 14:44:46 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FadO2-00074a-8q for nemo@ietf.org; Mon, 01 May 2006 14:44:46 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id BE30DD4C5C; Mon, 1 May 2006 20:44:40 +0200 (CEST) Received: from [163.117.203.225] (unknown [163.117.203.225]) by smtp01.uc3m.es (Postfix) with ESMTP id 107B9D4C4B; Mon, 1 May 2006 20:44:39 +0200 (CEST) In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21BFDB@XCH-NW-8V1.nw.nos.boeing.com> References: <0D090F1E0F5536449C7E6527AFFA280A21BFDB@XCH-NW-8V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Rewording of RO work in the charter Date: Mon, 1 May 2006 21:44:38 +0300 To: "Davis, Terry L" X-Mailer: Apple Mail (2.623) X-Spam-Score: 0.0 (/) X-Scan-Signature: 72dbfff5c6b8ad2b1b727c13be042129 Cc: ml-nemo WG , "T.J. Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org El 01/05/2006, a las 21:24, Davis, Terry L escribi=F3: > Marcelo > > To me it is preferable to be able to use one consistent design=20 > approach regardless of the onboard domain (air traffic control,=20 > airline operations, passenger services). i can see that such approach would provide benefits since it would be=20 simpler > But it is certainly conceivable that for instance multi-homing and=20 > seamless hand off could be relaxed for airline operations and=20 > passenger services. > yes i would suggest to identify the requirements for the different type of=20= on board networks and also note explicitly that it would be a plus if=20 all the capabilities could be provided by a single mechanism regards, marcelo > And definitely the routing solutions may be different (i.e. the=20 > relatively small size of a closed aviation network allows=20 > consideration of technologies that may scale adequately for the global=20= > Internet). > > Take care > Terry > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Monday, May 01, 2006 9:23 AM >> To: Davis, Terry L >> Cc: ml-nemo WG; T.J. Kniveton >> Subject: Re: [nemo] Rewording of RO work in the charter >> >> Hi Terry, >> >> I have been reading the email that you sent to the ppml list about >> aviation requirements and PI addressing (which was very clarifiyng=20 >> BTW) >> and i have another question about the requirements below. In >> particular, you seem to have 3 different networks on board... does = all >> the requirements affect all the three networks? because i mean for >> instance in the case of the closed network, i guess that it is easier >> to provide some of the features since the peers are clearly located=20= >> and >> cannot be anywhere in the global internet and any solution would only >> affect the close network/routing system... >> >> >> thanks, it is a really interesting problem statement this one that = you >> have here >> >> regards, marcelo >> >> El 29/04/2006, a las 7:45, Davis, Terry L escribi=F3: >> >>> T.J. >>> >>> You'll probably wish that you hadn't asked for this... >>> >>> These would be our ideal mobility solution. I realize that meeting=20= >>> all >>> of these is probably an extreme stretch. >>> >>> Take care >>> Terry >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> Generally the aviation mobility requirements are: >>> >>> 1- Ability to "dock" with numerous Internet service providers=20 >>> utilizing >>> different media; satellite (KU & L), EVDO, 802.11/802.16 airport; >>> hardwired Ethernet "gatelink". >>> >>> 2- Ability to be multihomed to different providers over different=20 >>> links >>> simultaneously. The desired aircraft state will be to have two = links >>> active always. >>> >>> 3- Ability to assign traffic for specific providers links only=20 >>> (safety >>> or operational certified providers) >>> >>> 4- Ability to re-profile traffic to match available link capacity = and >>> constraints when handing off between links. >>> >>> 5- Ability to seamlessly hand off existing network connections=20 >>> without >>> dropping the session (we do this today). >>> >>> 6- Ability to maintain security through link hand off. >>> >>> 7- Ability to continue to receive multicast traffic after hand off. >>> >>> 8- Route optimization such that on hand off to a new link, >>> connection/session routing is optimized to the new ground site. >>> >>> 9- Ability to maintain QoS on hand off with the capacity of the new >>> link >>> (You may hand off to a link with a smaller capacity or higher error >>> rate >>> or from an EVDO low latency link to a satellite high latency link) >>> >>> 10- Ability to support both IP-v6 and IP-v4 mobile platforms from an >>> IP-v6 network. >>> >>> 11- Ability to receive priority multicast/broadcast messages. >>> >>> 12- Ability to establish connections to multiple onboard networks=20 >>> over >>> a >>> single link and hand off them simultaneously. (We expect the=20 >>> aircraft >>> to have at three independent onboard isolated networks; air traffic >>> control, airline operations, and passenger services. >>> >>> 13- Ability to initiate encrypted tunnels on all links with IPSec >>> before >>> passing traffic. >>> >>> >>>> -----Original Message----- >>>> From: T.J. Kniveton [mailto:tj@kniveton.com] >>>> Sent: Friday, April 21, 2006 3:13 AM >>>> To: ml-nemo WG >>>> Subject: [nemo] Rewording of RO work in the charter >>>> >>>> Folks, >>>> >>>> I have been watching the conversation started by Marcelo a couple = of >>>> weeks ago, regarding the rewording of the (n,n,n) item in the >>>> charter. (Sorry I haven't been commenting lately). >>>> >>>> We need to figure out how to massage the concepts being batted=20 >>>> around >>>> so that we have something tractable that we can work on and=20 >>>> complete. >>>> =46rom the discussion so far, I tend to think: >>>> >>>> 1) We need somewhat more concrete idea of the requirements for the >>>> type of situation we want to solve. I agree with Andrew that we=20 >>>> don't >>>> want to get bogged down in this, and I do believe Terry gave us a >>>> list for the Conexion scenario quite a while ago. Perhaps he or >>>> Andrew could give an updated list. >>>> >>>> 2) We need a bit more analysis still on the RO problem space, based >>>> on some idea of requirements for the solution to be worked out >>>> (according to charter items). Specifically, the effects of having a >>>> "Mobile ISP" vs. "ISP-independent mobile home networks", the >>>> implications of that for the global BGP tables, how likely it is to >>>> get custom agreements between a mobility provider and ISPs it (or=20= >>>> its >>>> customers) uses, etc. >>>> >>>> 3) Route optimization - "Performance" as Marcelo called it -=20 >>>> avoiding >>>> long tunneling (geographically) - or avoiding expensive links. This >>>> is what we have discussed so far, and we need a stronger boundary = so >>>> that we can define what is to be solved in these specific >>>> circumstances. Otherwise this walks down the road toward many other >>>> long-standing issues. My view is that having a good list of >>>> requirements for the RO situation of interest would be helpful = here. >>>> >>>> 4) Aviation - question of "if" to use Mobile IP... NEMO base does=20= >>>> use >>>> it because it made sense. It's possible we have another deployment >>>> case where it does not make sense, but we still want a solution for >>>> Network Mobility. However, we have to be careful here. >>>> There are some general network mobility problems.. such as >>>> multiple ISPs, having high-cost links, and how/whether to inject >>>> routes into the BGP tables. I believe Terry already gave us a list=20= >>>> of >>>> requirements for this type of situation - can we review that? >>>> >>>> 5) Regarding HAHA - As Pascal mentioned, this wasn't supposed to be >>>> "the only" or even "the" solution for RO. It is simply something=20 >>>> that >>>> addressed a shown need, and so I considered it to be something that >>>> could be added for future work. But according to the list items >>>> above, the group is not including or excluding any certain solution >>>> at this point. We need more definition of what and how to solve, = and >>>> the implications of various approaches first. I would like to hear >>>> the RO-analysis authors chime in on this one. >>>> >>>> Besides Aviation, I have asked numerous times for anyone who is >>>> actually deploying NEMO or NEMO-like technology to give us industry >>>> input for requirements. Aside from aviation, I have heard a little >>>> bit regarding Japanese auto makers, but not much else. I also used=20= >>>> to >>>> know things about some large cell phone makers that might be doing >>>> these things, but never enough to make a good list of requirements. >>>> >>>> Remember, our goal here is to reshape the charter to solve problems >>>> so that NEMO can be deployed. If there are deployments that are >>>> facing these issues, they can be brought forward to be studied at >>>> this phase. >>>> >>>> In conclusion, I would like to have a bit more discussion, and then >>>> maybe people can offer suggestions on how specifically to reword >>>> charter language and/or change milestones so that these things can=20= >>>> be >>>> accomplished. >>> >>> >> > From nemo-bounces@ietf.org Tue May 02 09:02:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FauWM-0001Xh-60; Tue, 02 May 2006 09:02:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FauWK-0001Xb-UI for nemo@ietf.org; Tue, 02 May 2006 09:02:28 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FauWJ-0002a4-Jz for nemo@ietf.org; Tue, 02 May 2006 09:02:28 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42D2Of8013731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 2 May 2006 06:02:26 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k42D2MIu019805 for ; Tue, 2 May 2006 06:02:23 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 2 May 2006 06:02:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 2 May 2006 06:02:23 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0025E0114@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Extensions to NEMOv4 base for the Charter. Thread-Index: AcZtSw1PwC0Iw36/T4qsg1j2K5yyCgAnJ5ng From: "Tsirtsis, George" To: X-OriginalArrivalTime: 02 May 2006 13:02:22.0061 (UTC) FILETIME=[A68B11D0:01C66DE8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [nemo] Extensions to NEMOv4 base for the Charter. X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org In a recent discussion on the mailing list I suggested that we should define FA support and dynamic prefix allocation for the NEMOv4 base solution. A number of people at the time seemed to be supportive of the idea and I am in the process of writing a draft on the subject. Could we extend the charter to cover these issues? Thanks George From nemo-bounces@ietf.org Tue May 02 12:01:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaxJ8-0007U1-Du; Tue, 02 May 2006 12:01:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaxJ7-0007Tm-EH for nemo@ietf.org; Tue, 02 May 2006 12:01:01 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaxJ7-0001tL-6r for nemo@ietf.org; Tue, 02 May 2006 12:01:01 -0400 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP id 4482731; Tue, 02 May 2006 12:00:50 -0400 In-Reply-To: <01f301c66d4b$b920d7f0$026115ac@dcml.docomolabsusa.com> References: <01f301c66d4b$b920d7f0$026115ac@dcml.docomolabsusa.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <98963331-0468-40E4-9A9F-53951B7D6FA4@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: [nemo] Comments on Proposed New Charter Date: Tue, 2 May 2006 12:00:59 -0400 To: James Kempf X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hello; Are these comments on the "charter2" of March 22nd ? Or is there a newer one ? Regards Marshall Eubanks On May 1, 2006, at 2:19 PM, James Kempf wrote: > Comments on the proposed new charter. I'm sorry it has taken so long. > > The first five paragraphs seem like they are taken more or less > from the old charter with very little thought given to what the WG > intends to accomplish in the future. For example, > >> The WG will take a stepwise approach by standardizing some basic >> support mechanisms based on the bidirectional tunneling approach, and >> at the same time study the possible approaches and issues with >> providing more optimal routing than can be had with (potentially >> nested) tunneling. However, the WG is not chartered to actually >> standardize a solution to such route optimization for mobile networks >> at this point in time. > > But later the text says that a route optimization will, in fact, be > standardized. The introduction to the charter should be more > specific to what the WG intends to accomplish in the next phase. It > can have some words about what was accomplished and how the WG > intends to build on that, but it shouldn't include any constraints > or assumptions under which the previous charter was developed, if > those constraints or assumptions have changed. > > IMO, I think it would be useful at this time to lift the constraint > that the WG only study bidirectional tunneling based solutions > which utilize MIP signaling. In particular, there is at least one > deployment case (Connexion) that needs a route optimized solution > which might not be best served by RFC 3963. In general, I think it > would be worthwhile to explicitly state which cases of route > optimization are considered to be sufficiently well-enough > understood that they will be included in work and which cases are > still imperfectly understood and are rather topics for IRTF. This > would not only help focus the charter, but also give some impetus > to researchers to help understand these cases. > > The list of WG Goals seems mostly to consist of completion of WG > drafts that are currently underway. This is OK, and probably no > more need be said about them since the current versions speak for > themselves. There are in addition three new drafts that are listed > in the Goals, one on route optimization, one on MNN visibility, and > one on (n,n,n) ingress filtering. But the body of the charter says > very little about what these drafts are about. The discussion of > route optimization is, as mentioned, contradictory and somewhat > vague, the discussion of MNN visibility is fairly generic, and > AFICT, there is no discussion of (n,n,n) ingress filtering. > > I am very much in favor of making WG charters very specific. It > helps to avoid ambiguity about what the WG is intending to > accomplish, and also helps focus the energy of the WG and avoid > having it become distracted by other proposals that tend to pop up, > until the originally promised work is completed. Therefore, I would > recommend that the charter include a bulleted list with three items > corresponding to each of these new drafts, with each item giving a > concise but complete description of what the promised draft is > intended to accomplish. If there are existing individual drafts > that cover these, the descriptions can be based on the individual > drafts. Also, it might be helpful to be more specific about the > goals and their timing. Rather than just a single goal, have a list > that correspond to the process: 00 WG draft selected by this time, > WG last call by this time, submission to IESG by this time. > > Hope that helps. > > jak > > > > From nemo-bounces@ietf.org Tue May 02 12:51:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fay6H-0002vN-Es; Tue, 02 May 2006 12:51:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fay6F-0002vI-VF for nemo@ietf.org; Tue, 02 May 2006 12:51:47 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fay6E-0003uP-1c for nemo@ietf.org; Tue, 02 May 2006 12:51:47 -0400 Message-ID: <03a601c66e09$6fc80ba0$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Marshall Eubanks" References: <01f301c66d4b$b920d7f0$026115ac@dcml.docomolabsusa.com> <98963331-0468-40E4-9A9F-53951B7D6FA4@multicasttech.com> Subject: Re: [nemo] Comments on Proposed New Charter Date: Tue, 2 May 2006 09:57:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I got the charter on 4/6 via the Mobility Directorate. I don't know if it has been reissued, but I haven't heard anything to that effect. jak ----- Original Message ----- From: "Marshall Eubanks" To: "James Kempf" Cc: Sent: Tuesday, May 02, 2006 9:00 AM Subject: Re: [nemo] Comments on Proposed New Charter > Hello; > > Are these comments on the "charter2" of March 22nd ? Or is there a newer > one ? > > Regards > Marshall Eubanks > > On May 1, 2006, at 2:19 PM, James Kempf wrote: > >> Comments on the proposed new charter. I'm sorry it has taken so long. >> >> The first five paragraphs seem like they are taken more or less from the >> old charter with very little thought given to what the WG intends to >> accomplish in the future. For example, >> >>> The WG will take a stepwise approach by standardizing some basic >>> support mechanisms based on the bidirectional tunneling approach, and >>> at the same time study the possible approaches and issues with >>> providing more optimal routing than can be had with (potentially >>> nested) tunneling. However, the WG is not chartered to actually >>> standardize a solution to such route optimization for mobile networks >>> at this point in time. >> >> But later the text says that a route optimization will, in fact, be >> standardized. The introduction to the charter should be more specific to >> what the WG intends to accomplish in the next phase. It can have some >> words about what was accomplished and how the WG intends to build on >> that, but it shouldn't include any constraints or assumptions under >> which the previous charter was developed, if those constraints or >> assumptions have changed. >> >> IMO, I think it would be useful at this time to lift the constraint that >> the WG only study bidirectional tunneling based solutions which utilize >> MIP signaling. In particular, there is at least one deployment case >> (Connexion) that needs a route optimized solution which might not be >> best served by RFC 3963. In general, I think it would be worthwhile to >> explicitly state which cases of route optimization are considered to be >> sufficiently well-enough understood that they will be included in work >> and which cases are still imperfectly understood and are rather topics >> for IRTF. This would not only help focus the charter, but also give some >> impetus to researchers to help understand these cases. >> >> The list of WG Goals seems mostly to consist of completion of WG drafts >> that are currently underway. This is OK, and probably no more need be >> said about them since the current versions speak for themselves. There >> are in addition three new drafts that are listed in the Goals, one on >> route optimization, one on MNN visibility, and one on (n,n,n) ingress >> filtering. But the body of the charter says very little about what these >> drafts are about. The discussion of route optimization is, as mentioned, >> contradictory and somewhat vague, the discussion of MNN visibility is >> fairly generic, and AFICT, there is no discussion of (n,n,n) ingress >> filtering. >> >> I am very much in favor of making WG charters very specific. It helps to >> avoid ambiguity about what the WG is intending to accomplish, and also >> helps focus the energy of the WG and avoid having it become distracted >> by other proposals that tend to pop up, until the originally promised >> work is completed. Therefore, I would recommend that the charter include >> a bulleted list with three items corresponding to each of these new >> drafts, with each item giving a concise but complete description of what >> the promised draft is intended to accomplish. If there are existing >> individual drafts that cover these, the descriptions can be based on the >> individual drafts. Also, it might be helpful to be more specific about >> the goals and their timing. Rather than just a single goal, have a list >> that correspond to the process: 00 WG draft selected by this time, WG >> last call by this time, submission to IESG by this time. >> >> Hope that helps. >> >> jak >> >> >> >> > > From nemo-bounces@ietf.org Tue May 02 12:51:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fay6K-0002yW-OR; Tue, 02 May 2006 12:51:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fay6I-0002wW-U5 for nemo@ietf.org; Tue, 02 May 2006 12:51:50 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fay6C-0003uY-R4 for nemo@ietf.org; Tue, 02 May 2006 12:51:50 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k42H8cO3005442; Tue, 2 May 2006 10:08:42 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k42H9HqG001766; Tue, 2 May 2006 12:09:17 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 833C3865980; Tue, 2 May 2006 18:51:35 +0200 (CEST) Message-ID: <44578E17.2060504@motorola.com> Date: Tue, 02 May 2006 18:51:35 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF0025E0114@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0025E0114@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Tsirtsis, George wrote: > In a recent discussion on the mailing list I suggested that we should > define FA support and dynamic prefix allocation for the NEMOv4 base > solution. > > A number of people at the time seemed to be supportive of the idea > and I am in the process of writing a draft on the subject. Could we > extend the charter to cover these issues? I agree to request extending the Charter to deal with FA support for NEMOv4. Maybe that could be simply put like: "produce IPv4 NEMO protocol based on Mobile IPv4 (basic support, FA support and prefix allocation from the foreign and/or home networks)." Or similar? Just some short phrasing. Alex From nemo-bounces@ietf.org Tue May 02 16:12:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1E2-0002rM-9I; Tue, 02 May 2006 16:12:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1E1-0002rH-1J for nemo@ietf.org; Tue, 02 May 2006 16:12:01 -0400 Received: from motgate7.mot.com ([129.188.136.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb1Dv-0005Zk-V8 for nemo@ietf.org; Tue, 02 May 2006 16:12:01 -0400 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate7.mot.com (8.12.11/Motgate7) with ESMTP id k42KhBpA025157; Tue, 2 May 2006 13:43:15 -0700 (MST) Received: from [10.129.40.10] ([10.129.40.10]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k42KS4LM006429; Tue, 2 May 2006 15:28:05 -0500 (CDT) Message-ID: <4457BCD9.70400@motorola.com> Date: Tue, 02 May 2006 22:11:05 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Re: is global HAHA so complex? References: <7892795E1A87F04CADFCCF41FADD00FC021A9C9E@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC021A9C9E@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: marcelo bagnulo braun , nemo@ietf.org, Henrik Levkowetz , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Pascal Thubert (pthubert) wrote: >>> >>> >>>> Anyway, i still argue that we need to flesh out the >>>> requirements > that >>>> gloablly moving networks have in order to figure out which >>>> solution are best suited for them >>> Yes. That's it exactly. If we don't have a clear picture of the >>> potential users, >> after all this long thread, i think that the case of globally >> moving networks on board of airplanes or other transportation >> mechanisms are a use case for which there is interest and that we >> could try to work on a solution for that. >> > [Pascal] Yes, this is already in the NEMO requirements :) > > " # Networks of sensors and computers deployed in vehicles: vehicles > are increasingly embedded with a number of processing units for > safety and ease of driving reasons, as advocated by ITS (Intelligent > Transportation Systems) applications ([9], CALM - Medium and Long > Range, High Speed, Air Interfaces parameters and protocols for > broadcast, point to point, vehicle to vehicle, and vehicle to point > communication in the ITS sector - Networking Protocol - Complementary > Element, February 2005., [8]Ernst, T. and K. Uehara, Connecting > Automobiles to the Internet, November 2002.). > > # Access networks deployed in public transportation (buses, trains, > taxis, aircrafts): they provide Internet access to IP devices carried > by passengers: laptop, camera, mobile phone: host mobility within > network mobility or PANs: network mobility within network mobility, > i.e. nested mobility (see [4]Ernst, T. and H. Lach, Network Mobility > Support Terminology, February 2005. for the definition of nested > mobility). " > > But we can move forward and detail more if you wish. > > Note that for devices like cars, they expect to rely on cheap common > devices such as 4G phones with some application capability built in > (like JAVA or .net). As a result, you can not do most of the > vehicules if you do not include 4G phones... Well, there are devices that do WVAN and one can't place phone calls on them; and pertain to vehicular stuff. They're supposed to be cheap and common. HSDPA/HSUPA, wibro, wimax, and something called "something Air" used in Japan. In these cases they're just modems. Alex From nemo-bounces@ietf.org Tue May 02 16:19:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1LM-0004IS-B7; Tue, 02 May 2006 16:19:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1LK-0004Hh-P1 for nemo@ietf.org; Tue, 02 May 2006 16:19:34 -0400 Received: from ftpbox.mot.com ([129.188.136.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb1LJ-0005p5-GC for nemo@ietf.org; Tue, 02 May 2006 16:19:34 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by ftpbox.mot.com (8.12.11/Motgate7) with ESMTP id k42KOore015668; Tue, 2 May 2006 15:24:50 -0500 (CDT) Received: from [10.129.40.10] ([10.129.40.10]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k42KWZuA020143; Tue, 2 May 2006 15:32:36 -0500 (CDT) Message-ID: <4457BEAE.9000402@motorola.com> Date: Tue, 02 May 2006 22:18:54 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" Subject: Re: [nemo] Re: is global HAHA so complex? References: <7892795E1A87F04CADFCCF41FADD00FC021F1A96@xmb-ams-337.emea.cisco.com> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC021F1A96@xmb-ams-337.emea.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: marcelo bagnulo braun , nemo@ietf.org, Henrik Levkowetz , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Pascal Thubert (pthubert) wrote: > Hi Marcelo; > > There's a lot of good sense in your words; and I'd agree in general > terms. > > Now please consider this angle: the design point we want to fix in > MIP6 is the Home Link, which is a single point of failure, a > bottleneck and anchors Home at a given location. We want to replace > the ND based operation by a protocol over IP and enable a real (site > or HA) redundancy using routing protocols. Pascal, when they designed MIP they tried to address the locator-id problem too. For some reason that led to the home link being fixed and people complaining about triangular routing which led to RO. IF there's something now to be fixed it's the RO, not the locator-id problem, which is dealt with by shim6 anew, hoping that RO will be obtained as a side effect. > In other words, we want to fix MIP problems within MIP. Not to force > ISP to deploy multiple prefixes, and either SHIM6 or PRESENCE to fix > a limitation of another protocol. I do not think that HAHA breaks the > end to end principle. I think it obeys another principle, Give back > to Cesar what is Cesar's, fix a problem where it occurs. SO who's Cesar and what does he own? Alex From nemo-bounces@ietf.org Tue May 02 16:28:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1TU-0003XX-Iy; Tue, 02 May 2006 16:28:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb1TT-0003U4-4D for nemo@ietf.org; Tue, 02 May 2006 16:27:59 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb1TN-0006K6-1P for nemo@ietf.org; Tue, 02 May 2006 16:27:59 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k42KijtQ027800; Tue, 2 May 2006 13:44:46 -0700 (MST) Received: from [10.129.40.10] ([10.129.40.10]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k42KfwJR007395; Tue, 2 May 2006 15:41:59 -0500 (CDT) Message-ID: <4457C0C0.2020108@motorola.com> Date: Tue, 02 May 2006 22:27:44 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: James Kempf Subject: Re: [nemo] Comments on Proposed New Charter References: <01f301c66d4b$b920d7f0$026115ac@dcml.docomolabsusa.com> In-Reply-To: <01f301c66d4b$b920d7f0$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org James Kempf wrote: > Comments on the proposed new charter. I'm sorry it has taken so long. > > > > The first five paragraphs seem like they are taken more or less from > the old charter with very little thought given to what the WG intends > to accomplish in the future. For example, > >> The WG will take a stepwise approach by standardizing some basic >> support mechanisms based on the bidirectional tunneling approach, >> and at the same time study the possible approaches and issues with >> providing more optimal routing than can be had with (potentially >> nested) tunneling. However, the WG is not chartered to actually >> standardize a solution to such route optimization for mobile >> networks at this point in time. > > But later the text says that a route optimization will, in fact, be > standardized. The introduction to the charter should be more specific > to what the WG intends to accomplish in the next phase. It can have > some words about what was accomplished and how the WG intends to > build on that, but it shouldn't include any constraints or > assumptions under which the previous charter was developed, if those > constraints or assumptions have changed. I agree, I think the initial part of the charter should be re-written to say that 3963 may not be sufficient in some cases, and some specific needs for enhancements exist. But that initial part should still mention work on basic network mobility support - for IPv4. Alex From nemo-bounces@ietf.org Tue May 02 18:25:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb3JC-0003cn-MN; Tue, 02 May 2006 18:25:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb3JA-0003ci-NO for nemo@ietf.org; Tue, 02 May 2006 18:25:28 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb3J9-0003XV-Eb for nemo@ietf.org; Tue, 02 May 2006 18:25:28 -0400 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 02 May 2006 15:25:28 -0700 X-IronPort-AV: i="4.05,81,1146466800"; d="scan'208"; a="321445811:sNHT29469444" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k42MPQhA002007; Tue, 2 May 2006 15:25:26 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 May 2006 15:25:20 -0700 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 Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Tue, 2 May 2006 15:25:18 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5201C0AB78@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZuCMZNwc4JDHL7SrenX4QP/19lHwAK/XRw From: "Kent Leung \(kleung\)" To: "Alexandru Petrescu" , "Tsirtsis, George" X-OriginalArrivalTime: 02 May 2006 22:25:20.0541 (UTC) FILETIME=[4C1614D0:01C66E37] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I agree with the suggestion for a work item on IPv4 based NEMO. The experiences with deployments in various markets will lead to enrichment of both IPv4 and IPv6 NEMO technologies. Especially in areas where commonalities exist. Kent > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]=20 > Sent: Tuesday, May 02, 2006 9:52 AM > To: Tsirtsis, George > Cc: nemo@ietf.org > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >=20 > Tsirtsis, George wrote: > > In a recent discussion on the mailing list I suggested that=20 > we should =20 > > define FA support and dynamic prefix allocation for the NEMOv4 base=20 > > solution. > >=20 > > A number of people at the time seemed to be supportive of=20 > the idea and=20 > > I am in the process of writing a draft on the subject.=20 > Could we extend=20 > > the charter to cover these issues? >=20 > I agree to request extending the Charter to deal with FA=20 > support for NEMOv4. Maybe that could be simply put like:=20 > "produce IPv4 NEMO protocol based on Mobile IPv4 (basic=20 > support, FA support and prefix allocation from the foreign=20 > and/or home networks)." >=20 > Or similar? Just some short phrasing. >=20 > Alex >=20 From nemo-bounces@ietf.org Tue May 02 20:25:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb5BY-0007Kp-64; Tue, 02 May 2006 20:25:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fb5BW-0007Kk-Eg for nemo@ietf.org; Tue, 02 May 2006 20:25:42 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fb5BV-0007uv-5a for nemo@ietf.org; Tue, 02 May 2006 20:25:42 -0400 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 02 May 2006 17:25:40 -0700 X-IronPort-AV: i="4.05,81,1146466800"; d="scan'208"; a="426021815:sNHT30409900" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k430Pcw3017088; Tue, 2 May 2006 17:25:40 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 2 May 2006 17:25:40 -0700 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 Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Tue, 2 May 2006 17:25:39 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5201C0AC39@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZuCMZNwc4JDHL7SrenX4QP/19lHwAK/XRwAATTqPA= From: "Kent Leung \(kleung\)" To: "Kent Leung \(kleung\)" , "Alexandru Petrescu" , "Tsirtsis, George" X-OriginalArrivalTime: 03 May 2006 00:25:40.0351 (UTC) FILETIME=[1B6DA8F0:01C66E48] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Just to clarify, I support the request for extensions to base NEMOv4... Kent=20 > -----Original Message----- > From: Kent Leung (kleung)=20 > Sent: Tuesday, May 02, 2006 3:25 PM > To: Alexandru Petrescu; Tsirtsis, George > Cc: nemo@ietf.org > Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. >=20 > I agree with the suggestion for a work item on IPv4 based=20 > NEMO. The experiences with deployments in various markets=20 > will lead to enrichment of both IPv4 and IPv6 NEMO=20 > technologies. Especially in areas where commonalities exist. >=20 > Kent >=20 > > -----Original Message----- > > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > > Sent: Tuesday, May 02, 2006 9:52 AM > > To: Tsirtsis, George > > Cc: nemo@ietf.org > > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. > >=20 > > Tsirtsis, George wrote: > > > In a recent discussion on the mailing list I suggested that > > we should > > > define FA support and dynamic prefix allocation for the=20 > NEMOv4 base=20 > > > solution. > > >=20 > > > A number of people at the time seemed to be supportive of > > the idea and > > > I am in the process of writing a draft on the subject.=20 > > Could we extend > > > the charter to cover these issues? > >=20 > > I agree to request extending the Charter to deal with FA=20 > support for=20 > > NEMOv4. Maybe that could be simply put like: > > "produce IPv4 NEMO protocol based on Mobile IPv4 (basic support, FA=20 > > support and prefix allocation from the foreign and/or home=20 > networks)." > >=20 > > Or similar? Just some short phrasing. > >=20 > > Alex > >=20 >=20 From nemo-bounces@ietf.org Wed May 03 04:26:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbCh1-0002Ao-4P; Wed, 03 May 2006 04:26:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbCgz-0002Aa-Cn for nemo@ietf.org; Wed, 03 May 2006 04:26:41 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbCgz-0003SB-0i for nemo@ietf.org; Wed, 03 May 2006 04:26:41 -0400 Received: from guest-rocq-135223.inria.fr (guest-rocq-135223.inria.fr [128.93.135.223]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k438QcU8019035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 3 May 2006 10:26:39 +0200 Date: Wed, 3 May 2006 10:27:37 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Message-Id: <20060503102737.491d94ad.thierry.ernst@inria.fr> In-Reply-To: <44578E17.2060504@motorola.com> References: <1487A357FD2ED544B8AD29E528FF9DF0025E0114@NAEX06.na.qualcomm.com> <44578E17.2060504@motorola.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 4458693F.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Dear all, Just a note, I remember v4-defenders stating not so long ago that they would just do something basic on V4 for NEMO, but now some folks are suggesting FA support, prefix allocation, etc. What is next ? I don't personaly mind work on NEMOv4 (but I don't support this), however, I do mind that the NEMO WG has a strong focus on v6, and I would rather see work on v4 and v6 taking places in SEPARATE working groups. Many people don't want to lose their time on v4 discussions. I really think that melting IPv4 and IPv6 in a single working group is at minimum confusing, and possibly damaging the message the IETF is addressing to the world (i.e. non-IETFers who follow the output of the IETF, but not the internal discussions). The only exception I see to this if v4-v6 interoperability issues, if any. PS: I was unable to participate to the IETF and the discussions on IETF mailing lists since mid-March until now (back to normal mode now, I hope), so there are a lot of important discussions in which I couldn't participate. I still need to dig back into the discussions to see what other important thread I missed. Thierry > Tsirtsis, George wrote: > > In a recent discussion on the mailing list I suggested that we should > > define FA support and dynamic prefix allocation for the NEMOv4 base > > solution. > > > > A number of people at the time seemed to be supportive of the idea > > and I am in the process of writing a draft on the subject. Could we > > extend the charter to cover these issues? > > I agree to request extending the Charter to deal with FA support for > NEMOv4. Maybe that could be simply put like: "produce IPv4 NEMO > protocol based on Mobile IPv4 (basic support, FA support and prefix > allocation from the foreign and/or home networks)." > > Or similar? Just some short phrasing. > > Alex > -- Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Wed May 03 08:50:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbGoh-0002GG-GE; Wed, 03 May 2006 08:50:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbGog-0002GB-6q for nemo@ietf.org; Wed, 03 May 2006 08:50:54 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbGof-0006jr-RG for nemo@ietf.org; Wed, 03 May 2006 08:50:54 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k43DCS1Z027335; Wed, 3 May 2006 06:12:31 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k43D54jo022466; Wed, 3 May 2006 08:05:04 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 5D815865980; Wed, 3 May 2006 14:50:49 +0200 (CEST) Message-ID: <4458A726.40404@motorola.com> Date: Wed, 03 May 2006 14:50:46 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF0025E0114@NAEX06.na.qualcomm.com> <44578E17.2060504@motorola.com> <20060503102737.491d94ad.thierry.ernst@inria.fr> In-Reply-To: <20060503102737.491d94ad.thierry.ernst@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thierry Ernst wrote: > Dear all, > > Just a note, I remember v4-defenders stating not so long ago that > they would just do something basic on V4 for NEMO, but now some folks > are suggesting FA support, prefix allocation, etc. What is next ? Next will come whatever somebody may need. With respect to the initial statement that initially there would be only the basic v4 NEMO, I still agree and still propose to have the basic support document just basic no FA and/or prefix allocation extensions. > I don't personaly mind work on NEMOv4 (but I don't support this), > however, I do mind that the NEMO WG has a strong focus on v6, and I > would rather see work on v4 and v6 taking places in SEPARATE working > groups. Many people don't want to lose their time on v4 discussions. > > > I really think that melting IPv4 and IPv6 in a single working group > is at minimum confusing, I somehow agree with you. Mainly it's good to divide work when there's too much of it. > and possibly damaging the message the IETF is addressing to the world > (i.e. non-IETFers who follow the output of the IETF, but not the > internal discussions). That looks strange to me. I don't think IETF has any single coherent message to address to the world (and that's all for the better). And there are many WGs still addressing IPv4 together with IPv6. > The only exception I see to this if v4-v6 interoperability issues, if > any. YEs, the easiest way for a MR to connect to both a v4 and a v6 infrastructures is still to have a MIP4 stack and a MIP6 stack. It's true that mip6trans tries to optimize this and use exclusively DS-MIPv6 (no MIP4) but that's still an enhancement and/or optimization. Moreover, DS-MIPv6 can does not try to accomodate some particular deployments where both a MIP4 and a MIP6 stack are used on the MR (i.e. DS-MIPv6 doesn't accommodate a v6-only HA). > PS: I was unable to participate to the IETF and the discussions on > IETF mailing lists since mid-March until now (back to normal mode > now, I hope), so there are a lot of important discussions in which I > couldn't participate. I still need to dig back into the discussions > to see what other important thread I missed. It's fine, your comments don't show any misinformation, no new information showed up on the mailing list opposing NEMOv4 work since last time you wrote. Alex From nemo-bounces@ietf.org Wed May 03 11:36:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbJOW-0005HZ-FU; Wed, 03 May 2006 11:36:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbJOU-0005HN-N5 for nemo@ietf.org; Wed, 03 May 2006 11:36:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbIXs-00031u-OW for nemo@ietf.org; Wed, 03 May 2006 10:41:40 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FbIGR-0005lD-1T for nemo@ietf.org; Wed, 03 May 2006 10:23:41 -0400 Received: from blv-av-01.boeing.com ([192.42.227.216]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id HAA28353; Wed, 3 May 2006 07:23:30 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k43ENTr00638; Wed, 3 May 2006 07:23:29 -0700 (PDT) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 3 May 2006 07:23:26 -0700 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 Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Wed, 3 May 2006 07:23:26 -0700 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21C018@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: <20060503102737.491d94ad.thierry.ernst@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZui1fOG0gMKknjRpyVvuILUPyYGwAMJ3mg From: "Davis, Terry L" To: "Thierry Ernst" , X-OriginalArrivalTime: 03 May 2006 14:23:26.0955 (UTC) FILETIME=[24A8BBB0:01C66EBD] X-Spam-Score: -2.6 (--) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thierry I agree! I would like to insure that the v6 solution includes the ability to support an architecture that would allow our existing v4 aircraft to be supported by v6 mobility. In our case, trying to support global aircraft fleets with two separate mobility architectures (v4 & v6) does not seem reasonable. Take care Terry > -----Original Message----- > From: Thierry Ernst [mailto:thierry.ernst@inria.fr] > Sent: Wednesday, May 03, 2006 1:28 AM > To: nemo@ietf.org > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >=20 >=20 > Dear all, >=20 > Just a note, I remember v4-defenders stating not so long ago that they > would just do something basic on V4 for NEMO, but now some folks are > suggesting FA support, prefix allocation, etc. What is next ? >=20 > I don't personaly mind work on NEMOv4 (but I don't support this), > however, I do mind that the NEMO WG has a strong focus on v6, and I > would rather see work on v4 and v6 taking places in SEPARATE working > groups. Many people don't want to lose their time on v4 discussions. >=20 > I really think that melting IPv4 and IPv6 in a single working group is > at minimum confusing, and possibly damaging the message the IETF is > addressing to the world (i.e. non-IETFers who follow the output of the > IETF, but not the internal discussions). >=20 > The only exception I see to this if v4-v6 interoperability issues, if any. >=20 > PS: I was unable to participate to the IETF and the discussions on IETF > mailing lists since mid-March until now (back to normal mode now, I > hope), so there are a lot of important discussions in which I couldn't > participate. I still need to dig back into the discussions to see what > other important thread I missed. >=20 > Thierry >=20 >=20 > > Tsirtsis, George wrote: > > > In a recent discussion on the mailing list I suggested that we should > > > define FA support and dynamic prefix allocation for the NEMOv4 base > > > solution. > > > > > > A number of people at the time seemed to be supportive of the idea > > > and I am in the process of writing a draft on the subject. Could we > > > extend the charter to cover these issues? > > > > I agree to request extending the Charter to deal with FA support for > > NEMOv4. Maybe that could be simply put like: "produce IPv4 NEMO > > protocol based on Mobile IPv4 (basic support, FA support and prefix > > allocation from the foreign and/or home networks)." > > > > Or similar? Just some short phrasing. > > > > Alex > > >=20 >=20 > -- > Thierry ERNST, PhD > INRIA Rocquencourt Projet IMARA > +33 1 39 63 59 30 >=20 From nemo-bounces@ietf.org Thu May 04 02:11:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbX3s-0006kj-5e; Thu, 04 May 2006 02:11:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbX3p-0006ju-NQ for nemo@ietf.org; Thu, 04 May 2006 02:11:37 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbX2v-0000HO-Mu for nemo@ietf.org; Thu, 04 May 2006 02:10:42 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CE416212C61; Thu, 4 May 2006 09:10:39 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id 9758A212C5F; Thu, 4 May 2006 09:10:39 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id 537A9BDC40; Thu, 4 May 2006 09:10:39 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id 1D0A4BDC38; Thu, 4 May 2006 09:10:39 +0300 (EEST) In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21C018@XCH-NW-8V1.nw.nos.boeing.com> References: <0D090F1E0F5536449C7E6527AFFA280A21C018@XCH-NW-8V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <505b770155c4ca28b573c94ef0eae06e@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Date: Thu, 4 May 2006 09:10:43 +0300 To: "Davis, Terry L" X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org You mean that you can use v6 signaling to convey information about v6=20 addresses, like DSMIP? that sound reasonable to me... regards, marcelo El 03/05/2006, a las 17:23, Davis, Terry L escribi=F3: > Thierry > > I agree! > > I would like to insure that the v6 solution includes the ability to > support an architecture that would allow our existing v4 aircraft to = be > supported by v6 mobility. In our case, trying to support global > aircraft fleets with two separate mobility architectures (v4 & v6) = does > not seem reasonable. > > Take care > Terry > >> -----Original Message----- >> From: Thierry Ernst [mailto:thierry.ernst@inria.fr] >> Sent: Wednesday, May 03, 2006 1:28 AM >> To: nemo@ietf.org >> Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >> >> >> Dear all, >> >> Just a note, I remember v4-defenders stating not so long ago that = they >> would just do something basic on V4 for NEMO, but now some folks are >> suggesting FA support, prefix allocation, etc. What is next ? >> >> I don't personaly mind work on NEMOv4 (but I don't support this), >> however, I do mind that the NEMO WG has a strong focus on v6, and I >> would rather see work on v4 and v6 taking places in SEPARATE working >> groups. Many people don't want to lose their time on v4 discussions. >> >> I really think that melting IPv4 and IPv6 in a single working group = is >> at minimum confusing, and possibly damaging the message the IETF is >> addressing to the world (i.e. non-IETFers who follow the output of = the >> IETF, but not the internal discussions). >> >> The only exception I see to this if v4-v6 interoperability issues, if > any. >> >> PS: I was unable to participate to the IETF and the discussions on > IETF >> mailing lists since mid-March until now (back to normal mode now, I >> hope), so there are a lot of important discussions in which I = couldn't >> participate. I still need to dig back into the discussions to see = what >> other important thread I missed. >> >> Thierry >> >> >>> Tsirtsis, George wrote: >>>> In a recent discussion on the mailing list I suggested that we > should >>>> define FA support and dynamic prefix allocation for the NEMOv4 > base >>>> solution. >>>> >>>> A number of people at the time seemed to be supportive of the idea >>>> and I am in the process of writing a draft on the subject. Could > we >>>> extend the charter to cover these issues? >>> >>> I agree to request extending the Charter to deal with FA support for >>> NEMOv4. Maybe that could be simply put like: "produce IPv4 NEMO >>> protocol based on Mobile IPv4 (basic support, FA support and prefix >>> allocation from the foreign and/or home networks)." >>> >>> Or similar? Just some short phrasing. >>> >>> Alex >>> >> >> >> -- >> Thierry ERNST, PhD >> INRIA Rocquencourt Projet IMARA >> +33 1 39 63 59 30 >> > > From nemo-bounces@ietf.org Thu May 04 05:13:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbZta-0000UR-Hg; Thu, 04 May 2006 05:13:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbZtZ-0000U6-9a for nemo@ietf.org; Thu, 04 May 2006 05:13:13 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbZtX-0007l0-Th for nemo@ietf.org; Thu, 04 May 2006 05:13:13 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k449QT0Z021481; Thu, 4 May 2006 02:26:29 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k449ZkiS019543; Thu, 4 May 2006 04:35:48 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id D2D51865980; Thu, 4 May 2006 11:12:58 +0200 (CEST) Message-ID: <4459C59A.2010602@motorola.com> Date: Thu, 04 May 2006 11:12:58 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <0D090F1E0F5536449C7E6527AFFA280A21C018@XCH-NW-8V1.nw.nos.boeing.com> <505b770155c4ca28b573c94ef0eae06e@it.uc3m.es> In-Reply-To: <505b770155c4ca28b573c94ef0eae06e@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: nemo@ietf.org, Thierry Ernst , "Davis, Terry L" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org marcelo bagnulo braun wrote: > You mean that you can use v6 signaling to convey information about v6 > addresses, like DSMIP? that sound reasonable to me... Yes, DS-MIPv6 is an extension to Mobile IPv6 allowing a MN to connect to an IPv4-only infrastructure. It requires MN and HA to run both IPv4 and IPv6 (and DS-MIP6 but not MIP4). It uses the MN's IPv4 address as a IPv4-mapped IPv6 address. It allows MN to run IPv6 continuous apps. As such, it does not offer support for an IPv6-exclusively HA. DS-MIPv6 HA must run IPv4 too. I think there is some deployed networks running only IPv6, although not at the edge. I think the air-space industry will be happy (I don't know) with its infrastructure running IPv4 now, IPv4 and IPv6 in the near future, and IPv6 only for the longer term. Although an infrastructure is running IPv6 only (and under control of s single operator) the points of "docking" for an air-space element are under the control of so many other operators that they can't be assumed to be IPv6-only at the time the infrastructure operator pulls the plug on IPv4. DS-MIPv6 will not be useful in these cases. Alex From nemo-bounces@ietf.org Thu May 04 05:33:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbaDL-00051v-Ou; Thu, 04 May 2006 05:33:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbaDK-00051q-Ji for nemo@ietf.org; Thu, 04 May 2006 05:33:38 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbaDI-0000ac-44 for nemo@ietf.org; Thu, 04 May 2006 05:33:38 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D0231212C44; Thu, 4 May 2006 12:33:29 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id 69FEF212C3D; Thu, 4 May 2006 12:33:29 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id 2F9B7BDC40; Thu, 4 May 2006 12:33:29 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id ECAA6BDC38; Thu, 4 May 2006 12:33:28 +0300 (EEST) In-Reply-To: <4459C59A.2010602@motorola.com> References: <0D090F1E0F5536449C7E6527AFFA280A21C018@XCH-NW-8V1.nw.nos.boeing.com> <505b770155c4ca28b573c94ef0eae06e@it.uc3m.es> <4459C59A.2010602@motorola.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <8c4450630ccc3f9c9eaa9900e0a9941c@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Date: Thu, 4 May 2006 12:33:33 +0300 To: Alexandru Petrescu X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: nemo@ietf.org, Thierry Ernst , "Davis, Terry L" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Alex, El 04/05/2006, a las 12:12, Alexandru Petrescu escribi=F3: > marcelo bagnulo braun wrote: >> You mean that you can use v6 signaling to convey information about v6 >> addresses, like DSMIP? that sound reasonable to me... > > Yes, DS-MIPv6 is an extension to Mobile IPv6 allowing a MN to connect=20= > to > an IPv4-only infrastructure. It requires MN and HA to run both IPv4=20= > and > IPv6 (and DS-MIP6 but not MIP4). It uses the MN's IPv4 address as a > IPv4-mapped IPv6 address. It allows MN to run IPv6 continuous apps. > > As such, it does not offer support for an IPv6-exclusively HA. i think i am lost... if you want only IPv6, wouldn't just MIPv6/nemov6=20= be enough for that? I mean if you have a v4 CoA or a v4 HoA the HA needs to support v4, in=20= order to receive or send packet to the address. If there is no v4=20 HoA/CoA, what do need v4 support for? regards, marcelo > DS-MIPv6 > HA must run IPv4 too. I think there is some deployed networks running > only IPv6, although not at the edge. > > I think the air-space industry will be happy (I don't know) with its > infrastructure running IPv4 now, IPv4 and IPv6 in the near future, > and IPv6 only for the longer term. Although an infrastructure is > running IPv6 only (and under control of s single operator) the points=20= > of > "docking" for an air-space element are under the control of so many > other operators that they can't be assumed to be IPv6-only at the time > the infrastructure operator pulls the plug on IPv4. > > DS-MIPv6 will not be useful in these cases. > > Alex > From nemo-bounces@ietf.org Thu May 04 06:05:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbahl-0005Qx-LR; Thu, 04 May 2006 06:05:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbahl-0005Qp-0U for nemo@ietf.org; Thu, 04 May 2006 06:05:05 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbahi-0002Ep-OH for nemo@ietf.org; Thu, 04 May 2006 06:05:04 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k44ALxNe015244; Thu, 4 May 2006 03:21:59 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k44AMFm0002401; Thu, 4 May 2006 05:22:16 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 85135865980; Thu, 4 May 2006 12:04:56 +0200 (CEST) Message-ID: <4459D1C8.5020108@motorola.com> Date: Thu, 04 May 2006 12:04:56 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <0D090F1E0F5536449C7E6527AFFA280A21C018@XCH-NW-8V1.nw.nos.boeing.com> <505b770155c4ca28b573c94ef0eae06e@it.uc3m.es> <4459C59A.2010602@motorola.com> <8c4450630ccc3f9c9eaa9900e0a9941c@it.uc3m.es> In-Reply-To: <8c4450630ccc3f9c9eaa9900e0a9941c@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate8.mot.com id k44ALxNe015244 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: nemo@ietf.org, Thierry Ernst , "Davis, Terry L" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org marcelo bagnulo braun wrote: > Hi Alex, >=20 > El 04/05/2006, a las 12:12, Alexandru Petrescu escribi=F3: >=20 >> marcelo bagnulo braun wrote: >>> You mean that you can use v6 signaling to convey information=20 >>> about v6 addresses, like DSMIP? that sound reasonable to me... >>=20 >> Yes, DS-MIPv6 is an extension to Mobile IPv6 allowing a MN to=20 >> connect to an IPv4-only infrastructure. It requires MN and HA to=20 >> run both IPv4 and IPv6 (and DS-MIP6 but not MIP4). It uses the=20 >> MN's IPv4 address as a IPv4-mapped IPv6 address. It allows MN to=20 >> run IPv6 continuous apps. >>=20 >> As such, it does not offer support for an IPv6-exclusively HA. >=20 > i think i am lost... if you want only IPv6, wouldn't just=20 > MIPv6/nemov6 be enough for that? Yes, it would. But not with DS-MIPv6. Even if the access network is IPv4-only. > I mean if you have a v4 CoA or a v4 HoA the HA needs to support v4,=20 > in order to receive or send packet to the address. As reflected in some discussions I had recently on the MIP6 list, there's a big issue I (or you or both) may have with understanding "v4 CoA" in the context of MIP6. Otherwise, you're right, if you have a v4 CoA/HoA then v4 apps on MN should be supported. That's best done with MIP4. Doing it with DS-MIPv6 instead implies that MIP6 HA must support IPv4. I.e. DS-MIPv6 requires one's infrastructure to support IPv4 when the access network is IPv4. > If there is no v4 HoA/CoA, what do need v4 support for? We need IPv6 apps running on MN to continue when MN accesses an IPv4-only access network, and MN owned by an IPv6-only infrastructure. I don't think we need to work on continuous IPv4 apps running on MN - it's MIP4. Alex From nemo-bounces@ietf.org Thu May 04 06:20:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbawi-0001EK-Rp; Thu, 04 May 2006 06:20:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbawh-0001EF-Qc for nemo@ietf.org; Thu, 04 May 2006 06:20:31 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbawh-0002pP-Aw for nemo@ietf.org; Thu, 04 May 2006 06:20:31 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id CF96F212C44; Thu, 4 May 2006 13:20:27 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id 68DF5212C3D; Thu, 4 May 2006 13:20:27 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id EBCD6BDC40; Thu, 4 May 2006 13:20:26 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id B5A35BDC38; Thu, 4 May 2006 13:20:26 +0300 (EEST) In-Reply-To: <4459D1C8.5020108@motorola.com> References: <0D090F1E0F5536449C7E6527AFFA280A21C018@XCH-NW-8V1.nw.nos.boeing.com> <505b770155c4ca28b573c94ef0eae06e@it.uc3m.es> <4459C59A.2010602@motorola.com> <8c4450630ccc3f9c9eaa9900e0a9941c@it.uc3m.es> <4459D1C8.5020108@motorola.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <279359343b6b82750325e4532fb0154e@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Date: Thu, 4 May 2006 13:20:31 +0300 To: Alexandru Petrescu X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: nemo@ietf.org, Thierry Ernst , "Davis, Terry L" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org El 04/05/2006, a las 13:04, Alexandru Petrescu escribi=F3: > marcelo bagnulo braun wrote: >> Hi Alex, >> El 04/05/2006, a las 12:12, Alexandru Petrescu escribi=F3: >>> marcelo bagnulo braun wrote: >>>> You mean that you can use v6 signaling to convey information about=20= >>>> v6 addresses, like DSMIP? that sound reasonable to me... >>> Yes, DS-MIPv6 is an extension to Mobile IPv6 allowing a MN to=20 >>> connect to an IPv4-only infrastructure. It requires MN and HA to=20 >>> run both IPv4 and IPv6 (and DS-MIP6 but not MIP4). It uses the MN's=20= >>> IPv4 address as a IPv4-mapped IPv6 address. It allows MN to run=20 >>> IPv6 continuous apps. >>> As such, it does not offer support for an IPv6-exclusively HA. >> i think i am lost... if you want only IPv6, wouldn't just=20 >> MIPv6/nemov6 be enough for that? > > Yes, it would. But not with DS-MIPv6. Even if the access network is > IPv4-only. > what would be the alternative? i mean how do you register a v4 CoA for=20= a v6 HoA if not using DSMIP then? >> I mean if you have a v4 CoA or a v4 HoA the HA needs to support v4,=20= >> in order to receive or send packet to the address. > > As reflected in some discussions I had recently on the MIP6 list, > there's a big issue I (or you or both) may have with understanding "v4 > CoA" in the context of MIP6. > i am not following the mip6 list lately, and i don't want to go into=20 discussion that thye have already had there, but, as i understand it,=20 the HoA is the upper layer identifier used for the communications while=20= the CoA is the locator (while the node is away from home), so i don't=20 see any problems in having a identifier associated with alocator that=20 is form another address family... i mean having a v6 HoA boound to a v4=20= CoA does nto present any conceptual issues to me... what am i missing? > Otherwise, you're right, if you have a v4 CoA/HoA then v4 apps on MN > should be supported. That's best done with MIP4. Doing it with > DS-MIPv6 instead implies that MIP6 HA must support IPv4. > i guess that your issue is with respect to regsitering a v4 CoA for a=20 v4 HoA using DSMIP... as i read that is just a signalling optimization=20= in case that you are running both v4 and v6 in order to avoid using=20 mipv4 and mipv6 simoultaneously (of course if you are running just v4,=20= no point in running DSMIP, just use MIPv4) > I.e. DS-MIPv6 requires one's infrastructure to support IPv4 when the > access network is IPv4. > >> If there is no v4 HoA/CoA, what do need v4 support for? > > We need IPv6 apps running on MN to continue when MN accesses an > IPv4-only access network, and MN owned by an IPv6-only infrastructure. this is one of the things that DSMIP provides, right? or there is another alternative for this? > > I don't think we need to work on continuous IPv4 apps running on MN - > it's MIP4. > agree regards, marcelo PS: please let me know if this is OT for the list and i go private > Alex > From nemo-bounces@ietf.org Thu May 04 06:44:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbbK4-0004LI-AQ; Thu, 04 May 2006 06:44:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbbK3-0004LA-F4 for nemo@ietf.org; Thu, 04 May 2006 06:44:39 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbbK1-0004SR-3q for nemo@ietf.org; Thu, 04 May 2006 06:44:39 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k44B1aCa022955; Thu, 4 May 2006 04:01:36 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k44AxT9a016705; Thu, 4 May 2006 05:59:31 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 5F057865980; Thu, 4 May 2006 12:44:31 +0200 (CEST) Message-ID: <4459DB0E.508@motorola.com> Date: Thu, 04 May 2006 12:44:30 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <0D090F1E0F5536449C7E6527AFFA280A21C018@XCH-NW-8V1.nw.nos.boeing.com> <505b770155c4ca28b573c94ef0eae06e@it.uc3m.es> <4459C59A.2010602@motorola.com> <8c4450630ccc3f9c9eaa9900e0a9941c@it.uc3m.es> <4459D1C8.5020108@motorola.com> <279359343b6b82750325e4532fb0154e@it.uc3m.es> In-Reply-To: <279359343b6b82750325e4532fb0154e@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Cc: nemo@ietf.org, Thierry Ernst , "Davis, Terry L" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org marcelo bagnulo braun wrote: >>>> marcelo bagnulo braun wrote: >>>>> You mean that you can use v6 signaling to convey information >>>>> about v6 addresses, like DSMIP? that sound reasonable to >>>>> me... >>>> Yes, DS-MIPv6 is an extension to Mobile IPv6 allowing a MN to >>>> connect to an IPv4-only infrastructure. It requires MN and HA >>>> to run both IPv4 and IPv6 (and DS-MIP6 but not MIP4). It uses >>>> the MN's IPv4 address as a IPv4-mapped IPv6 address. It >>>> allows MN to run IPv6 continuous apps. As such, it does not >>>> offer support for an IPv6-exclusively HA. >>> i think i am lost... if you want only IPv6, wouldn't just >>> MIPv6/nemov6 be enough for that? >> >> Yes, it would. But not with DS-MIPv6. Even if the access network >> is IPv4-only. >> > > what would be the alternative? i mean how do you register a v4 CoA > for a v6 HoA if not using DSMIP then? One would register the v4 CoA for a v4 HoA with MIP4, and a v6 CoA for a v4 HoA with MIP6. DS-MIPv6 starts with the assumption that MN is not efficient to run both MIP4 and MIP6 and proposes DS-MIPv6 instead, but at the same time requires HA to run both v4 and v6. Running both MIP4 and MIP6 on MN (and not DS-MIPv6) does not require a HA to run both IPv4 and IPv6. The HA running IPv4 can be different than the HA running IPv6, thus there's place for IPv6-only infrastructure for HA. One thing that DS-MIPv6 has and MIPv6 hasn't is NAT traversal (re-used from MIPv4's NAT Traversal). >>> I mean if you have a v4 CoA or a v4 HoA the HA needs to support >>> v4, in order to receive or send packet to the address. >> >> As reflected in some discussions I had recently on the MIP6 list, >> there's a big issue I (or you or both) may have with understanding >> "v4 CoA" in the context of MIP6. >> > > i am not following the mip6 list lately, and i don't want to go into > discussion that thye have already had there, That's ok. Basically I write same messages as here and get strong push-back. > but, as i understand it, the HoA is the upper layer identifier used > for the communications while the CoA is the locator (while the node > is away from home), so i don't see any problems in having a > identifier associated with alocator that is form another address > family... i mean having a v6 HoA boound to a v4 CoA does nto present > any conceptual issues to me... what am i missing? The above reasoning seems correct. That implies however that the DS-MIPv6 HA runs both v4 and v6. That's clear in the draft and it's accepted in the MIP6 WG also. Whether this is a useful thing or not it's a matter of debate. I mean if I have an MN and I wonder what should I put on it: both MIPv6 and MIPv4 or only DS-MIPv6? I may answer myself both MIPv6 and MIPv4 because DS-MIPv6 doesn't allow me to have an IPv6-only HA infrastructure. If on the other hand I consider that it's not efficient to run both MIPv6 and MIPv4 messaging then I'd prefer DS-MIPv6 and try to have all my HA infrastructure support both IPv4 and IPv6. From an "efficiency" perspective that's still debatable. On yet another hand, if I consider that my MN runs only IPv6 apps (no IPv4 apps) then no need of MIPv4 on it and thus even less need to run IPv4 on my HA infrastructure. But I still need to connect to the IPv4-only access network. That could be done by re-using only the IPv4 UDP tunnel from MIP4 NAT Traversal, not the entire MIP4. >> Otherwise, you're right, if you have a v4 CoA/HoA then v4 apps on >> MN should be supported. That's best done with MIP4. Doing it with >> DS-MIPv6 instead implies that MIP6 HA must support IPv4. >> > > i guess that your issue is with respect to regsitering a v4 CoA for a > v4 HoA using DSMIP... as i read that is just a signalling > optimization in case that you are running both v4 and v6 in order to > avoid using mipv4 and mipv6 simoultaneously (of course if you are > running just v4, no point in running DSMIP, just use MIPv4) I somehow agree. >> I.e. DS-MIPv6 requires one's infrastructure to support IPv4 when >> the access network is IPv4. >> >>> If there is no v4 HoA/CoA, what do need v4 support for? >> >> We need IPv6 apps running on MN to continue when MN accesses an >> IPv4-only access network, and MN owned by an IPv6-only >> infrastructure. > > this is one of the things that DSMIP provides, right? DS-MIPv6 (draft-ietf-mip6-nemo-v4traversal-01.txt) doesn't, because doesn't allow MN to be owned by a v6-only HA infrastructure. "DS-MIPv4" (draft-tsirtsis-v4v6-mipv4-01.txt) doesn't either, because it's modifications to MIPv4 and an IPv6 address can't be converted into an IPv4 address, and that it assumes too that the HA runs IPv4. > or there is another alternative for this? The non-specified alternative for the above need () is to run MIP6 on MN, run UDP tunnel software from MIPv4 UDP NAT traversal (or maybe 6to4 IPv6-in-IPv4 software) and thus having IPv6-only HA infrastructure. If there is need for this I can write draft text for scenario, problem with DS-MIPv6 solution addressing this scenario, and alternative implementation. >> I don't think we need to work on continuous IPv4 apps running on MN >> - it's MIP4. >> > > agree Alex From nemo-bounces@ietf.org Thu May 04 07:00:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbbZb-0006TK-Nn; Thu, 04 May 2006 07:00:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbbZa-0006TF-H7 for nemo@ietf.org; Thu, 04 May 2006 07:00:42 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbbZZ-00059s-7X for nemo@ietf.org; Thu, 04 May 2006 07:00:42 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 30CAB212C44; Thu, 4 May 2006 14:00:40 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id F3827212C3D; Thu, 4 May 2006 14:00:39 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id C0CCFBDC40; Thu, 4 May 2006 14:00:39 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id 8BB50BDC38; Thu, 4 May 2006 14:00:39 +0300 (EEST) In-Reply-To: <4459DB0E.508@motorola.com> References: <0D090F1E0F5536449C7E6527AFFA280A21C018@XCH-NW-8V1.nw.nos.boeing.com> <505b770155c4ca28b573c94ef0eae06e@it.uc3m.es> <4459C59A.2010602@motorola.com> <8c4450630ccc3f9c9eaa9900e0a9941c@it.uc3m.es> <4459D1C8.5020108@motorola.com> <279359343b6b82750325e4532fb0154e@it.uc3m.es> <4459DB0E.508@motorola.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <74414752f290d011a4319f854e2e12f1@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Date: Thu, 4 May 2006 14:00:44 +0300 To: Alexandru Petrescu X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org El 04/05/2006, a las 13:44, Alexandru Petrescu escribi=F3: > > DS-MIPv6 (draft-ietf-mip6-nemo-v4traversal-01.txt) doesn't, because > doesn't allow MN to be owned by a v6-only HA infrastructure. > understood and agree thanks, marcelo From nemo-bounces@ietf.org Thu May 04 10:01:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbeOM-0005St-JI; Thu, 04 May 2006 10:01:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbeOL-0005So-Nh for nemo@ietf.org; Thu, 04 May 2006 10:01:17 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbeOK-0004vJ-Cn for nemo@ietf.org; Thu, 04 May 2006 10:01:17 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k44E1FGT017893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 May 2006 07:01:15 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k44E1Ec9006404; Thu, 4 May 2006 07:01:14 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 May 2006 07:01:14 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Thu, 4 May 2006 07:01:18 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF002653491@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZui175ChbD0HNpQ6avq2+zFwTpPAA9gJvw From: "Tsirtsis, George" To: "Thierry Ernst" , X-OriginalArrivalTime: 04 May 2006 14:01:14.0053 (UTC) FILETIME=[3499C750:01C66F83] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > -----Original Message----- > From: Thierry Ernst [mailto:thierry.ernst@inria.fr] > Sent: Wednesday, May 03, 2006 4:28 AM > To: nemo@ietf.org > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >=20 >=20 > Dear all, >=20 > Just a note, I remember v4-defenders stating not so long ago that they > would just do something basic on V4 for NEMO, but now some folks are > suggesting FA support, prefix allocation, etc. What is next ? >=20 To second Alex, next is what people agree to do. > I don't personaly mind work on NEMOv4 (but I don't support this), > however, I do mind that the NEMO WG has a strong focus on v6, and I > would rather see work on v4 and v6 taking places in SEPARATE working > groups. Many people don't want to lose their time on v4 discussions. >=20 > I really think that melting IPv4 and IPv6 in a single working group is > at minimum confusing, and possibly damaging the message the IETF is > addressing to the world (i.e. non-IETFers who follow the output of the > IETF, but not the internal discussions). >=20 What is the message that the IETF gives to the world? Please show me the message written somewhere. The IETF has no message. The IETF produces technology when people agree to define it. The market decides what is worth using.=20 Beside, we are not talking about major technology shifts here. It is not like we are suggesting a new version of the Internet Protocol to which the IETF collective (whatever that is) has to agree to. We are talking about simple and technically sound extensions to existing and already deployed technology.=20 George From nemo-bounces@ietf.org Thu May 04 10:15:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbecC-0003FN-Bl; Thu, 04 May 2006 10:15:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbecA-0003FI-Mb for nemo@ietf.org; Thu, 04 May 2006 10:15:34 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbecA-0005DW-A1 for nemo@ietf.org; Thu, 04 May 2006 10:15:34 -0400 Received: from guest-rocq-135223.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k44EFTSS023607 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 May 2006 16:15:30 +0200 Date: Thu, 4 May 2006 16:16:28 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Message-Id: <20060504161628.5d689671.thierry.ernst@inria.fr> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF002653491@NAEX06.na.qualcomm.com> References: <1487A357FD2ED544B8AD29E528FF9DF002653491@NAEX06.na.qualcomm.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 445A0C81.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi. > > Just a note, I remember v4-defenders stating not so long ago that they > > would just do something basic on V4 for NEMO, but now some folks are > > suggesting FA support, prefix allocation, etc. What is next ? > > > > To second Alex, next is what people agree to do. I would add: collectively, and based on rough consensus, as it has always been within the IETF. > > I don't personaly mind work on NEMOv4 (but I don't support this), > > however, I do mind that the NEMO WG has a strong focus on v6, and I > > would rather see work on v4 and v6 taking places in SEPARATE working > > groups. Many people don't want to lose their time on v4 discussions. > > > > I really think that melting IPv4 and IPv6 in a single working group is > > at minimum confusing, and possibly damaging the message the IETF is > > addressing to the world (i.e. non-IETFers who follow the output of the > > IETF, but not the internal discussions). > > > > What is the message that the IETF gives to the world? Please show me the > message written somewhere. The IETF has no message. The IETF produces > technology when people agree to define it. The market decides what is > worth using. > > Beside, we are not talking about major technology shifts here. It is not > like we are suggesting a new version of the Internet Protocol to which > the IETF collective (whatever that is) has to agree to. We are talking > about simple and technically sound extensions to existing and already > deployed technology. I have a subtle understanding of what the message should be, and it is valid in all organizations: been clear, not confusing, and well documented. We cannot develop IPv4 and IPv6 protocols in the same group (unless, as I said, we are working on interoperability issues). >From outside, NEMO is seen as a WG focusing on IPv6. In addition to this, there is a vast majority of people active in the NEMO WG who really don't have interest in IPv4. So, not only our output must be clear for the people monitoring what the WG is doing, but also we must make all the necessary things to gather within this group active participants with a clear focus of what we are doing. My personal position has always been that people willing to bring similar features to IPv4 or whatever which is not IPv6 should simply gather together and set up their own WG. Thierry. From nemo-bounces@ietf.org Thu May 04 11:00:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbfJC-0000Qk-8R; Thu, 04 May 2006 11:00:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbfJB-0000QU-2n for nemo@ietf.org; Thu, 04 May 2006 11:00:01 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbfJA-0007cl-Pk for nemo@ietf.org; Thu, 04 May 2006 11:00:01 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k44FH1Zr025477; Thu, 4 May 2006 08:17:01 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k44FHEll022808; Thu, 4 May 2006 10:17:16 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 516BC865980; Thu, 4 May 2006 16:59:54 +0200 (CEST) Message-ID: <445A16E9.3050102@motorola.com> Date: Thu, 04 May 2006 16:59:53 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF002653491@NAEX06.na.qualcomm.com> <20060504161628.5d689671.thierry.ernst@inria.fr> In-Reply-To: <20060504161628.5d689671.thierry.ernst@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thierry Ernst wrote: > I have a subtle understanding of what the message should be, and it > is valid in all organizations: been clear, not confusing, and well > documented. I agree, inter-operability between v4 and v6 is necessary. Knowing that MIP4 3344 doesn't provide network mobility, and that mip6trans of this NEMO WG is working on v4 and v6 inter-operability - it is obvious to me that MIP4 NEMO extensions should be done and is being done here, something that has been already agreed since some time. Being incoherent about how NEMOv6 and NEMOv4 work only makes tougher the work of inter-operability between them. One example is in netlmm, where main IPv4 address auto-configuration (DHCP) is so different than IPv6 (stateless) that netlmm has more work to do to transform stateless into DHCP. Or here, we want NEMOv4 to also use prefixes in RegReq just as NEMOv6 does in BU. If not, the mip6trans DT will be tempted to add IPv4 prefixes in the BU as well, for good reason. People deploying moving networks would like to do so similarly for v4 and v6. They wouldn't prefer to use NEMOv6 for IPv6, but NAT+DHCP for IPv4. > We cannot develop IPv4 and IPv6 protocols in the same group (unless, > as I said, we are working on interoperability issues). Why not? DHCP is done in DHC WG for both v4 and v6. Similar with IKE and DNS. > From outside, NEMO is seen as a WG focusing on IPv6. I'm not sure about this exclusivity. From the outside that I see the WG is working on Network Mobility. It is true that up to late 2005 it did mainly NEMOv6 with MIP6 3775. If there is a need to educate the "outside" as to what this WG is doing - that's the job of both its Chairs or any other participant. > In addition to this, there is a vast majority of people active in the > NEMO WG who really don't have interest in IPv4. If it were so, mip6trans DT wouldn't be attached to NEMO WG and to MIP6 WG. Mip6trans DT addresses important IPv4 aspets, for example it considers the HA to run an IPv4 stack and connected to the IPv4 Internet, with IPv6 addresses being IPv4-mapped. > So, not only our output must be clear for the people monitoring what > the WG is doing, Yes, I completely agree, we should be clear on that. > but also we must make all the necessary things to gather within this > group active participants with a clear focus of what we are doing. YEs. That is already happening. With respect to IPv4-related activities, we have already atracted active participants with a clear focus of what we are doing about IPv4. mip6trans is but an example. > My personal position has always been that people willing to bring > similar features to IPv4 or whatever which is not IPv6 should simply > gather together and set up their own WG. This didn't happen with the mip6trans DT: mip6trans is doing some IPv4 stuff. They didn't form their separated WG. But I agree with you there's a fine balance to be achieved between effort spent in re-organizing activities, effort spent in documenting and agreeing on technologies and effort spent on educating the outside of the WG about what this WG is doing. Outside the WG there are many documenting papers about the WG, speeches, books, and so on. These are all excellent venues for educating the outside. Alex PS: one can't use NEMO as being IPv6 only and as a technical superiority to enforce switching from IPv4 to IPv6. People can and do today IPv4 moving networks with NEMOv4, with DHCP+NAT and many other ways. Somebody even sells "Mobile Routers" that don't do IPv6 at all. But I agree with you it may have been a motivator in the long gone past. From nemo-bounces@ietf.org Thu May 04 11:20:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbfco-0002mp-93; Thu, 04 May 2006 11:20:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbfcn-0002mk-Ca for nemo@ietf.org; Thu, 04 May 2006 11:20:17 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbfcm-00082p-Uy for nemo@ietf.org; Thu, 04 May 2006 11:20:17 -0400 Received: from guest-rocq-135223.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k44FKFSs031681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 May 2006 17:20:16 +0200 Date: Thu, 4 May 2006 17:21:14 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Message-Id: <20060504172114.591cf6c1.thierry.ernst@inria.fr> In-Reply-To: <445A16E9.3050102@motorola.com> References: <1487A357FD2ED544B8AD29E528FF9DF002653491@NAEX06.na.qualcomm.com> <20060504161628.5d689671.thierry.ernst@inria.fr> <445A16E9.3050102@motorola.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 445A1BAF.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I will not answer back your mail Alex though I have a comment for every single sentence, because I don't want to enter into a long-lasting debate. What I would like to get is room for other people expressing their will for what should be in scope of the NEMO WG vs what shouldn't. IMHO, what matters now the most are operational issues with deploying existing RFC 3963 (e.g. Global HAHA, fixing RFC 3963, multiple MR, etc). If NEMOv4 stuff helps deploying RFC 3963, why not ? But I have some doubts here. Thierry. On Thu, 04 May 2006 16:59:53 +0200 Alexandru Petrescu wrote: > Thierry Ernst wrote: > > I have a subtle understanding of what the message should be, and it > > is valid in all organizations: been clear, not confusing, and well > > documented. > > I agree, inter-operability between v4 and v6 is necessary. Knowing that > MIP4 3344 doesn't provide network mobility, and that mip6trans of this > NEMO WG is working on v4 and v6 inter-operability - it is obvious to me > that MIP4 NEMO extensions should be done and is being done here, > something that has been already agreed since some time. > > Being incoherent about how NEMOv6 and NEMOv4 work only makes tougher the > work of inter-operability between them. One example is in netlmm, where > main IPv4 address auto-configuration (DHCP) is so different than IPv6 > (stateless) that netlmm has more work to do to transform stateless into > DHCP. Or here, we want NEMOv4 to also use prefixes in RegReq just > as NEMOv6 does in BU. If not, the mip6trans DT will be tempted to add > IPv4 prefixes in the BU as well, for good reason. > > People deploying moving networks would like to do so similarly for v4 > and v6. They wouldn't prefer to use NEMOv6 for IPv6, but NAT+DHCP for IPv4. > > > We cannot develop IPv4 and IPv6 protocols in the same group (unless, > > as I said, we are working on interoperability issues). > > Why not? > > DHCP is done in DHC WG for both v4 and v6. Similar with IKE and DNS. > > > From outside, NEMO is seen as a WG focusing on IPv6. > > I'm not sure about this exclusivity. From the outside that I see the WG > is working on Network Mobility. It is true that up to late 2005 it did > mainly NEMOv6 with MIP6 3775. > > If there is a need to educate the "outside" as to what this WG is doing > - that's the job of both its Chairs or any other participant. > > > In addition to this, there is a vast majority of people active in the > > NEMO WG who really don't have interest in IPv4. > > If it were so, mip6trans DT wouldn't be attached to NEMO WG and to MIP6 > WG. Mip6trans DT addresses important IPv4 aspets, for example it > considers the HA to run an IPv4 stack and connected to the IPv4 > Internet, with IPv6 addresses being IPv4-mapped. > > > So, not only our output must be clear for the people monitoring what > > the WG is doing, > > Yes, I completely agree, we should be clear on that. > > > but also we must make all the necessary things to gather within this > > group active participants with a clear focus of what we are doing. > > YEs. That is already happening. With respect to IPv4-related > activities, we have already atracted active participants with a clear > focus of what we are doing about IPv4. mip6trans is but an example. > > > My personal position has always been that people willing to bring > > similar features to IPv4 or whatever which is not IPv6 should simply > > gather together and set up their own WG. > > This didn't happen with the mip6trans DT: mip6trans is doing some IPv4 > stuff. They didn't form their separated WG. > > But I agree with you there's a fine balance to be achieved between > effort spent in re-organizing activities, effort spent in documenting > and agreeing on technologies and effort spent on educating the outside > of the WG about what this WG is doing. Outside the WG there are many > documenting papers about the WG, speeches, books, and so on. These are > all excellent venues for educating the outside. > > Alex > PS: one can't use NEMO as being IPv6 only and as a technical superiority > to enforce switching from IPv4 to IPv6. People can and do today IPv4 > moving networks with NEMOv4, with DHCP+NAT and many other ways. > Somebody even sells "Mobile Routers" that don't do IPv6 at all. But I > agree with you it may have been a motivator in the long gone past. > -- Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Thu May 04 13:21:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbhW9-0008Jq-TF; Thu, 04 May 2006 13:21:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbhW9-0008IG-3A for nemo@ietf.org; Thu, 04 May 2006 13:21:33 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbhW8-00053T-Mt for nemo@ietf.org; Thu, 04 May 2006 13:21:33 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 May 2006 10:21:30 -0700 Message-ID: <445A381A.1030405@azairenet.com> Date: Thu, 04 May 2006 10:21:30 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF002653491@NAEX06.na.qualcomm.com> <20060504161628.5d689671.thierry.ernst@inria.fr> <445A16E9.3050102@motorola.com> <20060504172114.591cf6c1.thierry.ernst@inria.fr> In-Reply-To: <20060504172114.591cf6c1.thierry.ernst@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 May 2006 17:21:30.0245 (UTC) FILETIME=[2ECF2B50:01C66F9F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I agree on focusing on IPv6 in the NEMO WG. Vijay Thierry Ernst wrote: > > I will not answer back your mail Alex though I have a comment for every > single sentence, because I don't want to enter into a long-lasting > debate. > > What I would like to get is room for other people expressing their will > for what should be in scope of the NEMO WG vs what shouldn't. > > IMHO, what matters now the most are operational issues with deploying > existing RFC 3963 (e.g. Global HAHA, fixing RFC 3963, multiple MR, etc). > If NEMOv4 stuff helps deploying RFC 3963, why not ? But I have some > doubts here. > > Thierry. > > > > > On Thu, 04 May 2006 16:59:53 +0200 > Alexandru Petrescu wrote: > >> Thierry Ernst wrote: >>> I have a subtle understanding of what the message should be, and it >>> is valid in all organizations: been clear, not confusing, and well >>> documented. >> I agree, inter-operability between v4 and v6 is necessary. Knowing that >> MIP4 3344 doesn't provide network mobility, and that mip6trans of this >> NEMO WG is working on v4 and v6 inter-operability - it is obvious to me >> that MIP4 NEMO extensions should be done and is being done here, >> something that has been already agreed since some time. >> >> Being incoherent about how NEMOv6 and NEMOv4 work only makes tougher the >> work of inter-operability between them. One example is in netlmm, where >> main IPv4 address auto-configuration (DHCP) is so different than IPv6 >> (stateless) that netlmm has more work to do to transform stateless into >> DHCP. Or here, we want NEMOv4 to also use prefixes in RegReq just >> as NEMOv6 does in BU. If not, the mip6trans DT will be tempted to add >> IPv4 prefixes in the BU as well, for good reason. >> >> People deploying moving networks would like to do so similarly for v4 >> and v6. They wouldn't prefer to use NEMOv6 for IPv6, but NAT+DHCP for IPv4. >> >>> We cannot develop IPv4 and IPv6 protocols in the same group (unless, >>> as I said, we are working on interoperability issues). >> Why not? >> >> DHCP is done in DHC WG for both v4 and v6. Similar with IKE and DNS. >> >>> From outside, NEMO is seen as a WG focusing on IPv6. >> I'm not sure about this exclusivity. From the outside that I see the WG >> is working on Network Mobility. It is true that up to late 2005 it did >> mainly NEMOv6 with MIP6 3775. >> >> If there is a need to educate the "outside" as to what this WG is doing >> - that's the job of both its Chairs or any other participant. >> >>> In addition to this, there is a vast majority of people active in the >>> NEMO WG who really don't have interest in IPv4. >> If it were so, mip6trans DT wouldn't be attached to NEMO WG and to MIP6 >> WG. Mip6trans DT addresses important IPv4 aspets, for example it >> considers the HA to run an IPv4 stack and connected to the IPv4 >> Internet, with IPv6 addresses being IPv4-mapped. >> >>> So, not only our output must be clear for the people monitoring what >>> the WG is doing, >> Yes, I completely agree, we should be clear on that. >> >>> but also we must make all the necessary things to gather within this >>> group active participants with a clear focus of what we are doing. >> YEs. That is already happening. With respect to IPv4-related >> activities, we have already atracted active participants with a clear >> focus of what we are doing about IPv4. mip6trans is but an example. >> >>> My personal position has always been that people willing to bring >>> similar features to IPv4 or whatever which is not IPv6 should simply >>> gather together and set up their own WG. >> This didn't happen with the mip6trans DT: mip6trans is doing some IPv4 >> stuff. They didn't form their separated WG. >> >> But I agree with you there's a fine balance to be achieved between >> effort spent in re-organizing activities, effort spent in documenting >> and agreeing on technologies and effort spent on educating the outside >> of the WG about what this WG is doing. Outside the WG there are many >> documenting papers about the WG, speeches, books, and so on. These are >> all excellent venues for educating the outside. >> >> Alex >> PS: one can't use NEMO as being IPv6 only and as a technical superiority >> to enforce switching from IPv4 to IPv6. People can and do today IPv4 >> moving networks with NEMOv4, with DHCP+NAT and many other ways. >> Somebody even sells "Mobile Routers" that don't do IPv6 at all. But I >> agree with you it may have been a motivator in the long gone past. >> > > From nemo-bounces@ietf.org Thu May 04 15:31:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbjXu-0001FC-AY; Thu, 04 May 2006 15:31:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbjXs-0001E0-TU for nemo@ietf.org; Thu, 04 May 2006 15:31:28 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbjXr-0002BS-Lh for nemo@ietf.org; Thu, 04 May 2006 15:31:28 -0400 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k44JmOpt002811; Thu, 4 May 2006 12:48:24 -0700 (MST) Received: from [10.129.40.148] ([10.129.40.148]) by il06exr02.mot.com (8.13.1/8.13.0) with ESMTP id k44JkIYX023977; Thu, 4 May 2006 14:46:19 -0500 (CDT) Message-ID: <445A5688.9020509@motorola.com> Date: Thu, 04 May 2006 21:31:20 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF002653491@NAEX06.na.qualcomm.com> <20060504161628.5d689671.thierry.ernst@inria.fr> <445A16E9.3050102@motorola.com> <20060504172114.591cf6c1.thierry.ernst@inria.fr> <445A381A.1030405@azairenet.com> In-Reply-To: <445A381A.1030405@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Vijay Devarapalli wrote: > I agree on focusing on IPv6 in the NEMO WG. I somehow agree but the focusing is debatable. Would you care to say what and why? Alex From nemo-bounces@ietf.org Thu May 04 17:27:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FblMW-0003Rw-7w; Thu, 04 May 2006 17:27:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FblMV-0003Rr-Kr for nemo@ietf.org; Thu, 04 May 2006 17:27:51 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FblMQ-0007zw-03 for nemo@ietf.org; Thu, 04 May 2006 17:27:51 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA26917; Thu, 4 May 2006 14:27:30 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k44LRTG00256; Thu, 4 May 2006 16:27:29 -0500 (CDT) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 May 2006 14:27:29 -0700 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 Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Thu, 4 May 2006 14:27:28 -0700 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21C02C@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: <4459C59A.2010602@motorola.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZvWvgdGI7Jg24CQLqRGZBjc/N7fwAZj4oA From: "Davis, Terry L" To: "Alexandru Petrescu" , "marcelo bagnulo braun" X-OriginalArrivalTime: 04 May 2006 21:27:29.0091 (UTC) FILETIME=[8BC45930:01C66FC1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Alexandru/Marcelo That is certainly one option we will consider. Transition time for aviation is measured in decades at least. (We are still running an OSI version from the late 80's.) Take care Terry > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Thursday, May 04, 2006 2:13 AM > To: marcelo bagnulo braun > Cc: Davis, Terry L; nemo@ietf.org; Thierry Ernst > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >=20 > marcelo bagnulo braun wrote: > > You mean that you can use v6 signaling to convey information about v6 > > addresses, like DSMIP? that sound reasonable to me... >=20 > Yes, DS-MIPv6 is an extension to Mobile IPv6 allowing a MN to connect to > an IPv4-only infrastructure. It requires MN and HA to run both IPv4 and > IPv6 (and DS-MIP6 but not MIP4). It uses the MN's IPv4 address as a > IPv4-mapped IPv6 address. It allows MN to run IPv6 continuous apps. >=20 > As such, it does not offer support for an IPv6-exclusively HA. DS-MIPv6 > HA must run IPv4 too. I think there is some deployed networks running > only IPv6, although not at the edge. >=20 > I think the air-space industry will be happy (I don't know) with its > infrastructure running IPv4 now, IPv4 and IPv6 in the near future, > and IPv6 only for the longer term. Although an infrastructure is > running IPv6 only (and under control of s single operator) the points of > "docking" for an air-space element are under the control of so many > other operators that they can't be assumed to be IPv6-only at the time > the infrastructure operator pulls the plug on IPv4. >=20 > DS-MIPv6 will not be useful in these cases. >=20 > Alex From nemo-bounces@ietf.org Fri May 05 02:55:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbuE1-0003hI-QF; Fri, 05 May 2006 02:55:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbuE1-0003fR-2C for nemo@ietf.org; Fri, 05 May 2006 02:55:41 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbuDy-00043v-BF for nemo@ietf.org; Fri, 05 May 2006 02:55:41 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k456tT9W017883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 4 May 2006 23:55:29 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k456tTOK001398; Thu, 4 May 2006 23:55:29 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 4 May 2006 23:55:28 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Thu, 4 May 2006 23:55:24 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB847925D9@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZui16cmZDHBOOYRJav0qqbjCEFkABg+C4g From: "Narayanan, Vidya" To: "Thierry Ernst" , X-OriginalArrivalTime: 05 May 2006 06:55:28.0324 (UTC) FILETIME=[E492A040:01C67010] X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Thierry, At the risk of falling under the "v4-defenders" camp, I am not sure why there is a problem with doing the work if there is a practical need for it and if there are volunteers to work on the topic. When we did the base draft, we did mention that our desire was to work on the NEMOv4 base protocol - however, there was a discussion related to what happens if more topics come up and we had decided that we will take up those topics as they go based on need and consensus.=20 And, I completely disagree that there should be a separate WG to do any IPv4 work - there are a lot of functional similarities between NEMOv4 and NEMOv6 and the work required for any additions to NEMOv4 base is minimal. If there is enough interest and need for getting this work done, it should be done here.=20 The mobility space already has way too many WGs - way more than there needs to be. If anything the IETF is doing in this space is sending a confusing message to observers, that alone is sufficient to drive an observer to ultimate confusion :) The fact that a WG titled "Network Mobility" is working on IPv4 and IPv6 network mobility is hardly the reason an observer is likely to get confused!=20 Regards, Vidya > -----Original Message----- > From: Thierry Ernst [mailto:thierry.ernst@inria.fr]=20 > Sent: Wednesday, May 03, 2006 1:28 AM > To: nemo@ietf.org > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >=20 >=20 > Dear all, >=20 > Just a note, I remember v4-defenders stating not so long ago=20 > that they would just do something basic on V4 for NEMO, but=20 > now some folks are suggesting FA support, prefix allocation,=20 > etc. What is next ? >=20 > I don't personaly mind work on NEMOv4 (but I don't support=20 > this), however, I do mind that the NEMO WG has a strong focus=20 > on v6, and I would rather see work on v4 and v6 taking places=20 > in SEPARATE working groups. Many people don't want to lose=20 > their time on v4 discussions. >=20 > I really think that melting IPv4 and IPv6 in a single working=20 > group is at minimum confusing, and possibly damaging the=20 > message the IETF is addressing to the world (i.e. non-IETFers=20 > who follow the output of the IETF, but not the internal discussions).=20 >=20 > The only exception I see to this if v4-v6 interoperability=20 > issues, if any.=20 >=20 > PS: I was unable to participate to the IETF and the=20 > discussions on IETF mailing lists since mid-March until now=20 > (back to normal mode now, I hope), so there are a lot of=20 > important discussions in which I couldn't participate. I=20 > still need to dig back into the discussions to see what other=20 > important thread I missed. >=20 > Thierry >=20 >=20 > > Tsirtsis, George wrote: > > > In a recent discussion on the mailing list I suggested that we=20 > > > should define FA support and dynamic prefix allocation for the=20 > > > NEMOv4 base solution. > > >=20 > > > A number of people at the time seemed to be supportive of=20 > the idea=20 > > > and I am in the process of writing a draft on the=20 > subject. Could we=20 > > > extend the charter to cover these issues? > >=20 > > I agree to request extending the Charter to deal with FA=20 > support for=20 > > NEMOv4. Maybe that could be simply put like: "produce IPv4 NEMO=20 > > protocol based on Mobile IPv4 (basic support, FA support and prefix=20 > > allocation from the foreign and/or home networks)." > >=20 > > Or similar? Just some short phrasing. > >=20 > > Alex > >=20 >=20 >=20 > -- > Thierry ERNST, PhD > INRIA Rocquencourt Projet IMARA > +33 1 39 63 59 30 >=20 >=20 >=20 From nemo-bounces@ietf.org Fri May 05 04:52:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbw3R-0003ct-3A; Fri, 05 May 2006 04:52:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbw3P-0003co-AK for nemo@ietf.org; Fri, 05 May 2006 04:52:51 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbw3O-0001RJ-SK for nemo@ietf.org; Fri, 05 May 2006 04:52:51 -0400 Received: from guest-rocq-135223.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k458qnHi029217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 May 2006 10:52:50 +0200 Date: Fri, 5 May 2006 10:53:49 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Message-Id: <20060505105349.5669c002.thierry.ernst@inria.fr> In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB847925D9@NAEX06.na.qualcomm.com> References: <2EBB8025B6D1BA41B567DB32C1D8DB847925D9@NAEX06.na.qualcomm.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 445B1261.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Vidya, Some people want to concentrate on v6 work only (including me and a couple of other who have been involved in the NEMO WG from the beginning) and for these people there are valid reasons not to mix up things. On the other hand, there are other people who just want to work on NEMO without distinction between IPv4 and IPv6. There people also have valid reasons. I stand on the side of those people who want to work on IPv6 specific issues. If there are good reasons to motivate a reduction in the number of WGs, I would rather group MIP6 and NEMO together rather than NEMOv4 and NEMOv6 together. But the debate on "too many mobility WGs within the IETF" should be discussed on the IETF general ML or the WG chairs ML, not here. I would like to get the opinion of more (i.e. others) people whether we should concentrate on IPv6 or not. Thierry. On Thu, 4 May 2006 23:55:24 -0700 "Narayanan, Vidya" wrote: > Hi Thierry, > At the risk of falling under the "v4-defenders" camp, I am not sure why > there is a problem with doing the work if there is a practical need for > it and if there are volunteers to work on the topic. When we did the > base draft, we did mention that our desire was to work on the NEMOv4 > base protocol - however, there was a discussion related to what happens > if more topics come up and we had decided that we will take up those > topics as they go based on need and consensus. > > And, I completely disagree that there should be a separate WG to do any > IPv4 work - there are a lot of functional similarities between NEMOv4 > and NEMOv6 and the work required for any additions to NEMOv4 base is > minimal. If there is enough interest and need for getting this work > done, it should be done here. > > The mobility space already has way too many WGs - way more than there > needs to be. If anything the IETF is doing in this space is sending a > confusing message to observers, that alone is sufficient to drive an > observer to ultimate confusion :) The fact that a WG titled "Network > Mobility" is working on IPv4 and IPv6 network mobility is hardly the > reason an observer is likely to get confused! > > Regards, > Vidya > > > -----Original Message----- > > From: Thierry Ernst [mailto:thierry.ernst@inria.fr] > > Sent: Wednesday, May 03, 2006 1:28 AM > > To: nemo@ietf.org > > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. > > > > > > Dear all, > > > > Just a note, I remember v4-defenders stating not so long ago > > that they would just do something basic on V4 for NEMO, but > > now some folks are suggesting FA support, prefix allocation, > > etc. What is next ? > > > > I don't personaly mind work on NEMOv4 (but I don't support > > this), however, I do mind that the NEMO WG has a strong focus > > on v6, and I would rather see work on v4 and v6 taking places > > in SEPARATE working groups. Many people don't want to lose > > their time on v4 discussions. > > > > I really think that melting IPv4 and IPv6 in a single working > > group is at minimum confusing, and possibly damaging the > > message the IETF is addressing to the world (i.e. non-IETFers > > who follow the output of the IETF, but not the internal discussions). > > > > The only exception I see to this if v4-v6 interoperability > > issues, if any. > > > > PS: I was unable to participate to the IETF and the > > discussions on IETF mailing lists since mid-March until now > > (back to normal mode now, I hope), so there are a lot of > > important discussions in which I couldn't participate. I > > still need to dig back into the discussions to see what other > > important thread I missed. > > > > Thierry > > > > > > > Tsirtsis, George wrote: > > > > In a recent discussion on the mailing list I suggested that we > > > > should define FA support and dynamic prefix allocation for the > > > > NEMOv4 base solution. > > > > > > > > A number of people at the time seemed to be supportive of > > the idea > > > > and I am in the process of writing a draft on the > > subject. Could we > > > > extend the charter to cover these issues? > > > > > > I agree to request extending the Charter to deal with FA > > support for > > > NEMOv4. Maybe that could be simply put like: "produce IPv4 NEMO > > > protocol based on Mobile IPv4 (basic support, FA support and prefix > > > allocation from the foreign and/or home networks)." > > > > > > Or similar? Just some short phrasing. > > > > > > Alex > > > > > > > > > -- > > Thierry ERNST, PhD > > INRIA Rocquencourt Projet IMARA > > +33 1 39 63 59 30 > > > > > > > > -- Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Fri May 05 05:42:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbwpl-00051Y-65; Fri, 05 May 2006 05:42:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbwpk-00051T-KG for nemo@ietf.org; Fri, 05 May 2006 05:42:48 -0400 Received: from p-mail2.rd.francetelecom.com ([195.101.245.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbwpk-000374-5c for nemo@ietf.org; Fri, 05 May 2006 05:42:48 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 11:42:33 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Fri, 5 May 2006 11:39:23 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZvn2X7B3K3ujxbSYCcI79tn2CfpAAh7vRw From: "COMBES Jean-Michel RD-MAPS-ISS" To: "Vijay Devarapalli" , "Thierry Ernst" X-OriginalArrivalTime: 05 May 2006 09:42:33.0755 (UTC) FILETIME=[3C31FEB0:01C67028] X-Spam-Score: 0.0 (/) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I agree too on focusing on IPv6 in the NEMO WG.=20 Clearly, someone that wants to follow NEMO4 and NEMO6 has just to subscribe to the 2 WG's ML.=20 If NEMO4 and NEMO6 are studied in the same WG, this will increase the chances to miss important debates if we are only focused on one of the two topics because of the number of emails (BTW, that was clearly my case when there was the mobileip WG). Best regards. JMC. France Telecom - R&D Division - MAPS/NSS =20 Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16=20 =20 > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com]=20 > Sent: Thursday, May 04, 2006 7:22 PM > To: Thierry Ernst > Cc: nemo@ietf.org > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >=20 > I agree on focusing on IPv6 in the NEMO WG. >=20 > Vijay >=20 > Thierry Ernst wrote: > >=20 > > I will not answer back your mail Alex though I have a comment for=20 > > every single sentence, because I don't want to enter into a=20 > > long-lasting debate. > >=20 > > What I would like to get is room for other people expressing their=20 > > will for what should be in scope of the NEMO WG vs what shouldn't. > >=20 > > IMHO, what matters now the most are operational issues with=20 > deploying=20 > > existing RFC 3963 (e.g. Global HAHA, fixing RFC 3963,=20 > multiple MR, etc). > > If NEMOv4 stuff helps deploying RFC 3963, why not ? But I=20 > have some=20 > > doubts here. > >=20 > > Thierry. > >=20 > >=20 > >=20 > >=20 > > On Thu, 04 May 2006 16:59:53 +0200 > > Alexandru Petrescu wrote: > >=20 > >> Thierry Ernst wrote: > >>> I have a subtle understanding of what the message should=20 > be, and it=20 > >>> is valid in all organizations: been clear, not confusing,=20 > and well=20 > >>> documented. > >> I agree, inter-operability between v4 and v6 is necessary.=20 > Knowing=20 > >> that > >> MIP4 3344 doesn't provide network mobility, and that mip6trans of=20 > >> this NEMO WG is working on v4 and v6 inter-operability - it is=20 > >> obvious to me that MIP4 NEMO extensions should be done and=20 > is being=20 > >> done here, something that has been already agreed since some time. > >> > >> Being incoherent about how NEMOv6 and NEMOv4 work only=20 > makes tougher=20 > >> the work of inter-operability between them. One example is in=20 > >> netlmm, where main IPv4 address auto-configuration (DHCP) is so=20 > >> different than IPv6 > >> (stateless) that netlmm has more work to do to transform stateless=20 > >> into DHCP. Or here, we want NEMOv4 to also use prefixes in RegReq=20 > >> just as NEMOv6 does in BU. If not, the mip6trans DT will=20 > be tempted=20 > >> to add > >> IPv4 prefixes in the BU as well, for good reason. > >> > >> People deploying moving networks would like to do so=20 > similarly for v4=20 > >> and v6. They wouldn't prefer to use NEMOv6 for IPv6, but=20 > NAT+DHCP for IPv4. > >> > >>> We cannot develop IPv4 and IPv6 protocols in the same=20 > group (unless, =20 > >>> as I said, we are working on interoperability issues). > >> Why not? > >> > >> DHCP is done in DHC WG for both v4 and v6. Similar with=20 > IKE and DNS. > >> > >>> From outside, NEMO is seen as a WG focusing on IPv6. > >> I'm not sure about this exclusivity. From the outside=20 > that I see the=20 > >> WG is working on Network Mobility. It is true that up to=20 > late 2005=20 > >> it did mainly NEMOv6 with MIP6 3775. > >> > >> If there is a need to educate the "outside" as to what this WG is=20 > >> doing > >> - that's the job of both its Chairs or any other participant. > >> > >>> In addition to this, there is a vast majority of people active in=20 > >>> the NEMO WG who really don't have interest in IPv4. > >> If it were so, mip6trans DT wouldn't be attached to NEMO WG and to=20 > >> MIP6 WG. Mip6trans DT addresses important IPv4 aspets,=20 > for example=20 > >> it considers the HA to run an IPv4 stack and connected to the IPv4=20 > >> Internet, with IPv6 addresses being IPv4-mapped. > >> > >>> So, not only our output must be clear for the people=20 > monitoring what=20 > >>> the WG is doing, > >> Yes, I completely agree, we should be clear on that. > >> > >>> but also we must make all the necessary things to gather=20 > within this =20 > >>> group active participants with a clear focus of what we are doing. > >> YEs. That is already happening. With respect to IPv4-related=20 > >> activities, we have already atracted active participants=20 > with a clear=20 > >> focus of what we are doing about IPv4. mip6trans is but=20 > an example. > >> > >>> My personal position has always been that people willing to bring=20 > >>> similar features to IPv4 or whatever which is not IPv6=20 > should simply =20 > >>> gather together and set up their own WG. > >> This didn't happen with the mip6trans DT: mip6trans is doing some=20 > >> IPv4 stuff. They didn't form their separated WG. > >> > >> But I agree with you there's a fine balance to be achieved between=20 > >> effort spent in re-organizing activities, effort spent in=20 > documenting=20 > >> and agreeing on technologies and effort spent on educating the=20 > >> outside of the WG about what this WG is doing. Outside=20 > the WG there=20 > >> are many documenting papers about the WG, speeches, books,=20 > and so on. =20 > >> These are all excellent venues for educating the outside. > >> > >> Alex > >> PS: one can't use NEMO as being IPv6 only and as a technical=20 > >> superiority to enforce switching from IPv4 to IPv6. =20 > People can and=20 > >> do today IPv4 moving networks with NEMOv4, with DHCP+NAT=20 > and many other ways. > >> Somebody even sells "Mobile Routers" that don't do IPv6 at=20 > all. But=20 > >> I agree with you it may have been a motivator in the long=20 > gone past. > >> > >=20 > >=20 >=20 >=20 >=20 From nemo-bounces@ietf.org Fri May 05 06:00:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbx6M-0002HM-31; Fri, 05 May 2006 05:59:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbx6K-0002HE-93 for nemo@ietf.org; Fri, 05 May 2006 05:59:56 -0400 Received: from smtp2.int-evry.fr ([157.159.10.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbx6J-0003dr-ED for nemo@ietf.org; Fri, 05 May 2006 05:59:56 -0400 Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76]) by smtp2.int-evry.fr (Postfix) with ESMTP id BADED815F; Fri, 5 May 2006 11:59:51 +0200 (CEST) Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52) id 1FbwA3-00035S-7D; Fri, 05 May 2006 10:59:43 +0200 Date: Fri, 5 May 2006 10:59:43 +0200 From: Julien Bournelle To: Thierry Ernst Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Message-ID: <20060505085943.GA11861@ipv6-3.int-evry.fr> References: <2EBB8025B6D1BA41B567DB32C1D8DB847925D9@NAEX06.na.qualcomm.com> <20060505105349.5669c002.thierry.ernst@inria.fr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060505105349.5669c002.thierry.ernst@inria.fr> User-Agent: Mutt/1.5.9i X-INT-MailScanner-Information: Please contact the ISP for more information X-INT-MailScanner: Found to be clean X-INT-MailScanner-SpamCheck: X-MailScanner-From: jb@int-evry.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi all, I can remember that mobileip has decided to split to work more efficiently. So maybe it would be better to do the same thing for NEMO and thus to keep focus on v6. My 2 cents, Julien On Fri, May 05, 2006 at 10:53:49AM +0200, Thierry Ernst wrote: > > Vidya, > > Some people want to concentrate on v6 work only (including me and a > couple of other who have been involved in the NEMO WG from the > beginning) and for these people there are valid reasons not to mix up > things. On the other hand, there are other people who just want to work > on NEMO without distinction between IPv4 and IPv6. There people also > have valid reasons. > > I stand on the side of those people who want to work on IPv6 specific > issues. If there are good reasons to motivate a reduction in the number > of WGs, I would rather group MIP6 and NEMO together rather than NEMOv4 > and NEMOv6 together. But the debate on "too many mobility WGs within the > IETF" should be discussed on the IETF general ML or the WG chairs ML, > not here. > > I would like to get the opinion of more (i.e. others) people whether we > should concentrate on IPv6 or not. > > Thierry. > > On Thu, 4 May 2006 23:55:24 -0700 > "Narayanan, Vidya" wrote: > > > Hi Thierry, > > At the risk of falling under the "v4-defenders" camp, I am not sure why > > there is a problem with doing the work if there is a practical need for > > it and if there are volunteers to work on the topic. When we did the > > base draft, we did mention that our desire was to work on the NEMOv4 > > base protocol - however, there was a discussion related to what happens > > if more topics come up and we had decided that we will take up those > > topics as they go based on need and consensus. > > > > And, I completely disagree that there should be a separate WG to do any > > IPv4 work - there are a lot of functional similarities between NEMOv4 > > and NEMOv6 and the work required for any additions to NEMOv4 base is > > minimal. If there is enough interest and need for getting this work > > done, it should be done here. > > > > The mobility space already has way too many WGs - way more than there > > needs to be. If anything the IETF is doing in this space is sending a > > confusing message to observers, that alone is sufficient to drive an > > observer to ultimate confusion :) The fact that a WG titled "Network > > Mobility" is working on IPv4 and IPv6 network mobility is hardly the > > reason an observer is likely to get confused! > > > > Regards, > > Vidya > > > > > -----Original Message----- > > > From: Thierry Ernst [mailto:thierry.ernst@inria.fr] > > > Sent: Wednesday, May 03, 2006 1:28 AM > > > To: nemo@ietf.org > > > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. > > > > > > > > > Dear all, > > > > > > Just a note, I remember v4-defenders stating not so long ago > > > that they would just do something basic on V4 for NEMO, but > > > now some folks are suggesting FA support, prefix allocation, > > > etc. What is next ? > > > > > > I don't personaly mind work on NEMOv4 (but I don't support > > > this), however, I do mind that the NEMO WG has a strong focus > > > on v6, and I would rather see work on v4 and v6 taking places > > > in SEPARATE working groups. Many people don't want to lose > > > their time on v4 discussions. > > > > > > I really think that melting IPv4 and IPv6 in a single working > > > group is at minimum confusing, and possibly damaging the > > > message the IETF is addressing to the world (i.e. non-IETFers > > > who follow the output of the IETF, but not the internal discussions). > > > > > > The only exception I see to this if v4-v6 interoperability > > > issues, if any. > > > > > > PS: I was unable to participate to the IETF and the > > > discussions on IETF mailing lists since mid-March until now > > > (back to normal mode now, I hope), so there are a lot of > > > important discussions in which I couldn't participate. I > > > still need to dig back into the discussions to see what other > > > important thread I missed. > > > > > > Thierry > > > > > > > > > > Tsirtsis, George wrote: > > > > > In a recent discussion on the mailing list I suggested that we > > > > > should define FA support and dynamic prefix allocation for the > > > > > NEMOv4 base solution. > > > > > > > > > > A number of people at the time seemed to be supportive of > > > the idea > > > > > and I am in the process of writing a draft on the > > > subject. Could we > > > > > extend the charter to cover these issues? > > > > > > > > I agree to request extending the Charter to deal with FA > > > support for > > > > NEMOv4. Maybe that could be simply put like: "produce IPv4 NEMO > > > > protocol based on Mobile IPv4 (basic support, FA support and prefix > > > > allocation from the foreign and/or home networks)." > > > > > > > > Or similar? Just some short phrasing. > > > > > > > > Alex > > > > > > > > > > > > > -- > > > Thierry ERNST, PhD > > > INRIA Rocquencourt Projet IMARA > > > +33 1 39 63 59 30 > > > > > > > > > > > > > > > > -- > Thierry ERNST, PhD > INRIA Rocquencourt Projet IMARA > +33 1 39 63 59 30 > > -- julien.bournelle at int-evry.fr From nemo-bounces@ietf.org Fri May 05 06:11:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbxHT-000347-Bp; Fri, 05 May 2006 06:11:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbxHS-000342-58 for nemo@ietf.org; Fri, 05 May 2006 06:11:26 -0400 Received: from mobqos.ee.unsw.edu.au ([129.94.230.70]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbxHR-0004Ay-Ch for nemo@ietf.org; Fri, 05 May 2006 06:11:26 -0400 Received: from [129.94.230.70] (helo=ErangaLaptop) by mobqos.ee.unsw.edu.au with esmtp (Exim 4.34) id 1FbxGv-0007jv-Hf; Fri, 05 May 2006 20:10:54 +1000 From: "Eranga Perera" To: "'Julien Bournelle'" , "'Thierry Ernst'" Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Fri, 5 May 2006 20:11:18 +1000 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZwKqjTsnlKnY7gQ9ON6+b/tV6+tgAAXI0g In-Reply-To: <20060505085943.GA11861@ipv6-3.int-evry.fr> Message-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Even I think keeping the two separate would be much easier to follow the issues. Cheers, Eranga -----Original Message----- From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] Sent: Friday, May 05, 2006 7:00 PM To: Thierry Ernst Cc: nemo@ietf.org Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Hi all, I can remember that mobileip has decided to split to work more efficiently. So maybe it would be better to do the same thing for NEMO and thus to keep focus on v6. My 2 cents, Julien On Fri, May 05, 2006 at 10:53:49AM +0200, Thierry Ernst wrote: > > Vidya, > > Some people want to concentrate on v6 work only (including me and a > couple of other who have been involved in the NEMO WG from the > beginning) and for these people there are valid reasons not to mix up > things. On the other hand, there are other people who just want to work > on NEMO without distinction between IPv4 and IPv6. There people also > have valid reasons. > > I stand on the side of those people who want to work on IPv6 specific > issues. If there are good reasons to motivate a reduction in the number > of WGs, I would rather group MIP6 and NEMO together rather than NEMOv4 > and NEMOv6 together. But the debate on "too many mobility WGs within the > IETF" should be discussed on the IETF general ML or the WG chairs ML, > not here. > > I would like to get the opinion of more (i.e. others) people whether we > should concentrate on IPv6 or not. > > Thierry. > > On Thu, 4 May 2006 23:55:24 -0700 > "Narayanan, Vidya" wrote: > > > Hi Thierry, > > At the risk of falling under the "v4-defenders" camp, I am not sure why > > there is a problem with doing the work if there is a practical need for > > it and if there are volunteers to work on the topic. When we did the > > base draft, we did mention that our desire was to work on the NEMOv4 > > base protocol - however, there was a discussion related to what happens > > if more topics come up and we had decided that we will take up those > > topics as they go based on need and consensus. > > > > And, I completely disagree that there should be a separate WG to do any > > IPv4 work - there are a lot of functional similarities between NEMOv4 > > and NEMOv6 and the work required for any additions to NEMOv4 base is > > minimal. If there is enough interest and need for getting this work > > done, it should be done here. > > > > The mobility space already has way too many WGs - way more than there > > needs to be. If anything the IETF is doing in this space is sending a > > confusing message to observers, that alone is sufficient to drive an > > observer to ultimate confusion :) The fact that a WG titled "Network > > Mobility" is working on IPv4 and IPv6 network mobility is hardly the > > reason an observer is likely to get confused! > > > > Regards, > > Vidya > > > > > -----Original Message----- > > > From: Thierry Ernst [mailto:thierry.ernst@inria.fr] > > > Sent: Wednesday, May 03, 2006 1:28 AM > > > To: nemo@ietf.org > > > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. > > > > > > > > > Dear all, > > > > > > Just a note, I remember v4-defenders stating not so long ago > > > that they would just do something basic on V4 for NEMO, but > > > now some folks are suggesting FA support, prefix allocation, > > > etc. What is next ? > > > > > > I don't personaly mind work on NEMOv4 (but I don't support > > > this), however, I do mind that the NEMO WG has a strong focus > > > on v6, and I would rather see work on v4 and v6 taking places > > > in SEPARATE working groups. Many people don't want to lose > > > their time on v4 discussions. > > > > > > I really think that melting IPv4 and IPv6 in a single working > > > group is at minimum confusing, and possibly damaging the > > > message the IETF is addressing to the world (i.e. non-IETFers > > > who follow the output of the IETF, but not the internal discussions). > > > > > > The only exception I see to this if v4-v6 interoperability > > > issues, if any. > > > > > > PS: I was unable to participate to the IETF and the > > > discussions on IETF mailing lists since mid-March until now > > > (back to normal mode now, I hope), so there are a lot of > > > important discussions in which I couldn't participate. I > > > still need to dig back into the discussions to see what other > > > important thread I missed. > > > > > > Thierry > > > > > > > > > > Tsirtsis, George wrote: > > > > > In a recent discussion on the mailing list I suggested that we > > > > > should define FA support and dynamic prefix allocation for the > > > > > NEMOv4 base solution. > > > > > > > > > > A number of people at the time seemed to be supportive of > > > the idea > > > > > and I am in the process of writing a draft on the > > > subject. Could we > > > > > extend the charter to cover these issues? > > > > > > > > I agree to request extending the Charter to deal with FA > > > support for > > > > NEMOv4. Maybe that could be simply put like: "produce IPv4 NEMO > > > > protocol based on Mobile IPv4 (basic support, FA support and prefix > > > > allocation from the foreign and/or home networks)." > > > > > > > > Or similar? Just some short phrasing. > > > > > > > > Alex > > > > > > > > > > > > > -- > > > Thierry ERNST, PhD > > > INRIA Rocquencourt Projet IMARA > > > +33 1 39 63 59 30 > > > > > > > > > > > > > > > > -- > Thierry ERNST, PhD > INRIA Rocquencourt Projet IMARA > +33 1 39 63 59 30 > > -- julien.bournelle at int-evry.fr From nemo-bounces@ietf.org Fri May 05 06:21:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbxRO-0004vs-Hn; Fri, 05 May 2006 06:21:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbxRM-0004vn-VO for nemo@ietf.org; Fri, 05 May 2006 06:21:40 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbxRL-0004ag-Kg for nemo@ietf.org; Fri, 05 May 2006 06:21:40 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k45AhLLu020284 for ; Fri, 5 May 2006 03:43:21 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k45AXdnE004032 for ; Fri, 5 May 2006 05:33:40 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 2921D865980 for ; Fri, 5 May 2006 12:21:36 +0200 (CEST) Message-ID: <445B2730.6030302@motorola.com> Date: Fri, 05 May 2006 12:21:36 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ml-nemo WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [nemo] Making NEMO... X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Dear WG members, Building moving networks with network mobility is one main goal of this Working Group. We have produced an RFC based on IPv6 and Mobile IPv6 for this. We have some interoperable implementations, validation tests and demos. It's known it is not enough to just agree on a spec and prototype it in order to obtain widespread deployment. But when the existing network mobility deployments are profitable businesses and make no use of the products of this WG there may be some questions to be raised. Two example uses of Mobile Router and NEMO that don't use IPv6 at all: http://tinyurl.com/s84r7 describes a wireless Mobile Router. http://tinyurl.com/qb7ka describes a bus with a moving network connected to sattelite. There's even a van called NEMO. Remark I do not oppose any IPv6 work, I'm doing myself lots of it from text to prototyping; but I find opposing IPv4 work in this WG to be debatable. Alex From nemo-bounces@ietf.org Fri May 05 06:32:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbxbk-0007ZU-KF; Fri, 05 May 2006 06:32:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbxbj-0007ZP-V7 for nemo@ietf.org; Fri, 05 May 2006 06:32:23 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbxbi-00058A-NP for nemo@ietf.org; Fri, 05 May 2006 06:32:23 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k45AnOvP009162; Fri, 5 May 2006 03:49:25 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k45AnehG026762; Fri, 5 May 2006 05:49:40 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 93102865980; Fri, 5 May 2006 12:32:20 +0200 (CEST) Message-ID: <445B29B4.9070001@motorola.com> Date: Fri, 05 May 2006 12:32:20 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Julien Bournelle Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <2EBB8025B6D1BA41B567DB32C1D8DB847925D9@NAEX06.na.qualcomm.com> <20060505105349.5669c002.thierry.ernst@inria.fr> <20060505085943.GA11861@ipv6-3.int-evry.fr> In-Reply-To: <20060505085943.GA11861@ipv6-3.int-evry.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Julien Bournelle wrote: > Hi all, > > I can remember that mobileip has decided to split to work more > efficiently. So maybe it would be better to do the same thing for > NEMO and thus to keep focus on v6. Julien, splitting MIP into other WGs happened at a time when there was only one WG about mobility, called just MIP. Since about 3 years there are many WGs related to mobility: mip6, mip4, mipshop, monami6, mobike, netlmm and maybe others. Netlmm and monami6 BoFs were happening at about the same time. Monami6 became a WG before netlmm and there was strong discussion and questioning about the necessity about so many mobility related WGs. It is normal to question the high number of these WGs. Because actual deployment of their output compared to other WGs (e.g. vpn or pkix WG) is really non-significant. I think the question to be asked is whether WG thinks this v4 work is important or not, not necessarily whether it should be done here or there. And when people think the v4 work is not important to counter-exemplify with v6 deployments out there. Alex From nemo-bounces@ietf.org Fri May 05 07:42:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbyhr-0003cs-2t; Fri, 05 May 2006 07:42:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbyhp-0003ck-TF for nemo@ietf.org; Fri, 05 May 2006 07:42:45 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbyhp-0008DT-8w for nemo@ietf.org; Fri, 05 May 2006 07:42:45 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 13:42:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Fri, 5 May 2006 13:42:38 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_010D_01C67049.C59F6900" Message-ID: <941BA0BF46DB8F4983FF7C8AFE800BC2044BBFFB@ftrdmel3.rd.francetelecom.fr> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZwIVF68+BiWPP8SOiiESmVm0yVXAAFHhzA From: "BINET David RD-CORE-CAE" To: "Thierry Ernst" , X-OriginalArrivalTime: 05 May 2006 11:42:39.0799 (UTC) FILETIME=[03550C70:01C67039] X-Spam-Score: 0.0 (/) X-Scan-Signature: 025f8c5000216988bfe31585db759250 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_010D_01C67049.C59F6900 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, Nemo working group deals with Network Mobility. First charter = concentrated efforts on IPv6 but I remember an IETF meeting where it was said that = IPv4 could be considered if some persons in the working group wanted to work = on such topic. Personnally, I think it is some kind of regression to = consider at this stage in Nemo working group IPv4 solutions but if some persons = or some companies want to work on IPv4, it must be considered. Maybe it is useful for a short term Nemo services deployment since very few IPv6 operational networks are deployed today, unfortunaltely ! But we also have to notice that some interoperabilty problems between = IPv4 and IPv6 nemo services may arise and will have to be considered if we go = in that way. I am not in favor of creating two separate working groups, nemov6 and nemov4, because we are trying to solve one problem, Network Mobility, independantly of IP version protocol used. I do not think that we want = to create an IPv6 IETF and an IPv4 IETF ! I did not react on Nemo proposed charter2 but I think it is a good idea = to work on proposed item: - Look into the issues and tradeoffs involved in making the network's movement visible to some mobile network nodes, by making them "NEMO aware", because it could be useful, maybe for some performance reasons, to give some information about Nemo "status" to = MNs. David =20 -----Message d'origine----- De : Thierry Ernst [mailto:thierry.ernst@inria.fr]=20 Envoy=E9 : vendredi 5 mai 2006 10:54 =C0 : nemo@ietf.org Objet : Re: [nemo] Extensions to NEMOv4 base for the Charter. Vidya,=20 Some people want to concentrate on v6 work only (including me and a = couple of other who have been involved in the NEMO WG from the beginning) and for these people there are valid reasons not to mix up things. On the other hand, there are other people who just want to work = on NEMO without distinction between IPv4 and IPv6. There people also have = valid reasons. I stand on the side of those people who want to work on IPv6 specific issues. If there are good reasons to motivate a reduction in the number = of WGs, I would rather group MIP6 and NEMO together rather than NEMOv4 and NEMOv6 together. But the debate on "too many mobility WGs within the = IETF" should be discussed on the IETF general ML or the WG chairs ML, not = here. I would like to get the opinion of more (i.e. others) people whether we should concentrate on IPv6 or not. Thierry. On Thu, 4 May 2006 23:55:24 -0700 "Narayanan, Vidya" wrote: > Hi Thierry, > At the risk of falling under the "v4-defenders" camp, I am not sure=20 > why there is a problem with doing the work if there is a practical=20 > need for it and if there are volunteers to work on the topic. When we=20 > did the base draft, we did mention that our desire was to work on the=20 > NEMOv4 base protocol - however, there was a discussion related to what = > happens if more topics come up and we had decided that we will take up = > those topics as they go based on need and consensus. >=20 > And, I completely disagree that there should be a separate WG to do=20 > any > IPv4 work - there are a lot of functional similarities between NEMOv4=20 > and NEMOv6 and the work required for any additions to NEMOv4 base is=20 > minimal. If there is enough interest and need for getting this work=20 > done, it should be done here. >=20 > The mobility space already has way too many WGs - way more than there=20 > needs to be. If anything the IETF is doing in this space is sending a=20 > confusing message to observers, that alone is sufficient to drive an=20 > observer to ultimate confusion :) The fact that a WG titled "Network=20 > Mobility" is working on IPv4 and IPv6 network mobility is hardly the=20 > reason an observer is likely to get confused! >=20 > Regards, > Vidya >=20 > > -----Original Message----- > > From: Thierry Ernst [mailto:thierry.ernst@inria.fr] > > Sent: Wednesday, May 03, 2006 1:28 AM > > To: nemo@ietf.org > > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. > >=20 > >=20 > > Dear all, > >=20 > > Just a note, I remember v4-defenders stating not so long ago that=20 > > they would just do something basic on V4 for NEMO, but now some=20 > > folks are suggesting FA support, prefix allocation, etc. What is=20 > > next ? > >=20 > > I don't personaly mind work on NEMOv4 (but I don't support this),=20 > > however, I do mind that the NEMO WG has a strong focus on v6, and I=20 > > would rather see work on v4 and v6 taking places in SEPARATE working = > > groups. Many people don't want to lose their time on v4 discussions. > >=20 > > I really think that melting IPv4 and IPv6 in a single working group=20 > > is at minimum confusing, and possibly damaging the message the IETF=20 > > is addressing to the world (i.e. non-IETFers who follow the output=20 > > of the IETF, but not the internal discussions). > >=20 > > The only exception I see to this if v4-v6 interoperability issues,=20 > > if any. > >=20 > > PS: I was unable to participate to the IETF and the discussions on=20 > > IETF mailing lists since mid-March until now (back to normal mode=20 > > now, I hope), so there are a lot of important discussions in which I = > > couldn't participate. I still need to dig back into the discussions=20 > > to see what other important thread I missed. > >=20 > > Thierry > >=20 > >=20 > > > Tsirtsis, George wrote: > > > > In a recent discussion on the mailing list I suggested that we=20 > > > > should define FA support and dynamic prefix allocation for the > > > > NEMOv4 base solution. > > > >=20 > > > > A number of people at the time seemed to be supportive of > > the idea > > > > and I am in the process of writing a draft on the > > subject. Could we > > > > extend the charter to cover these issues? > > >=20 > > > I agree to request extending the Charter to deal with FA > > support for > > > NEMOv4. Maybe that could be simply put like: "produce IPv4 NEMO=20 > > > protocol based on Mobile IPv4 (basic support, FA support and=20 > > > prefix allocation from the foreign and/or home networks)." > > >=20 > > > Or similar? Just some short phrasing. > > >=20 > > > Alex > > >=20 > >=20 > >=20 > > -- > > Thierry ERNST, PhD > > INRIA Rocquencourt Projet IMARA > > +33 1 39 63 59 30 > >=20 > >=20 > >=20 >=20 >=20 -- Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 ------=_NextPart_000_010D_01C67049.C59F6900 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISIzCCBGYw ggNOoAMCAQICAhILMA0GCSqGSIb3DQEBBQUAMFwxCzAJBgNVBAYTAkZSMRcwFQYDVQQKEw5GcmFu Y2UgVGVsZWNvbTETMBEGA1UECxMKRlRSRC1Bc3BpYzEfMB0GA1UEAxMWRlRSRCBBQyBvcGVyYXRp b25uZWxsZTAeFw0wNDAxMjYxMjUwMTJaFw0wNzAxMjUxMjUwMTJaMIGZMQswCQYDVQQGEwJGUjEX MBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQtQVNQSUMxFDASBgNVBAMTC0Rh dmlkIEJJTkVUMRgwFgYKCZImiZPyLGQBARMIRElPQjY1ODExLDAqBgkqhkiG9w0BCQEWHWRhdmlk LmJpbmV0QGZyYW5jZXRlbGVjb20uY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOdAfD l17Tp8xgXvvtVVHBB46S7x8teGbt5P6mUqmdmunJgfgwsZZlgVE/A0LiL115gkEvS1W57o5e3Isf SEjjnwYDcH7abUMZ8+jb3gYgSLJphbu5Z+cvjWhd1duZrW0ZtxFOYzpcVa5BCR10w3pnFqGw+DaE iR46xQrGGLSDeQIDAQABo4IBdjCCAXIwHQYDVR0OBBYEFCg+pLg0sW8lUCMr94tIfE76Ibs1MB8G A1UdIwQYMBaAFKeHuNCL9G/jwcDa7Y604KcQKfzYMIGSBgNVHR8EgYowgYcwR6BFoEOGQWh0dHA6 Ly9sdWNpZmVyLnJkLmZyYW5jZXRlbGVjb20uZnIvcmV2b3F1ZXMvY3Jsb3BlcmF0aW9ubmVsbGUu Y3JsMDygOqA4hjZodHRwOi8vcGtpLWwucmQuZnJhbmNldGVsZWNvbS5mci9jcmxvcGVyYXRpb25u ZWxsZS5jcmwwDgYDVR0PAQH/BAQDAgQwMBMGA1UdJQQMMAoGCCsGAQUFBwMEMBEGCWCGSAGG+EIB AQQEAwIFIDAoBgNVHREEITAfgR1kYXZpZC5iaW5ldEBmcmFuY2V0ZWxlY29tLmNvbTA5BglghkgB hvhCAQ0ELBYqQ2VydGlmaWNhdCBkZSBDaGlmZnJlbWVudCBwb3VyIERhdmlkIEJJTkVUMA0GCSqG SIb3DQEBBQUAA4IBAQDqPf4OEZt3wUJvLlyGQhzjaA0Ij/Rc4PSMkWEPZ+/OHZIxnSMScglLflQG q608ug9/lMjdrqSlkbfSYG+sBp4/RAm+3N5f5AW0/kEAmjcBtnQZmhXtk77P4PjPZUiRSBHC7XJQ MbsBGONF2VxvrY5izil9L3uDSc6GTkfcjtvgfqK5kz3iRfiY3wCn92XL/VvHbMW8crqDiguwta3y tvqMAAQy66llT1TGliFXc4QyDwZWBGB0TNufQzpFwsDjUST7JnSZ/y1E7mcuFy+vG3tN34Fs+6KW TPniNhqsIjxc3SwoHwFNJhjCsPhl+libtP0l7YXJDKLSBlsqPGAC8aCOMIIEgDCCA2igAwIBAgIB ADANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJGUjEXMBUGA1UEChMORnJhbmNlIFRlbGVjb20x EzARBgNVBAsTCkZUUkQtQXNwaWMxFzAVBgNVBAMTDkZUUkQgQUMgUmFjaW5lMB4XDTAyMTAwMzA3 MDc1OFoXDTEyMTAwMjA3MDc1OFowVDELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZyYW5jZSBUZWxl Y29tMRMwEQYDVQQLEwpGVFJELUFzcGljMRcwFQYDVQQDEw5GVFJEIEFDIFJhY2luZTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAN81v0NOnfyYxmzODVMnAd441zKVC749cLug6OmEhid7 QdBAdRJeMoMonu9uWdOQCuyvdG67VCsA686aSbDPyTTozTeFwZnRj3byhZrcobqJ2Sx0rA2PjQmp ZukgSS3l8Cw0OnZO5lpQZSBfOJ4F0ORje7IWrQb8QbpPt/cbCPie7ZjhUilr3js2TSWPAUrhZJKp 0NNSHxk5V+loB+xSLqVrKdYWloiq4RrjEpXL8792NMwR6URm9rwAOJu0LwYU07q6iLKOI106qTvK ejLVxAL5+sT5YWK/ubi8hdLhW8u9CxOTmSfJ9pY8A1FiqPyWcJ3gHSz2ItRvH2mJq1c/IuMCAwEA AaOCAVswggFXMBIGA1UdEwEB/wQIMAYBAf8CAQEwHQYDVR0OBBYEFLdJ7pNBIn/ZqJeVJz5kZp6u GD8DMHwGA1UdIwR1MHOAFLdJ7pNBIn/ZqJeVJz5kZp6uGD8DoVikVjBUMQswCQYDVQQGEwJGUjEX MBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQtQXNwaWMxFzAVBgNVBAMTDkZU UkQgQUMgUmFjaW5lggEAMA4GA1UdDwEB/wQEAwIBBjCBgAYDVR0fBHkwdzA/oD2gO4Y5aHR0cDov L2x1Y2lmZXIucmQuZnJhbmNldGVsZWNvbS5mci9yZXZvcXVlcy9jcmxyYWNpbmUuY3JsMDSgMqAw hi5odHRwOi8vcGtpLWwucmQuZnJhbmNldGVsZWNvbS5mci9jcmxyYWNpbmUuY3JsMBEGCWCGSAGG +EIBAQQEAwIABzANBgkqhkiG9w0BAQUFAAOCAQEAaLy9uyUJDjvHSevW9ldaZsG+zl7Q1J+PnMPO CffYHdKHI6/rtzp0S+rUGMWEdF82FxGnGaIT0/gc6p+2gPv+/3YxGWgb0aBK5xEjxIefmhA7rGKx purGq4PmEj4b6Ye/Z9hTBFlFI2Ixu51zk4hEvHoky8oFdQdzb29q541pFBsP7qbidxi62zlqxE7S 4Zx+3KzkegDJIJ6k4XXK307jUYJBbnC7aBodST6P2I8qTXclG7qTkKf/wzy1y8DSyRqNABoX6XLe QyM9omGrKARhdCgsMULoPNRAMI1N1n3DlDCKfWjJl7WVaaywyKGVmiSKInbYtM5XB2hoaErJ1ZEk 3TCCBIgwggNwoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCRlIxFzAVBgNVBAoT DkZyYW5jZSBUZWxlY29tMRMwEQYDVQQLEwpGVFJELUFzcGljMRcwFQYDVQQDEw5GVFJEIEFDIFJh Y2luZTAeFw0wMjEwMDMwNzE1MjBaFw0xMjEwMDIwNzE1MjBaMFwxCzAJBgNVBAYTAkZSMRcwFQYD VQQKEw5GcmFuY2UgVGVsZWNvbTETMBEGA1UECxMKRlRSRC1Bc3BpYzEfMB0GA1UEAxMWRlRSRCBB QyBvcGVyYXRpb25uZWxsZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAPKErrcyQf+t gRGBsiBQKGGnvheMF+E74XARkkDrNnL/oA5w6e96Nj5eF7TdoiE7AIQRvOUrJkI9xP74szDUP/CP BPVxxL0855pyoH/qBcgdVCVWBDKGGroc9A5OeXsKCietb1y4+PV5JeQVw3e41vqJ06Ut81QYPkZ8 4uJSIiRNoaZG+dBYBOfP8pL3Gj2jnX53eslfdiXjslMk7icbvcvAuBlzHU/LkLNHZV/iEJGGfj3X 8kOMF0e3v1OlAX+TXEYlvA46wnffqVMIgiiFbAHPOBMIqOMOVQXx2SdokRcpAsHtb8LcaLrSseDf /bmzvhkufp6qYoUoNC9s4g48J9ECAwEAAaOCAVswggFXMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYD VR0OBBYEFKeHuNCL9G/jwcDa7Y604KcQKfzYMHwGA1UdIwR1MHOAFLdJ7pNBIn/ZqJeVJz5kZp6u GD8DoVikVjBUMQswCQYDVQQGEwJGUjEXMBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzARBgNVBAsT CkZUUkQtQXNwaWMxFzAVBgNVBAMTDkZUUkQgQUMgUmFjaW5lggEAMA4GA1UdDwEB/wQEAwIBBjCB gAYDVR0fBHkwdzA/oD2gO4Y5aHR0cDovL2x1Y2lmZXIucmQuZnJhbmNldGVsZWNvbS5mci9yZXZv cXVlcy9jcmxyYWNpbmUuY3JsMDSgMqAwhi5odHRwOi8vcGtpLWwucmQuZnJhbmNldGVsZWNvbS5m ci9jcmxyYWNpbmUuY3JsMBEGCWCGSAGG+EIBAQQEAwIABzANBgkqhkiG9w0BAQUFAAOCAQEAto0W YTNPzNN/XrdT255IwPKbYLZD/YRfQwwcbB4Ff6F9Km+J69KLpZZZx0Z/8rTsjVFc3A2QHTMy4OB2 vJ1qPMUO+JlahqhHbun4GHxM0xl9qzGAaveo5xvIMqHYUnnRZ6s8LadQVbkcHxgw4oPkwRGbKoGy T6WEdFhWmn4BOBuwURN/JL4LynTkwHEklDbheEyAVTOrJIbZ88rWAKOoSzDhD+Wu/ZVvbcYuYNev qafJceD1g6rQhaz7O4HnGdmiau3/ayV7ZNDqxnm0Sfli4r4ltTi6GkxmEoT7X1JdKuH0na0ZdYRo qxRopM8uLsFMOHc46GT7HwsNcqXctRpORDCCBKUwggONoAMCAQICAhIKMA0GCSqGSIb3DQEBBQUA MFwxCzAJBgNVBAYTAkZSMRcwFQYDVQQKEw5GcmFuY2UgVGVsZWNvbTETMBEGA1UECxMKRlRSRC1B c3BpYzEfMB0GA1UEAxMWRlRSRCBBQyBvcGVyYXRpb25uZWxsZTAeFw0wNDAxMjYxMjUwMTFaFw0w NzAxMjUxMjUwMTFaMIGZMQswCQYDVQQGEwJGUjEXMBUGA1UEChMORnJhbmNlIFRlbGVjb20xEzAR BgNVBAsTCkZUUkQtQVNQSUMxFDASBgNVBAMTC0RhdmlkIEJJTkVUMRgwFgYKCZImiZPyLGQBARMI RElPQjY1ODExLDAqBgkqhkiG9w0BCQEWHWRhdmlkLmJpbmV0QGZyYW5jZXRlbGVjb20uY29tMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDVMuAQQtYZ/mxyQbRxXgI4Kp/z1/xlEYvwolFN91nz FxOwBD3a04aCkJ4CXmQcCwII5z2CpS9Jzso3LJk826y+PUnazPsjbm2UGl8y7wi+wX9beiKw0OJr YcUk60xeJ5hd/gjQDW8yJMZc3EF5j/31tbsI7s9GheBdRlcva5HzywIDAQABo4IBtTCCAbEwHQYD VR0OBBYEFKswHhI0e7oquK+GIX1gCr+Nk/heMB8GA1UdIwQYMBaAFKeHuNCL9G/jwcDa7Y604KcQ KfzYMIGSBgNVHR8EgYowgYcwR6BFoEOGQWh0dHA6Ly9sdWNpZmVyLnJkLmZyYW5jZXRlbGVjb20u ZnIvcmV2b3F1ZXMvY3Jsb3BlcmF0aW9ubmVsbGUuY3JsMDygOqA4hjZodHRwOi8vcGtpLWwucmQu ZnJhbmNldGVsZWNvbS5mci9jcmxvcGVyYXRpb25uZWxsZS5jcmwwDgYDVR0PAQH/BAQDAgbAMCkG A1UdJQQiMCAGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNxQCAjARBglghkgBhvhCAQEEBAMC BaAwUwYDVR0RBEwwSqApBgorBgEEAYI3FAIDoBsMGWJpbmV0QHJkLmZyYW5jZXRlbGVjb20uZnKB HWRhdmlkLmJpbmV0QGZyYW5jZXRlbGVjb20uY29tMDcGCWCGSAGG+EIBDQQqFihDZXJ0aWZpY2F0 IGRlIFNpZ25hdHVyZSBwb3VyIERhdmlkIEJJTkVUMA0GCSqGSIb3DQEBBQUAA4IBAQB9NRmWQwKo uhTf77JMc76SI/Znjt8CAsDFkmJ1mdoSi3Tf8e2heC27V0/kqWoAMjQZuRJ3BrWNdl75weyucBtQ DUxumlfMAsxQ/c1RTvWMHCLvFjXssXySQXUIdihLexrxpJGSjnQ6VNKQFRqUeqxDDLR8CTVUZXPE TYbyEthuazQCVJ7pcON+7S8K6hPmJlH8gGgtKMBDf02WnLyQ0Z40wWTgQXRyQuqi42iXtSe02RLI 0FqI3caYnOEp3t7ojZH+y0WbOBg309VpZNq1ynh1zs8KifBVUPgKEDVNUnHBKXzxQfwOcPZLQDDI 679KVrZyyU+6/SMn1fpMERWx2xngMYICujCCArYCAQEwYjBcMQswCQYDVQQGEwJGUjEXMBUGA1UE ChMORnJhbmNlIFRlbGVjb20xEzARBgNVBAsTCkZUUkQtQXNwaWMxHzAdBgNVBAMTFkZUUkQgQUMg b3BlcmF0aW9ubmVsbGUCAhIKMAkGBSsOAwIaBQCgggGuMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA2MDUwNTExNDIzN1owIwYJKoZIhvcNAQkEMRYEFB7WcJE0tb3+ zHFeigb0k0g5FJY6MGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMHEGCSsGAQQBgjcQBDFkMGIwXDELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZyYW5jZSBUZWxl Y29tMRMwEQYDVQQLEwpGVFJELUFzcGljMR8wHQYDVQQDExZGVFJEIEFDIG9wZXJhdGlvbm5lbGxl AgISCzBzBgsqhkiG9w0BCRACCzFkoGIwXDELMAkGA1UEBhMCRlIxFzAVBgNVBAoTDkZyYW5jZSBU ZWxlY29tMRMwEQYDVQQLEwpGVFJELUFzcGljMR8wHQYDVQQDExZGVFJEIEFDIG9wZXJhdGlvbm5l bGxlAgISCzANBgkqhkiG9w0BAQEFAASBgMGfEOXBSmS9cX1IXOGDkJ+cx5W3Y+Yf2C7R8IgyDaHw dMtzH5cGWc5SvHwSDPTGNa67RKdoFrXxXXjPM2hN7Weit/VbGO2eHlbQSp2C1//KGRgIFTGOhH0z WjWxBMBk8rREUr7kcvG528t50Vussv2EVyhMwk9nqjYN+hTMdv5JAAAAAAAA ------=_NextPart_000_010D_01C67049.C59F6900-- From nemo-bounces@ietf.org Fri May 05 08:01:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbz03-0001Up-Fe; Fri, 05 May 2006 08:01:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbyzu-0001H0-Mp for nemo@ietf.org; Fri, 05 May 2006 08:01:26 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbyzt-0000Ya-Ak for nemo@ietf.org; Fri, 05 May 2006 08:01:26 -0400 Received: from dhcp-rocq-97.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k45C1LN7027397 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 May 2006 14:01:21 +0200 Date: Fri, 5 May 2006 14:02:20 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Making NEMO... Message-Id: <20060505140220.3ae4e9d4.thierry.ernst@inria.fr> In-Reply-To: <445B2730.6030302@motorola.com> References: <445B2730.6030302@motorola.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 445B3E91.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Alex, what are you talking about by saying "make no use of the products of this WG there may be some questions to be raised" , that RFC 3963 is not used ? There exists concurrent solutions not based on RFC 3963, but it does mean that the work being done by this WG are not used. If you simply intend to be provocative, I would like to ask to refrain doing this (chair's hat on). Thierry On Fri, 05 May 2006 12:21:36 +0200 Alexandru Petrescu wrote: > Dear WG members, > > Building moving networks with network mobility is one main goal of > this Working Group. We have produced an RFC based on IPv6 and Mobile > IPv6 for this. We have some interoperable implementations, validation > tests and demos. > > It's known it is not enough to just agree on a spec and prototype it in > order to obtain widespread deployment. But when the existing network > mobility deployments are profitable businesses and make no use of the > products of this WG there may be some questions to be raised. > > Two example uses of Mobile Router and NEMO that don't use IPv6 at all: > > http://tinyurl.com/s84r7 describes a wireless Mobile Router. > > http://tinyurl.com/qb7ka describes a bus with a moving network > connected to sattelite. There's even a van called NEMO. > > Remark I do not oppose any IPv6 work, I'm doing myself lots of it from > text to prototyping; but I find opposing IPv4 work in this WG to be > debatable. > > Alex > > -- Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Fri May 05 08:12:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbzA8-00084g-RO; Fri, 05 May 2006 08:12:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbzA7-00084T-Uz for nemo@ietf.org; Fri, 05 May 2006 08:11:59 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbzA7-00011A-JG for nemo@ietf.org; Fri, 05 May 2006 08:11:59 -0400 Received: from dhcp-rocq-97.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k45CBwVg028310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 May 2006 14:11:59 +0200 Date: Fri, 5 May 2006 14:12:58 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Message-Id: <20060505141258.6bf01bc3.thierry.ernst@inria.fr> In-Reply-To: <445B29B4.9070001@motorola.com> References: <2EBB8025B6D1BA41B567DB32C1D8DB847925D9@NAEX06.na.qualcomm.com> <20060505105349.5669c002.thierry.ernst@inria.fr> <20060505085943.GA11861@ipv6-3.int-evry.fr> <445B29B4.9070001@motorola.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 445B410E.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org NEMOv4 could not be taken care of the MIP4 WG, so no new WG would be needed, but v4 and v6 work would be addressed by the most appropriate WG. The people supporting NEMOv4 work never considered that possibility ? Thierry On Fri, 05 May 2006 12:32:20 +0200 Alexandru Petrescu wrote: > Julien Bournelle wrote: > > Hi all, > > > > I can remember that mobileip has decided to split to work more > > efficiently. So maybe it would be better to do the same thing for > > NEMO and thus to keep focus on v6. > > Julien, splitting MIP into other WGs happened at a time when there was > only one WG about mobility, called just MIP. > > Since about 3 years there are many WGs related to mobility: mip6, mip4, > mipshop, monami6, mobike, netlmm and maybe others. Netlmm and monami6 > BoFs were happening at about the same time. Monami6 became a WG before > netlmm and there was strong discussion and questioning about the > necessity about so many mobility related WGs. > > It is normal to question the high number of these WGs. Because actual > deployment of their output compared to other WGs (e.g. vpn or pkix WG) > is really non-significant. > > I think the question to be asked is whether WG thinks this v4 work is > important or not, not necessarily whether it should be done here or > there. And when people think the v4 work is not important to > counter-exemplify with v6 deployments out there. > > Alex > -- Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Fri May 05 08:23:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbzLY-00029t-SF; Fri, 05 May 2006 08:23:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbzLX-00029n-CT for nemo@ietf.org; Fri, 05 May 2006 08:23:47 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbzLW-0001Ii-5N for nemo@ietf.org; Fri, 05 May 2006 08:23:47 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k45Cen0p000719; Fri, 5 May 2006 05:40:49 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k45CfWB8027069; Fri, 5 May 2006 07:41:33 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 16B6F865980; Fri, 5 May 2006 14:23:41 +0200 (CEST) Message-ID: <445B43CD.6070904@motorola.com> Date: Fri, 05 May 2006 14:23:41 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <2EBB8025B6D1BA41B567DB32C1D8DB847925D9@NAEX06.na.qualcomm.com> <20060505105349.5669c002.thierry.ernst@inria.fr> <20060505085943.GA11861@ipv6-3.int-evry.fr> <445B29B4.9070001@motorola.com> <20060505141258.6bf01bc3.thierry.ernst@inria.fr> In-Reply-To: <20060505141258.6bf01bc3.thierry.ernst@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thierry Ernst wrote: > > NEMOv4 could not be taken care of the MIP4 WG, so no new WG would be > needed, but v4 and v6 work would be addressed by the most > appropriate WG. Do you mean "could" or "could not"? I'm not sure. Before the NEMO WG was even asked (and thus long before it approved) we went both to MIP4 WG Chair and to Internet Area AD at that time (and today we'd even go to Mobility sub-Area AD) and asked where to try this work. For MIP4 the Chair asked whether we've tried here; for Internet AD we've been informally indicated towards here too. It's natural, whenever one says "network mobility" people think NEMO WG. Currently, the base v4 nemo spec is WG item in this WG, as INFORMATIONAL, with ongoing feedback on this WG. The v4 and v6 mobility transition work is currently addressed only by the mip6trans, which is not a WG but a DT. They went to v6ops WG and were directed to mobility WGs. But there are too many WGs, so there's a common nemo-mip6 DT. Alex From nemo-bounces@ietf.org Fri May 05 08:36:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbzY6-0007hn-OK; Fri, 05 May 2006 08:36:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FbzY4-0007hc-Qb for nemo@ietf.org; Fri, 05 May 2006 08:36:44 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FbzY4-0001vP-EV for nemo@ietf.org; Fri, 05 May 2006 08:36:44 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k45CaYqP009273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 5 May 2006 05:36:35 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k45CaYr3012713; Fri, 5 May 2006 05:36:34 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 05:36:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Fri, 5 May 2006 05:36:29 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0026BB295@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZwPSh1jO29bdx5RrCNf1e9vm2rxAAAUX0g From: "Tsirtsis, George" To: "Thierry Ernst" , X-OriginalArrivalTime: 05 May 2006 12:36:34.0581 (UTC) FILETIME=[8B699C50:01C67040] X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thierry, Your last e-mail is a bit confusing. Did you mean to say that the NEMOv4 could be taken care in the MIP4 WG? If that is what you said, then yes, it could be done there but it would be weird to do so. Network Mobility is Network Mobility (v4 or v6). Talking about confusing the observer... I find the desire to work on v4 only or v6 only issues narrow minded. We still exist in an IPv4 world and when IPv6 is deployed we will exist in a dual stack world for a long, long time. Why do people think that it is a good idea to "focus" on one version of IP or another is a mystery.=20 But even if some people do want to have IPv6 only "focus", the argument that a discussion about IPv4 would "break their concentration" and "cause them to loose track of the important threads" is very, very lame. Come one guys, be serious.=20 George =20 > -----Original Message----- > From: Thierry Ernst [mailto:thierry.ernst@inria.fr] > Sent: Friday, May 05, 2006 8:13 AM > To: nemo@ietf.org > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >=20 >=20 >=20 > NEMOv4 could not be taken care of the MIP4 WG, so no new WG would be > needed, but v4 and v6 work would be addressed by the most appropriate > WG. >=20 > The people supporting NEMOv4 work never considered that possibility ? >=20 > Thierry >=20 > On Fri, 05 May 2006 12:32:20 +0200 > Alexandru Petrescu wrote: >=20 > > Julien Bournelle wrote: > > > Hi all, > > > > > > I can remember that mobileip has decided to split to work more > > > efficiently. So maybe it would be better to do the same thing for > > > NEMO and thus to keep focus on v6. > > > > Julien, splitting MIP into other WGs happened at a time when there was > > only one WG about mobility, called just MIP. > > > > Since about 3 years there are many WGs related to mobility: mip6, mip4, > > mipshop, monami6, mobike, netlmm and maybe others. Netlmm and monami6 > > BoFs were happening at about the same time. Monami6 became a WG before > > netlmm and there was strong discussion and questioning about the > > necessity about so many mobility related WGs. > > > > It is normal to question the high number of these WGs. Because actual > > deployment of their output compared to other WGs (e.g. vpn or pkix WG) > > is really non-significant. > > > > I think the question to be asked is whether WG thinks this v4 work is > > important or not, not necessarily whether it should be done here or > > there. And when people think the v4 work is not important to > > counter-exemplify with v6 deployments out there. > > > > Alex > > >=20 >=20 > -- > Thierry ERNST, PhD > INRIA Rocquencourt Projet IMARA > +33 1 39 63 59 30 >=20 From nemo-bounces@ietf.org Fri May 05 08:50:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbzl3-0006lA-6c; Fri, 05 May 2006 08:50:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbzl2-0006l5-Jh for nemo@ietf.org; Fri, 05 May 2006 08:50:08 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbzl1-0002e0-7H for nemo@ietf.org; Fri, 05 May 2006 08:50:08 -0400 Received: from dhcp-rocq-97.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k45CntsP032110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 May 2006 14:49:55 +0200 Date: Fri, 5 May 2006 14:50:55 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Message-Id: <20060505145055.2ee9fe2d.thierry.ernst@inria.fr> In-Reply-To: <445B43CD.6070904@motorola.com> References: <2EBB8025B6D1BA41B567DB32C1D8DB847925D9@NAEX06.na.qualcomm.com> <20060505105349.5669c002.thierry.ernst@inria.fr> <20060505085943.GA11861@ipv6-3.int-evry.fr> <445B29B4.9070001@motorola.com> <20060505141258.6bf01bc3.thierry.ernst@inria.fr> <445B43CD.6070904@motorola.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 445B49F3.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, > > NEMOv4 could not be taken care of the MIP4 WG, so no new WG would be > > needed, but v4 and v6 work would be addressed by the most > > appropriate WG. > > Do you mean "could" or "could not"? I'm not sure. Typo, I meant "NEMOv4 could be taken care of the MIP4 WG". > Before the NEMO WG was even asked (and thus long before it approved) we > went both to MIP4 WG Chair and to Internet Area AD at that time (and > today we'd even go to Mobility sub-Area AD) and asked where to try this > work. For MIP4 the Chair asked whether we've tried here; for Internet > AD we've been informally indicated towards here too. It's natural, > whenever one says "network mobility" people think NEMO WG. That depends on the interpretation of people, and a few voices today said that they would prefer not dealing with v4 issues. > Currently, the base v4 nemo spec is WG item in this WG, as > INFORMATIONAL, with ongoing feedback on this WG. Hold on, at the time we accepted this work item, we (both chairs as far as I can remember) worried that more work items would came up, and it was decided to do this v4 spec only, and only it, and keep it as informational so that this would not give more burden to the WG. So, if that was a strategic game to get more work being accepted later once the 1st work item was done, I don't play it. > The v4 and v6 mobility transition work is currently addressed only by > the mip6trans, which is not a WG but a DT. They went to v6ops WG and > were directed to mobility WGs. But there are too many WGs, so there's a > common nemo-mip6 DT. Not quite. The draft you are refering to is a WG item, that belongs to MIP6 and NEMO WGs, this is why the draft is named as draft-ietf-mip6-nemo and listed in both WG charters. As I said earlier in this thread, there is a difference between transition from v4 to v6 and plain v4 work. Thierry. From nemo-bounces@ietf.org Fri May 05 09:02:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbzx1-0008Qd-M4; Fri, 05 May 2006 09:02:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbzx0-0008QY-4L for nemo@ietf.org; Fri, 05 May 2006 09:02:30 -0400 Received: from p-mail1.rd.francetelecom.com ([195.101.245.15]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbzwz-00039B-NB for nemo@ietf.org; Fri, 05 May 2006 09:02:30 -0400 Received: from ftrdmel3.rd.francetelecom.fr ([10.193.117.155]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 15:02:18 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Fri, 5 May 2006 15:02:15 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZwPSh1jO29bdx5RrCNf1e9vm2rxAAAUX0gAACpdHA= From: "COMBES Jean-Michel RD-MAPS-ISS" To: "Tsirtsis, George" , "Thierry Ernst" , X-OriginalArrivalTime: 05 May 2006 13:02:18.0335 (UTC) FILETIME=[238FC6F0:01C67044] X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi George, > -----Original Message----- > From: Tsirtsis, George [mailto:tsirtsis@qualcomm.com]=20 > Sent: Friday, May 05, 2006 2:36 PM > To: Thierry Ernst; nemo@ietf.org > Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. >=20 > Thierry, >=20 > Your last e-mail is a bit confusing. Did you mean to say that=20 > the NEMOv4 could be taken care in the MIP4 WG? >=20 > If that is what you said, then yes, it could be done there=20 > but it would be weird to do so. Network Mobility is Network=20 > Mobility (v4 or v6). > Talking about confusing the observer... >=20 > I find the desire to work on v4 only or v6 only issues narrow=20 > minded. We still exist in an IPv4 world and when IPv6 is=20 > deployed we will exist in a dual stack world for a long, long=20 > time. Why do people think that it is a good idea to "focus"=20 > on one version of IP or another is a mystery.=20 >=20 > But even if some people do want to have IPv6 only "focus",=20 > the argument that a discussion about IPv4 would "break their=20 > concentration" and "cause them to loose track of the=20 > important threads" is very, very lame. > Come one guys, be serious.=20 It is totally serious! Just think about the number of threads where the subject of the email was not about what was the text inside it .... the consequences are that main issues may be missed by people. Another point is regarding the fact that you may have two sessions in an IETF meeting that are in parallel: generally, you follow always the one where there more topics in scope with your activities. So the consequences are that people will become less active in NEMO. To summarize my point of view: I am only afraid that will gain in quantity vs quality if all the works about NEMO (v4+v6) will be done in the same WG. >=20 > George >=20 Best regards. France Telecom - R&D Division - MAPS/NSS =20 Jean-Michel COMBES, Internet/Intranet Security E-Mail: jeanmichel.combes@francetelecom.com Phone: +33 (0)1 45 29 45 94 Fax: +33 (0)1 45 29 65 19 Mobile: +33 (0)6 07 29 30 16=20 =20 >=20 > =20 > > -----Original Message----- > > From: Thierry Ernst [mailto:thierry.ernst@inria.fr] > > Sent: Friday, May 05, 2006 8:13 AM > > To: nemo@ietf.org > > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. > >=20 > >=20 > >=20 > > NEMOv4 could not be taken care of the MIP4 WG, so no new WG=20 > would be=20 > > needed, but v4 and v6 work would be addressed by the most=20 > appropriate=20 > > WG. > >=20 > > The people supporting NEMOv4 work never considered that=20 > possibility ? > >=20 > > Thierry > >=20 > > On Fri, 05 May 2006 12:32:20 +0200 > > Alexandru Petrescu wrote: > >=20 > > > Julien Bournelle wrote: > > > > Hi all, > > > > > > > > I can remember that mobileip has decided to split to work more=20 > > > > efficiently. So maybe it would be better to do the same=20 > thing for=20 > > > > NEMO and thus to keep focus on v6. > > > > > > Julien, splitting MIP into other WGs happened at a time when there > was > > > only one WG about mobility, called just MIP. > > > > > > Since about 3 years there are many WGs related to mobility: mip6, > mip4, > > > mipshop, monami6, mobike, netlmm and maybe others. Netlmm and > monami6 > > > BoFs were happening at about the same time. Monami6 became a WG > before > > > netlmm and there was strong discussion and questioning about the=20 > > > necessity about so many mobility related WGs. > > > > > > It is normal to question the high number of these WGs. Because > actual > > > deployment of their output compared to other WGs (e.g. vpn or pkix > WG) > > > is really non-significant. > > > > > > I think the question to be asked is whether WG thinks this v4 work > is > > > important or not, not necessarily whether it should be=20 > done here or=20 > > > there. And when people think the v4 work is not important to=20 > > > counter-exemplify with v6 deployments out there. > > > > > > Alex > > > > >=20 > >=20 > > -- > > Thierry ERNST, PhD > > INRIA Rocquencourt Projet IMARA > > +33 1 39 63 59 30 > >=20 >=20 >=20 >=20 From nemo-bounces@ietf.org Fri May 05 09:03:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbzy3-0000IP-7y; Fri, 05 May 2006 09:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fbzy2-0000Fy-3c for nemo@ietf.org; Fri, 05 May 2006 09:03:34 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fbzy1-0003AL-Mf for nemo@ietf.org; Fri, 05 May 2006 09:03:34 -0400 Received: from dhcp-rocq-97.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k45D3WWt001177 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 May 2006 15:03:33 +0200 Date: Fri, 5 May 2006 15:04:32 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Message-Id: <20060505150432.21b4cf4e.thierry.ernst@inria.fr> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0026BB295@NAEX06.na.qualcomm.com> References: <1487A357FD2ED544B8AD29E528FF9DF0026BB295@NAEX06.na.qualcomm.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 445B4D24.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi George, > Your last e-mail is a bit confusing. Did you mean to say that the NEMOv4 > could be taken care in the MIP4 WG? Yes, I meant this. > If that is what you said, then yes, it could be done there but it would > be weird to do so. Network Mobility is Network Mobility (v4 or v6). > Talking about confusing the observer... Depends where the observer stands, if the observer stands on the IPv6 side, he certainly wants more IPv6 issues to be addressed and not being diverted by IPv4 issues. Tell me why MobileIP was divided between MIP4 and MIP6. Working on both IPv4 and IPv6 in the same WG would make the overall output less effective and delay deployment of the technologies (and here, I mean it would delay the deployment of both NEMOv4 and NEMOv6, though I'm more concerned about the v6 deployment). Let's not forget that the NEMO work is based on Mobile IP work. The IPv4 expertise is in the MIPv4 WG, not in the NEMO WG (of course, you could argue that the IPv4 expertise coud be brought in the NEMO WG, but this doesn't mean MIPv4 shouldn't be considered in the 1st place). > I find the desire to work on v4 only or v6 only issues narrow minded. We > still exist in an IPv4 world and when IPv6 is deployed we will exist in > a dual stack world for a long, long time. Why do people think that it is > a good idea to "focus" on one version of IP or another is a mystery. When I said "focusing" I meant for the NEMO WG, not for the entire IETF. IPv4 WGs are better for this work being done. > But even if some people do want to have IPv6 only "focus", the argument > that a discussion about IPv4 would "break their concentration" and > "cause them to loose track of the important threads" is very, very lame. > Come one guys, be serious. I'm very serious, and other people on this thread have supported this view that it would. Thierry. From nemo-bounces@ietf.org Fri May 05 09:06:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc00a-0002k5-Ju; Fri, 05 May 2006 09:06:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc00Z-0002k0-4t for nemo@ietf.org; Fri, 05 May 2006 09:06:11 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc00W-0003Fq-RL for nemo@ietf.org; Fri, 05 May 2006 09:06:11 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k45DN7Qh010253; Fri, 5 May 2006 06:23:07 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k45DKOKA021442; Fri, 5 May 2006 08:20:24 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 9BB7A865980; Fri, 5 May 2006 15:06:04 +0200 (CEST) Message-ID: <445B4DBC.2010306@motorola.com> Date: Fri, 05 May 2006 15:06:04 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <2EBB8025B6D1BA41B567DB32C1D8DB847925D9@NAEX06.na.qualcomm.com> <20060505105349.5669c002.thierry.ernst@inria.fr> <20060505085943.GA11861@ipv6-3.int-evry.fr> <445B29B4.9070001@motorola.com> <20060505141258.6bf01bc3.thierry.ernst@inria.fr> <445B43CD.6070904@motorola.com> <20060505145055.2ee9fe2d.thierry.ernst@inria.fr> In-Reply-To: <20060505145055.2ee9fe2d.thierry.ernst@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thierry Ernst wrote: > Hi, > >>> NEMOv4 could not be taken care of the MIP4 WG, so no new WG would >>> be needed, but v4 and v6 work would be addressed by the most >>> appropriate WG. >> Do you mean "could" or "could not"? I'm not sure. > > Typo, I meant "NEMOv4 could be taken care of the MIP4 WG". Ok. As previously, we've tried it, we've been directed here. >> Before the NEMO WG was even asked (and thus long before it >> approved) we went both to MIP4 WG Chair and to Internet Area AD at >> that time (and today we'd even go to Mobility sub-Area AD) and >> asked where to try this work. For MIP4 the Chair asked whether >> we've tried here; for Internet AD we've been informally indicated >> towards here too. It's natural, whenever one says "network >> mobility" people think NEMO WG. > > That depends on the interpretation of people, and a few voices today > said that they would prefer not dealing with v4 issues. > >> Currently, the base v4 nemo spec is WG item in this WG, as >> INFORMATIONAL, with ongoing feedback on this WG. > > Hold on, at the time we accepted this work item, we (both chairs as > far as I can remember) worried that more work items would came up, > and it was decided to do this v4 spec only, and only it, and keep it > as informational so that this would not give more burden to the WG. I agree you expressed this. Co-authors and myself didn't expect much public feedback on NEMOv4 in NEMO. But some of it happened. That's why now when you asked "what next?" I only say "whatever other people need and agree to work on". > So, if that was a strategic game to get more work being accepted > later once the 1st work item was done, I don't play it. Thierry, this is not about secret strategies or secret agendas. I'm all for openness too here. It's how things are supposed to happen in IETF. Somebody posts an idea, somebody else finds it good, others bad and so on. The technical feedback on NEMOv4 came here naturally, there's no secret plan from either side. >> The v4 and v6 mobility transition work is currently addressed only >> by the mip6trans, which is not a WG but a DT. They went to v6ops >> WG and were directed to mobility WGs. But there are too many WGs, >> so there's a common nemo-mip6 DT. > > Not quite. The draft you are refering to is a WG item, that belongs > to MIP6 and NEMO WGs, this is why the draft is named as > draft-ietf-mip6-nemo and listed in both WG charters. Thierry, indeed it is a WG item, belongs to both MIP6 and NEMO, I don't disagree with that. > As I said earlier in this thread, there is a difference between > transition from v4 to v6 and plain v4 work. I agree with you, but differently. There are things that DS-MIPv6 (result of mip6trans) does not address, and could only be addressed _if_ NEMOv4 existed as extensions of RFC3344, a "plain IPv4 work". (1) DS-MIPv6 running on a Mobile Router does not allow for LFN to have ongoing sessions at its IPv4 permanent address and (2) DS-MIPv6 does not provide for a transition method where the HA network is completely v6 and the access v4. I hope this is clear, otherwise I can explain. I realized this by looking at both MIP6 WG and NEMO WG. Discussions of DS-MIPv6 naturally happen only on the MIP6 mailing list (although a WG item here too). It's more difficult to follow two mailing lists than one, especially vor v4-v6 transitioning. Alex From nemo-bounces@ietf.org Fri May 05 10:07:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc0y0-0001A7-9O; Fri, 05 May 2006 10:07:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc0xy-0001A2-Dj for nemo@ietf.org; Fri, 05 May 2006 10:07:34 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc0xx-0005XH-50 for nemo@ietf.org; Fri, 05 May 2006 10:07:34 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k45EOObW026167; Fri, 5 May 2006 07:24:24 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k45EOfFp026550; Fri, 5 May 2006 09:24:42 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 172FE865980; Fri, 5 May 2006 16:07:21 +0200 (CEST) Message-ID: <445B5C18.80401@motorola.com> Date: Fri, 05 May 2006 16:07:20 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: COMBES Jean-Michel RD-MAPS-ISS Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org COMBES Jean-Michel RD-MAPS-ISS wrote: > Just think about the number of threads where the subject of the email > was not about what was the text inside it .... the consequences are > that main issues may be missed by people. I agree. But sometimes changing the Subject line too often is not appreciated either. > Another point is regarding the fact that you may have two sessions in > an IETF meeting that are in parallel: generally, you follow always > the one where there more topics in scope with your activities. So the > consequences are that people will become less active in NEMO. Exactly, two parallel sessions of a v4 group and a v6 group makes it impossible to have a good transition mechanism. Mip6trans is an example of parallel work (MIP6 and NEMO WGs). Its discussions happen in MIP6 WG only however, for the reason people naturally think mip6trans is about Mobile IPv6 only, not NEMOv6. This is a bad thing, because I have to follow the two to understand the implications on NEMOv4. > To summarize my point of view: I am only afraid that will gain in > quantity vs quality if all the works about NEMO (v4+v6) will be done > in the same WG. Yes, we should strive for better balance quality-quantity in whatever the group does. Alex From nemo-bounces@ietf.org Fri May 05 10:46:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1Zt-00030Z-QZ; Fri, 05 May 2006 10:46:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1Zs-00030U-Mb for nemo@ietf.org; Fri, 05 May 2006 10:46:44 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc1Zr-000749-99 for nemo@ietf.org; Fri, 05 May 2006 10:46:44 -0400 Received: from dhcp-rocq-97.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k45EkeJJ014022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 May 2006 16:46:40 +0200 Date: Fri, 5 May 2006 16:47:40 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Message-Id: <20060505164740.21945445.thierry.ernst@inria.fr> In-Reply-To: <445B5C18.80401@motorola.com> References: <445B5C18.80401@motorola.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 445B6550.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > Another point is regarding the fact that you may have two sessions in > > an IETF meeting that are in parallel: generally, you follow always > > the one where there more topics in scope with your activities. So the > > consequences are that people will become less active in NEMO. > > Exactly, two parallel sessions of a v4 group and a v6 group makes it > impossible to have a good transition mechanism. The point Jean-Michel wanted to make - I think - is that it is probably easier to avoid conflicts with parallel sessions when the same WG is addressing both IPv4 and IPv6. Currently, we already have difficulties to avoid conflicts with other WGs where active NEMO WGs members are actively participating, if we mix up NEMOv4 and NEMOv6 in the same WG we will have to avoid conflicts with IPv4 and IPv6 related WGs. Currently, we only list IPv6-related WGs. > Mip6trans is an example of parallel work (MIP6 and NEMO WGs). Its > discussions happen in MIP6 WG only however, for the reason people > naturally think mip6trans is about Mobile IPv6 only, not NEMOv6. This > is a bad thing, because I have to follow the two to understand the > implications on NEMOv4. Here you are speaking about transitioning between v4 and v6, not about plain v4, so you cannot mix up your arguments to make your point. > > To summarize my point of view: I am only afraid that will gain in > > quantity vs quality if all the works about NEMO (v4+v6) will be done > > in the same WG. > > Yes, we should strive for better balance quality-quantity in whatever > the group does. I don't see any tradeoff between quantity and quality. Quality should be 1st. Thierry. From nemo-bounces@ietf.org Fri May 05 10:53:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1gZ-0005ay-2i; Fri, 05 May 2006 10:53:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1gY-0005at-2R for nemo@ietf.org; Fri, 05 May 2006 10:53:38 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc1gX-0007Po-Mg for nemo@ietf.org; Fri, 05 May 2006 10:53:38 -0400 Received: from dhcp-rocq-97.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k45Erahu014811 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 5 May 2006 16:53:37 +0200 Date: Fri, 5 May 2006 16:54:36 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Message-Id: <20060505165436.275638c1.thierry.ernst@inria.fr> In-Reply-To: <20060505164740.21945445.thierry.ernst@inria.fr> References: <445B5C18.80401@motorola.com> <20060505164740.21945445.thierry.ernst@inria.fr> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 445B66F0.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > > Another point is regarding the fact that you may have two sessions in > > > an IETF meeting that are in parallel: generally, you follow always > > > the one where there more topics in scope with your activities. So the > > > consequences are that people will become less active in NEMO. > > > > Exactly, two parallel sessions of a v4 group and a v6 group makes it > > impossible to have a good transition mechanism. > > The point Jean-Michel wanted to make - I think - is that it is probably > easier to avoid conflicts with parallel sessions when the same WG is > addressing both IPv4 and IPv6. I might be tired, I meant the opposite, "it is probably easer to avoid conflicts with // sessions when distinct WGs are addressing IPv4 and IPv6, respectively rathen than a single WG addressing both IPv4 and IPv6 variants of a protocol.". > Currently, we already have difficulties to avoid conflicts with other > WGs where active NEMO WGs members are actively participating, if we mix > up NEMOv4 and NEMOv6 in the same WG we will have to avoid conflicts with > IPv4 and IPv6 related WGs. Currently, we only list IPv6-related WGs. > > > Mip6trans is an example of parallel work (MIP6 and NEMO WGs). Its > > discussions happen in MIP6 WG only however, for the reason people > > naturally think mip6trans is about Mobile IPv6 only, not NEMOv6. This > > is a bad thing, because I have to follow the two to understand the > > implications on NEMOv4. > > Here you are speaking about transitioning between v4 and v6, not about > plain v4, so you cannot mix up your arguments to make your point. > > > > To summarize my point of view: I am only afraid that will gain in > > > quantity vs quality if all the works about NEMO (v4+v6) will be done > > > in the same WG. > > > > Yes, we should strive for better balance quality-quantity in whatever > > the group does. > > I don't see any tradeoff between quantity and quality. Quality should be 1st. > > Thierry. > > -- Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Fri May 05 11:08:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1um-000320-KV; Fri, 05 May 2006 11:08:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc1ul-00031v-5b for nemo@ietf.org; Fri, 05 May 2006 11:08:19 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc1uk-0007zx-UC for nemo@ietf.org; Fri, 05 May 2006 11:08:19 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k45FPK0I013337; Fri, 5 May 2006 08:25:20 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k45FPc2H027821; Fri, 5 May 2006 10:25:38 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 6AD30865980; Fri, 5 May 2006 17:08:17 +0200 (CEST) Message-ID: <445B6A61.1050703@motorola.com> Date: Fri, 05 May 2006 17:08:17 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <445B5C18.80401@motorola.com> <20060505164740.21945445.thierry.ernst@inria.fr> <20060505165436.275638c1.thierry.ernst@inria.fr> In-Reply-To: <20060505165436.275638c1.thierry.ernst@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thierry Ernst wrote: >>>> Another point is regarding the fact that you may have two >>>> sessions in an IETF meeting that are in parallel: generally, >>>> you follow always the one where there more topics in scope with >>>> your activities. So the consequences are that people will >>>> become less active in NEMO. >>> Exactly, two parallel sessions of a v4 group and a v6 group makes >>> it impossible to have a good transition mechanism. >> The point Jean-Michel wanted to make - I think - is that it is >> probably easier to avoid conflicts with parallel sessions when the >> same WG is addressing both IPv4 and IPv6. > > I might be tired, I meant the opposite, "it is probably easer to > avoid conflicts with // sessions when distinct WGs are addressing > IPv4 and IPv6, respectively rathen than a single WG addressing both > IPv4 and IPv6 variants of a protocol.". I understand. What may look conflicting to him looks helpful for me and vice-versa. Why? Because I'm already getting through the struggle of following the mip6trans work, claimed to be // (parallel), but actually happening only on MIP6. It's a natural tendency. I wouldn't want NEMOv4 work to "officially" be attached to here _and_ MIP4 WG because the actual work will happen in only one place. I've already given examples of v4 and v6 versions of same protocol happening in many other WGs (dhc, pkix, ipsec). The mip4-mip6 WG distinction is a particular split, not the general case. But I agree that many people in this WG are doing IPv6 work, I myself am doing much IPv6 work. I don't oppose IPv4 work happening here. Alex From nemo-bounces@ietf.org Fri May 05 12:34:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc3Fr-00061S-Ba; Fri, 05 May 2006 12:34:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc3Fp-00061N-WD for nemo@ietf.org; Fri, 05 May 2006 12:34:10 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc3Fn-00031P-Na for nemo@ietf.org; Fri, 05 May 2006 12:34:09 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 05 May 2006 09:34:07 -0700 X-IronPort-AV: i="4.05,93,1146466800"; d="scan'208"; a="273185725:sNHT23271460" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k45GY6RT020949; Fri, 5 May 2006 09:34:06 -0700 (PDT) Received: from xmb-sjc-235.amer.cisco.com ([128.107.191.85]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 5 May 2006 09:34:06 -0700 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 Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Fri, 5 May 2006 09:34:05 -0700 Message-ID: <2979E38DD6FC6544B789C8DAD7BAFC5201C68F2A@xmb-sjc-235.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZwU8WBjC19ZIx6RYWsSJGOdcS5VQADRbcA From: "Kent Leung \(kleung\)" To: "Thierry Ernst" , X-OriginalArrivalTime: 05 May 2006 16:34:06.0715 (UTC) FILETIME=[BA58ACB0:01C67061] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Thierry. > > I don't see any tradeoff between quantity and quality.=20 > Quality should be 1st. > >=20 I agree with your statement. But it seems that we can accomplish quality for both NEMOv4 and NEMOv6. This doesn't seem contradictory as long as there are folks willing to put forth the time and energy. BTW, it seems that if we harnessed the mind-power that's been put into this thread to address George's draft, I really think we'd be done with it already. :) Kent From nemo-bounces@ietf.org Fri May 05 14:10:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc4kp-0001NU-2H; Fri, 05 May 2006 14:10:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fc4kn-0001NP-OJ for nemo@ietf.org; Fri, 05 May 2006 14:10:13 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fc4kn-0006mH-DU for nemo@ietf.org; Fri, 05 May 2006 14:10:13 -0400 Received: from [10.1.201.19] ([10.1.201.19]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 11:10:09 -0700 Message-ID: <445B9500.7050405@azairenet.com> Date: Fri, 05 May 2006 11:10:08 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF0026BB295@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0026BB295@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 May 2006 18:10:09.0634 (UTC) FILETIME=[25505420:01C6706F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Tsirtsis, George wrote: > Thierry, > > Your last e-mail is a bit confusing. Did you mean to say that the NEMOv4 > could be taken care in the MIP4 WG? > > If that is what you said, then yes, it could be done there but it would > be weird to do so. Network Mobility is Network Mobility (v4 or v6). > Talking about confusing the observer... > > I find the desire to work on v4 only or v6 only issues narrow minded. We > still exist in an IPv4 world and when IPv6 is deployed we will exist in > a dual stack world for a long, long time. Why do people think that it is > a good idea to "focus" on one version of IP or another is a mystery. > > But even if some people do want to have IPv6 only "focus", the argument > that a discussion about IPv4 would "break their concentration" and > "cause them to loose track of the important threads" is very, very lame. > Come one guys, be serious. oh yeah.. I like to just waste my time being humorous on the mailing list... its my favorite past time... Vijay > > George > > > >> -----Original Message----- >> From: Thierry Ernst [mailto:thierry.ernst@inria.fr] >> Sent: Friday, May 05, 2006 8:13 AM >> To: nemo@ietf.org >> Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >> >> >> >> NEMOv4 could not be taken care of the MIP4 WG, so no new WG would be >> needed, but v4 and v6 work would be addressed by the most appropriate >> WG. >> >> The people supporting NEMOv4 work never considered that possibility ? >> >> Thierry >> >> On Fri, 05 May 2006 12:32:20 +0200 >> Alexandru Petrescu wrote: >> >>> Julien Bournelle wrote: >>>> Hi all, >>>> >>>> I can remember that mobileip has decided to split to work more >>>> efficiently. So maybe it would be better to do the same thing for >>>> NEMO and thus to keep focus on v6. >>> Julien, splitting MIP into other WGs happened at a time when there > was >>> only one WG about mobility, called just MIP. >>> >>> Since about 3 years there are many WGs related to mobility: mip6, > mip4, >>> mipshop, monami6, mobike, netlmm and maybe others. Netlmm and > monami6 >>> BoFs were happening at about the same time. Monami6 became a WG > before >>> netlmm and there was strong discussion and questioning about the >>> necessity about so many mobility related WGs. >>> >>> It is normal to question the high number of these WGs. Because > actual >>> deployment of their output compared to other WGs (e.g. vpn or pkix > WG) >>> is really non-significant. >>> >>> I think the question to be asked is whether WG thinks this v4 work > is >>> important or not, not necessarily whether it should be done here or >>> there. And when people think the v4 work is not important to >>> counter-exemplify with v6 deployments out there. >>> >>> Alex >>> >> >> -- >> Thierry ERNST, PhD >> INRIA Rocquencourt Projet IMARA >> +33 1 39 63 59 30 >> > > From nemo-bounces@ietf.org Fri May 05 21:19:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcBSX-00028L-Su; Fri, 05 May 2006 21:19:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcBSW-000285-Cw for nemo@ietf.org; Fri, 05 May 2006 21:19:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FcBSW-0003ic-Ap for nemo@ietf.org; Fri, 05 May 2006 21:19:48 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FcBPE-000221-ST for nemo@ietf.org; Fri, 05 May 2006 21:16:25 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k461GMrD032488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 5 May 2006 18:16:23 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k461GKBN026518; Fri, 5 May 2006 18:16:21 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 5 May 2006 18:16:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Fri, 5 May 2006 18:16:20 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8480F0AE@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZwU8WBjC19ZIx6RYWsSJGOdcS5VQADRbcAABJYB1A= From: "Narayanan, Vidya" To: "Kent Leung \(kleung\)" , "Thierry Ernst" , X-OriginalArrivalTime: 06 May 2006 01:16:21.0618 (UTC) FILETIME=[AF676D20:01C670AA] X-Spam-Score: -2.6 (--) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I completely agree with Kent here. This discussion has taken more energy and time from people than the actual work needed for the NEMOv4 extensions.=20 This discussion has completely de-railed and lost its meaning - so, I will stop further specific comments on this topic here.=20 Vidya=20 > -----Original Message----- > From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 > Sent: Friday, May 05, 2006 9:34 AM > To: Thierry Ernst; nemo@ietf.org > Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. >=20 > Hi Thierry. >=20 > > > I don't see any tradeoff between quantity and quality.=20 > > Quality should be 1st. > > >=20 >=20 > I agree with your statement. But it seems that we can=20 > accomplish quality for both NEMOv4 and NEMOv6. This doesn't=20 > seem contradictory as long as there are folks willing to put=20 > forth the time and energy. BTW, it seems that if we=20 > harnessed the mind-power that's been put into this thread to=20 > address George's draft, I really think we'd be done with it=20 > already. :) >=20 > Kent >=20 >=20 From nemo-bounces@ietf.org Sun May 07 22:27:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcvS6-0006r0-1J; Sun, 07 May 2006 22:26:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FcvS4-0006jI-JU for nemo@ietf.org; Sun, 07 May 2006 22:26:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fcuwp-0000yQ-0T for nemo@ietf.org; Sun, 07 May 2006 21:54:07 -0400 Received: from otm-mgo01.iij.ad.jp ([210.138.20.175]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fcuig-00063K-75 for nemo@ietf.org; Sun, 07 May 2006 21:39:33 -0400 Received: OTM-MO(otm-mgo01) id k481dRh5095616; Mon, 8 May 2006 10:39:27 +0900 (JST) Received: OTM-MIX(otm-mix00) id k481dQxh038867; Mon, 8 May 2006 10:39:27 +0900 (JST) Received: from localhost (keiichi00.osaka.iij.ad.jp [192.168.64.45]) by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id k481dQ9U015446; Mon, 8 May 2006 10:39:26 +0900 (JST) Date: Mon, 08 May 2006 10:42:55 +0900 (JST) Message-Id: <20060508.104255.10274405.keiichi@iijlab.net> To: thierry.ernst@inria.fr Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. From: Keiichi SHIMA In-Reply-To: <20060505105349.5669c002.thierry.ernst@inria.fr> References: <2EBB8025B6D1BA41B567DB32C1D8DB847925D9@NAEX06.na.qualcomm.com> <20060505105349.5669c002.thierry.ernst@inria.fr> X-Mailer: Mew version 4.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -1.1 (-) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hello all, From: Thierry Ernst Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Date: Fri, 5 May 2006 10:53:49 +0200 > I would like to get the opinion of more (i.e. others) people whether we > should concentrate on IPv6 or not. I am and will be focusing on IPv6 related topics only. And I probably will not be deeply involved in the IPv4 centric protocols. But I think discussing NEMO for IPv4 protocol in this WG should not be excluded in general. Some of technologies or protocols may be able to be shared by v4 and v6, and I think we should not discuss the same things in different places. --- Keiichi SHIMA IIJ Research Laboratory WIDE Project From nemo-bounces@ietf.org Mon May 08 01:18:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fcy8G-00070I-AR; Mon, 08 May 2006 01:18:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fcy8F-00070D-1q for nemo@ietf.org; Mon, 08 May 2006 01:18:07 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fcy8C-0003OU-O2 for nemo@ietf.org; Mon, 08 May 2006 01:18:07 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Sun, 7 May 2006 22:17:59 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZwU8WBjC19ZIx6RYWsSJGOdcS5VQADRbcAABJYB1AAbOHuIA== From: "Vijay Devarapalli" To: "Narayanan, Vidya" , "Kent Leung \(kleung\)" , "Thierry Ernst" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org on the contrary, Thierry is asking for more=20 opinions on whether we should work only on IPv6=20 NEMO or also on IPv4 NEMO. it would be good idea=20 to get an opinion from as many folks as possible and figure out what majority of the folks in=20 this WG want to do. the proposed new charter for=20 WG re-chartering has quite a few items. infact,=20 I would say it has too many items. Vijay > -----Original Message----- > From: Narayanan, Vidya [mailto:vidyan@qualcomm.com]=20 > Sent: Friday, May 05, 2006 6:16 PM > To: Kent Leung (kleung); Thierry Ernst; nemo@ietf.org > Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. >=20 > I completely agree with Kent here. This discussion has taken=20 > more energy > and time from people than the actual work needed for the NEMOv4 > extensions.=20 >=20 > This discussion has completely de-railed and lost its meaning - so, I > will stop further specific comments on this topic here.=20 >=20 > Vidya=20 >=20 > > -----Original Message----- > > From: Kent Leung (kleung) [mailto:kleung@cisco.com]=20 > > Sent: Friday, May 05, 2006 9:34 AM > > To: Thierry Ernst; nemo@ietf.org > > Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. > >=20 > > Hi Thierry. > >=20 > > > > I don't see any tradeoff between quantity and quality.=20 > > > Quality should be 1st. > > > >=20 > >=20 > > I agree with your statement. But it seems that we can=20 > > accomplish quality for both NEMOv4 and NEMOv6. This doesn't=20 > > seem contradictory as long as there are folks willing to put=20 > > forth the time and energy. BTW, it seems that if we=20 > > harnessed the mind-power that's been put into this thread to=20 > > address George's draft, I really think we'd be done with it=20 > > already. :) > >=20 > > Kent > >=20 > >=20 >=20 >=20 From nemo-bounces@ietf.org Mon May 08 11:01:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd7EF-0006xS-BO; Mon, 08 May 2006 11:00:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd7ED-0006xM-WB for nemo@ietf.org; Mon, 08 May 2006 11:00:54 -0400 Received: from yui.nc.u-tokyo.ac.jp ([130.69.251.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd7ED-0005ba-EQ for nemo@ietf.org; Mon, 08 May 2006 11:00:53 -0400 Received: from [192.168.0.11] (p7006-ipbf1107marunouchi.tokyo.ocn.ne.jp [124.101.246.6]) (authenticated bits=0) by yui.nc.u-tokyo.ac.jp (8.12.10/8.12.3/Debian-6.4) with ESMTP id k48F0pUl006114; Tue, 9 May 2006 00:00:51 +0900 In-Reply-To: <445A16E9.3050102@motorola.com> References: <1487A357FD2ED544B8AD29E528FF9DF002653491@NAEX06.na.qualcomm.com> <20060504161628.5d689671.thierry.ernst@inria.fr> <445A16E9.3050102@motorola.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5A718C18-587B-4CE6-8D90-49EC0855235B@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Date: Tue, 9 May 2006 00:00:36 +0900 To: Alexandru Petrescu X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Alex On 2006/05/04, at 23:59, Alexandru Petrescu wrote: >> In addition to this, there is a vast majority of people active in the >> NEMO WG who really don't have interest in IPv4. > > If it were so, mip6trans DT wouldn't be attached to NEMO WG and to > MIP6 > WG. Mip6trans DT addresses important IPv4 aspets, for example it > considers the HA to run an IPv4 stack and connected to the IPv4 > Internet, with IPv6 addresses being IPv4-mapped. This is wrong. When v6 service is launched, operator must consider v4 access network which is majority of the Internet still. Applications are also developed with IPv4. Therefore, mip6trans work is definitely related to NEMOv6 activity. I think Thierry said about a basic v4 mobility protocol for NEMO. The mip6trans is extension to MIP6/NEMOv6. ryuji >> So, not only our output must be clear for the people monitoring >> what the WG is doing, > > Yes, I completely agree, we should be clear on that. > >> but also we must make all the necessary things to gather within this >> group active participants with a clear focus of what we are doing. > > YEs. That is already happening. With respect to IPv4-related > activities, we have already atracted active participants with a clear > focus of what we are doing about IPv4. mip6trans is but an example. > >> My personal position has always been that people willing to bring >> similar features to IPv4 or whatever which is not IPv6 should simply >> gather together and set up their own WG. > > This didn't happen with the mip6trans DT: mip6trans is doing some IPv4 > stuff. They didn't form their separated WG. > > But I agree with you there's a fine balance to be achieved between > effort spent in re-organizing activities, effort spent in documenting > and agreeing on technologies and effort spent on educating the outside > of the WG about what this WG is doing. Outside the WG there are many > documenting papers about the WG, speeches, books, and so on. These > are > all excellent venues for educating the outside. > > Alex > PS: one can't use NEMO as being IPv6 only and as a technical > superiority > to enforce switching from IPv4 to IPv6. People can and do today IPv4 > moving networks with NEMOv4, with DHCP+NAT and many other ways. > Somebody even sells "Mobile Routers" that don't do IPv6 at all. But I > agree with you it may have been a motivator in the long gone past. > From nemo-bounces@ietf.org Mon May 08 11:08:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd7LW-000163-BV; Mon, 08 May 2006 11:08:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd7LU-00015y-Is for nemo@ietf.org; Mon, 08 May 2006 11:08:24 -0400 Received: from yui.nc.u-tokyo.ac.jp ([130.69.251.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd7LS-00064g-Vh for nemo@ietf.org; Mon, 08 May 2006 11:08:24 -0400 Received: from [192.168.0.11] (p7006-ipbf1107marunouchi.tokyo.ocn.ne.jp [124.101.246.6]) (authenticated bits=0) by yui.nc.u-tokyo.ac.jp (8.12.10/8.12.3/Debian-6.4) with ESMTP id k48F8IUl006747; Tue, 9 May 2006 00:08:19 +0900 In-Reply-To: <445B5C18.80401@motorola.com> References: <445B5C18.80401@motorola.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Date: Tue, 9 May 2006 00:08:03 +0900 To: Alexandru Petrescu X-Mailer: Apple Mail (2.749.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: nemo@ietf.org, Thierry Ernst , COMBES Jean-Michel RD-MAPS-ISS X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On 2006/05/05, at 23:07, Alexandru Petrescu wrote: > COMBES Jean-Michel RD-MAPS-ISS wrote: >> Just think about the number of threads where the subject of the email >> was not about what was the text inside it .... the consequences >> are that main issues may be missed by people. > > I agree. But sometimes changing the Subject line too often is not > appreciated either. > >> Another point is regarding the fact that you may have two sessions in >> an IETF meeting that are in parallel: generally, you follow >> always the one where there more topics in scope with your >> activities. So the >> consequences are that people will become less active in NEMO. > > Exactly, two parallel sessions of a v4 group and a v6 group makes it > impossible to have a good transition mechanism. > > Mip6trans is an example of parallel work (MIP6 and NEMO WGs). Its > discussions happen in MIP6 WG only however, for the reason people > naturally think mip6trans is about Mobile IPv6 only, not NEMOv6. This > is a bad thing, because I have to follow the two to understand the > implications on NEMOv4. This is not parallel work. see the file name. it is draft-ietf-mip6- nemo. NEMO is also same, because it is just extension of Mobile IPv6. But it didn't take place in MIP6 WG. ryuji >> To summarize my point of view: I am only afraid that will gain in >> quantity vs quality if all the works about NEMO (v4+v6) will be >> done in the same WG. > > Yes, we should strive for better balance quality-quantity in whatever > the group does. > > Alex > From nemo-bounces@ietf.org Mon May 08 11:48:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd7yC-0002RU-16; Mon, 08 May 2006 11:48:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd7n9-0001T8-GC for nemo@ietf.org; Mon, 08 May 2006 11:36:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd7h0-00079c-Rv for nemo@ietf.org; Mon, 08 May 2006 11:30:38 -0400 Received: from yui.nc.u-tokyo.ac.jp ([130.69.251.116]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fd7Qs-00080j-Lw for nemo@ietf.org; Mon, 08 May 2006 11:13:59 -0400 Received: from [192.168.0.11] (p7006-ipbf1107marunouchi.tokyo.ocn.ne.jp [124.101.246.6]) (authenticated bits=0) by yui.nc.u-tokyo.ac.jp (8.12.10/8.12.3/Debian-6.4) with ESMTP id k48FDpUl007302 for ; Tue, 9 May 2006 00:13:52 +0900 Mime-Version: 1.0 (Apple Message framework v749.3) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2A5050A1-82EC-45B2-8A27-16633149D317@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Date: Tue, 9 May 2006 00:13:37 +0900 To: nemo@ietf.org X-Mailer: Apple Mail (2.749.3) X-Spam-Score: -2.6 (--) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi I want to work on IPv6 only items. NEMOv4 is already starting deployed in commercial. I am afraid if it is worth to define new spec for v4. With mip6trans, NEMOv4 carry IPv4 and IPv6 mobile network prefix by single MR (NEMOv6). ryuji On 2006/05/08, at 14:17, Vijay Devarapalli wrote: > on the contrary, Thierry is asking for more > opinions on whether we should work only on IPv6 > NEMO or also on IPv4 NEMO. it would be good idea > to get an opinion from as many folks as possible > and figure out what majority of the folks in > this WG want to do. the proposed new charter for > WG re-chartering has quite a few items. infact, > I would say it has too many items. > > Vijay > >> -----Original Message----- >> From: Narayanan, Vidya [mailto:vidyan@qualcomm.com] >> Sent: Friday, May 05, 2006 6:16 PM >> To: Kent Leung (kleung); Thierry Ernst; nemo@ietf.org >> Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. >> >> I completely agree with Kent here. This discussion has taken >> more energy >> and time from people than the actual work needed for the NEMOv4 >> extensions. >> >> This discussion has completely de-railed and lost its meaning - so, I >> will stop further specific comments on this topic here. >> >> Vidya >> >>> -----Original Message----- >>> From: Kent Leung (kleung) [mailto:kleung@cisco.com] >>> Sent: Friday, May 05, 2006 9:34 AM >>> To: Thierry Ernst; nemo@ietf.org >>> Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. >>> >>> Hi Thierry. >>> >>>>> I don't see any tradeoff between quantity and quality. >>>> Quality should be 1st. >>>>> >>> >>> I agree with your statement. But it seems that we can >>> accomplish quality for both NEMOv4 and NEMOv6. This doesn't >>> seem contradictory as long as there are folks willing to put >>> forth the time and energy. BTW, it seems that if we >>> harnessed the mind-power that's been put into this thread to >>> address George's draft, I really think we'd be done with it >>> already. :) >>> >>> Kent >>> >>> >> >> > From nemo-bounces@ietf.org Mon May 08 13:08:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd9DR-0000as-Ru; Mon, 08 May 2006 13:08:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fd9DQ-0000an-6y for nemo@ietf.org; Mon, 08 May 2006 13:08:12 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fd9DO-0003vm-Rd for nemo@ietf.org; Mon, 08 May 2006 13:08:12 -0400 Message-ID: <013401c672c2$0a211540$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: References: <1487A357FD2ED544B8AD29E528FF9DF0026BB295@NAEX06.na.qualcomm.com> Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Date: Mon, 8 May 2006 10:08:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Trying to uplevel this discussion a bit... I think the first thing the NEMO WG needs to decide on is whether the WG should broaden out its topic area to include network mobility in general. The first set of deliverables involved a network-mobility extension to MIPv6. Now, it seems like there are a few non-MIPv6 and even non-MIP approaches that people are interested in. For example, a routing-based approach would be appealing to customers such as Connexion. And, as some have mentioned, a MIPv4 based approach might have some commercial appeal. There are pros and cons of broadening the topic area for a WG. The WG needs to make sure the right people are present, which might not be the case, for example, if a routing approach is discussed and the WG has not history of examining routing-based approaches. On the other hand, is there enough additional work involved in the current MIPv6-only approach to continue a WG narrowly focussed on that topic area? It seems as if there are quite a few yet on-going drafts that need to be completed for the MIPv6-only approach, and the amount of new work that has been proposed in that vein is actually quite minimal. Of that new work, there is some question whether one item - route optimization - really falls under the MIPv6-based approach, since route optimization for moving networks using the NEMO-base is still not very well understood and is more of a research topic. Are there others? Maybe now is too soon to conduct this kind of deep rechartering discussion. Perhaps the WG should wait until the current set of MIPv6-based approach drafts are complete, then have the disucussion about whether to broaden the topic area or keep it narrow. jak From nemo-bounces@ietf.org Mon May 08 13:59:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdA17-0001lB-81; Mon, 08 May 2006 13:59:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdA16-0001l6-MX for nemo@ietf.org; Mon, 08 May 2006 13:59:32 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdA15-0007FR-AM for nemo@ietf.org; Mon, 08 May 2006 13:59:32 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k48HxSLw028894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 8 May 2006 10:59:28 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k48HxQN1021350; Mon, 8 May 2006 10:59:27 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 8 May 2006 10:59:26 -0700 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 Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Mon, 8 May 2006 10:59:25 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF002754D50@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZywkXtMWb0P+IoQaeOOb6s2b+v6wABMrig From: "Tsirtsis, George" To: "James Kempf" , X-OriginalArrivalTime: 08 May 2006 17:59:26.0664 (UTC) FILETIME=[25502480:01C672C9] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Just to clarify one thing. The WG has already accepted the NEMOv4 base solution as a working group item and as far as I understand the work on that has progressed well and the draft will soon be ready for last call etc. The current proposal for broadening the charter is about FA and dynamic prefix allocation extensions to the Nemov4 base spec.=20 The work is certainly not substantial enough to warrant a WG of its own and a small, but determined :-), number of NEMO WG members have expressed active interest in this topic. I also have to point out that arguments against this work item (which have also been expressed) are not technical in nature i.e., no one as far as I can tell says that what we are suggesting is "wrong" or "technically flawed". Instead the arguments are rather organizational e.g, the focus of the WG is IPv6 or there are too many items on the agenda etc.=20 George > -----Original Message----- > From: James Kempf [mailto:kempf@docomolabs-usa.com] > Sent: Monday, May 08, 2006 1:09 PM > To: nemo@ietf.org > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >=20 > Trying to uplevel this discussion a bit... >=20 > I think the first thing the NEMO WG needs to decide on is whether the WG > should broaden out its topic area to include network mobility in general. > The first set of deliverables involved a network-mobility extension to > MIPv6. Now, it seems like there are a few non-MIPv6 and even non-MIP > approaches that people are interested in. For example, a routing-based > approach would be appealing to customers such as Connexion. And, as some > have mentioned, a MIPv4 based approach might have some commercial appeal. >=20 > There are pros and cons of broadening the topic area for a WG. The WG > needs > to make sure the right people are present, which might not be the case, > for > example, if a routing approach is discussed and the WG has not history of > examining routing-based approaches. On the other hand, is there enough > additional work involved in the current MIPv6-only approach to continue a > WG > narrowly focussed on that topic area? It seems as if there are quite a few > yet on-going drafts that need to be completed for the MIPv6-only approach, > and the amount of new work that has been proposed in that vein is actually > quite minimal. Of that new work, there is some question whether one item - > route optimization - really falls under the MIPv6-based approach, since > route optimization for moving networks using the NEMO-base is still not > very > well understood and is more of a research topic. Are there others? >=20 > Maybe now is too soon to conduct this kind of deep rechartering > discussion. > Perhaps the WG should wait until the current set of MIPv6-based approach > drafts are complete, then have the disucussion about whether to broaden > the > topic area or keep it narrow. >=20 > jak >=20 >=20 From nemo-bounces@ietf.org Mon May 08 14:19:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAJt-0007Lk-7p; Mon, 08 May 2006 14:18:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdAJr-0007Lf-SI for nemo@ietf.org; Mon, 08 May 2006 14:18:55 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdAJr-0007zx-Gq for nemo@ietf.org; Mon, 08 May 2006 14:18:55 -0400 Message-ID: <010c01c672cb$ef173180$026115ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Tsirtsis, George" , References: <1487A357FD2ED544B8AD29E528FF9DF002754D50@NAEX06.na.qualcomm.com> Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Date: Mon, 8 May 2006 11:19:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Spam-Score: 3.1 (+++) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org The work is certainly not substantial enough to warrant a WG of its own and a small, but determined :-), number of NEMO WG members have expressed active interest in this topic. I also have to point out that arguments against this work item (which have also been expressed) are not technical in nature i.e., no one as far as I can tell says that what we are suggesting is "wrong" or "technically flawed". Instead the arguments are rather organizational e.g, the focus of the WG is IPv6 or there are too many items on the agenda etc. jak>> In a rechartering effort, arguments of an organizational nature are as helpful in getting a coherent charter as those of a technical nature. Developing a charter is, after all, and organizational effort. jak>> But if the WG has efforts ongoing to standardize non-MIPv6-based solutions, and there are people who are committed to doing the work, then of course the work should continue. jak From nemo-bounces@ietf.org Mon May 08 15:15:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdBCH-0000xo-TS; Mon, 08 May 2006 15:15:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdBCG-0000xa-S0 for nemo@ietf.org; Mon, 08 May 2006 15:15:08 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdBCE-0002El-Il for nemo@ietf.org; Mon, 08 May 2006 15:15:08 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k48JW69J019749; Mon, 8 May 2006 12:32:06 -0700 (MST) Received: from [10.193.154.29] ([10.193.154.29]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k48JWmTF000473; Mon, 8 May 2006 14:32:50 -0500 (CDT) Message-ID: <445F98A9.9030203@motorola.com> Date: Mon, 08 May 2006 21:14:49 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF002653491@NAEX06.na.qualcomm.com> <20060504161628.5d689671.thierry.ernst@inria.fr> <445A16E9.3050102@motorola.com> <5A718C18-587B-4CE6-8D90-49EC0855235B@sfc.wide.ad.jp> In-Reply-To: <5A718C18-587B-4CE6-8D90-49EC0855235B@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Ryuji Wakikawa wrote: > Hi Alex > > On 2006/05/04, at 23:59, Alexandru Petrescu wrote: > > > >>> In addition to this, there is a vast majority of people active in >>> the NEMO WG who really don't have interest in IPv4. >> >> If it were so, mip6trans DT wouldn't be attached to NEMO WG and to >> MIP6 WG. Mip6trans DT addresses important IPv4 aspets, for >> example it considers the HA to run an IPv4 stack and connected to >> the IPv4 Internet, with IPv6 addresses being IPv4-mapped. > > This is wrong. When v6 service is launched, operator must consider v4 > access network which is majority of the Internet still. Indeed, when operator launches v6 service it will somehow still carry on an IPv4 address architecture. But I think you agree too that in the farthest future some v6 operators will eventually have only an IPv6 HA infrastructure (not IPv4 addressable) while some other operators will continue to offer v4-only access to mobiles. In this particular case the DS-MIPv6 (as proposed today) is probably a little less adapted, maybe. > Applications are also developed with IPv4. Therefore, mip6trans work > is definitely related to NEMOv6 activity. I agree it _is_ related, didn't try to express the opposite. > I think Thierry said about a basic v4 mobility protocol for NEMO. The > mip6trans is extension to MIP6/NEMOv6. Ok. Alex From nemo-bounces@ietf.org Tue May 09 04:15:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdNNP-0007A2-RC; Tue, 09 May 2006 04:15:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdNNO-00079Y-E6 for nemo@ietf.org; Tue, 09 May 2006 04:15:26 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdNNK-0001oa-0L for nemo@ietf.org; Tue, 09 May 2006 04:15:26 -0400 Received: from dhcp-rocq-97.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k498FCCg013205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 9 May 2006 10:15:13 +0200 Date: Tue, 9 May 2006 10:16:17 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Message-Id: <20060509101617.38fa3e12.thierry.ernst@inria.fr> In-Reply-To: <010c01c672cb$ef173180$026115ac@dcml.docomolabsusa.com> References: <1487A357FD2ED544B8AD29E528FF9DF002754D50@NAEX06.na.qualcomm.com> <010c01c672cb$ef173180$026115ac@dcml.docomolabsusa.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-j-chkmail-Score: MSGID : 44604F90.002 on concorde : j-chkmail score : XX : 5/20 0 X-Miltered: at concorde with ID 44604F90.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thanks for the "outside" comments James, this is surely helpful. One detail, though, directed to George (and James regarding his comment on the lack of technical discussion): the NEMOv4 work is informational, this is a big difference with the NEMOv6 work, and there are reasons why this document has been accepted as informational only. A direct consequence of this document being informational is that it didn't raise much debate on the technical side. If the document was in the proper standard track, it's pretty sure that more debate would have occured on the technical side. Also, as I already pointed out, it was accepted a while ago to the condition the workload put on the WG would be minimum (I'm not saying we have to stick to this - I'm just recalling the history so that people don't use the existing v4 work as a justification for more work - all justification must be technical and about organizational priorities of the WG). Thierry. On Mon, 8 May 2006 11:19:24 -0700 "James Kempf" wrote: > The work is certainly not substantial enough to warrant a WG of its own > and a small, but determined :-), number of NEMO WG members have > expressed active interest in this topic. I also have to point out that > arguments against this work item (which have also been expressed) are > not technical in nature i.e., no one as far as I can tell says that what > we are suggesting is "wrong" or "technically flawed". Instead the > arguments are rather organizational e.g, the focus of the WG is IPv6 or > there are too many items on the agenda etc. > > jak>> In a rechartering effort, arguments of an organizational nature are as > helpful in getting a coherent charter as those of a technical nature. > Developing a charter is, after all, and organizational effort. > > jak>> But if the WG has efforts ongoing to standardize non-MIPv6-based > solutions, and there are people who are committed to doing the work, then of > course the work should continue. > > jak > > > -- Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Tue May 09 07:08:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdQ46-000157-8E; Tue, 09 May 2006 07:07:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdQ44-00014z-Ny for nemo@ietf.org; Tue, 09 May 2006 07:07:40 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdQ44-00020c-AZ for nemo@ietf.org; Tue, 09 May 2006 07:07:40 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k49B7Zk8014227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 9 May 2006 04:07:35 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k49B7YCu002607; Tue, 9 May 2006 04:07:34 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 9 May 2006 04:07:34 -0700 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 Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Tue, 9 May 2006 04:07:33 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0027552AC@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZzQQ/pXdM9OutdRYOKnoYOLwBO+gAF2+kA From: "Tsirtsis, George" To: "Thierry Ernst" , X-OriginalArrivalTime: 09 May 2006 11:07:34.0220 (UTC) FILETIME=[C5F630C0:01C67358] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thierry, And of course the extensions to NEMOv4 base that I am suggesting will also be informational which is another reason why I do not get the resistance to all this. George > -----Original Message----- > From: Thierry Ernst [mailto:thierry.ernst@inria.fr] > Sent: Tuesday, May 09, 2006 4:16 AM > To: nemo@ietf.org > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >=20 >=20 > Thanks for the "outside" comments James, this is surely helpful. >=20 > One detail, though, directed to George (and James regarding his comment > on the lack of technical discussion): the NEMOv4 work is informational, > this is a big difference with the NEMOv6 work, and there are reasons why > this document has been accepted as informational only. A direct > consequence of this document being informational is that it didn't raise > much debate on the technical side. If the document was in the proper > standard track, it's pretty sure that more debate would have occured on > the technical side. >=20 > Also, as I already pointed out, it was accepted a while ago to the > condition the workload put on the WG would be minimum (I'm not saying we > have to stick to this - I'm just recalling the history so that people > don't use the existing v4 work as a justification for more work - all > justification must be technical and about organizational priorities of > the WG). >=20 > Thierry. >=20 >=20 >=20 >=20 >=20 > On Mon, 8 May 2006 11:19:24 -0700 > "James Kempf" wrote: >=20 > > The work is certainly not substantial enough to warrant a WG of its own > > and a small, but determined :-), number of NEMO WG members have > > expressed active interest in this topic. I also have to point out that > > arguments against this work item (which have also been expressed) are > > not technical in nature i.e., no one as far as I can tell says that what > > we are suggesting is "wrong" or "technically flawed". Instead the > > arguments are rather organizational e.g, the focus of the WG is IPv6 or > > there are too many items on the agenda etc. > > > > jak>> In a rechartering effort, arguments of an organizational nature > are as > > helpful in getting a coherent charter as those of a technical nature. > > Developing a charter is, after all, and organizational effort. > > > > jak>> But if the WG has efforts ongoing to standardize non-MIPv6-based > > solutions, and there are people who are committed to doing the work, > then of > > course the work should continue. > > > > jak > > > > > > >=20 >=20 > -- > Thierry ERNST, PhD > INRIA Rocquencourt Projet IMARA > +33 1 39 63 59 30 >=20 From nemo-bounces@ietf.org Tue May 09 07:39:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdQYX-0004Y5-UY; Tue, 09 May 2006 07:39:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdQYW-0004Xr-Dw for nemo@ietf.org; Tue, 09 May 2006 07:39:08 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdQYW-0003wC-CP for nemo@ietf.org; Tue, 09 May 2006 07:39:08 -0400 Received: from motgate3.mot.com ([144.189.100.103]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FdQU8-0005jk-Lq for nemo@ietf.org; Tue, 09 May 2006 07:34:37 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate3.mot.com (8.12.11/Motgate3) with ESMTP id k49BvAZC008382; Tue, 9 May 2006 04:57:11 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k49BmK7F008278; Tue, 9 May 2006 06:48:21 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 4B6CC865980; Tue, 9 May 2006 13:34:27 +0200 (CEST) Message-ID: <44607E43.50103@motorola.com> Date: Tue, 09 May 2006 13:34:27 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: James Kempf Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF0026BB295@NAEX06.na.qualcomm.com> <013401c672c2$0a211540$026115ac@dcml.docomolabsusa.com> In-Reply-To: <013401c672c2$0a211540$026115ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: -2.6 (--) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org James Kempf wrote: > Trying to uplevel this discussion a bit... > > I think the first thing the NEMO WG needs to decide on is whether the > WG should broaden out its topic area to include network mobility in > general. The first set of deliverables involved a network-mobility > extension to MIPv6. Now, it seems like there are a few non-MIPv6 and > even non-MIP approaches that people are interested in. For example, a > routing-based approach would be appealing to customers such as > Connexion. And, as some have mentioned, a MIPv4 based approach might > have some commercial appeal. > > There are pros and cons of broadening the topic area for a WG. The WG > needs to make sure the right people are present, which might not be > the case, for example, if a routing approach is discussed and the WG > has not history of examining routing-based approaches. On the other > hand, is there enough additional work involved in the current > MIPv6-only approach to continue a WG narrowly focussed on that topic > area? It seems as if there are quite a few yet on-going drafts that > need to be completed for the MIPv6-only approach, and the amount of > new work that has been proposed in that vein is actually quite > minimal. Of that new work, there is some question whether one item - > route optimization - really falls under the MIPv6-based approach, > since route optimization for moving networks using the NEMO-base is > still not very well understood and is more of a research topic. Are > there others? > > Maybe now is too soon to conduct this kind of deep rechartering > discussion. Perhaps the WG should wait until the current set of > MIPv6-based approach drafts are complete, then have the disucussion > about whether to broaden the topic area or keep it narrow. I am a strong proponent of keeping a WG focus narrow, to one only base protocol and eventual enhancements of that protocol. In this respect, I consider that the work items suggested can be grouped in at least three narrowly focused WGs: 1) NEMOv6 + prefix delegation + other bootstrapping; NEMOv4 + FA extensions + v4 prefix delegation + other bootstrapping. 2) v4-v6 traversal schemes for Mobile IPv6. 3) Alternative routing, network mobility without session continuity, without permanent reachability, route optimization for MNP, multiple interfaces and homing. For v4 and v6. This makes for three WGs and of course there's little place for so many. Some of the aspects can be addressed by existing WGs. And I would oppose addressing GlobalHAHA in the NEMO WG. GlobalHAHA is an extension that has more impact on Mobile IPv6 than on the NEMOv6 part of Mobile IPv6. Alex From nemo-bounces@ietf.org Tue May 09 17:16:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdZYs-00084G-3D; Tue, 09 May 2006 17:16:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdZYq-00084B-22 for nemo@ietf.org; Tue, 09 May 2006 17:16:04 -0400 Received: from mail.uc.pt ([193.137.200.38] helo=mail-2.ci.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdZYn-0006gS-BV for nemo@ietf.org; Tue, 09 May 2006 17:16:03 -0400 Received: from mail-2.ci.uc.pt (mail.uc.pt [127.0.0.1]) by localhost.mail.uc.pt (Postfix) with ESMTP id 21DC288DE2F for ; Tue, 9 May 2006 22:15:49 +0100 (WEST) Received: from medusa (bl5-52-125.dsl.telepac.pt [82.154.52.125]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail-2.ci.uc.pt (Postfix) with ESMTP id 78AA388DE2E for ; Tue, 9 May 2006 22:15:48 +0100 (WEST) From: "Pedro Pinheiro" To: Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Tue, 9 May 2006 22:15:51 +0100 Message-ID: <001e01c673ad$c075f450$9200a8c0@medusa> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <44607E43.50103@motorola.com> Thread-Index: AcZzXWknM5Mbl0eHT/2pS4pAeYxi3gATnpRw X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi all, First of all, I am sorry for being intrusive in your discussion, but I = would like to add my humble opinion. I believe that nobility is a future wave that requires an open mind and = that requires some break with the past in order to allow a really emerging technology awaiting the WG important work: _really_ feasible mobile networking.=20 This will, probably, require some work in the protocol. As so, I believe it will be more productive if the WC spends its efforts working in the future protocol - the one that will be viable for the eventual future number of devices that will require a huge number of IP addresses - the IPv6 protocol. Only after that I believe it will *probably* would be a good idea to see = if it is viable on IPv4 environment. I hope it's not too na=EFf...=20 Best regards, Pedro Vapi ------------------------------------ Universidade de Coimbra Pedro Pinheiro Eng, MSc vapi@ci.uc.pt Centro de Informatica=20 R. Arco da Trai=E7=E3o, Ap. 3080 3001-401 COIMBRA tel: +351 239 853 170 fax: +351 239 853 189 IM: MSN: pvapi@hotmail.com Skype ID:pedrovapi ------------------------------------ > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: ter=E7a-feira, 9 de Maio de 2006 12:34 > To: James Kempf > Cc: nemo@ietf.org > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >=20 > James Kempf wrote: > > Trying to uplevel this discussion a bit... > > > > I think the first thing the NEMO WG needs to decide on is whether = the > > WG should broaden out its topic area to include network mobility in > > general. The first set of deliverables involved a network-mobility > > extension to MIPv6. Now, it seems like there are a few non-MIPv6 and > > even non-MIP approaches that people are interested in. For example, = a > > routing-based approach would be appealing to customers such as > > Connexion. And, as some have mentioned, a MIPv4 based approach might > > have some commercial appeal. > > > > There are pros and cons of broadening the topic area for a WG. The = WG > > needs to make sure the right people are present, which might not be > > the case, for example, if a routing approach is discussed and the WG > > has not history of examining routing-based approaches. On the other > > hand, is there enough additional work involved in the current > > MIPv6-only approach to continue a WG narrowly focussed on that topic > > area? It seems as if there are quite a few yet on-going drafts that > > need to be completed for the MIPv6-only approach, and the amount of > > new work that has been proposed in that vein is actually quite > > minimal. Of that new work, there is some question whether one item - > > route optimization - really falls under the MIPv6-based approach, > > since route optimization for moving networks using the NEMO-base is > > still not very well understood and is more of a research topic. Are > > there others? > > > > Maybe now is too soon to conduct this kind of deep rechartering > > discussion. Perhaps the WG should wait until the current set of > > MIPv6-based approach drafts are complete, then have the disucussion > > about whether to broaden the topic area or keep it narrow. >=20 > I am a strong proponent of keeping a WG focus narrow, to one only base > protocol and eventual enhancements of that protocol. In this respect, = I > consider that the work items suggested can be grouped in at least = three > narrowly focused WGs: >=20 > 1) NEMOv6 + prefix delegation + other bootstrapping; > NEMOv4 + FA extensions + v4 prefix delegation + other = bootstrapping. >=20 > 2) v4-v6 traversal schemes for Mobile IPv6. >=20 > 3) Alternative routing, network mobility without session continuity, > without permanent reachability, route optimization for MNP, = multiple > interfaces and homing. For v4 and v6. >=20 > This makes for three WGs and of course there's little place for so = many. > Some of the aspects can be addressed by existing WGs. >=20 > And I would oppose addressing GlobalHAHA in the NEMO WG. GlobalHAHA = is > an extension that has more impact on Mobile IPv6 than on the NEMOv6 = part > of Mobile IPv6. >=20 > Alex From nemo-bounces@ietf.org Tue May 09 19:31:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdbfs-0006Q4-Cy; Tue, 09 May 2006 19:31:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdbfr-0006Mk-0s for nemo@ietf.org; Tue, 09 May 2006 19:31:27 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdbfp-0004EZ-Iz for nemo@ietf.org; Tue, 09 May 2006 19:31:26 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k49NiqJk013980; Tue, 9 May 2006 16:44:52 -0700 (MST) Received: from [10.169.4.32] (mvp-10-169-4-32.corp.mot.com [10.169.4.32]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k49NmXL5018113; Tue, 9 May 2006 18:48:35 -0500 (CDT) Message-ID: <44612644.9090805@motorola.com> Date: Wed, 10 May 2006 01:31:16 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Pedro Pinheiro Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <001e01c673ad$c075f450$9200a8c0@medusa> In-Reply-To: <001e01c673ad$c075f450$9200a8c0@medusa> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by motgate4.mot.com id k49NiqJk013980 X-Spam-Score: 0.0 (/) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Pedro, Until August 2005 the WG has worked on an IPv6-based protocol for network mobility, the one viable for a large number of devices. It's in rfc3963, and it mainly extends Mobile IPv6 Binding Update and Binding Acknowledgements to register home prefixes (in addition to the home address of the Mobile Router). Is this the future protocol you think of, or something else? This is why some of us were thinking that same thing that was tried for IPv6 already, could be tried to see whether it is viable in an IPv4 environment. Alex Pedro Pinheiro wrote: > Hi all, >=20 > First of all, I am sorry for being intrusive in your discussion, but=20 > I would like to add my humble opinion. >=20 > I believe that nobility is a future wave that requires an open mind=20 > and that requires some break with the past in order to allow a really > emerging technology awaiting the WG important work: _really_ > feasible mobile networking. >=20 > This will, probably, require some work in the protocol. As so, I=20 > believe it will be more productive if the WC spends its efforts=20 > working in the future protocol - the one that will be viable for the > eventual future number of devices that will require a huge number of > IP addresses - the IPv6 protocol. >=20 > Only after that I believe it will *probably* would be a good idea to=20 > see if it is viable on IPv4 environment. >=20 > I hope it's not too na=EFf... Best regards, Pedro Vapi >=20 > ------------------------------------ Universidade de Coimbra Pedro=20 > Pinheiro Eng, MSc vapi@ci.uc.pt Centro de Informatica R. Arco da=20 > Trai=E7=E3o, Ap. 3080 3001-401 COIMBRA tel: +351 239 853 170 fax: +351=20 > 239 853 189 IM: MSN: pvapi@hotmail.com Skype ID:pedrovapi=20 > ------------------------------------ >> -----Original Message----- From: Alexandru Petrescu=20 >> [mailto:alexandru.petrescu@motorola.com] Sent: ter=E7a-feira, 9 de=20 >> Maio de 2006 12:34 To: James Kempf Cc: nemo@ietf.org Subject: Re:=20 >> [nemo] Extensions to NEMOv4 base for the Charter. >>=20 >> James Kempf wrote: >>> Trying to uplevel this discussion a bit... >>>=20 >>> I think the first thing the NEMO WG needs to decide on is whether >>> the WG should broaden out its topic area to include network=20 >>> mobility in general. The first set of deliverables involved a=20 >>> network-mobility extension to MIPv6. Now, it seems like there are >>> a few non-MIPv6 and even non-MIP approaches that people are=20 >>> interested in. For example, a routing-based approach would be=20 >>> appealing to customers such as Connexion. And, as some have=20 >>> mentioned, a MIPv4 based approach might have some commercial=20 >>> appeal. >>>=20 >>> There are pros and cons of broadening the topic area for a WG.=20 >>> The WG needs to make sure the right people are present, which=20 >>> might not be the case, for example, if a routing approach is=20 >>> discussed and the WG has not history of examining routing-based=20 >>> approaches. On the other hand, is there enough additional work=20 >>> involved in the current MIPv6-only approach to continue a WG=20 >>> narrowly focussed on that topic area? It seems as if there are=20 >>> quite a few yet on-going drafts that need to be completed for the >>> MIPv6-only approach, and the amount of new work that has been=20 >>> proposed in that vein is actually quite minimal. Of that new=20 >>> work, there is some question whether one item - route=20 >>> optimization - really falls under the MIPv6-based approach, since >>> route optimization for moving networks using the NEMO-base is=20 >>> still not very well understood and is more of a research topic.=20 >>> Are there others? >>>=20 >>> Maybe now is too soon to conduct this kind of deep rechartering=20 >>> discussion. Perhaps the WG should wait until the current set of=20 >>> MIPv6-based approach drafts are complete, then have the=20 >>> disucussion about whether to broaden the topic area or keep it=20 >>> narrow. >> I am a strong proponent of keeping a WG focus narrow, to one only=20 >> base protocol and eventual enhancements of that protocol. In this=20 >> respect, I consider that the work items suggested can be grouped in >> at least three narrowly focused WGs: >>=20 >> 1) NEMOv6 + prefix delegation + other bootstrapping; NEMOv4 + FA=20 >> extensions + v4 prefix delegation + other bootstrapping. >>=20 >> 2) v4-v6 traversal schemes for Mobile IPv6. >>=20 >> 3) Alternative routing, network mobility without session=20 >> continuity, without permanent reachability, route optimization for=20 >> MNP, multiple interfaces and homing. For v4 and v6. >>=20 >> This makes for three WGs and of course there's little place for so=20 >> many. Some of the aspects can be addressed by existing WGs. >>=20 >> And I would oppose addressing GlobalHAHA in the NEMO WG. GlobalHAHA >> is an extension that has more impact on Mobile IPv6 than on the >> NEMOv6 part of Mobile IPv6. >>=20 >> Alex >=20 >=20 From nemo-bounces@ietf.org Wed May 10 00:26:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdgGf-0000Vy-DB; Wed, 10 May 2006 00:25:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdgGe-0000Vr-8Z for nemo@ietf.org; Wed, 10 May 2006 00:25:44 -0400 Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdgGd-0008DY-Iu for nemo@ietf.org; Wed, 10 May 2006 00:25:44 -0400 Received: from [10.0.2.111] (jules.nautilus6.org [203.178.138.2]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id B29FE4D8E0 for ; Wed, 10 May 2006 13:25:27 +0900 (JST) Message-ID: <44616B41.2000803@sfc.wide.ad.jp> Date: Wed, 10 May 2006 13:25:37 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: nemo@ietf.org Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <001e01c673ad$c075f450$9200a8c0@medusa> <44612644.9090805@motorola.com> In-Reply-To: <44612644.9090805@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Alex, Following the discussion from the beginning, I still do not understand=20 what is the advantage of NEMOv4 and extensions compared to, for example,=20 the DSMIPv6 solution. Your point with DSMIPv6 seems to be that the HA=20 requires IPv6. Is there any other concern? Maybe I missed something. DSMIPv6 is very promising as it allows to get both IPv4 and IPv6 access=20 in the Mobile Network, while crossing through IPv6 or IPv4 networks. I=20 cannot see what advantages could bring a pure v4 solution in the future. Regards, --=20 Romain KUNTZ kuntz@sfc.wide.ad.jp Alexandru Petrescu wrote: > Hi Pedro, >=20 > Until August 2005 the WG has worked on an IPv6-based protocol for > network mobility, the one viable for a large number of devices. It's i= n > rfc3963, and it mainly extends Mobile IPv6 Binding Update and Binding > Acknowledgements to register home prefixes (in addition to the home > address of the Mobile Router). >=20 > Is this the future protocol you think of, or something else? >=20 > This is why some of us were thinking that same thing that was tried for > IPv6 already, could be tried to see whether it is viable in an IPv4 > environment. >=20 > Alex >=20 > Pedro Pinheiro wrote: >> Hi all, >> >> First of all, I am sorry for being intrusive in your discussion, but I= =20 >> would like to add my humble opinion. >> >> I believe that nobility is a future wave that requires an open mind=20 >> and that requires some break with the past in order to allow a really >> emerging technology awaiting the WG important work: _really_ >> feasible mobile networking. >> >> This will, probably, require some work in the protocol. As so, I=20 >> believe it will be more productive if the WC spends its efforts=20 >> working in the future protocol - the one that will be viable for the >> eventual future number of devices that will require a huge number of >> IP addresses - the IPv6 protocol. >> >> Only after that I believe it will *probably* would be a good idea to=20 >> see if it is viable on IPv4 environment. >> >> I hope it's not too na=EFf... Best regards, Pedro Vapi >> >> ------------------------------------ Universidade de Coimbra Pedro=20 >> Pinheiro Eng, MSc vapi@ci.uc.pt Centro de Informatica R. Arco da=20 >> Trai=E7=E3o, Ap. 3080 3001-401 COIMBRA tel: +351 239 853 170 fax: +351= 239=20 >> 853 189 IM: MSN: pvapi@hotmail.com Skype ID:pedrovapi=20 >> ------------------------------------ >>> -----Original Message----- From: Alexandru Petrescu=20 >>> [mailto:alexandru.petrescu@motorola.com] Sent: ter=E7a-feira, 9 de Ma= io=20 >>> de 2006 12:34 To: James Kempf Cc: nemo@ietf.org Subject: Re: [nemo]=20 >>> Extensions to NEMOv4 base for the Charter. >>> >>> James Kempf wrote: >>>> Trying to uplevel this discussion a bit... >>>> >>>> I think the first thing the NEMO WG needs to decide on is whether >>>> the WG should broaden out its topic area to include network=20 >>>> mobility in general. The first set of deliverables involved a=20 >>>> network-mobility extension to MIPv6. Now, it seems like there are >>>> a few non-MIPv6 and even non-MIP approaches that people are=20 >>>> interested in. For example, a routing-based approach would be=20 >>>> appealing to customers such as Connexion. And, as some have=20 >>>> mentioned, a MIPv4 based approach might have some commercial appeal. >>>> >>>> There are pros and cons of broadening the topic area for a WG. The=20 >>>> WG needs to make sure the right people are present, which might not=20 >>>> be the case, for example, if a routing approach is discussed and the= =20 >>>> WG has not history of examining routing-based approaches. On the=20 >>>> other hand, is there enough additional work involved in the current=20 >>>> MIPv6-only approach to continue a WG narrowly focussed on that topic= =20 >>>> area? It seems as if there are quite a few yet on-going drafts that=20 >>>> need to be completed for the >>>> MIPv6-only approach, and the amount of new work that has been=20 >>>> proposed in that vein is actually quite minimal. Of that new work,=20 >>>> there is some question whether one item - route optimization -=20 >>>> really falls under the MIPv6-based approach, since >>>> route optimization for moving networks using the NEMO-base is still= =20 >>>> not very well understood and is more of a research topic. Are there=20 >>>> others? >>>> >>>> Maybe now is too soon to conduct this kind of deep rechartering=20 >>>> discussion. Perhaps the WG should wait until the current set of=20 >>>> MIPv6-based approach drafts are complete, then have the disucussion=20 >>>> about whether to broaden the topic area or keep it narrow. >>> I am a strong proponent of keeping a WG focus narrow, to one only=20 >>> base protocol and eventual enhancements of that protocol. In this=20 >>> respect, I consider that the work items suggested can be grouped in >>> at least three narrowly focused WGs: >>> >>> 1) NEMOv6 + prefix delegation + other bootstrapping; NEMOv4 + FA=20 >>> extensions + v4 prefix delegation + other bootstrapping. >>> >>> 2) v4-v6 traversal schemes for Mobile IPv6. >>> >>> 3) Alternative routing, network mobility without session continuity,=20 >>> without permanent reachability, route optimization for MNP, multiple=20 >>> interfaces and homing. For v4 and v6. >>> >>> This makes for three WGs and of course there's little place for so=20 >>> many. Some of the aspects can be addressed by existing WGs. >>> >>> And I would oppose addressing GlobalHAHA in the NEMO WG. GlobalHAHA >>> is an extension that has more impact on Mobile IPv6 than on the >>> NEMOv6 part of Mobile IPv6. >>> >>> Alex >> >> >=20 >=20 From nemo-bounces@ietf.org Wed May 10 05:11:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdkih-0002UL-DW; Wed, 10 May 2006 05:10:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdkig-0002SC-Cj for nemo@ietf.org; Wed, 10 May 2006 05:10:58 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdkie-0002rJ-3k for nemo@ietf.org; Wed, 10 May 2006 05:10:58 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k4A9Rsgu020427; Wed, 10 May 2006 02:27:55 -0700 (MST) Received: from [10.129.41.33] ([10.129.41.33]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k4A9SExM015955; Wed, 10 May 2006 04:28:15 -0500 (CDT) Message-ID: <4461AE12.3090809@motorola.com> Date: Wed, 10 May 2006 11:10:42 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Romain KUNTZ Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <001e01c673ad$c075f450$9200a8c0@medusa> <44612644.9090805@motorola.com> <44616B41.2000803@sfc.wide.ad.jp> In-Reply-To: <44616B41.2000803@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Romain KUNTZ wrote: > Hi Alex, > > Following the discussion from the beginning, I still do not > understand what is the advantage of NEMOv4 and extensions compared > to, for example, the DSMIPv6 solution. Your point with DSMIPv6 seems > to be that the HA requires IPv6. Is there any other concern? Maybe I > missed something. DS-MIPv6 does not have IPv4 moving network prefixes in the BU (although it may carry an IPv4 hoa). The consequence to that should not to be to add the v4 MNP in the DS-MIPv6 BU. DS-MIPv6 already has a too wide scope, should be reduced. It should only cover v6 continuous apps and permanent v6 hoa when MN connected to v4-only access network. Should not cover v4 hoa, nor v4 mnp, when connected to a v6-only access network. The reason for that is that if it tries to do so it becomes a MIP4. And also, doing so has much impact on other protocols that are only IPv4 or only IPv6 (not mixtures). E.g. how would DHCPv4 bootstrap a DS-MIPv6 MN is a complete unknown. > DSMIPv6 is very promising as it allows to get both IPv4 and IPv6 > access in the Mobile Network, while crossing through IPv6 or IPv4 > networks. While it allows an IPv6 access in the moving network when MR connected to a v4 access network it does not allow for IPv4 access in the moving network (although MR connected to a v4 access network). > I cannot see what advantages could bring a pure v4 solution in the > future. A pure MIP4 NEMOv4 solution allows LFN to have v4 permanent home address and v4 MNP when MR connected to a v4-only access network, naturally; when connected to a v4-only network no need to convert v4 into v6 and back into v4. Too much conversion v4-v6-v4 is not good for the conversion itself. The DS-MIPv6 design is based on two main assumptions: (1) not enough memory on MN to run both MIP4 and MIP6 and (2) network bandwidth unnecessarily used for both signalling (i.e. MN sends both IPv4 RegReq and IPv6 BU when changing a CoA). For (1) there are several mobile phones in the market that easily support two stacks MIP6 and MIP4, and their combined memory footprint is about 3% or less of the total available memory. For (2), when a MN is connected to a v4-only access network that manages its mobility with link-layer, the v4 address does not change whenever changing attachment (i.e. no RegReq for movement) and the v6 address does not change either if a constant prefix is assigned on the UDP v4 tunnel interface (i.e. no BU for movement within that v4-only network). There will be RegReqs and BUs but not upon every movement. They'll happen only for updating the lifetime (maybe every 5 minutes). DS-MIPv6 has other advantages but not with respect to MIP4 NEMOv4. I hope this is relevant to the questions, otherwise please follow-up I will try to clarify. Alex From nemo-bounces@ietf.org Wed May 10 06:29:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdlvi-0003W1-QR; Wed, 10 May 2006 06:28:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdlvg-0003Vj-Pu for nemo@ietf.org; Wed, 10 May 2006 06:28:28 -0400 Received: from mail.uc.pt ([193.137.200.38] helo=mail-2.ci.uc.pt) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdlvg-0006ER-4t for nemo@ietf.org; Wed, 10 May 2006 06:28:28 -0400 Received: from mail-2.ci.uc.pt (mail.uc.pt [127.0.0.1]) by localhost.mail.uc.pt (Postfix) with ESMTP id 05D4188DE2E for ; Wed, 10 May 2006 11:28:23 +0100 (WEST) Received: from medusa (dhcp-2.ci.uc.pt [193.136.200.250]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mail-2.ci.uc.pt (Postfix) with ESMTP id 60AC988DE2C for ; Wed, 10 May 2006 11:28:23 +0100 (WEST) From: "Pedro Pinheiro" To: Subject: FW: [nemo] Extensions to NEMOv4 base for the Charter. Date: Wed, 10 May 2006 11:28:26 +0100 Message-ID: <000a01c6741c$796bebe0$fac888c1@medusa> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: AcZ0Gpe3Fe12IK7aS8+eLzwJ+RGeygAAYQLA X-Spam-Score: 0.1 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi all and Alexandru, As Alexandru said in this mail, I am forwarding our conversation to the = ML so that others can discuss it. Alexandru: thanks for your comments and goodwill... :) Best regards, -Vapi ------------------------------------ Universidade de Coimbra Pedro Pinheiro Eng, MSc vapi@ci.uc.pt Centro de Informatica=20 R. Arco da Trai=E7=E3o, Ap. 3080 3001-401 COIMBRA tel: +351 239 853 170 fax: +351 239 853 189 IM: MSN: pvapi@hotmail.com Skype ID:pedrovapi ------------------------------------ -----Original Message----- From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]=20 Sent: quarta-feira, 10 de Maio de 2006 11:15 To: Pedro Pinheiro Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Pedro Pinheiro wrote: > Hi Alexandru, >=20 > I don't think rfc3963 is THE network mobile solution. There are still > a lot of questions for solving. As Thierry told in a presentation:=20 > rfc3963 is for connecting nemo networks. Now we must solve the=20 > performance problems... Ok, I agree that performance problems are important. Please post this about the performance problems on the NEMO mailing list, we can discuss about it there, it is relevant there. > For me, and is what I am trying to find a thesis for my PhD, the RO=20 > problem is one of the biggest and crucial for turning the NEMO and=20 > Mobility a reality. The latency, triangular routing, increased packet > overhead and processing delay, home network bottleneck and pinball=20 > at nested networks, beside others, are questions still waiting for=20 > answers. I somehow agree. I hope you are aware of the many drafts, IPR, PhDs and other technical reports published on the RO subject. And on the fact that IETF has been looking at this since about 10 years and there's still no widespread deployment of RO, maybe none at all. > For me, and my insignificancy :), No no, don't say so. All oppinions are important. WG Chairs look at the NEMO list traffic and try to derive a common understanding from all postings, yours as well as mine. > I would like to see all those problems solved first, and *only* after > that the WG should see the IPv4 scenario. Ah, now I understand why you said so. It was not immediately clear from the first mail that you prefer IPv6 optimizations before you look at IPv4. Could you please post this clarification. I somehow agree with = it. > (well, I hope you don't solve the RO problem so fast that I don't=20 > have time to propose my thesis... :) Don't worry. I don't think there's an universal RO solution fitting everything. I've been looking at the problem for a while, and it's difficult. Be confident you'll write a good thesis. Good luck, Alex From nemo-bounces@ietf.org Wed May 10 07:35:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdmyE-0002NB-1w; Wed, 10 May 2006 07:35:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdmyC-0002N0-Gy for nemo@ietf.org; Wed, 10 May 2006 07:35:08 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdmyC-0000p8-3z for nemo@ietf.org; Wed, 10 May 2006 07:35:08 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4ABZ29H029352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 May 2006 04:35:03 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4ABZ0cw022630; Wed, 10 May 2006 04:35:02 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 May 2006 04:35:00 -0700 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 Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Wed, 10 May 2006 04:34:59 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0027DCAE5@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZ0EmnD77NPbyReRdiLS3s2jcfpXwAEuZ8Q From: "Tsirtsis, George" To: "Alexandru Petrescu" , "Romain KUNTZ" X-OriginalArrivalTime: 10 May 2006 11:35:00.0610 (UTC) FILETIME=[C5B31E20:01C67425] X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org DS-MIPv6 vs NEMOv4 is...comparing apples and oranges since DS-MIPv6 clearly requires IPv6 and IPv4 capability in the mobile node/router while NEMOv4 requires only IPv4 capability in the mobile node/router. A dual stack mobile then would benefit most from DS-MIPv6 An IPv4 mobile would benefit from NEMOv4 George > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > Sent: Wednesday, May 10, 2006 5:11 AM > To: Romain KUNTZ > Cc: nemo@ietf.org > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >=20 > Romain KUNTZ wrote: > > Hi Alex, > > > > Following the discussion from the beginning, I still do not > > understand what is the advantage of NEMOv4 and extensions compared > > to, for example, the DSMIPv6 solution. Your point with DSMIPv6 seems > > to be that the HA requires IPv6. Is there any other concern? Maybe I > > missed something. >=20 > DS-MIPv6 does not have IPv4 moving network prefixes in the BU (although > it may carry an IPv4 hoa). >=20 > The consequence to that should not to be to add the v4 MNP in the > DS-MIPv6 BU. DS-MIPv6 already has a too wide scope, should be reduced. > It should only cover v6 continuous apps and permanent v6 hoa when MN > connected to v4-only access network. Should not cover v4 hoa, nor v4 > mnp, when connected to a v6-only access network. The reason for that is > that if it tries to do so it becomes a MIP4. And also, doing so has > much impact on other protocols that are only IPv4 or only IPv6 (not > mixtures). E.g. how would DHCPv4 bootstrap a DS-MIPv6 MN is a complete > unknown. >=20 > > DSMIPv6 is very promising as it allows to get both IPv4 and IPv6 > > access in the Mobile Network, while crossing through IPv6 or IPv4 > > networks. >=20 > While it allows an IPv6 access in the moving network when MR connected > to a v4 access network it does not allow for IPv4 access in the moving > network (although MR connected to a v4 access network). >=20 > > I cannot see what advantages could bring a pure v4 solution in the > > future. >=20 > A pure MIP4 NEMOv4 solution allows LFN to have v4 permanent home address > and v4 MNP when MR connected to a v4-only access network, naturally; > when connected to a v4-only network no need to convert v4 into v6 and > back into v4. Too much conversion v4-v6-v4 is not good for the > conversion itself. >=20 > The DS-MIPv6 design is based on two main assumptions: (1) not enough > memory on MN to run both MIP4 and MIP6 and (2) network bandwidth > unnecessarily used for both signalling (i.e. MN sends both IPv4 RegReq > and IPv6 BU when changing a CoA). >=20 > For (1) there are several mobile phones in the market that easily > support two stacks MIP6 and MIP4, and their combined memory footprint is > about 3% or less of the total available memory. >=20 > For (2), when a MN is connected to a v4-only access network that manages > its mobility with link-layer, the v4 address does not change whenever > changing attachment (i.e. no RegReq for movement) and the v6 address > does not change either if a constant prefix is assigned on the UDP v4 > tunnel interface (i.e. no BU for movement within that v4-only network). > There will be RegReqs and BUs but not upon every movement. They'll > happen only for updating the lifetime (maybe every 5 minutes). >=20 > DS-MIPv6 has other advantages but not with respect to MIP4 NEMOv4. >=20 > I hope this is relevant to the questions, otherwise please follow-up I > will try to clarify. >=20 > Alex From nemo-bounces@ietf.org Wed May 10 10:31:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdpiC-00028J-O8; Wed, 10 May 2006 10:30:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdpiA-000277-W7 for nemo@ietf.org; Wed, 10 May 2006 10:30:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdpiA-0008Q3-U0 for nemo@ietf.org; Wed, 10 May 2006 10:30:46 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fdpbr-0004qL-I2 for nemo@ietf.org; Wed, 10 May 2006 10:24:21 -0400 Received: from dhcp-rocq-97.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k4AEOBaR023053 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 May 2006 16:24:12 +0200 Date: Wed, 10 May 2006 16:25:17 +0200 From: Thierry Ernst To: nemo@ietf.org Message-Id: <20060510162517.613e8049.thierry.ernst@inria.fr> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0027DCAE5@NAEX06.na.qualcomm.com> References: <1487A357FD2ED544B8AD29E528FF9DF0027DCAE5@NAEX06.na.qualcomm.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 4461F78B.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: -2.6 (--) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Subject: [nemo] NEMOv4 vs DS-MIPv6 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org [Changedthe subject line] Hi George, I'm not sure what your scenario is, and in which situation NEMOv4 support would be necessary. If someone argue that NEMOv4 is necessary because there are existing vehicles - for instance - with IPv4 capabilities and the customer doesn't want to upgrade the vehicles to IPv6, then I guess the customer could be adviced to deployed DS-MIPv6 on the MR. It would be interesting to list down in which situation a transition mechanims (DM-MIPv6 or another one) could apply or not so that we could clarify how many important scenarios would require a plain IPv4 solution. Thierry. On Wed, 10 May 2006 04:34:59 -0700 "Tsirtsis, George" wrote: > DS-MIPv6 vs NEMOv4 is...comparing apples and oranges since DS-MIPv6 > clearly requires IPv6 and IPv4 capability in the mobile node/router > while NEMOv4 requires only IPv4 capability in the mobile node/router. > > A dual stack mobile then would benefit most from DS-MIPv6 > An IPv4 mobile would benefit from NEMOv4 > > George > > > -----Original Message----- > > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > > Sent: Wednesday, May 10, 2006 5:11 AM > > To: Romain KUNTZ > > Cc: nemo@ietf.org > > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. > > > > Romain KUNTZ wrote: > > > Hi Alex, > > > > > > Following the discussion from the beginning, I still do not > > > understand what is the advantage of NEMOv4 and extensions compared > > > to, for example, the DSMIPv6 solution. Your point with DSMIPv6 seems > > > to be that the HA requires IPv6. Is there any other concern? Maybe I > > > missed something. > > > > DS-MIPv6 does not have IPv4 moving network prefixes in the BU > (although > > it may carry an IPv4 hoa). > > > > The consequence to that should not to be to add the v4 MNP in the > > DS-MIPv6 BU. DS-MIPv6 already has a too wide scope, should be > reduced. > > It should only cover v6 continuous apps and permanent v6 hoa when MN > > connected to v4-only access network. Should not cover v4 hoa, nor v4 > > mnp, when connected to a v6-only access network. The reason for that > is > > that if it tries to do so it becomes a MIP4. And also, doing so has > > much impact on other protocols that are only IPv4 or only IPv6 (not > > mixtures). E.g. how would DHCPv4 bootstrap a DS-MIPv6 MN is a > complete > > unknown. > > > > > DSMIPv6 is very promising as it allows to get both IPv4 and IPv6 > > > access in the Mobile Network, while crossing through IPv6 or IPv4 > > > networks. > > > > While it allows an IPv6 access in the moving network when MR connected > > to a v4 access network it does not allow for IPv4 access in the moving > > network (although MR connected to a v4 access network). > > > > > I cannot see what advantages could bring a pure v4 solution in the > > > future. > > > > A pure MIP4 NEMOv4 solution allows LFN to have v4 permanent home > address > > and v4 MNP when MR connected to a v4-only access network, naturally; > > when connected to a v4-only network no need to convert v4 into v6 and > > back into v4. Too much conversion v4-v6-v4 is not good for the > > conversion itself. > > > > The DS-MIPv6 design is based on two main assumptions: (1) not enough > > memory on MN to run both MIP4 and MIP6 and (2) network bandwidth > > unnecessarily used for both signalling (i.e. MN sends both IPv4 RegReq > > and IPv6 BU when changing a CoA). > > > > For (1) there are several mobile phones in the market that easily > > support two stacks MIP6 and MIP4, and their combined memory footprint > is > > about 3% or less of the total available memory. > > > > For (2), when a MN is connected to a v4-only access network that > manages > > its mobility with link-layer, the v4 address does not change whenever > > changing attachment (i.e. no RegReq for movement) and the v6 address > > does not change either if a constant prefix is assigned on the UDP v4 > > tunnel interface (i.e. no BU for movement within that v4-only > network). > > There will be RegReqs and BUs but not upon every movement. They'll > > happen only for updating the lifetime (maybe every 5 minutes). > > > > DS-MIPv6 has other advantages but not with respect to MIP4 NEMOv4. > > > > I hope this is relevant to the questions, otherwise please follow-up I > > will try to clarify. > > > > Alex > > > -- Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Wed May 10 11:51:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdqy6-0004uy-MQ; Wed, 10 May 2006 11:51:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fdqy5-0004ut-5T for nemo@ietf.org; Wed, 10 May 2006 11:51:17 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fdqy2-000398-Pv for nemo@ietf.org; Wed, 10 May 2006 11:51:17 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4AFp7P3015934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 May 2006 08:51:08 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4AFp6nn027235; Wed, 10 May 2006 08:51:07 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 May 2006 08:51:06 -0700 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 Subject: RE: [nemo] NEMOv4 vs DS-MIPv6 Date: Wed, 10 May 2006 08:51:04 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0027DCDD9@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] NEMOv4 vs DS-MIPv6 Thread-Index: AcZ0QQE114STZm9LQtmbc4Vb3gWAbwABcEzw From: "Tsirtsis, George" To: "Thierry Ernst" , X-OriginalArrivalTime: 10 May 2006 15:51:06.0810 (UTC) FILETIME=[8CAB29A0:01C67449] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > -----Original Message----- > From: Thierry Ernst [mailto:thierry.ernst@inria.fr] > Sent: Wednesday, May 10, 2006 10:25 AM > To: nemo@ietf.org > Subject: [nemo] NEMOv4 vs DS-MIPv6 >=20 >=20 > [Changedthe subject line] >=20 > Hi George, >=20 > I'm not sure what your scenario is, and in which situation NEMOv4 > support would be necessary. If someone argue that NEMOv4 is necessary > because there are existing vehicles - for instance - with IPv4 > capabilities and the customer doesn't want to upgrade the vehicles to > IPv6, then I guess the customer could be adviced to deployed DS-MIPv6 on > the MR. >=20 First of all I am not sure that DS-MIPv6 currently supports IPv4 network prefixes allocation (maybe it should). But even if it does, what you are suggesting is that the network operator providing services to that car is IPv6 capable. Is it not clear to everyone that in most of the world this is still not the case?=20 > It would be interesting to list down in which situation a transition > mechanims (DM-MIPv6 or another one) could apply or not so that we could > clarify how many important scenarios would require a plain IPv4 solution. >=20 NEMOv4 would be useful for network operators that support mobile equipment (cars, trains, home routers or whatever) and that, for whatever reason, do not support IPv6 but still want to support network mobility.=20 I really do not like the fact that lately, to do any IPv4 work in the IETF, we are getting pressured to release customer information and deployment details. I will say the following which I hope will satisfy you: We have a number of customers (network operators) in various parts of the world that have deployed our FLASH-OFDM system. This is basically a MobileIPv4 based cellular data system (search for Flarion press releases if you want specifics...and sorry for the commercial).=20 Our customers would like to support network mobility. Some customers would also like to move to IPv6 some day, which is why we proposed DS-MIPv4 and DS-MIPv6 solutions. The two decisions, however, are not related and should not have to be coupled. George From nemo-bounces@ietf.org Wed May 10 12:32:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdrbY-0002gF-FQ; Wed, 10 May 2006 12:32:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdrbX-0002g5-FR for nemo@ietf.org; Wed, 10 May 2006 12:32:03 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdqW5-0002BC-71 for nemo@ietf.org; Wed, 10 May 2006 11:22:21 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fdq3S-00059j-W0 for nemo@ietf.org; Wed, 10 May 2006 10:52:48 -0400 Received: from dhcp-rocq-97.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k4AEqj8e027617 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 10 May 2006 16:52:45 +0200 Date: Wed, 10 May 2006 16:53:51 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 Message-Id: <20060510165351.5e70120e.thierry.ernst@inria.fr> In-Reply-To: <20060510162517.613e8049.thierry.ernst@inria.fr> References: <1487A357FD2ED544B8AD29E528FF9DF0027DCAE5@NAEX06.na.qualcomm.com> <20060510162517.613e8049.thierry.ernst@inria.fr> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 4461FE3D.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: -2.6 (--) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Rephrasing - I meant something really different, and my point was about listing the scenarios for which existing solutions could apply or not. Instead of the following: > I'm not sure what your scenario is, and in which situation NEMOv4 > support would be necessary. If someone argue that NEMOv4 is necessary > because there are existing vehicles - for instance - with IPv4 > capabilities and the customer doesn't want to upgrade the vehicles to > IPv6, then I guess the customer could be adviced to deployed DS-MIPv6 on > the MR. I wanted to say: I'm not sure what your scenario is, and in which situation NEMOv4 support would be necessary. If someone argue that NEMOv4 is necessary because there is existing deployment of IPv4 capabilities and the service provider doesn't want to upgrade the infrastructure to IPv6, then I guess the customer could be adviced to deploy DS-MIPv6 on the MR. > It would be interesting to list down in which situation a transition > mechanims (DM-MIPv6 or another one) could apply or not so that we could > clarify how many important scenarios would require a plain IPv4 solution. > Thierry. > > > > On Wed, 10 May 2006 04:34:59 -0700 > "Tsirtsis, George" wrote: > > > DS-MIPv6 vs NEMOv4 is...comparing apples and oranges since DS-MIPv6 > > clearly requires IPv6 and IPv4 capability in the mobile node/router > > while NEMOv4 requires only IPv4 capability in the mobile node/router. > > > > A dual stack mobile then would benefit most from DS-MIPv6 > > An IPv4 mobile would benefit from NEMOv4 > > > > George > > > > > -----Original Message----- > > > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > > > Sent: Wednesday, May 10, 2006 5:11 AM > > > To: Romain KUNTZ > > > Cc: nemo@ietf.org > > > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. > > > > > > Romain KUNTZ wrote: > > > > Hi Alex, > > > > > > > > Following the discussion from the beginning, I still do not > > > > understand what is the advantage of NEMOv4 and extensions compared > > > > to, for example, the DSMIPv6 solution. Your point with DSMIPv6 seems > > > > to be that the HA requires IPv6. Is there any other concern? Maybe I > > > > missed something. > > > > > > DS-MIPv6 does not have IPv4 moving network prefixes in the BU > > (although > > > it may carry an IPv4 hoa). > > > > > > The consequence to that should not to be to add the v4 MNP in the > > > DS-MIPv6 BU. DS-MIPv6 already has a too wide scope, should be > > reduced. > > > It should only cover v6 continuous apps and permanent v6 hoa when MN > > > connected to v4-only access network. Should not cover v4 hoa, nor v4 > > > mnp, when connected to a v6-only access network. The reason for that > > is > > > that if it tries to do so it becomes a MIP4. And also, doing so has > > > much impact on other protocols that are only IPv4 or only IPv6 (not > > > mixtures). E.g. how would DHCPv4 bootstrap a DS-MIPv6 MN is a > > complete > > > unknown. > > > > > > > DSMIPv6 is very promising as it allows to get both IPv4 and IPv6 > > > > access in the Mobile Network, while crossing through IPv6 or IPv4 > > > > networks. > > > > > > While it allows an IPv6 access in the moving network when MR connected > > > to a v4 access network it does not allow for IPv4 access in the moving > > > network (although MR connected to a v4 access network). > > > > > > > I cannot see what advantages could bring a pure v4 solution in the > > > > future. > > > > > > A pure MIP4 NEMOv4 solution allows LFN to have v4 permanent home > > address > > > and v4 MNP when MR connected to a v4-only access network, naturally; > > > when connected to a v4-only network no need to convert v4 into v6 and > > > back into v4. Too much conversion v4-v6-v4 is not good for the > > > conversion itself. > > > > > > The DS-MIPv6 design is based on two main assumptions: (1) not enough > > > memory on MN to run both MIP4 and MIP6 and (2) network bandwidth > > > unnecessarily used for both signalling (i.e. MN sends both IPv4 RegReq > > > and IPv6 BU when changing a CoA). > > > > > > For (1) there are several mobile phones in the market that easily > > > support two stacks MIP6 and MIP4, and their combined memory footprint > > is > > > about 3% or less of the total available memory. > > > > > > For (2), when a MN is connected to a v4-only access network that > > manages > > > its mobility with link-layer, the v4 address does not change whenever > > > changing attachment (i.e. no RegReq for movement) and the v6 address > > > does not change either if a constant prefix is assigned on the UDP v4 > > > tunnel interface (i.e. no BU for movement within that v4-only > > network). > > > There will be RegReqs and BUs but not upon every movement. They'll > > > happen only for updating the lifetime (maybe every 5 minutes). > > > > > > DS-MIPv6 has other advantages but not with respect to MIP4 NEMOv4. > > > > > > I hope this is relevant to the questions, otherwise please follow-up I > > > will try to clarify. > > > > > > Alex > > > > > > > > > -- > Thierry ERNST, PhD > INRIA Rocquencourt Projet IMARA > +33 1 39 63 59 30 > > -- Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Wed May 10 16:55:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdviC-0000XO-TC; Wed, 10 May 2006 16:55:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdviC-0000Vs-8G for nemo@ietf.org; Wed, 10 May 2006 16:55:12 -0400 Received: from av12-1-sn2.hy.skanova.net ([81.228.8.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdviB-0000xM-Qu for nemo@ietf.org; Wed, 10 May 2006 16:55:12 -0400 Received: by av12-1-sn2.hy.skanova.net (Postfix, from userid 502) id F2B3138214; Wed, 10 May 2006 22:55:10 +0200 (CEST) Received: from smtp4-2-sn2.hy.skanova.net (smtp4-2-sn2.hy.skanova.net [81.228.8.93]) by av12-1-sn2.hy.skanova.net (Postfix) with ESMTP id E514437E5F; Wed, 10 May 2006 22:55:10 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-2-sn2.hy.skanova.net (Postfix) with ESMTP id 8856A37E46; Wed, 10 May 2006 22:55:10 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.61) (envelope-from ) id 1Fdvi8-0002Bi-Bc; Wed, 10 May 2006 22:55:09 +0200 Message-ID: <4462532B.80103@levkowetz.com> Date: Wed, 10 May 2006 22:55:07 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 References: <1487A357FD2ED544B8AD29E528FF9DF0027DCDD9@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0027DCDD9@NAEX06.na.qualcomm.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi George, on 2006-05-10 17:51 Tsirtsis, George said the following: ... >> I'm not sure what your scenario is, and in which situation NEMOv4 >> support would be necessary. If someone argue that NEMOv4 is necessary >> because there are existing vehicles - for instance - with IPv4 >> capabilities and the customer doesn't want to upgrade the vehicles to >> IPv6, then I guess the customer could be adviced to deployed DS-MIPv6 > on >> the MR. >> > > First of all I am not sure that DS-MIPv6 currently supports IPv4 network > prefixes allocation (maybe it should). But even if it does, what you are > suggesting is that the network operator providing services to that car > is IPv6 capable. Is it not clear to everyone that in most of the world > this is still not the case? Mmm?? I believe that is incorrect. I don't see why the network operator has to be IPv6 capable. The only part in the network that has to be IPv6 is the home link, which can be virtual. So you'll need a MIPv6 HA, but the box it sits in doesn't even need a single physical interface which has an IPv6 address. >> It would be interesting to list down in which situation a transition >> mechanims (DM-MIPv6 or another one) could apply or not so that we > could >> clarify how many important scenarios would require a plain IPv4 > solution. >> > > NEMOv4 would be useful for network operators that support mobile > equipment (cars, trains, home routers or whatever) and that, for > whatever reason, do not support IPv6 but still want to support network > mobility. (As indicated above) I believe this doesn't hold. > I really do not like the fact that lately, to do any IPv4 work in the > IETF, we are getting pressured to release customer information and > deployment details. I will say the following which I hope will satisfy > you: > We have a number of customers (network operators) in various parts of > the world that have deployed our FLASH-OFDM system. This is basically a > MobileIPv4 based cellular data system (search for Flarion press releases > if you want specifics...and sorry for the commercial). > > Our customers would like to support network mobility. Some customers > would also like to move to IPv6 some day, which is why we proposed > DS-MIPv4 and DS-MIPv6 solutions. The two decisions, however, are not > related and should not have to be coupled. Fine. But nevertheless, NEMOv6 with DSMIPv6 will let you support network mobility without the operator having to support IPv6. Henrik From nemo-bounces@ietf.org Wed May 10 18:51:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdxWV-0004fz-Tf; Wed, 10 May 2006 18:51:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdxWU-0004fu-Pu for nemo@ietf.org; Wed, 10 May 2006 18:51:14 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdxWQ-0005zc-1W for nemo@ietf.org; Wed, 10 May 2006 18:51:14 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4AMp8oh030990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 May 2006 15:51:09 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by neophyte.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4AMp7EN001418; Wed, 10 May 2006 15:51:08 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 May 2006 15:51:07 -0700 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 Subject: RE: [nemo] NEMOv4 vs DS-MIPv6 Date: Wed, 10 May 2006 15:51:05 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0027DD453@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] NEMOv4 vs DS-MIPv6 Thread-Index: AcZ0dHfNmkGtHjoNQZ2kTM/dIwlK3AADpElw From: "Tsirtsis, George" To: "Henrik Levkowetz" X-OriginalArrivalTime: 10 May 2006 22:51:07.0842 (UTC) FILETIME=[39A77A20:01C67484] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Henrik, If I understood what you are saying, your suggestion requires that DS-MIPv6 runs on top of IPv4 tunnels...all the time. The MR also must support IPv6 (so it can create DS-MIPv6 messages i.e., MIPv6 messages with extensions). This might not be appropriate in the cases I described earlier. George P.S.: BTW, Hesham is telling me that DS-MIPv6 spec does support IPv4 prefixes=20 > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > Sent: Wednesday, May 10, 2006 4:55 PM > To: Tsirtsis, George > Cc: nemo@ietf.org; Thierry Ernst > Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 >=20 > Hi George, >=20 > on 2006-05-10 17:51 Tsirtsis, George said the following: > ... > >> I'm not sure what your scenario is, and in which situation NEMOv4 > >> support would be necessary. If someone argue that NEMOv4 is necessary > >> because there are existing vehicles - for instance - with IPv4 > >> capabilities and the customer doesn't want to upgrade the vehicles to > >> IPv6, then I guess the customer could be adviced to deployed DS-MIPv6 > > on > >> the MR. > >> > > > > First of all I am not sure that DS-MIPv6 currently supports IPv4 network > > prefixes allocation (maybe it should). But even if it does, what you are > > suggesting is that the network operator providing services to that car > > is IPv6 capable. Is it not clear to everyone that in most of the world > > this is still not the case? >=20 > Mmm?? I believe that is incorrect. I don't see why the network operator > has to be IPv6 capable. The only part in the network that has to be > IPv6 is the home link, which can be virtual. So you'll need a MIPv6 > HA, but the box it sits in doesn't even need a single physical interface > which has an IPv6 address. >=20 > >> It would be interesting to list down in which situation a transition > >> mechanims (DM-MIPv6 or another one) could apply or not so that we > > could > >> clarify how many important scenarios would require a plain IPv4 > > solution. > >> > > > > NEMOv4 would be useful for network operators that support mobile > > equipment (cars, trains, home routers or whatever) and that, for > > whatever reason, do not support IPv6 but still want to support network > > mobility. >=20 > (As indicated above) I believe this doesn't hold. >=20 > > I really do not like the fact that lately, to do any IPv4 work in the > > IETF, we are getting pressured to release customer information and > > deployment details. I will say the following which I hope will satisfy > > you: > > We have a number of customers (network operators) in various parts of > > the world that have deployed our FLASH-OFDM system. This is basically a > > MobileIPv4 based cellular data system (search for Flarion press releases > > if you want specifics...and sorry for the commercial). > > > > Our customers would like to support network mobility. Some customers > > would also like to move to IPv6 some day, which is why we proposed > > DS-MIPv4 and DS-MIPv6 solutions. The two decisions, however, are not > > related and should not have to be coupled. >=20 > Fine. But nevertheless, NEMOv6 with DSMIPv6 will let you support > network mobility without the operator having to support IPv6. >=20 >=20 > Henrik From nemo-bounces@ietf.org Wed May 10 21:06:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdzdF-000720-OX; Wed, 10 May 2006 21:06:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FdzdE-00071v-UF for nemo@ietf.org; Wed, 10 May 2006 21:06:20 -0400 Received: from av9-2-sn3.vrr.skanova.net ([81.228.9.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FdzdD-0002d6-Fn for nemo@ietf.org; Wed, 10 May 2006 21:06:20 -0400 Received: by av9-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 8DAC937E8C; Thu, 11 May 2006 03:06:12 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av9-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 793C637E57; Thu, 11 May 2006 03:06:12 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id CECE537E42; Thu, 11 May 2006 03:06:11 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.61) (envelope-from ) id 1Fdzcq-0007mz-MV; Thu, 11 May 2006 03:06:00 +0200 Message-ID: <44628DF4.7040704@levkowetz.com> Date: Thu, 11 May 2006 03:05:56 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 References: <1487A357FD2ED544B8AD29E528FF9DF0027DD453@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0027DD453@NAEX06.na.qualcomm.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi George, on 2006-05-11 00:51 Tsirtsis, George said the following: > Henrik, > > If I understood what you are saying, your suggestion requires that > DS-MIPv6 runs on top of IPv4 tunnels...all the time. Yes. If your deployment scenario is 'no IPv6', it can do that. > The MR also must > support IPv6 (so it can create DS-MIPv6 messages i.e., MIPv6 messages > with extensions). Yes, that's right. > This might not be appropriate in the cases I described > earlier. In *that* case you've got me, but I have to say that I have a hard time understanding how it might be possible to put in a new component with new NEMOv4 MR capability, but not a NEMOv6 MR. The v6 MR doesn't require any surrounding IPv6 infrastructure, either, so ... I have a hard time seeing how that restriction would come into place. Mind you, it might, but it's not obvious. > George > P.S.: BTW, Hesham is telling me that DS-MIPv6 spec does support IPv4 > prefixes Yes. Henrik >> -----Original Message----- >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >> Sent: Wednesday, May 10, 2006 4:55 PM >> To: Tsirtsis, George >> Cc: nemo@ietf.org; Thierry Ernst >> Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 >> >> Hi George, >> >> on 2006-05-10 17:51 Tsirtsis, George said the following: >> ... >> >> I'm not sure what your scenario is, and in which situation NEMOv4 >> >> support would be necessary. If someone argue that NEMOv4 is > necessary >> >> because there are existing vehicles - for instance - with IPv4 >> >> capabilities and the customer doesn't want to upgrade the vehicles > to >> >> IPv6, then I guess the customer could be adviced to deployed > DS-MIPv6 >> > on >> >> the MR. >> >> >> > >> > First of all I am not sure that DS-MIPv6 currently supports IPv4 > network >> > prefixes allocation (maybe it should). But even if it does, what you > are >> > suggesting is that the network operator providing services to that > car >> > is IPv6 capable. Is it not clear to everyone that in most of the > world >> > this is still not the case? >> >> Mmm?? I believe that is incorrect. I don't see why the network > operator >> has to be IPv6 capable. The only part in the network that has to be >> IPv6 is the home link, which can be virtual. So you'll need a MIPv6 >> HA, but the box it sits in doesn't even need a single physical > interface >> which has an IPv6 address. >> >> >> It would be interesting to list down in which situation a > transition >> >> mechanims (DM-MIPv6 or another one) could apply or not so that we >> > could >> >> clarify how many important scenarios would require a plain IPv4 >> > solution. >> >> >> > >> > NEMOv4 would be useful for network operators that support mobile >> > equipment (cars, trains, home routers or whatever) and that, for >> > whatever reason, do not support IPv6 but still want to support > network >> > mobility. >> >> (As indicated above) I believe this doesn't hold. >> >> > I really do not like the fact that lately, to do any IPv4 work in > the >> > IETF, we are getting pressured to release customer information and >> > deployment details. I will say the following which I hope will > satisfy >> > you: >> > We have a number of customers (network operators) in various parts > of >> > the world that have deployed our FLASH-OFDM system. This is > basically a >> > MobileIPv4 based cellular data system (search for Flarion press > releases >> > if you want specifics...and sorry for the commercial). >> > >> > Our customers would like to support network mobility. Some customers >> > would also like to move to IPv6 some day, which is why we proposed >> > DS-MIPv4 and DS-MIPv6 solutions. The two decisions, however, are not >> > related and should not have to be coupled. >> >> Fine. But nevertheless, NEMOv6 with DSMIPv6 will let you support >> network mobility without the operator having to support IPv6. >> >> >> Henrik > > From nemo-bounces@ietf.org Wed May 10 22:36:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe11u-000301-BN; Wed, 10 May 2006 22:35:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe11s-0002xq-MI for nemo@ietf.org; Wed, 10 May 2006 22:35:52 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe11p-0006GR-Ur for nemo@ietf.org; Wed, 10 May 2006 22:35:52 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4B2ZmjT003988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 10 May 2006 19:35:49 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4B2ZlBL015408; Wed, 10 May 2006 19:35:48 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 10 May 2006 19:35:47 -0700 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 Subject: RE: [nemo] NEMOv4 vs DS-MIPv6 Date: Wed, 10 May 2006 19:35:35 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8480F815@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] NEMOv4 vs DS-MIPv6 Thread-Index: AcZ0nQ/1/lNRxie5RM6rrGxJXVRhRgABVT/g From: "Narayanan, Vidya" To: "Henrik Levkowetz" , "Tsirtsis, George" X-OriginalArrivalTime: 11 May 2006 02:35:47.0127 (UTC) FILETIME=[9BEF2470:01C674A3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Henrik, =20 > In *that* case you've got me, but I have to say that I have a=20 > hard time understanding how it might be possible to put in a=20 > new component with new NEMOv4 MR capability, but not a NEMOv6=20 > MR. The v6 MR doesn't require any surrounding IPv6=20 > infrastructure, either, so ... I have a hard time seeing how=20 > that restriction would come into place. Mind you, it might,=20 > but it's not obvious. >=20 The problem sometimes is just the lack of an IPv6 stack in the host/mobile router. Putting new NEMOv4 functionality only relies on an existing IPv4 stack, while putting NEMOv6 brings in the need for an IPv6 stack. I am not saying that putting an IPv6 stack on such devices is the end of the world, but deployments aren't always that straightforward. In addition to adding NEMO functionality and dealing with the rollout, testing, etc. of that, such things are now broader with the introduction of IPv6 - which means more cycles, time, etc. - this is often a problem in the present world (unfortunately).=20 Vidya > > George > > P.S.: BTW, Hesham is telling me that DS-MIPv6 spec does=20 > support IPv4=20 > > prefixes >=20 > Yes. >=20 >=20 > Henrik >=20 >=20 > >> -----Original Message----- > >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] > >> Sent: Wednesday, May 10, 2006 4:55 PM > >> To: Tsirtsis, George > >> Cc: nemo@ietf.org; Thierry Ernst > >> Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 > >>=20 > >> Hi George, > >>=20 > >> on 2006-05-10 17:51 Tsirtsis, George said the following: > >> ... > >> >> I'm not sure what your scenario is, and in which=20 > situation NEMOv4=20 > >> >> support would be necessary. If someone argue that NEMOv4 is > > necessary > >> >> because there are existing vehicles - for instance - with IPv4=20 > >> >> capabilities and the customer doesn't want to upgrade=20 > the vehicles > > to > >> >> IPv6, then I guess the customer could be adviced to deployed > > DS-MIPv6 > >> > on > >> >> the MR. > >> >> > >> > > >> > First of all I am not sure that DS-MIPv6 currently supports IPv4 > > network > >> > prefixes allocation (maybe it should). But even if it does, what=20 > >> > you > > are > >> > suggesting is that the network operator providing=20 > services to that > > car > >> > is IPv6 capable. Is it not clear to everyone that in most of the > > world > >> > this is still not the case? > >>=20 > >> Mmm?? I believe that is incorrect. I don't see why the network > > operator > >> has to be IPv6 capable. The only part in the network that=20 > has to be > >> IPv6 is the home link, which can be virtual. So you'll=20 > need a MIPv6=20 > >> HA, but the box it sits in doesn't even need a single physical > > interface > >> which has an IPv6 address. > >>=20 > >> >> It would be interesting to list down in which situation a > > transition > >> >> mechanims (DM-MIPv6 or another one) could apply or not=20 > so that we > >> > could > >> >> clarify how many important scenarios would require a plain IPv4 > >> > solution. > >> >> > >> > > >> > NEMOv4 would be useful for network operators that support mobile=20 > >> > equipment (cars, trains, home routers or whatever) and that, for=20 > >> > whatever reason, do not support IPv6 but still want to support > > network > >> > mobility. > >>=20 > >> (As indicated above) I believe this doesn't hold. > >>=20 > >> > I really do not like the fact that lately, to do any IPv4 work in > > the > >> > IETF, we are getting pressured to release customer=20 > information and=20 > >> > deployment details. I will say the following which I hope will > > satisfy > >> > you: > >> > We have a number of customers (network operators) in=20 > various parts > > of > >> > the world that have deployed our FLASH-OFDM system. This is > > basically a > >> > MobileIPv4 based cellular data system (search for Flarion press > > releases > >> > if you want specifics...and sorry for the commercial). > >> > > >> > Our customers would like to support network mobility. Some=20 > >> > customers would also like to move to IPv6 some day,=20 > which is why we=20 > >> > proposed > >> > DS-MIPv4 and DS-MIPv6 solutions. The two decisions, however, are=20 > >> > not related and should not have to be coupled. > >>=20 > >> Fine. But nevertheless, NEMOv6 with DSMIPv6 will let you support=20 > >> network mobility without the operator having to support IPv6. > >>=20 > >>=20 > >> Henrik > >=20 > >=20 >=20 >=20 From nemo-bounces@ietf.org Thu May 11 04:24:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe6T7-0001Ha-0A; Thu, 11 May 2006 04:24:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe6T6-0001HV-3o for nemo@ietf.org; Thu, 11 May 2006 04:24:20 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe6T5-0004Vu-Nu for nemo@ietf.org; Thu, 11 May 2006 04:24:20 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k4B8bmLO024706; Thu, 11 May 2006 01:37:48 -0700 (MST) Received: from [10.161.194.46] (ZFR27-0227-010161194046.ea.mot.com [10.161.194.46]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k4B8aMn1013574; Thu, 11 May 2006 03:36:23 -0500 (CDT) Message-ID: <4462F4A9.1020604@motorola.com> Date: Thu, 11 May 2006 10:24:09 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 References: <1487A357FD2ED544B8AD29E528FF9DF0027DD453@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0027DD453@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 2857c5c041d6c02d7181d602c22822c8 Cc: nemo@ietf.org, Thierry Ernst , Henrik Levkowetz X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Tsirtsis, George wrote: > P.S.: BTW, Hesham is telling me that DS-MIPv6 spec does support IPv4 > prefixes ... where? The draft only says MR should attach a prefixlen on the v4 HoA in a IPv4 hoa option. Is there a way to communicate v4 MNPs that are not related to the HoA? Is it possible to specify several v4 MNPs? In NEMOv6, there is a particular case where the HoA is derived from the MNP. One would do same to support IPv4 moving networks: HoA derived from MNP should be a particular case, not the generic case. IMHO, the draft does not seem to specify a Prefix Table for security checks on the IPv4 MNPs. Without it there are important security risks. Or? Alex > >> -----Original Message----- From: Henrik Levkowetz >> [mailto:henrik@levkowetz.com] Sent: Wednesday, May 10, 2006 4:55 PM >> To: Tsirtsis, George Cc: nemo@ietf.org; Thierry Ernst Subject: Re: >> [nemo] NEMOv4 vs DS-MIPv6 >> >> Hi George, >> >> on 2006-05-10 17:51 Tsirtsis, George said the following: ... >>>> I'm not sure what your scenario is, and in which situation >>>> NEMOv4 support would be necessary. If someone argue that NEMOv4 >>>> is > necessary >>>> because there are existing vehicles - for instance - with IPv4 >>>> capabilities and the customer doesn't want to upgrade the >>>> vehicles > to >>>> IPv6, then I guess the customer could be adviced to deployed > DS-MIPv6 >>> on >>>> the MR. >>>> >>> First of all I am not sure that DS-MIPv6 currently supports IPv4 > network >>> prefixes allocation (maybe it should). But even if it does, what >>> you > are >>> suggesting is that the network operator providing services to >>> that > car >>> is IPv6 capable. Is it not clear to everyone that in most of the > world >>> this is still not the case? >> Mmm?? I believe that is incorrect. I don't see why the network > operator >> has to be IPv6 capable. The only part in the network that has to >> be IPv6 is the home link, which can be virtual. So you'll need a >> MIPv6 HA, but the box it sits in doesn't even need a single >> physical > interface >> which has an IPv6 address. >> >>>> It would be interesting to list down in which situation a > transition >>>> mechanims (DM-MIPv6 or another one) could apply or not so that >>>> we >>> could >>>> clarify how many important scenarios would require a plain IPv4 >>>> >>>> >>>> >>>> >>>> >>>> >>> solution. NEMOv4 would be useful for network operators that >>> support mobile equipment (cars, trains, home routers or whatever) >>> and that, for whatever reason, do not support IPv6 but still >>> want to support > network >>> mobility. >> (As indicated above) I believe this doesn't hold. >> >>> I really do not like the fact that lately, to do any IPv4 work in >>> >>> >>> >>> >>> >>> > the >>> IETF, we are getting pressured to release customer information >>> and deployment details. I will say the following which I hope >>> will > satisfy >>> you: We have a number of customers (network operators) in various >>> parts > of >>> the world that have deployed our FLASH-OFDM system. This is > basically a >>> MobileIPv4 based cellular data system (search for Flarion press > releases >>> if you want specifics...and sorry for the commercial). >>> >>> Our customers would like to support network mobility. Some >>> customers would also like to move to IPv6 some day, which is why >>> we proposed DS-MIPv4 and DS-MIPv6 solutions. The two decisions, >>> however, are not related and should not have to be coupled. >> Fine. But nevertheless, NEMOv6 with DSMIPv6 will let you support >> network mobility without the operator having to support IPv6. >> >> >> Henrik > > From nemo-bounces@ietf.org Thu May 11 04:28:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe6Wl-0002Bq-RP; Thu, 11 May 2006 04:28:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe6Wk-0002Bl-QV for nemo@ietf.org; Thu, 11 May 2006 04:28:06 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe6Wj-0004ea-K3 for nemo@ietf.org; Thu, 11 May 2006 04:28:06 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k4B8jDfC017482; Thu, 11 May 2006 01:45:13 -0700 (MST) Received: from [10.161.194.46] (ZFR27-0227-010161194046.ea.mot.com [10.161.194.46]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k4B8S4Ke021665; Thu, 11 May 2006 03:28:04 -0500 (CDT) Message-ID: <4462F58E.8060605@motorola.com> Date: Thu, 11 May 2006 10:27:58 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 References: <1487A357FD2ED544B8AD29E528FF9DF0027DD453@NAEX06.na.qualcomm.com> <44628DF4.7040704@levkowetz.com> In-Reply-To: <44628DF4.7040704@levkowetz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Henrik Levkowetz wrote: >> George P.S.: BTW, Hesham is telling me that DS-MIPv6 spec does >> support IPv4 prefixes > > Yes. IPv4 MNPs (mobile network prefixes) only prefixing the HoA? (the prefix len is attached to the HoA only, in the IPv4 home address option). There should be MNPs without any relation to HoA, no? IPv4 MNPs without a Prefix Table in the HA for security checks? Or do I have it wrong somehow again... Alex From nemo-bounces@ietf.org Thu May 11 04:35:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe6dT-0007ge-NP; Thu, 11 May 2006 04:35:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe6dS-0007fs-0l for nemo@ietf.org; Thu, 11 May 2006 04:35:02 -0400 Received: from otm-mgo01.iij.ad.jp ([210.138.20.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe6dQ-0004yw-Gm for nemo@ietf.org; Thu, 11 May 2006 04:35:02 -0400 Received: OTM-MO(otm-mgo01) id k4B8YrDM014377; Thu, 11 May 2006 17:34:53 +0900 (JST) Received: OTM-MIX(otm-mix00) id k4B8Yq7F048043; Thu, 11 May 2006 17:34:53 +0900 (JST) Received: from localhost (keiichi00.osaka.iij.ad.jp [192.168.64.45]) by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id k4B8YqDd014974; Thu, 11 May 2006 17:34:52 +0900 (JST) Date: Thu, 11 May 2006 17:38:30 +0900 (JST) Message-Id: <20060511.173830.84061247.keiichi@iijlab.net> To: alexandru.petrescu@motorola.com Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 From: Keiichi SHIMA In-Reply-To: <4462F4A9.1020604@motorola.com> References: <1487A357FD2ED544B8AD29E528FF9DF0027DD453@NAEX06.na.qualcomm.com> <4462F4A9.1020604@motorola.com> X-Mailer: Mew version 4.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: nemo@ietf.org, thierry.ernst@inria.fr, henrik@levkowetz.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org From: Alexandru Petrescu Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 Date: Thu, 11 May 2006 10:24:09 +0200 > Tsirtsis, George wrote: > > P.S.: BTW, Hesham is telling me that DS-MIPv6 spec does support IPv4 > > prefixes > > ... where? The draft only says MR should attach a prefixlen on the v4 > HoA in a IPv4 hoa option. Is there a way to communicate v4 MNPs that > are not related to the HoA? Is it possible to specify several v4 MNPs? I think I raised the feature in the Vancouver meeting and I believe authors incorporated the function to carry multiple v4pfxes in the draft. The issue 57 is that proposal I raised, and it seems it had been accepted. Maybe a short status report of this topic from the authors make your question clear. --- Keiichi SHIMA IIJ Research Laboratory WIDE Project From nemo-bounces@ietf.org Thu May 11 04:41:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe6jM-0001CR-0f; Thu, 11 May 2006 04:41:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe6jK-0001CM-Lv for nemo@ietf.org; Thu, 11 May 2006 04:41:06 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe6jK-0005CY-DA for nemo@ietf.org; Thu, 11 May 2006 04:41:06 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k4B8wI5r020490; Thu, 11 May 2006 01:58:18 -0700 (MST) Received: from [10.161.194.46] (ZFR27-0227-010161194046.ea.mot.com [10.161.194.46]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k4B8f6rl023150; Thu, 11 May 2006 03:41:07 -0500 (CDT) Message-ID: <4462F89E.9050901@motorola.com> Date: Thu, 11 May 2006 10:41:02 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Henrik Levkowetz Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 References: <1487A357FD2ED544B8AD29E528FF9DF0027DCDD9@NAEX06.na.qualcomm.com> <4462532B.80103@levkowetz.com> In-Reply-To: <4462532B.80103@levkowetz.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Henrik Levkowetz wrote: > Hi George, > > on 2006-05-10 17:51 Tsirtsis, George said the following: ... >>> I'm not sure what your scenario is, and in which situation NEMOv4 >>> support would be necessary. If someone argue that NEMOv4 is >>> necessary because there are existing vehicles - for instance - >>> with IPv4 capabilities and the customer doesn't want to upgrade >>> the vehicles to IPv6, then I guess the customer could be adviced >>> to deployed DS-MIPv6 >> on >>> the MR. >>> >> First of all I am not sure that DS-MIPv6 currently supports IPv4 >> network prefixes allocation (maybe it should). But even if it does, >> what you are suggesting is that the network operator providing >> services to that car is IPv6 capable. Is it not clear to everyone >> that in most of the world this is still not the case? > > Mmm?? I believe that is incorrect. I don't see why the network > operator has to be IPv6 capable. The only part in the network that > has to be IPv6 is the home link, which can be virtual. So you'll > need a MIPv6 HA, but the box it sits in doesn't even need a single > physical interface which has an IPv6 address. Sorry for asking this again, but I can't really understand this. I understand that some IPv6 home links can be virtual. But how about all the IPv6 real links that host IPv6 hosts. If these IPv6 hosts need to become mobile there is a need for a HA on that link with a real physical interface, no? I think in the case of the real IPv6 links hosting IPv6 hosts that don't have IPv4 stacks DS-MIPv6 is little adapted, no? There seems to me to be two main concepts of using Mobile IPv6: one with virtual home links (3gpp, mobile operators, HoA derived from MNP, etc) and one with real home links. I think both concepts should be supported by any MIP6-related protocol. Alex Alex > >>> It would be interesting to list down in which situation a >>> transition mechanims (DM-MIPv6 or another one) could apply or not >>> so that we >> could >>> clarify how many important scenarios would require a plain IPv4 >> solution. NEMOv4 would be useful for network operators that support >> mobile equipment (cars, trains, home routers or whatever) and >> that, for whatever reason, do not support IPv6 but still want to >> support network mobility. > > (As indicated above) I believe this doesn't hold. > >> I really do not like the fact that lately, to do any IPv4 work in >> the IETF, we are getting pressured to release customer information >> and deployment details. I will say the following which I hope will >> satisfy you: We have a number of customers (network operators) in >> various parts of the world that have deployed our FLASH-OFDM >> system. This is basically a MobileIPv4 based cellular data system >> (search for Flarion press releases if you want specifics...and >> sorry for the commercial). >> >> Our customers would like to support network mobility. Some >> customers would also like to move to IPv6 some day, which is why we >> proposed DS-MIPv4 and DS-MIPv6 solutions. The two decisions, >> however, are not related and should not have to be coupled. > > Fine. But nevertheless, NEMOv6 with DSMIPv6 will let you support > network mobility without the operator having to support IPv6. > > > Henrik > From nemo-bounces@ietf.org Thu May 11 04:43:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe6li-0001Ld-V7; Thu, 11 May 2006 04:43:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe6lh-0001LY-Ui for nemo@ietf.org; Thu, 11 May 2006 04:43:33 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe6lg-0005H1-Ni for nemo@ietf.org; Thu, 11 May 2006 04:43:33 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k4B90eds021018; Thu, 11 May 2006 02:00:40 -0700 (MST) Received: from [10.161.194.46] (ZFR27-0227-010161194046.ea.mot.com [10.161.194.46]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k4B90w0f018814; Thu, 11 May 2006 04:00:58 -0500 (CDT) Message-ID: <4462F92B.6090108@motorola.com> Date: Thu, 11 May 2006 10:43:23 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Keiichi SHIMA Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 References: <1487A357FD2ED544B8AD29E528FF9DF0027DD453@NAEX06.na.qualcomm.com> <4462F4A9.1020604@motorola.com> <20060511.173830.84061247.keiichi@iijlab.net> In-Reply-To: <20060511.173830.84061247.keiichi@iijlab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: nemo@ietf.org, thierry.ernst@inria.fr, henrik@levkowetz.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Keiichi SHIMA wrote: > From: Alexandru Petrescu Subject: > Re: [nemo] NEMOv4 vs DS-MIPv6 Date: Thu, 11 May 2006 10:24:09 +0200 > >> Tsirtsis, George wrote: >>> P.S.: BTW, Hesham is telling me that DS-MIPv6 spec does support >>> IPv4 prefixes >> ... where? The draft only says MR should attach a prefixlen on the >> v4 HoA in a IPv4 hoa option. Is there a way to communicate v4 MNPs >> that are not related to the HoA? Is it possible to specify several >> v4 MNPs? > > I think I raised the feature in the Vancouver meeting and I believe > authors incorporated the function to carry multiple v4pfxes in the > draft. > > The issue 57 is that proposal I raised, and it seems it had been > accepted. Is the issue also supporting HoA _not_ derived from MNP? And about extending the IPv6 Prefix Table to support IPv4 MNP related to IPv4 HoA? Alex From nemo-bounces@ietf.org Thu May 11 05:46:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe7kM-00043y-VT; Thu, 11 May 2006 05:46:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe7kL-00043t-G6 for nemo@ietf.org; Thu, 11 May 2006 05:46:13 -0400 Received: from av11-1-sn2.hy.skanova.net ([81.228.8.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe7kK-00082Y-V0 for nemo@ietf.org; Thu, 11 May 2006 05:46:13 -0400 Received: by av11-1-sn2.hy.skanova.net (Postfix, from userid 502) id 4A33537FDD; Thu, 11 May 2006 11:46:12 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av11-1-sn2.hy.skanova.net (Postfix) with ESMTP id 26CFB37F54; Thu, 11 May 2006 11:46:12 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id BE83437E50; Thu, 11 May 2006 11:46:07 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.61) (envelope-from ) id 1Fe7kE-0005aX-81; Thu, 11 May 2006 11:46:06 +0200 Message-ID: <446307DD.4090707@levkowetz.com> Date: Thu, 11 May 2006 11:46:05 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 References: <2EBB8025B6D1BA41B567DB32C1D8DB8480F815@NAEX06.na.qualcomm.com> In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB8480F815@NAEX06.na.qualcomm.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Vidya, on 2006-05-11 04:35 Narayanan, Vidya said the following: > Hi Henrik, > >> In *that* case you've got me, but I have to say that I have a >> hard time understanding how it might be possible to put in a >> new component with new NEMOv4 MR capability, but not a NEMOv6 >> MR. The v6 MR doesn't require any surrounding IPv6 >> infrastructure, either, so ... I have a hard time seeing how >> that restriction would come into place. Mind you, it might, >> but it's not obvious. >> > > The problem sometimes is just the lack of an IPv6 stack in the > host/mobile router. Putting new NEMOv4 functionality only relies on an > existing IPv4 stack, while putting NEMOv6 brings in the need for an IPv6 > stack. I am not saying that putting an IPv6 stack on such devices is the > end of the world, but deployments aren't always that straightforward. In > addition to adding NEMO functionality and dealing with the rollout, > testing, etc. of that, such things are now broader with the introduction > of IPv6 - which means more cycles, time, etc. - this is often a problem > in the present world (unfortunately). Heh. I understand. I see a market opening here for an implementation of MIPv6 which doesn't require an IPv6 stack as long as you're not sending IPv6 traffic. Entirely possible, I think. ;-) Henrik > Vidya > > >> > George >> > P.S.: BTW, Hesham is telling me that DS-MIPv6 spec does >> support IPv4 >> > prefixes >> >> Yes. >> >> >> Henrik >> >> >> >> -----Original Message----- >> >> From: Henrik Levkowetz [mailto:henrik@levkowetz.com] >> >> Sent: Wednesday, May 10, 2006 4:55 PM >> >> To: Tsirtsis, George >> >> Cc: nemo@ietf.org; Thierry Ernst >> >> Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 >> >> >> >> Hi George, >> >> >> >> on 2006-05-10 17:51 Tsirtsis, George said the following: >> >> ... >> >> >> I'm not sure what your scenario is, and in which >> situation NEMOv4 >> >> >> support would be necessary. If someone argue that NEMOv4 is >> > necessary >> >> >> because there are existing vehicles - for instance - with IPv4 >> >> >> capabilities and the customer doesn't want to upgrade >> the vehicles >> > to >> >> >> IPv6, then I guess the customer could be adviced to deployed >> > DS-MIPv6 >> >> > on >> >> >> the MR. >> >> >> >> >> > >> >> > First of all I am not sure that DS-MIPv6 currently supports IPv4 >> > network >> >> > prefixes allocation (maybe it should). But even if it does, what >> >> > you >> > are >> >> > suggesting is that the network operator providing >> services to that >> > car >> >> > is IPv6 capable. Is it not clear to everyone that in most of the >> > world >> >> > this is still not the case? >> >> >> >> Mmm?? I believe that is incorrect. I don't see why the network >> > operator >> >> has to be IPv6 capable. The only part in the network that >> has to be >> >> IPv6 is the home link, which can be virtual. So you'll >> need a MIPv6 >> >> HA, but the box it sits in doesn't even need a single physical >> > interface >> >> which has an IPv6 address. >> >> >> >> >> It would be interesting to list down in which situation a >> > transition >> >> >> mechanims (DM-MIPv6 or another one) could apply or not >> so that we >> >> > could >> >> >> clarify how many important scenarios would require a plain IPv4 >> >> > solution. >> >> >> >> >> > >> >> > NEMOv4 would be useful for network operators that support mobile >> >> > equipment (cars, trains, home routers or whatever) and that, for >> >> > whatever reason, do not support IPv6 but still want to support >> > network >> >> > mobility. >> >> >> >> (As indicated above) I believe this doesn't hold. >> >> >> >> > I really do not like the fact that lately, to do any IPv4 work in >> > the >> >> > IETF, we are getting pressured to release customer >> information and >> >> > deployment details. I will say the following which I hope will >> > satisfy >> >> > you: >> >> > We have a number of customers (network operators) in >> various parts >> > of >> >> > the world that have deployed our FLASH-OFDM system. This is >> > basically a >> >> > MobileIPv4 based cellular data system (search for Flarion press >> > releases >> >> > if you want specifics...and sorry for the commercial). >> >> > >> >> > Our customers would like to support network mobility. Some >> >> > customers would also like to move to IPv6 some day, >> which is why we >> >> > proposed >> >> > DS-MIPv4 and DS-MIPv6 solutions. The two decisions, however, are >> >> > not related and should not have to be coupled. >> >> >> >> Fine. But nevertheless, NEMOv6 with DSMIPv6 will let you support >> >> network mobility without the operator having to support IPv6. >> >> >> >> >> >> Henrik >> > >> > >> >> > From nemo-bounces@ietf.org Thu May 11 07:29:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe9Lt-0001xz-3b; Thu, 11 May 2006 07:29:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FaP5v-0001cW-LY for nemo@ietf.org; Sun, 30 Apr 2006 23:29:07 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FaOVH-0001EE-LY for nemo@ietf.org; Sun, 30 Apr 2006 22:51:15 -0400 Received: from mx2.grc.nasa.gov ([128.156.11.69]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FaOGX-0002LW-N8 for nemo@ietf.org; Sun, 30 Apr 2006 22:36:02 -0400 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id BEFD0C22D for ; Sun, 30 Apr 2006 22:36:00 -0400 (EDT) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.13.6/8.13.6) with ESMTP id k412ZxOq013546; Sun, 30 Apr 2006 22:35:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.6/8.13.1) with ESMTP id k412ZxDm000438; Sun, 30 Apr 2006 22:35:59 -0400 (EDT) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.nasa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 20914-14; Sun, 30 Apr 2006 22:35:56 -0400 (EDT) Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19])by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.6/8.13.1) with ESMTP id k412ZpMr000421;Sun, 30 Apr 2006 22:35:51 -0400 (EDT) Received: by webmail.grc.nasa.gov (Postfix, from userid 48)id A8D1634C2D; Sun, 30 Apr 2006 22:35:51 -0400 (EDT) Received: from nolmstd-cadent1-68-169-125-132.clvdoh.adelphia.net(nolmstd-cadent1-68-169-1 25-132.clvdoh.adelphia.net [68.169.125.132]) bywebmail.grc.nasa.gov (Horde MIME library) with HTTP; Sun, 30 Apr 200622:35:51 -0400 Message-ID: <20060430223551.s7jlv1ysxd0kscc0@webmail.grc.nasa.gov> Date: Sun, 30 Apr 2006 22:35:51 -0400 From: ivancic@grc.nasa.gov To: "Davis, Terry L" Subject: RE: [nemo] Rewording of RO work in the charter References: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing .com> In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boein g.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-imss-version: 2.038 X-imss-result: Passed X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 X-Mailman-Approved-At: Thu, 11 May 2006 07:29:01 -0400 Cc: ml-nemo WG , "T.J. Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Terry, You forgot two. Low cost. Zero delay. :-) Actually, I was at the last Internation Civil Aeronautics Organization (ICAO) working group meeting on IPv6. I may be very possible that a combination of routing using OSPFv3 for IPv6 and NEMO with MONAMI policy based routing can get most of what is required by aeronautics - actually perhaps all if some requirements are modified to match the paricular flight portions. As it is today, many of the delay requirement cannot be met by satellite because the delay requirements are the same for take-off and landing (surface area) as the are for enroute (plane in general flight at 30,000 ft). Obviously these requirments should not be the same. Today, most of the requirment are not met for all conditions and have never really been adequately tested under all conditions and all loads. For example, make-before-break is not really done as one has to reset frequency on the radio during some handover situations. This is a break before make situation. The requirment to send Air Traffic Control (ATC) over one link and Air Operations Control (AOC) over another is also not done - to the best of my knowledge. If I got the story right, much of the AOC was done before the ATC and then the ATC started using AOC links. The airlines don't want to pay for multiple links and generally do not operate multiple links. So what are requirements established years ago is actually not done in practice. Will Quoting "Davis, Terry L" : > T.J. > > You'll probably wish that you hadn't asked for this... > > These would be our ideal mobility solution. I realize that meeting all > of these is probably an extreme stretch. > > Take care > Terry > > ================================================================= > Generally the aviation mobility requirements are: > > 1- Ability to "dock" with numerous Internet service providers utilizing > different media; satellite (KU & L), EVDO, 802.11/802.16 airport; > hardwired Ethernet "gatelink". > > 2- Ability to be multihomed to different providers over different links > simultaneously. The desired aircraft state will be to have two links > active always. > > 3- Ability to assign traffic for specific providers links only (safety > or operational certified providers) > > 4- Ability to re-profile traffic to match available link capacity and > constraints when handing off between links. > > 5- Ability to seamlessly hand off existing network connections without > dropping the session (we do this today). > > 6- Ability to maintain security through link hand off. > > 7- Ability to continue to receive multicast traffic after hand off. > > 8- Route optimization such that on hand off to a new link, > connection/session routing is optimized to the new ground site. > > 9- Ability to maintain QoS on hand off with the capacity of the new link > (You may hand off to a link with a smaller capacity or higher error rate > or from an EVDO low latency link to a satellite high latency link) > > 10- Ability to support both IP-v6 and IP-v4 mobile platforms from an > IP-v6 network. > > 11- Ability to receive priority multicast/broadcast messages. > > 12- Ability to establish connections to multiple onboard networks over a > single link and hand off them simultaneously. (We expect the aircraft > to have at three independent onboard isolated networks; air traffic > control, airline operations, and passenger services. > > 13- Ability to initiate encrypted tunnels on all links with IPSec before > passing traffic. > > >> -----Original Message----- >> From: T.J. Kniveton [mailto:tj@kniveton.com] >> Sent: Friday, April 21, 2006 3:13 AM >> To: ml-nemo WG >> Subject: [nemo] Rewording of RO work in the charter >> >> Folks, >> >> I have been watching the conversation started by Marcelo a couple of >> weeks ago, regarding the rewording of the (n,n,n) item in the >> charter. (Sorry I haven't been commenting lately). >> >> We need to figure out how to massage the concepts being batted around >> so that we have something tractable that we can work on and complete. >> From the discussion so far, I tend to think: >> >> 1) We need somewhat more concrete idea of the requirements for the >> type of situation we want to solve. I agree with Andrew that we don't >> want to get bogged down in this, and I do believe Terry gave us a >> list for the Conexion scenario quite a while ago. Perhaps he or >> Andrew could give an updated list. >> >> 2) We need a bit more analysis still on the RO problem space, based >> on some idea of requirements for the solution to be worked out >> (according to charter items). Specifically, the effects of having a >> "Mobile ISP" vs. "ISP-independent mobile home networks", the >> implications of that for the global BGP tables, how likely it is to >> get custom agreements between a mobility provider and ISPs it (or its >> customers) uses, etc. >> >> 3) Route optimization - "Performance" as Marcelo called it - avoiding >> long tunneling (geographically) - or avoiding expensive links. This >> is what we have discussed so far, and we need a stronger boundary so >> that we can define what is to be solved in these specific >> circumstances. Otherwise this walks down the road toward many other >> long-standing issues. My view is that having a good list of >> requirements for the RO situation of interest would be helpful here. >> >> 4) Aviation - question of "if" to use Mobile IP... NEMO base does use >> it because it made sense. It's possible we have another deployment >> case where it does not make sense, but we still want a solution for >> Network Mobility. However, we have to be careful here. >> There are some general network mobility problems.. such as >> multiple ISPs, having high-cost links, and how/whether to inject >> routes into the BGP tables. I believe Terry already gave us a list of >> requirements for this type of situation - can we review that? >> >> 5) Regarding HAHA - As Pascal mentioned, this wasn't supposed to be >> "the only" or even "the" solution for RO. It is simply something that >> addressed a shown need, and so I considered it to be something that >> could be added for future work. But according to the list items >> above, the group is not including or excluding any certain solution >> at this point. We need more definition of what and how to solve, and >> the implications of various approaches first. I would like to hear >> the RO-analysis authors chime in on this one. >> >> Besides Aviation, I have asked numerous times for anyone who is >> actually deploying NEMO or NEMO-like technology to give us industry >> input for requirements. Aside from aviation, I have heard a little >> bitregarding Japanese auto makers, but not much else. I also used to >> know things about some large cell phone makers that might be doing >> these things, but never enough to make a good list of requirements. >> >> Remember, our goal here is to reshape the charter to solve problems >> so that NEMO can be deployed. If there are deployments that are >> facing these issues, they can be brought forward to be studied at >> this phase. >> >> In conclusion, I would like to have a bit more discussion, and then >> maybe people can offer suggestions on how specifically to reword >> charter language and/or change milestones so that these things can be >> accomplished. > > > From nemo-bounces@ietf.org Thu May 11 07:58:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe9oJ-0002hJ-HB; Thu, 11 May 2006 07:58:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe9oI-0002hE-Ev for nemo@ietf.org; Thu, 11 May 2006 07:58:26 -0400 Received: from otm-mgo00.iij.ad.jp ([210.138.20.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe9oG-0005Jk-Uc for nemo@ietf.org; Thu, 11 May 2006 07:58:26 -0400 Received: OTM-MO(otm-mgo00) id k4BBwNAC022022; Thu, 11 May 2006 20:58:23 +0900 (JST) Received: OTM-MIX(otm-mix01) id k4BBwMj8073936; Thu, 11 May 2006 20:58:22 +0900 (JST) Received: from localhost (keiichi00.osaka.iij.ad.jp [192.168.64.45]) by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id k4BBwKBV025495; Thu, 11 May 2006 20:58:22 +0900 (JST) Date: Thu, 11 May 2006 21:02:00 +0900 (JST) Message-Id: <20060511.210200.21724536.keiichi@iijlab.net> To: alexandru.petrescu@motorola.com Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 From: Keiichi SHIMA In-Reply-To: <4462F92B.6090108@motorola.com> References: <4462F4A9.1020604@motorola.com> <20060511.173830.84061247.keiichi@iijlab.net> <4462F92B.6090108@motorola.com> X-Mailer: Mew version 4.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: nemo@ietf.org, thierry.ernst@inria.fr, henrik@levkowetz.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org # I think the subject should be changed is this discussion continues From: Alexandru Petrescu Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 Date: Thu, 11 May 2006 10:43:23 +0200 > >>> P.S.: BTW, Hesham is telling me that DS-MIPv6 spec does support > >>> IPv4 prefixes > >> ... where? The draft only says MR should attach a prefixlen on the > >> v4 HoA in a IPv4 hoa option. Is there a way to communicate v4 MNPs > >> that are not related to the HoA? Is it possible to specify several > >> v4 MNPs? > > > > I think I raised the feature in the Vancouver meeting and I believe > > authors incorporated the function to carry multiple v4pfxes in the > > draft. > > > > The issue 57 is that proposal I raised, and it seems it had been > > accepted. > > Is the issue also supporting HoA _not_ derived from MNP? The issue doesn't explicitly mention it. But I don't think it is prohibited. > And about > extending the IPv6 Prefix Table to support IPv4 MNP related to IPv4 HoA? What does this mean? I don't understand why IPv6 prefix table have to support IPv4 prefix... (or are you talking about binding IPv6 prefixes to IPv4 HoA?) --- Keiichi SHIMA IIJ Research Laboratory WIDE Project From nemo-bounces@ietf.org Thu May 11 08:03:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe9tM-0005pw-BF; Thu, 11 May 2006 08:03:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fe9tL-0005pm-K4 for nemo@ietf.org; Thu, 11 May 2006 08:03:39 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fe9tK-0005YG-Cx for nemo@ietf.org; Thu, 11 May 2006 08:03:39 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k4BCKngi002842 for ; Thu, 11 May 2006 05:20:49 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k4BCLADf006697 for ; Thu, 11 May 2006 07:21:11 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 3000C865980 for ; Thu, 11 May 2006 14:03:37 +0200 (CEST) Message-ID: <44632818.7000403@motorola.com> Date: Thu, 11 May 2006 14:03:36 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ml-nemo WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [nemo] proxy vagueness for IPv4 HoA in DS-MIPv6, draft-ietf-mip6-nemo-v4traversal-01.txt X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Some comments on proxy behaviour of DS-MIPv6 HA draft-ietf-mip6-nemo-v4traversal-01.txt. The draft currently says: > A home agent must also act as a proxy for address resolution in IPv4 > for the registered IPv4 home addresses of mobile nodes it is serving. The draft doesn't mention anything about ARP. I was wondering whether HA should do proxy ARP for the real IPv4 HoA or proxy ND for IPv4-mapped IPv6 address (derived from the IPv4 HoA). I personally think it should do proxy ARP and not proxy ND, because I don't know how ND works with IPv4-mapped IPv6 addresses. If so, maybe it should be specified in the draft. What do you think? Alex From nemo-bounces@ietf.org Thu May 11 08:11:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeA0T-0000rz-UB; Thu, 11 May 2006 08:11:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeA0T-0000ru-Gr for nemo@ietf.org; Thu, 11 May 2006 08:11:01 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeA0S-0005lR-8T for nemo@ietf.org; Thu, 11 May 2006 08:11:01 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k4BCSA03004516; Thu, 11 May 2006 05:28:10 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k4BCB1Jk013242; Thu, 11 May 2006 07:11:02 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 84E0B865980; Thu, 11 May 2006 14:10:57 +0200 (CEST) Message-ID: <446329D1.6070006@motorola.com> Date: Thu, 11 May 2006 14:10:57 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Keiichi SHIMA Subject: Re: DS-MIPv6 technicals (waS: [nemo] NEMOv4 vs DS-MIPv6) References: <4462F4A9.1020604@motorola.com> <20060511.173830.84061247.keiichi@iijlab.net> <4462F92B.6090108@motorola.com> <20060511.210200.21724536.keiichi@iijlab.net> In-Reply-To: <20060511.210200.21724536.keiichi@iijlab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: nemo@ietf.org, thierry.ernst@inria.fr, henrik@levkowetz.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Keiichi SHIMA wrote: > # I think the subject should be changed is this discussion continues > > From: Alexandru Petrescu Subject: > Re: [nemo] NEMOv4 vs DS-MIPv6 Date: Thu, 11 May 2006 10:43:23 +0200 > >>>>> P.S.: BTW, Hesham is telling me that DS-MIPv6 spec does >>>>> support IPv4 prefixes >>>> ... where? The draft only says MR should attach a prefixlen on >>>> the v4 HoA in a IPv4 hoa option. Is there a way to >>>> communicate v4 MNPs that are not related to the HoA? Is it >>>> possible to specify several v4 MNPs? >>> I think I raised the feature in the Vancouver meeting and I >>> believe authors incorporated the function to carry multiple >>> v4pfxes in the draft. >>> >>> The issue 57 is that proposal I raised, and it seems it had been >>> accepted. >> Is the issue also supporting HoA _not_ derived from MNP? > > The issue doesn't explicitly mention it. But I don't think it is > prohibited. I'm not sure I understand. The draft doesn't say at all that the BU can carry an IPv4 MNP that is not prefixing the HoA as well. The option in BU is named "IPv4 home address option". It's difficult to read it as a "IPv4 mobile network prefix" although technically speaking the IPv4 home address option contains an address/prefix length. >> And about extending the IPv6 Prefix Table to support IPv4 MNP >> related to IPv4 HoA? > > What does this mean? I don't understand why IPv6 prefix table have > to support IPv4 prefix... (or are you talking about binding IPv6 > prefixes to IPv4 HoA?) No, talking about MR's IPv4 HoA - IPv4 MNP. The LFNs run IPv4-only, there are MNP (moving network prefixes) in the BU sent by MR to its HA. In this case the MNP is IPv4. HA should check that MR (its IPv4 Home Address) is allowed to use that particular MNP. This association is done in the prefix table. The prefix table is specified for NEMOv6, contains associations IPv6 HoA - IPv6 MNP. For DS-MIPv6 should probably contain IPv4 HoA - IPv4 MNP, just like NEMOv4 informational document does in its IPv4 Prefix Table. The prefix table serves to avoid security attacks on re-directing the MNP. Alex From nemo-bounces@ietf.org Thu May 11 08:24:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeADD-0006eY-Dq; Thu, 11 May 2006 08:24:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeADC-0006eT-Mh for nemo@ietf.org; Thu, 11 May 2006 08:24:10 -0400 Received: from otm-mgo01.iij.ad.jp ([210.138.20.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeADC-0006Lg-6E for nemo@ietf.org; Thu, 11 May 2006 08:24:10 -0400 Received: OTM-MO(otm-mgo01) id k4BCO9C8021020; Thu, 11 May 2006 21:24:09 +0900 (JST) Received: OTM-MIX(otm-mix00) id k4BCO8O7084168; Thu, 11 May 2006 21:24:08 +0900 (JST) Received: from localhost (keiichi00.osaka.iij.ad.jp [192.168.64.45]) by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id k4BCO8DN026605; Thu, 11 May 2006 21:24:08 +0900 (JST) Date: Thu, 11 May 2006 21:27:46 +0900 (JST) Message-Id: <20060511.212746.98611382.keiichi@iijlab.net> To: alexandru.petrescu@motorola.com From: Keiichi SHIMA In-Reply-To: <446329D1.6070006@motorola.com> References: <4462F92B.6090108@motorola.com> <20060511.210200.21724536.keiichi@iijlab.net> <446329D1.6070006@motorola.com> X-Mailer: Mew version 4.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: nemo@ietf.org, thierry.ernst@inria.fr, henrik@levkowetz.com Subject: [nemo] Re: DS-MIPv6 technicals X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, From: Alexandru Petrescu Subject: Re: DS-MIPv6 technicals (waS: [nemo] NEMOv4 vs DS-MIPv6) Date: Thu, 11 May 2006 14:10:57 +0200 > I'm not sure I understand. The draft doesn't say at all that the BU can > carry an IPv4 MNP that is not prefixing the HoA as well. > > The option in BU is named "IPv4 home address option". It's difficult to > read it as a "IPv4 mobile network prefix" although technically speaking > the IPv4 home address option contains an address/prefix length. I agree. I think the best way is to write your proposed text to solve the above confusion and put it in the issue tracker. > >> And about extending the IPv6 Prefix Table to support IPv4 MNP > >> related to IPv4 HoA? > > > > What does this mean? I don't understand why IPv6 prefix table have > > to support IPv4 prefix... (or are you talking about binding IPv6 > > prefixes to IPv4 HoA?) > > No, talking about MR's IPv4 HoA - IPv4 MNP. > > The LFNs run IPv4-only, there are MNP (moving network prefixes) in the > BU sent by MR to its HA. In this case the MNP is IPv4. HA should check > that MR (its IPv4 Home Address) is allowed to use that particular MNP. > This association is done in the prefix table. I raised this problem as issue 59. http://www.mip4.org/issues/tracker/mip6/issue59 Is this your concern? --- Keiichi SHIMA IIJ Research Laboratory WIDE Project From nemo-bounces@ietf.org Thu May 11 08:52:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAeA-0000Iv-HZ; Thu, 11 May 2006 08:52:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeAe8-0000IX-Rg for nemo@ietf.org; Thu, 11 May 2006 08:52:00 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeAe8-0007nE-QH for nemo@ietf.org; Thu, 11 May 2006 08:52:00 -0400 Received: from otm-mgo01.iij.ad.jp ([210.138.20.175]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FeA9B-0008CH-SL for nemo@ietf.org; Thu, 11 May 2006 08:20:06 -0400 Received: OTM-MO(otm-mgo01) id k4BCJxQJ020943; Thu, 11 May 2006 21:19:59 +0900 (JST) Received: OTM-MIX(otm-mix00) id k4BCJwPY083653; Thu, 11 May 2006 21:19:59 +0900 (JST) Received: from localhost (keiichi00.osaka.iij.ad.jp [192.168.64.45]) by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id k4BCJwVO026476; Thu, 11 May 2006 21:19:58 +0900 (JST) Date: Thu, 11 May 2006 21:23:38 +0900 (JST) Message-Id: <20060511.212338.88834948.keiichi@iijlab.net> To: alexandru.petrescu@motorola.com Subject: Re: [nemo] proxy vagueness for IPv4 HoA in DS-MIPv6, draft-ietf-mip6-nemo-v4traversal-01.txt From: Keiichi SHIMA In-Reply-To: <44632818.7000403@motorola.com> References: <44632818.7000403@motorola.com> X-Mailer: Mew version 4.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -1.8 (-) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, From: Alexandru Petrescu > The draft doesn't mention anything about ARP. > > I was wondering whether HA should do proxy ARP for the real IPv4 HoA or > proxy ND for IPv4-mapped IPv6 address (derived from the IPv4 HoA). > > I personally think it should do proxy ARP and not proxy ND, because I > don't know how ND works with IPv4-mapped IPv6 addresses. I raised this problem as issue 58. http://www.mip4.org/issues/tracker/mip6/issue58 --- Keiichi SHIMA IIJ Research Laboratory WIDE Project From nemo-bounces@ietf.org Thu May 11 09:24:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeB9d-00022L-Rr; Thu, 11 May 2006 09:24:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeB9c-00022G-RB for nemo@ietf.org; Thu, 11 May 2006 09:24:32 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeB9b-0001QB-I6 for nemo@ietf.org; Thu, 11 May 2006 09:24:32 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k4BDfY7c022933; Thu, 11 May 2006 06:41:34 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k4BDftjA012207; Thu, 11 May 2006 08:41:55 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 58AAA865980; Thu, 11 May 2006 15:24:21 +0200 (CEST) Message-ID: <44633B05.7070304@motorola.com> Date: Thu, 11 May 2006 15:24:21 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Keiichi SHIMA References: <4462F92B.6090108@motorola.com> <20060511.210200.21724536.keiichi@iijlab.net> <446329D1.6070006@motorola.com> <20060511.212746.98611382.keiichi@iijlab.net> In-Reply-To: <20060511.212746.98611382.keiichi@iijlab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: nemo@ietf.org, thierry.ernst@inria.fr, henrik@levkowetz.com Subject: [nemo] Re: DS-MIPv6 technicals X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Keiichi SHIMA wrote: > Hi, > > From: Alexandru Petrescu Subject: > Re: DS-MIPv6 technicals (waS: [nemo] NEMOv4 vs DS-MIPv6) Date: Thu, > 11 May 2006 14:10:57 +0200 > >> I'm not sure I understand. The draft doesn't say at all that the >> BU can carry an IPv4 MNP that is not prefixing the HoA as well. >> >> The option in BU is named "IPv4 home address option". It's >> difficult to read it as a "IPv4 mobile network prefix" although >> technically speaking the IPv4 home address option contains an >> address/prefix length. > > I agree. I think the best way is to write your proposed text to > solve the above confusion and put it in the issue tracker. I am not sure I can write something in the issue tracker until the authors of the document agree. I think they are responsible for the issue tracker, no? >>>> And about extending the IPv6 Prefix Table to support IPv4 MNP >>>> related to IPv4 HoA? >>> What does this mean? I don't understand why IPv6 prefix table >>> have to support IPv4 prefix... (or are you talking about binding >>> IPv6 prefixes to IPv4 HoA?) >> No, talking about MR's IPv4 HoA - IPv4 MNP. >> >> The LFNs run IPv4-only, there are MNP (moving network prefixes) in >> the BU sent by MR to its HA. In this case the MNP is IPv4. HA >> should check that MR (its IPv4 Home Address) is allowed to use that >> particular MNP. This association is done in the prefix table. > > I raised this problem as issue 59. > http://www.mip4.org/issues/tracker/mip6/issue59 > > Is this your concern? My concern is about the text there: > for 4.3. Home agent operations: > > IPv4 packets delivered to the home agent must be forwarded using the > bi-directional tunnel to the corresponding mobile node which has > registered the same IPv4 prefix of the delivered packets as an IPv4 > mobile network prefix. IPv4 packets received from the bi-directional > tunnel created between the home agent and a mobile node must be > forwarded based on the routing information of the home agent, if the > prefix is registered as one of IPv4 mobile network prefixes of the > mobile node. I am thinking about writing specific text about Prefix Table. Not about "routing information of the home agent". Prefix Table is described both in NEMOv6 and NEMOv4. >> if the prefix is registered as one of IPv4 mobile network prefixes >> of the mobile node. The MNP in the Prefix Table is not "registered" as if it were inserted there upon reception of the BU. The MNP in Prefix Table is pre-configured in the HA. When HA receives BU from MR it checks the MNP and HoA in the BU against the MNP and HoA already in the Prefix Table. The only thing I'm suggesting is to have a section titled "Prefix Table for DS-MIPv6" that says that the Prefix Table may contain IPv6 HoA - IPv6 MNP pairs, or IPv4 HoA - IPv4 MNP pairs, or IPv4-mapped IPv6 HoA... etc. There may be need of agreement of what exactly to put in the Prefix Table. Alex From nemo-bounces@ietf.org Thu May 11 10:51:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCVR-0001CU-0H; Thu, 11 May 2006 10:51:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeCVP-0001CP-VZ for nemo@ietf.org; Thu, 11 May 2006 10:51:07 -0400 Received: from revol1.enst.fr ([137.194.2.7] helo=smtp2.enst.fr) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeCVM-0005KA-MW for nemo@ietf.org; Thu, 11 May 2006 10:51:07 -0400 Received: from localhost (localhost.enst.fr [127.0.0.1]) by smtp2.enst.fr (Postfix) with ESMTP id ED76B1653E6 for ; Thu, 11 May 2006 16:51:01 +0200 (CEST) X-Virus-Scanned: amavisd-new at enst.fr Received: from smtp2.enst.fr ([127.0.0.1]) by localhost (revol1.enst.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NA+FvxG9TCSJ for ; Thu, 11 May 2006 16:51:01 +0200 (CEST) Received: from [137.194.160.211] (dhcp160-211.enst.fr [137.194.160.211]) by smtp2.enst.fr (Postfix) with ESMTP id 8DFB4164CF6 for ; Thu, 11 May 2006 16:51:01 +0200 (CEST) Message-ID: <44634F53.2010004@enst.fr> Date: Thu, 11 May 2006 16:50:59 +0200 From: LIN hai User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: nemo@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [nemo] demand of nemo simulation X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hello everybody, I am looking for the nemo simulation for NS2; if someone has it, could you please send me your source codes? thank you in advance, lin hai From nemo-bounces@ietf.org Thu May 11 13:48:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFGl-0000Of-Vw; Thu, 11 May 2006 13:48:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFGk-0000Oa-Ie for nemo@ietf.org; Thu, 11 May 2006 13:48:10 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeFGj-0004jt-8M for nemo@ietf.org; Thu, 11 May 2006 13:48:10 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4BHlxRL022901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 May 2006 10:48:01 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4BHlrJF016156; Thu, 11 May 2006 10:47:57 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 May 2006 10:47:53 -0700 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 Subject: RE: [nemo] NEMOv4 vs DS-MIPv6 Date: Thu, 11 May 2006 10:47:52 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF00284A0ED@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] NEMOv4 vs DS-MIPv6 Thread-Index: AcZ013crDnW5+tlVShazHcuOap3DPAAS3x3w From: "Soliman, Hesham" To: "Keiichi SHIMA" , X-OriginalArrivalTime: 11 May 2006 17:47:53.0856 (UTC) FILETIME=[079B4800:01C67523] X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: nemo@ietf.org, thierry.ernst@inria.fr, henrik@levkowetz.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org =20 > > Tsirtsis, George wrote: > > > P.S.: BTW, Hesham is telling me that DS-MIPv6 spec does=20 > support IPv4=20 > > > prefixes > >=20 > > ... where? The draft only says MR should attach a=20 > prefixlen on the v4 > > HoA in a IPv4 hoa option. Is there a way to communicate=20 > v4 MNPs that > > are not related to the HoA? Is it possible to specify=20 > several v4 MNPs? >=20 > I think I raised the feature in the Vancouver meeting and I believe > authors incorporated the function to carry multiple v4pfxes=20 > in the draft. >=20 > The issue 57 is that proposal I raised, and it seems it had=20 > been accepted. > =20 > Maybe a short status report of this topic from the authors make your > question clear. =3D> What Keiichi said is correct. We included this based on his = comments. Hesham >=20 > --- > Keiichi SHIMA > IIJ Research Laboratory > WIDE Project >=20 >=20 >=20 From nemo-bounces@ietf.org Thu May 11 13:52:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFL0-0000o7-30; Thu, 11 May 2006 13:52:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFKy-0000nj-H1 for nemo@ietf.org; Thu, 11 May 2006 13:52:32 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeFKx-0004sO-9S for nemo@ietf.org; Thu, 11 May 2006 13:52:32 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k4BI9YoS005611; Thu, 11 May 2006 11:09:42 -0700 (MST) Received: from [10.169.4.90] (mvp-10-169-4-90.corp.mot.com [10.169.4.90]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k4BI9stj005327; Thu, 11 May 2006 13:09:54 -0500 (CDT) Message-ID: <446379D3.1000906@motorola.com> Date: Thu, 11 May 2006 19:52:19 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 References: <1487A357FD2ED544B8AD29E528FF9DF00284A0ED@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF00284A0ED@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: nemo@ietf.org, thierry.ernst@inria.fr, henrik@levkowetz.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Soliman, Hesham wrote: > >>> Tsirtsis, George wrote: >>>> P.S.: BTW, Hesham is telling me that DS-MIPv6 spec does >> support IPv4 >>>> prefixes >>> >>> ... where? The draft only says MR should attach a >> prefixlen on the v4 >>> HoA in a IPv4 hoa option. Is there a way to communicate >> v4 MNPs that >>> are not related to the HoA? Is it possible to specify >> several v4 MNPs? >> >> I think I raised the feature in the Vancouver meeting and I believe >> authors incorporated the function to carry multiple v4pfxes in the >> draft. >> >> The issue 57 is that proposal I raised, and it seems it had been >> accepted. >> >> Maybe a short status report of this topic from the authors make >> your question clear. > > => What Keiichi said is correct. We included this based on his > comments. Ah I see, thanks. I based my remarks on the published draft. I'll wait for the next draft cycle to see whether MNP can be different than HoA, and I will comment then. Alex From nemo-bounces@ietf.org Thu May 11 14:03:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFVG-0002cZ-2J; Thu, 11 May 2006 14:03:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeFVE-0002cP-At for nemo@ietf.org; Thu, 11 May 2006 14:03:08 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeFVC-0005NK-Vx for nemo@ietf.org; Thu, 11 May 2006 14:03:08 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4BI35Rq008413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 May 2006 11:03:05 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4BI30nx009524; Thu, 11 May 2006 11:03:04 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 May 2006 11:03:01 -0700 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 Subject: RE: [nemo] NEMOv4 vs DS-MIPv6 Date: Thu, 11 May 2006 11:02:59 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF00284A12D@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] NEMOv4 vs DS-MIPv6 Thread-Index: AcZ1I7qPjvI9CUuGSwij04KymJ7F5wAAVCvQ From: "Soliman, Hesham" To: "Alexandru Petrescu" X-OriginalArrivalTime: 11 May 2006 18:03:01.0107 (UTC) FILETIME=[245ECC30:01C67525] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: nemo@ietf.org, thierry.ernst@inria.fr, henrik@levkowetz.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org It is in the published draft. We don't talk about MNP tables but=20 that doesn't mean we don't support it.=20 Hesham =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]=20 > Sent: Thursday, May 11, 2006 1:52 PM > To: Soliman, Hesham > Cc: Keiichi SHIMA; nemo@ietf.org; thierry.ernst@inria.fr;=20 > henrik@levkowetz.com > Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 >=20 > Soliman, Hesham wrote: > >=20 > >>> Tsirtsis, George wrote: > >>>> P.S.: BTW, Hesham is telling me that DS-MIPv6 spec does > >> support IPv4 > >>>> prefixes > >>>=20 > >>> ... where? The draft only says MR should attach a > >> prefixlen on the v4 > >>> HoA in a IPv4 hoa option. Is there a way to communicate > >> v4 MNPs that > >>> are not related to the HoA? Is it possible to specify > >> several v4 MNPs? > >>=20 > >> I think I raised the feature in the Vancouver meeting and=20 > I believe > >> authors incorporated the function to carry multiple=20 > v4pfxes in the > >> draft. > >>=20 > >> The issue 57 is that proposal I raised, and it seems it had been=20 > >> accepted. > >>=20 > >> Maybe a short status report of this topic from the authors make=20 > >> your question clear. > >=20 > > =3D> What Keiichi said is correct. We included this based on his=20 > > comments. >=20 > Ah I see, thanks. I based my remarks on the published draft. I'll > wait for the next draft cycle to see whether MNP can be=20 > different than > HoA, and I will comment then. >=20 > Alex >=20 From nemo-bounces@ietf.org Thu May 11 14:36:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeG0z-0001Su-RZ; Thu, 11 May 2006 14:35:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeG0y-0001Sp-MO for nemo@ietf.org; Thu, 11 May 2006 14:35:56 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeG0x-0006u1-Ah for nemo@ietf.org; Thu, 11 May 2006 14:35:56 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k4BInNCt028656; Thu, 11 May 2006 11:49:23 -0700 (MST) Received: from [10.169.4.90] (mvp-10-169-4-90.corp.mot.com [10.169.4.90]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k4BIne3x024203; Thu, 11 May 2006 13:49:42 -0500 (CDT) Message-ID: <446383FF.3050009@motorola.com> Date: Thu, 11 May 2006 20:35:43 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 References: <1487A357FD2ED544B8AD29E528FF9DF00284A12D@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF00284A12D@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: nemo@ietf.org, thierry.ernst@inria.fr, henrik@levkowetz.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Soliman, Hesham wrote: > It is in the published draft. The published draft says this: > 3.1.1 IPv4 home address option > > This option is included in the Mobility Header including the binding > update message sent from the mobile node to a home agent or Mobility > Anchor Point. > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Type | Length | Pref |Res| > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IPv4 home address | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > Type TBD > > Length 1 > > Pref The length of the prefix associated with the > home address. If only a single address is > needed/allowed, this field MUST be set to 32. The title of the option is "IPv4 home address option", and the field name is "IPv4 Home Address". There is a "Pref" field for prefix length. I was confused by two things. "Pref" can be confused with "Preference", that's how I read it. Better be named "plen" in the message diagram and fully spelled "plen - Prefix Length" in the body, or similar, to avoid confusion with "preference". The second confusion is that it clearly suggests that the HoA is bound to MNP. Both in NEMOv6 and NEMOv4 HoA is not bound to MNP. I suggest DS-MIPv6 doesn't bind them either. The only place where they are bound is in soon-to-be RFC informational Home Network models (IESG queue). > We don't talk about MNP tables but that doesn't mean we don't support > it. I'm against silently supporting an essential data structure for security. When programming DS-MIPv6 on a node with IPv4 and MIP6-NEMOv6 stacks (not NEMOv4) the data structure available is the Prefix Table of NEMOv6. That contains IPv6 HoA-MNP pairs. For DS-MIPv6 to support IPv4 MNPs it should contain IPv4 HoA-MNP pairs. Or maybe IPv4-mapped IPv6 addresses? What does the draft recommend to implementers with respect to this choice? Alex From nemo-bounces@ietf.org Thu May 11 14:41:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeG67-0004Ei-MZ; Thu, 11 May 2006 14:41:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeG66-0004BV-2a for nemo@ietf.org; Thu, 11 May 2006 14:41:14 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeG63-0007Gp-NH for nemo@ietf.org; Thu, 11 May 2006 14:41:14 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4BIf9QN012217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 11 May 2006 11:41:10 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4BIel8p022814; Thu, 11 May 2006 11:41:07 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 May 2006 11:41:05 -0700 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 Subject: RE: [nemo] NEMOv4 vs DS-MIPv6 Date: Thu, 11 May 2006 11:41:04 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF00284A193@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] NEMOv4 vs DS-MIPv6 Thread-Index: AcZ1Kc5TxRZFBYTZSb6RCMT6103pqQAAFDRw From: "Soliman, Hesham" To: "Alexandru Petrescu" X-OriginalArrivalTime: 11 May 2006 18:41:05.0458 (UTC) FILETIME=[75F31920:01C6752A] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: nemo@ietf.org, thierry.ernst@inria.fr, henrik@levkowetz.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > The title of the option is "IPv4 home address option", and the field=20 > name is "IPv4 Home Address". There is a "Pref" field for=20 > prefix length.=20 > I was confused by two things. =3D> The intro of the draft states that we use "address" to refer to both addresses and prefixes.=20 >=20 > "Pref" can be confused with "Preference", that's how I read=20 > it. Better=20 > be named "plen" in the message diagram and fully spelled=20 > "plen - Prefix=20 > Length" in the body, or similar, to avoid confusion with=20 > "preference". =3D> ok. >=20 > The second confusion is that it clearly suggests that the=20 > HoA is bound=20 > to MNP. Both in NEMOv6 and NEMOv4 HoA is not bound to MNP. =20 > I suggest=20 > DS-MIPv6 doesn't bind them either. The only place where=20 > they are bound=20 > is in soon-to-be RFC informational Home Network models (IESG queue). =3D> ok.=20 >=20 > > We don't talk about MNP tables but that doesn't mean we=20 > don't support > > it. >=20 > I'm against silently supporting an essential data structure=20 > for security. =3D> Fine, I'll add something to explain this. Feel free to suggest = text.=20 Hesham >=20 > When programming DS-MIPv6 on a node with IPv4 and MIP6-NEMOv6 stacks=20 > (not NEMOv4) the data structure available is the Prefix=20 > Table of NEMOv6.=20 > That contains IPv6 HoA-MNP pairs. For DS-MIPv6 to support=20 > IPv4 MNPs it=20 > should contain IPv4 HoA-MNP pairs. Or maybe IPv4-mapped IPv6=20 > addresses?=20 > What does the draft recommend to implementers with respect=20 > to this choice? >=20 > Alex >=20 >=20 From nemo-bounces@ietf.org Thu May 11 15:01:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGPs-0004OO-60; Thu, 11 May 2006 15:01:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGPq-0004OJ-G5 for nemo@ietf.org; Thu, 11 May 2006 15:01:38 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeGPp-0008AM-4D for nemo@ietf.org; Thu, 11 May 2006 15:01:38 -0400 Received: from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k4BJNNMx005977; Thu, 11 May 2006 12:23:23 -0700 (MST) Received: from [10.169.4.90] (mvp-10-169-4-90.corp.mot.com [10.169.4.90]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id k4BJFK49010316; Thu, 11 May 2006 14:15:21 -0500 (CDT) Message-ID: <44638A03.4060905@motorola.com> Date: Thu, 11 May 2006 21:01:23 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: "Soliman, Hesham" Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 References: <1487A357FD2ED544B8AD29E528FF9DF00284A193@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF00284A193@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: nemo@ietf.org, thierry.ernst@inria.fr, henrik@levkowetz.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Soliman, Hesham wrote: > >> The title of the option is "IPv4 home address option", and the >> field name is "IPv4 Home Address". There is a "Pref" field for >> prefix length. I was confused by two things. > > => The intro of the draft states that we use "address" to refer to > both addresses and prefixes. Even if "address" is substituted with "prefix", this gives "IPv4 home prefix option" and "IPv4 home prefix". And here we actually talk about Mobile Network Prefix. The "home prefix" is only the prefix on the home link, not MNPs below the MR. >> "Pref" can be confused with "Preference", that's how I read it. >> Better be named "plen" in the message diagram and fully spelled >> "plen - Prefix Length" in the body, or similar, to avoid confusion >> with "preference". > > => ok. Thanks. >> The second confusion is that it clearly suggests that the HoA is >> bound to MNP. Both in NEMOv6 and NEMOv4 HoA is not bound to MNP. I >> suggest DS-MIPv6 doesn't bind them either. The only place where >> they are bound is in soon-to-be RFC informational Home Network >> models (IESG queue). > > => ok. Thanks. >>> We don't talk about MNP tables but that doesn't mean we >> don't support >>> it. >> >> I'm against silently supporting an essential data structure for >> security. > > => Fine, I'll add something to explain this. Feel free to suggest > text. I suggest using IPv4-mapped IPv6 addresses in the Prefix Table whenever the HoA of MR is an IPv4 HoA (and not simple 32bit IPv4 addresses in the NEMOv6 Prefix Table). I am not sure though about the IPv4 MNP. There seems to be no specification about how to use an IPv4 prefix in the v4-mapped v6 form, I've checked rfc4038 (app aspects of v6 trans) and 4291 (v6 addr arch). The confusion that may arise representing a v4 MNP in v4-mapped form is illustrated by the following two representations saying same thing but written completely differently: ::ffff:1.0.0.0/8 ::ffff:1.0.0.0/102. The 8bits plen is from the v4 prefix, and 102bits plen is a v6 plen. So, because of this IPv4 MNP issue I don't know what to put in the DS-MIPv6 Prefix Table. Any idea? Alex From nemo-bounces@ietf.org Thu May 11 15:19:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGgi-0007Q5-BI; Thu, 11 May 2006 15:19:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGgh-0007Q0-Sa for nemo@ietf.org; Thu, 11 May 2006 15:19:03 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeGgg-0000V4-JS for nemo@ietf.org; Thu, 11 May 2006 15:19:03 -0400 Received: from [10.1.201.13] ([10.1.201.13]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 May 2006 12:18:59 -0700 Message-ID: <44638E22.7070606@azairenet.com> Date: Thu, 11 May 2006 12:18:58 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 References: <1487A357FD2ED544B8AD29E528FF9DF00284A193@NAEX06.na.qualcomm.com> <44638A03.4060905@motorola.com> In-Reply-To: <44638A03.4060905@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 May 2006 19:18:59.0973 (UTC) FILETIME=[C1AA8B50:01C6752F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Alexandru Petrescu wrote: > I suggest using IPv4-mapped IPv6 addresses in the Prefix Table whenever > the HoA of MR is an IPv4 HoA (and not simple 32bit IPv4 addresses in the > NEMOv6 Prefix Table). I am not sure though about the IPv4 MNP. There > seems to be no specification about how to use an IPv4 prefix in the > v4-mapped v6 form, I've checked rfc4038 (app aspects of v6 trans) and > 4291 (v6 addr arch). > > The confusion that may arise representing a v4 MNP in v4-mapped form is > illustrated by the following two representations saying same thing but > written completely differently: ::ffff:1.0.0.0/8 > ::ffff:1.0.0.0/102. > The 8bits plen is from the v4 prefix, and 102bits plen is a v6 plen. > > So, because of this IPv4 MNP issue I don't know what to put in the > DS-MIPv6 Prefix Table. > > Any idea? we can extend the definition of Prefix Table to include IPv4 mobile network prefixes in addition to IPv6 mobile network prefixes. that would be the simplest. Vijay From nemo-bounces@ietf.org Thu May 11 15:32:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGtk-0001Rx-VA; Thu, 11 May 2006 15:32:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeGtk-0001Rs-5a for nemo@ietf.org; Thu, 11 May 2006 15:32:32 -0400 Received: from motgate4.mot.com ([144.189.100.102]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeGti-0001Jg-QI for nemo@ietf.org; Thu, 11 May 2006 15:32:32 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate4.mot.com (8.12.11/Motgate4) with ESMTP id k4BJjwKt003855; Thu, 11 May 2006 12:45:58 -0700 (MST) Received: from [10.169.4.90] (mvp-10-169-4-90.corp.mot.com [10.169.4.90]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k4BJiWqb014300; Thu, 11 May 2006 14:44:33 -0500 (CDT) Message-ID: <44639143.401@motorola.com> Date: Thu, 11 May 2006 21:32:19 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 References: <1487A357FD2ED544B8AD29E528FF9DF00284A193@NAEX06.na.qualcomm.com> <44638A03.4060905@motorola.com> <44638E22.7070606@azairenet.com> In-Reply-To: <44638E22.7070606@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Vijay Devarapalli wrote: > Alexandru Petrescu wrote: >> I suggest using IPv4-mapped IPv6 addresses in the Prefix Table >> whenever the HoA of MR is an IPv4 HoA (and not simple 32bit IPv4 >> addresses in the NEMOv6 Prefix Table). I am not sure though about >> the IPv4 MNP. There seems to be no specification about how to use >> an IPv4 prefix in the v4-mapped v6 form, I've checked rfc4038 (app >> aspects of v6 trans) and 4291 (v6 addr arch). >> >> The confusion that may arise representing a v4 MNP in v4-mapped >> form is illustrated by the following two representations saying >> same thing but written completely differently: ::ffff:1.0.0.0/8 >> ::ffff:1.0.0.0/102. The 8bits plen is from the v4 prefix, and >> 102bits plen is a v6 plen. >> >> So, because of this IPv4 MNP issue I don't know what to put in the >> DS-MIPv6 Prefix Table. >> >> Any idea? > > we can extend the definition of Prefix Table to include IPv4 mobile > network prefixes in addition to IPv6 mobile network prefixes. that > would be the simplest. Right, that's what we did in NEMOv4. Alex From nemo-bounces@ietf.org Thu May 11 21:36:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeMZG-0003e4-Bg; Thu, 11 May 2006 21:35:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeMZF-0003dz-Mx for nemo@ietf.org; Thu, 11 May 2006 21:35:45 -0400 Received: from otm-mgo01.iij.ad.jp ([210.138.20.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeMZC-0001gN-1B for nemo@ietf.org; Thu, 11 May 2006 21:35:45 -0400 Received: OTM-MO(otm-mgo01) id k4C1ZS04036550; Fri, 12 May 2006 10:35:28 +0900 (JST) Received: OTM-MIX(otm-mix01) id k4C1ZRw2063446; Fri, 12 May 2006 10:35:27 +0900 (JST) Received: from localhost (keiichi00.osaka.iij.ad.jp [192.168.64.45]) by jc-smtp.iij.ad.jp (JC-SMTP/jc-smtp) id k4C1ZRtA025839; Fri, 12 May 2006 10:35:27 +0900 (JST) Date: Fri, 12 May 2006 10:39:08 +0900 (JST) Message-Id: <20060512.103908.119810004.keiichi@iijlab.net> To: alexandru.petrescu@motorola.com Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 From: Keiichi SHIMA In-Reply-To: <44638A03.4060905@motorola.com> References: <1487A357FD2ED544B8AD29E528FF9DF00284A193@NAEX06.na.qualcomm.com> <44638A03.4060905@motorola.com> X-Mailer: Mew version 4.1.50 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: nemo@ietf.org, thierry.ernst@inria.fr, henrik@levkowetz.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org From: Alexandru Petrescu Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 Date: Thu, 11 May 2006 21:01:23 +0200 > >>> We don't talk about MNP tables but that doesn't mean we > >> don't support > >>> it. > >> > >> I'm against silently supporting an essential data structure for > >> security. > > > > => Fine, I'll add something to explain this. Feel free to suggest > > text. > > I suggest using IPv4-mapped IPv6 addresses in the Prefix Table whenever > the HoA of MR is an IPv4 HoA (and not simple 32bit IPv4 addresses in the > NEMOv6 Prefix Table). I am not sure though about the IPv4 MNP. There > seems to be no specification about how to use an IPv4 prefix in the > v4-mapped v6 form, I've checked rfc4038 (app aspects of v6 trans) and > 4291 (v6 addr arch). If your suggestion is to write that "IPv4 MNP should be kept in IPv4-mapped IPv6 address in IPv6 prefix tables", then I am against. That kind of design should be implementation matter. As Vijay said in the following mail, simply saying that the prefix table can keep both IPv6 and IPv4 prefixes seems enough to me. --- Keiichi SHIMA IIJ Research Laboratory WIDE Project From nemo-bounces@ietf.org Fri May 12 05:51:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeUIK-000691-3m; Fri, 12 May 2006 05:50:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FeUII-00068w-8U for nemo@ietf.org; Fri, 12 May 2006 05:50:46 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FeUIG-0000Rn-Vy for nemo@ietf.org; Fri, 12 May 2006 05:50:46 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k4CA7tN2007418; Fri, 12 May 2006 03:07:55 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k4C9ok2V013899; Fri, 12 May 2006 04:50:46 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 46E27865980; Fri, 12 May 2006 11:50:40 +0200 (CEST) Message-ID: <44645A70.5090301@motorola.com> Date: Fri, 12 May 2006 11:50:40 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Keiichi SHIMA Subject: Re: [nemo] NEMOv4 vs DS-MIPv6 References: <1487A357FD2ED544B8AD29E528FF9DF00284A193@NAEX06.na.qualcomm.com> <44638A03.4060905@motorola.com> <20060512.103908.119810004.keiichi@iijlab.net> In-Reply-To: <20060512.103908.119810004.keiichi@iijlab.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: nemo@ietf.org, thierry.ernst@inria.fr, henrik@levkowetz.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Keiichi, Keiichi SHIMA wrote: > From: Alexandru Petrescu Subject: > Re: [nemo] NEMOv4 vs DS-MIPv6 Date: Thu, 11 May 2006 21:01:23 +0200 > >>>>> We don't talk about MNP tables but that doesn't mean we >>>> don't support >>>>> it. >>>> I'm against silently supporting an essential data structure for >>>> security. >>> => Fine, I'll add something to explain this. Feel free to suggest >>> text. >> I suggest using IPv4-mapped IPv6 addresses in the Prefix Table >> whenever the HoA of MR is an IPv4 HoA (and not simple 32bit IPv4 >> addresses in the NEMOv6 Prefix Table). I am not sure though about >> the IPv4 MNP. There seems to be no specification about how to use >> an IPv4 prefix in the v4-mapped v6 form, I've checked rfc4038 (app >> aspects of v6 trans) and 4291 (v6 addr arch). > > If your suggestion is to write that "IPv4 MNP should be kept in > IPv4-mapped IPv6 address in IPv6 prefix tables", then I am against. > That kind of design should be implementation matter. It may seem as implementation matter to be left out. However, the same draft does not leave this out and does say that the BC may store the v4 hoa address/prefix as v4-mapped: > - If the binding update is accepted for the IPv4 home address, the > home agent MUST create a binding cache entry for the IPv4 home > address/prefix. If a single IPv4 home address were requested, it MAY > be stored in the IPv4-mapped IPv6 address format. So I thought that because the BC prefers this format (v4-mapped) maybe the Prefix Table too. > As Vijay said in the following mail, simply saying that the prefix > table can keep both IPv6 and IPv4 prefixes seems enough to me. I agree, it's simplest to write, leaving place for implementation interpretation. Maybe at the minimum, it is good to specify both BC and PT that IPv4 addresses and prefixes should be stored in whatever format the implementation finds coherent (maybe v4-mapped or maybe simple 32bit format, bot only one). Alex From nemo-bounces@ietf.org Mon May 15 17:08:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfkIQ-0000wE-1c; Mon, 15 May 2006 17:08:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfkIO-0000w9-7S for nemo@ietf.org; Mon, 15 May 2006 17:08:04 -0400 Received: from h-74-0-36-190.snfccasy.covad.net ([74.0.36.190] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfkIL-0004qI-S5 for nemo@ietf.org; Mon, 15 May 2006 17:08:04 -0400 Received: by deimos.multihop.net (Postfix, from userid 1013) id E55168AD194; Mon, 15 May 2006 14:07:50 -0700 (PDT) X-Spam-Score: -4.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on deimos.multihop.net X-Spam-Level: X-Spam-Status: No, score=-4.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.1 Received: from [192.168.4.10] (wideload.tehama.multihop.net [192.168.4.10]) by deimos.multihop.net (Postfix) with ESMTP id 694B88AD18A; Mon, 15 May 2006 14:07:50 -0700 (PDT) In-Reply-To: <20060504161628.5d689671.thierry.ernst@inria.fr> References: <1487A357FD2ED544B8AD29E528FF9DF002653491@NAEX06.na.qualcomm.com> <20060504161628.5d689671.thierry.ernst@inria.fr> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "T.J. Kniveton" Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Date: Mon, 15 May 2006 10:04:46 -0700 To: Thierry Ernst X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On May 4, 2006, at 7:16 AM, Thierry Ernst wrote: > I have a subtle understanding of what the message should be, and it is > valid in all organizations: been clear, not confusing, and well > documented. We cannot develop IPv4 and IPv6 protocols in the same > group > (unless, as I said, we are working on interoperability issues). I would like to add one comment to this discussion. It seems appropriate to make a solution for IPv4-only networks, which thankfully is now underway. At some point it may make sense to form a separate working group for IPv4-only issues, but it's probably a bit too early to do that until the work is more mature, and the industry interest level and engineering participation within the IETF can be gauged. For IPv4-IPv6 mixed networks, it makes sense to me that we continue to work on that issue here in this group (and in the Mobile IPv6 working group). I understand some people have no interest in working on IPv4-only protocols, and likewise some people in NEMO probably have little or no interest in IPv6-only protocols. But in a mixed network, we should have something to say about how NEMO will work. After all, that scenario is a growth industry. TJ From nemo-bounces@ietf.org Mon May 15 17:08:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfkId-0000yx-BA; Mon, 15 May 2006 17:08:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfkIc-0000ys-3B for nemo@ietf.org; Mon, 15 May 2006 17:08:18 -0400 Received: from h-74-0-36-190.snfccasy.covad.net ([74.0.36.190] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfkIa-0004rS-Q4 for nemo@ietf.org; Mon, 15 May 2006 17:08:18 -0400 Received: by deimos.multihop.net (Postfix, from userid 1013) id 34DB58ABA6D; Mon, 15 May 2006 14:08:16 -0700 (PDT) X-Spam-Score: -4.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on deimos.multihop.net X-Spam-Level: X-Spam-Status: No, score=-4.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.1 Received: from [192.168.4.10] (wideload.tehama.multihop.net [192.168.4.10]) by deimos.multihop.net (Postfix) with ESMTP id 8F1D28AB86E; Mon, 15 May 2006 14:08:15 -0700 (PDT) In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> References: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5916B65B-F318-429B-9561-04E9D28EF73E@kniveton.com> Content-Transfer-Encoding: 7bit From: T.J. Kniveton Subject: Re: [nemo] Rewording of RO work in the charter Date: Mon, 15 May 2006 10:47:04 -0700 To: "Davis, Terry L" X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote: > T.J. > > You'll probably wish that you hadn't asked for this... > > These would be our ideal mobility solution. I realize that meeting > all > of these is probably an extreme stretch. > > Take care > Terry Terry, I second the request to put your list of items into a draft. It will be helpful to have a concrete list of deployment requirements to refer to. While the WG can't necessarily solve all of the problems for one specific deployment, an informational document listing them can be useful for guidance when making engineering design decisions. Would you be willing to do that? Perhaps others in the WG can help with maintaining the document / editing if needed. TJ From nemo-bounces@ietf.org Mon May 15 17:08:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfkIk-00011q-Nk; Mon, 15 May 2006 17:08:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfkIj-00011l-Bd for nemo@ietf.org; Mon, 15 May 2006 17:08:25 -0400 Received: from h-74-0-36-190.snfccasy.covad.net ([74.0.36.190] helo=multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfkIi-0004s7-1Q for nemo@ietf.org; Mon, 15 May 2006 17:08:25 -0400 Received: by deimos.multihop.net (Postfix, from userid 1013) id 9D9058AD163; Mon, 15 May 2006 14:08:23 -0700 (PDT) X-Spam-Score: -4.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on deimos.multihop.net X-Spam-Level: X-Spam-Status: No, score=-4.1 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DATE_IN_PAST_03_06 autolearn=ham version=3.1.1 Received: from [192.168.4.10] (wideload.tehama.multihop.net [192.168.4.10]) by deimos.multihop.net (Postfix) with ESMTP id F21E08AD133 for ; Mon, 15 May 2006 14:08:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ml-nemo WG From: T.J. Kniveton Date: Mon, 15 May 2006 11:00:28 -0700 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [nemo] New versions of charter X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I have posted a new version of the proposed charter (on the web page) to replace the April 30 version. Some of the changes include: - Added some text about v6, v4 and v4/v6 solution distinctions. - Added some additional text throughout the tasks/nontasks - Added editing and typo fixes as suggested - Other suggested changes One remaining comment which I have not addressed yet: James Kempf wrote: > I am very much in favor of making WG charters very specific. It > helps to avoid ambiguity about what the WG is intending to > accomplish, and also helps focus the energy of the WG and avoid > having it become distracted by other proposals that tend to pop up, > until the originally promised work is completed. Therefore, I would > recommend that the charter include a bulleted list with three items > corresponding to each of these new drafts, with each item giving a > concise but complete description of what the promised draft is > intended to accomplish. If there are existing individual drafts > that cover these, the descriptions can be based on the individual > drafts. Also, it might be helpful to be more specific about the > goals and their timing. Rather than just a single goal, have a list > that correspond to the process: 00 WG draft selected by this time, > WG last call by this time, submission to IESG by this time. (Some help would be appreciated with this one). I think we still have to adjust the milestones a bit more to make sure everything is explicitly spelled out. I have tried to make the charter as concrete as possible, while still short enough to be manageable/readable. I would like the next revision to focus on the milestones. Can people please read this over and make comments/suggestions, with proposed text changes? That would be helpful. Thanks, TJ From nemo-bounces@ietf.org Mon May 15 17:58:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffl5F-0005aD-4F; Mon, 15 May 2006 17:58:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffl5D-0005a1-QE for nemo@ietf.org; Mon, 15 May 2006 17:58:31 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffl5D-0007Om-Fj for nemo@ietf.org; Mon, 15 May 2006 17:58:31 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 15 May 2006 14:58:29 -0700 Message-ID: <4468F985.6070108@azairenet.com> Date: Mon, 15 May 2006 14:58:29 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "T.J. Kniveton" Subject: Re: [nemo] New versions of charter References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 May 2006 21:58:29.0456 (UTC) FILETIME=[B32CC500:01C6786A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org hi TJ, my understanding was that there will also be a general purpose route optimization solution. and this solution would not depend on geographically distributed HAs. this is not mentioned anywhere in the charter. the charter only talks about "Analysis of the Solution Space for Route Optimization". > The working group has work items to describe a basic solution for > network mobility in IPv6-only networks, and to design a mechanism to > allow mixed IPv4/IPv6 networks, carrying signalling messages that > describe both IPv4 and IPv6 addresses and mobile network prefixes. The > latter task is shared with the Mobile IPv6 working group, addressed by > a joint design team. this is just DS-MIPv6 (with appropriate extensions for IPv4 mobile network prefixes), right? nothing more. Vijay T.J. Kniveton wrote: > I have posted a new version of the proposed charter (on the web page) to > replace the April 30 version. Some of the changes include: > > - Added some text about v6, v4 and v4/v6 solution distinctions. > - Added some additional text throughout the tasks/nontasks > - Added editing and typo fixes as suggested > - Other suggested changes > > One remaining comment which I have not addressed yet: > > James Kempf wrote: >> I am very much in favor of making WG charters very specific. It helps >> to avoid ambiguity about what the WG is intending to accomplish, and >> also helps focus the energy of the WG and avoid having it become >> distracted by other proposals that tend to pop up, until the >> originally promised work is completed. Therefore, I would recommend >> that the charter include a bulleted list with three items >> corresponding to each of these new drafts, with each item giving a >> concise but complete description of what the promised draft is >> intended to accomplish. If there are existing individual drafts that >> cover these, the descriptions can be based on the individual drafts. >> Also, it might be helpful to be more specific about the goals and >> their timing. Rather than just a single goal, have a list that >> correspond to the process: 00 WG draft selected by this time, WG last >> call by this time, submission to IESG by this time. > > (Some help would be appreciated with this one). I think we still have to > adjust the milestones a bit more to make sure everything is explicitly > spelled out. I have tried to make the charter as concrete as possible, > while still short enough to be manageable/readable. I would like the > next revision to focus on the milestones. > > Can people please read this over and make comments/suggestions, with > proposed text changes? That would be helpful. > > Thanks, > TJ > > From nemo-bounces@ietf.org Tue May 16 02:19:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffstp-0001YO-Os; Tue, 16 May 2006 02:19:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffstn-0001XC-OZ for nemo@ietf.org; Tue, 16 May 2006 02:19:15 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffsti-0001eo-8d for nemo@ietf.org; Tue, 16 May 2006 02:19:12 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 4793A212C63; Tue, 16 May 2006 09:19:09 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id D74F7212C61; Tue, 16 May 2006 09:19:08 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id 9E5DBBDC40; Tue, 16 May 2006 09:19:08 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id 649C4BDC38; Tue, 16 May 2006 09:19:08 +0300 (EEST) In-Reply-To: <5916B65B-F318-429B-9561-04E9D28EF73E@kniveton.com> References: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> <5916B65B-F318-429B-9561-04E9D28EF73E@kniveton.com> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Rewording of RO work in the charter Date: Tue, 16 May 2006 09:19:30 +0300 To: T.J.Kniveton X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ml-nemo WG , "Davis, Terry L" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org El 15/05/2006, a las 20:47, T.J.Kniveton escribi=F3: > On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote: > >> T.J. >> >> You'll probably wish that you hadn't asked for this... >> >> These would be our ideal mobility solution. I realize that meeting=20= >> all >> of these is probably an extreme stretch. >> >> Take care >> Terry > > Terry, > > I second the request to put your list of items into a draft. It will=20= > be helpful to have a concrete list of deployment requirements to refer=20= > to. While the WG can't necessarily solve all of the problems for one=20= > specific deployment, an informational document listing them can be=20 > useful for guidance when making engineering design decisions. > > Would you be willing to do that? Perhaps others in the WG can help=20 > with maintaining the document / editing if needed. > i am willing to help Terry on this in case it is needed... regards, marcelo > TJ > > From nemo-bounces@ietf.org Tue May 16 02:35:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fft9g-0005Q5-CV; Tue, 16 May 2006 02:35:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fft9e-0005O2-Ik for nemo@ietf.org; Tue, 16 May 2006 02:35:38 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fft9d-0002ND-1p for nemo@ietf.org; Tue, 16 May 2006 02:35:38 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id DC820212C61; Tue, 16 May 2006 09:35:35 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id 77C86212C59; Tue, 16 May 2006 09:35:35 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id 0D292BDC40; Tue, 16 May 2006 09:35:35 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id C6523BDC38; Tue, 16 May 2006 09:35:34 +0300 (EEST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <28c3e7f8ee58e55b015a0ad55f807ae8@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] New versions of charter Date: Tue, 16 May 2006 09:35:56 +0300 To: T.J.Kniveton X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi T.J. I think that the charter is still missing the identification of actual=20= application scenarios that require RO (in particular globally=20 distributed HAs) and the requirements that these use cases have. I think that during the charter discussion so far, the only use case we=20= have for RO is the aviation case, which they have these globally moving=20= network scenarios, and they have a very clear idea of what the=20 requirements are for this case. I think that it is not straight forward from these preliminary list of=20= requirements that they need globally distributed HAs, nor a protocol to=20= coordinate them. (It is neither clear they they do not need different=20 ISPs for instance, making global HAHA type of solution and contributor=20= to the global routing table) So, as i see it: - it is clear that the aviation is a relevant use case for RO in=20 globally moving networks - imho we should work to provide a solution for this particular use case - however, it is not clear what the solution should be (yet) So, i would suggest to include the following items in the charter: - Submit a -00 draft describing the requirements for globally moving=20 networks - Submit a -00 draft describing a solution for globally moving networks=20= that fulfills the identified requirements - Remove Submit -00 draft on Route Optimization for geographically=20 distributed HAs bottom line is that Submit -00 draft on Route Optimization for=20 geographically distributed HAs is assumning a solution while we still=20 haven't a concise requirements list for the problem, which makes it=20 hard to evaluate if the proposed solution fits the problem and how this=20= solution will be used and the effects that the deployment of such=20 solution will have (in particular in the global routing table) regards, marcelo El 15/05/2006, a las 21:00, T.J.Kniveton escribi=F3: > I have posted a new version of the proposed charter (on the web page)=20= > to replace the April 30 version. Some of the changes include: > > - Added some text about v6, v4 and v4/v6 solution distinctions. > - Added some additional text throughout the tasks/nontasks > - Added editing and typo fixes as suggested > - Other suggested changes > > One remaining comment which I have not addressed yet: > > James Kempf wrote: >> I am very much in favor of making WG charters very specific. It helps=20= >> to avoid ambiguity about what the WG is intending to accomplish, and=20= >> also helps focus the energy of the WG and avoid having it become=20 >> distracted by other proposals that tend to pop up, until the=20 >> originally promised work is completed. Therefore, I would recommend=20= >> that the charter include a bulleted list with three items=20 >> corresponding to each of these new drafts, with each item giving a=20 >> concise but complete description of what the promised draft is=20 >> intended to accomplish. If there are existing individual drafts that=20= >> cover these, the descriptions can be based on the individual drafts.=20= >> Also, it might be helpful to be more specific about the goals and=20 >> their timing. Rather than just a single goal, have a list that=20 >> correspond to the process: 00 WG draft selected by this time, WG last=20= >> call by this time, submission to IESG by this time. > > (Some help would be appreciated with this one). I think we still have=20= > to adjust the milestones a bit more to make sure everything is=20 > explicitly spelled out. I have tried to make the charter as concrete=20= > as possible, while still short enough to be manageable/readable. I=20 > would like the next revision to focus on the milestones. > > Can people please read this over and make comments/suggestions, with=20= > proposed text changes? That would be helpful. > > Thanks, > TJ > > From nemo-bounces@ietf.org Tue May 16 05:00:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfvPT-00030S-N7; Tue, 16 May 2006 05:00:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfvPR-00030K-D2 for nemo@ietf.org; Tue, 16 May 2006 05:00:05 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfvPO-0001O4-Vl for nemo@ietf.org; Tue, 16 May 2006 05:00:05 -0400 Received: from guest-rocq-135223.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k4G8xp6R028507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 May 2006 10:59:51 +0200 Date: Tue, 16 May 2006 11:01:01 +0200 From: Thierry Ernst To: nemo@ietf.org Message-Id: <20060516110101.5124f6cd.thierry.ernst@inria.fr> In-Reply-To: References: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> <5916B65B-F318-429B-9561-04E9D28EF73E@kniveton.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP X-Miltered: at concorde with ID 44699487.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by concorde.inria.fr id k4G8xp6R028507 X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: terry.l.davis@boeing.com Subject: [nemo] Deployment Requirements X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org [I changed the subject line] Speaking about "deployment requirements", I would propose to add a section in draft-ietf-nemo-requirements (actually, I intended to extend that draft since the beginning ;-) rather of editing a separate document. Would that make sense to everyone ? Thierry. On Tue, 16 May 2006 09:19:30 +0300 marcelo bagnulo braun wrote: >=20 > El 15/05/2006, a las 20:47, T.J.Kniveton escribi=F3: >=20 > > On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote: > > > >> T.J. > >> > >> You'll probably wish that you hadn't asked for this... > >> > >> These would be our ideal mobility solution. I realize that meeting=20 > >> all > >> of these is probably an extreme stretch. > >> > >> Take care > >> Terry > > > > Terry, > > > > I second the request to put your list of items into a draft. It will=20 > > be helpful to have a concrete list of deployment requirements to refe= r=20 > > to. While the WG can't necessarily solve all of the problems for one=20 > > specific deployment, an informational document listing them can be=20 > > useful for guidance when making engineering design decisions. > > > > Would you be willing to do that? Perhaps others in the WG can help=20 > > with maintaining the document / editing if needed. > > >=20 > i am willing to help Terry on this in case it is needed... >=20 > regards, marcelo >=20 >=20 > > TJ > > > > >=20 >=20 >=20 --=20 Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Tue May 16 05:47:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffw96-00074j-Jj; Tue, 16 May 2006 05:47:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffw95-00074e-SE for nemo@ietf.org; Tue, 16 May 2006 05:47:15 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffw94-0003fs-Cz for nemo@ietf.org; Tue, 16 May 2006 05:47:15 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 98236212C5D; Tue, 16 May 2006 12:47:10 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id 61302212C59; Tue, 16 May 2006 12:47:10 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id 1CB91BDC40; Tue, 16 May 2006 12:47:10 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id DBC7EBDC38; Tue, 16 May 2006 12:47:09 +0300 (EEST) In-Reply-To: <20060516110101.5124f6cd.thierry.ernst@inria.fr> References: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> <5916B65B-F318-429B-9561-04E9D28EF73E@kniveton.com> <20060516110101.5124f6cd.thierry.ernst@inria.fr> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <234519ed78b2bf91be22e01ed3d1f538@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Deployment Requirements Date: Tue, 16 May 2006 12:47:09 +0300 To: Thierry Ernst X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: nemo@ietf.org, terry.l.davis@boeing.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Thierry, El 16/05/2006, a las 12:01, Thierry Ernst escribi=F3: > > [I changed the subject line] > > Speaking about "deployment requirements", I would propose to add a > section in draft-ietf-nemo-requirements (actually, I intended to = extend > that draft since the beginning ;-) rather of editing a separate > document. > > Would that make sense to everyone ? > i think that there are some general deployment requirements that could=20= fit in there however, perhaps the case of aviation may have quite specific=20 requirements of their own that may not apply in the general case.... i=20= mean not all of us have worldwide sites and a nemo moving around=20 several of them in a single day :-) Regards, marcelo > Thierry. > > > > On Tue, 16 May 2006 09:19:30 +0300 > marcelo bagnulo braun wrote: > >> >> El 15/05/2006, a las 20:47, T.J.Kniveton escribi=F3: >> >>> On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote: >>> >>>> T.J. >>>> >>>> You'll probably wish that you hadn't asked for this... >>>> >>>> These would be our ideal mobility solution. I realize that meeting >>>> all >>>> of these is probably an extreme stretch. >>>> >>>> Take care >>>> Terry >>> >>> Terry, >>> >>> I second the request to put your list of items into a draft. It will >>> be helpful to have a concrete list of deployment requirements to=20 >>> refer >>> to. While the WG can't necessarily solve all of the problems for one >>> specific deployment, an informational document listing them can be >>> useful for guidance when making engineering design decisions. >>> >>> Would you be willing to do that? Perhaps others in the WG can help >>> with maintaining the document / editing if needed. >>> >> >> i am willing to help Terry on this in case it is needed... >> >> regards, marcelo >> >> >>> TJ >>> >>> >> >> >> > > > --=20 > Thierry ERNST, PhD > INRIA Rocquencourt Projet IMARA > +33 1 39 63 59 30 > > From nemo-bounces@ietf.org Tue May 16 05:53:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfwFO-0008NE-1d; Tue, 16 May 2006 05:53:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfwFM-0008N9-Rp for nemo@ietf.org; Tue, 16 May 2006 05:53:44 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfwFM-0003z0-Ha for nemo@ietf.org; Tue, 16 May 2006 05:53:44 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k4G9rWiM021517; Tue, 16 May 2006 02:53:36 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k4G9rUwv005930; Tue, 16 May 2006 04:53:31 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 49E14865980; Tue, 16 May 2006 11:53:30 +0200 (CEST) Message-ID: <4469A11A.3070509@motorola.com> Date: Tue, 16 May 2006 11:53:30 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] New versions of charter References: <4468F985.6070108@azairenet.com> In-Reply-To: <4468F985.6070108@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ml-nemo WG , "T.J. Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Vijay Devarapalli wrote: > hi TJ, > > my understanding was that there will also be a general purpose route > optimization solution. and this solution would not depend on > geographically distributed HAs. this is not mentioned anywhere in the > charter. the charter only talks about "Analysis of the Solution > Space for Route Optimization". > >> The working group has work items to describe a basic solution for >> network mobility in IPv6-only networks, and to design a mechanism >> to allow mixed IPv4/IPv6 networks, carrying signalling messages >> that describe both IPv4 and IPv6 addresses and mobile network >> prefixes. The latter task is shared with the Mobile IPv6 working >> group, addressed by a joint design team. > > this is just DS-MIPv6 (with appropriate extensions for IPv4 mobile > network prefixes), right? nothing more. Maybe something more generic than just DS-MIPv6? DS-MIPv6 addresses some relevant transition cases but not all (HA fully-v6 is not addressed). Alex From nemo-bounces@ietf.org Tue May 16 06:45:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffx2z-0004AX-2f; Tue, 16 May 2006 06:45:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ffx2y-000486-8k for nemo@ietf.org; Tue, 16 May 2006 06:45:00 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ffx2w-0006ZG-SI for nemo@ietf.org; Tue, 16 May 2006 06:45:00 -0400 Received: from guest-rocq-135223.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k4GAit50010609 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 May 2006 12:44:56 +0200 Date: Tue, 16 May 2006 12:46:06 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Deployment Requirements Message-Id: <20060516124606.6deac871.thierry.ernst@inria.fr> In-Reply-To: <234519ed78b2bf91be22e01ed3d1f538@it.uc3m.es> References: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> <5916B65B-F318-429B-9561-04E9D28EF73E@kniveton.com> <20060516110101.5124f6cd.thierry.ernst@inria.fr> <234519ed78b2bf91be22e01ed3d1f538@it.uc3m.es> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP X-Miltered: at concorde with ID 4469AD27.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by concorde.inria.fr id k4GAit50010609 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: marcelo bagnulo braun , terry.l.davis@boeing.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Marcelo, Well, do you intend to mean that we should write a deployment requirements draft for the aviation industry specifically, in which case we would do the same for the vehicular industry, and for each other existing use cases ? If yes, then I guess it would rather be individual submissions that could be used as input for determining a common list of deployment requirements. Thierry. > > [I changed the subject line] > > > > Speaking about "deployment requirements", I would propose to add a > > section in draft-ietf-nemo-requirements (actually, I intended to exte= nd > > that draft since the beginning ;-) rather of editing a separate > > document. > > > > Would that make sense to everyone ? > > >=20 > i think that there are some general deployment requirements that could=20 > fit in there >=20 > however, perhaps the case of aviation may have quite specific=20 > requirements of their own that may not apply in the general case.... i=20 > mean not all of us have worldwide sites and a nemo moving around=20 > several of them in a single day :-) >=20 > Regards, marcelo >=20 >=20 > > Thierry. > > > > > > > > On Tue, 16 May 2006 09:19:30 +0300 > > marcelo bagnulo braun wrote: > > > >> > >> El 15/05/2006, a las 20:47, T.J.Kniveton escribi=F3: > >> > >>> On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote: > >>> > >>>> T.J. > >>>> > >>>> You'll probably wish that you hadn't asked for this... > >>>> > >>>> These would be our ideal mobility solution. I realize that meetin= g > >>>> all > >>>> of these is probably an extreme stretch. > >>>> > >>>> Take care > >>>> Terry > >>> > >>> Terry, > >>> > >>> I second the request to put your list of items into a draft. It wil= l > >>> be helpful to have a concrete list of deployment requirements to=20 > >>> refer > >>> to. While the WG can't necessarily solve all of the problems for on= e > >>> specific deployment, an informational document listing them can be > >>> useful for guidance when making engineering design decisions. > >>> > >>> Would you be willing to do that? Perhaps others in the WG can help > >>> with maintaining the document / editing if needed. > >>> > >> > >> i am willing to help Terry on this in case it is needed... > >> > >> regards, marcelo > >> > >> > >>> TJ > >>> > >>> > >> > >> > >> > > > > > > --=20 > > Thierry ERNST, PhD > > INRIA Rocquencourt Projet IMARA > > +33 1 39 63 59 30 > > > > >=20 >=20 >=20 --=20 Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Tue May 16 07:11:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfxRw-0001oI-8M; Tue, 16 May 2006 07:10:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FfxRv-0001oD-2H for nemo@ietf.org; Tue, 16 May 2006 07:10:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfxRv-0007iT-0l for nemo@ietf.org; Tue, 16 May 2006 07:10:47 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FfxGf-00046L-9y for nemo@ietf.org; Tue, 16 May 2006 06:59:10 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6A474212C5D; Tue, 16 May 2006 13:59:07 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id 034A0212C59; Tue, 16 May 2006 13:59:07 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id 8707BBDC40; Tue, 16 May 2006 13:59:06 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id 52874BDC38; Tue, 16 May 2006 13:59:06 +0300 (EEST) In-Reply-To: <20060516124606.6deac871.thierry.ernst@inria.fr> References: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> <5916B65B-F318-429B-9561-04E9D28EF73E@kniveton.com> <20060516110101.5124f6cd.thierry.ernst@inria.fr> <234519ed78b2bf91be22e01ed3d1f538@it.uc3m.es> <20060516124606.6deac871.thierry.ernst@inria.fr> Mime-Version: 1.0 (Apple Message framework v623) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <74f86f393d8f38fffec68a9a079d6497@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Deployment Requirements Date: Tue, 16 May 2006 13:59:05 +0300 To: Thierry Ernst X-Mailer: Apple Mail (2.623) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: -2.6 (--) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: nemo@ietf.org, terry.l.davis@boeing.com X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org El 16/05/2006, a las 13:46, Thierry Ernst escribi=F3: > > Hi Marcelo, > > Well, do you intend to mean that we should write a deployment > requirements draft for the aviation industry specifically, in which=20 > case > we would do the same for the vehicular industry, and for each other > existing use cases ? > well, i am not sure about the vehicular technology because i don't know=20= if they have specific requirements. but following the emails that have been exchanged lately in this ml, it=20= is my opinion that the aviation case have quite special requirements=20 and that they need customized solutions for thier problems that have=20 their own set of deployment issues. I mean consider that they are moving globally quite rapidly, they have=20= wordlwide infrastruture, they need high reliability, and so on, which=20= makes their case somehow different from the case of nemos deployed in=20 buses cars and so on (or at least it seems so to me) that is why i think that the general requirements and in particular the=20= deployment requirements for a solution to this particular problem need=20= to be fleshed out > If yes, then I guess it would rather be individual submissions yes i think Terry initial list could be a starting point for this > that > could be used as input for determining a common list of deployment > requirements. > well depending on whether this requirements fit into the general=20 requirements, this may be ok.... but i think that they are likely to be=20= quite differetn from the general case regards, marcelo > Thierry. > > > >>> [I changed the subject line] >>> >>> Speaking about "deployment requirements", I would propose to add a >>> section in draft-ietf-nemo-requirements (actually, I intended to=20 >>> extend >>> that draft since the beginning ;-) rather of editing a separate >>> document. >>> >>> Would that make sense to everyone ? >>> >> >> i think that there are some general deployment requirements that = could >> fit in there >> >> however, perhaps the case of aviation may have quite specific >> requirements of their own that may not apply in the general case.... = i >> mean not all of us have worldwide sites and a nemo moving around >> several of them in a single day :-) >> >> Regards, marcelo >> >> >>> Thierry. >>> >>> >>> >>> On Tue, 16 May 2006 09:19:30 +0300 >>> marcelo bagnulo braun wrote: >>> >>>> >>>> El 15/05/2006, a las 20:47, T.J.Kniveton escribi=F3: >>>> >>>>> On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote: >>>>> >>>>>> T.J. >>>>>> >>>>>> You'll probably wish that you hadn't asked for this... >>>>>> >>>>>> These would be our ideal mobility solution. I realize that=20 >>>>>> meeting >>>>>> all >>>>>> of these is probably an extreme stretch. >>>>>> >>>>>> Take care >>>>>> Terry >>>>> >>>>> Terry, >>>>> >>>>> I second the request to put your list of items into a draft. It=20 >>>>> will >>>>> be helpful to have a concrete list of deployment requirements to >>>>> refer >>>>> to. While the WG can't necessarily solve all of the problems for=20= >>>>> one >>>>> specific deployment, an informational document listing them can be >>>>> useful for guidance when making engineering design decisions. >>>>> >>>>> Would you be willing to do that? Perhaps others in the WG can help >>>>> with maintaining the document / editing if needed. >>>>> >>>> >>>> i am willing to help Terry on this in case it is needed... >>>> >>>> regards, marcelo >>>> >>>> >>>>> TJ >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> --=20 >>> Thierry ERNST, PhD >>> INRIA Rocquencourt Projet IMARA >>> +33 1 39 63 59 30 >>> >>> >> >> >> > > > --=20 > Thierry ERNST, PhD > INRIA Rocquencourt Projet IMARA > +33 1 39 63 59 30 > From nemo-bounces@ietf.org Tue May 16 10:03:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg08u-0006ZJ-Kp; Tue, 16 May 2006 10:03:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg08s-0006Yl-RH for nemo@ietf.org; Tue, 16 May 2006 10:03:18 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FfzES-0005LL-30 for nemo@ietf.org; Tue, 16 May 2006 09:05:00 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ffyu2-0005U0-Pu for nemo@ietf.org; Tue, 16 May 2006 08:44:00 -0400 Received: from guest-rocq-135223.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k4GChorQ031054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 May 2006 14:43:51 +0200 Date: Tue, 16 May 2006 14:45:01 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Deployment Requirements Message-Id: <20060516144501.412c4270.thierry.ernst@inria.fr> In-Reply-To: <74f86f393d8f38fffec68a9a079d6497@it.uc3m.es> References: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> <5916B65B-F318-429B-9561-04E9D28EF73E@kniveton.com> <20060516110101.5124f6cd.thierry.ernst@inria.fr> <234519ed78b2bf91be22e01ed3d1f538@it.uc3m.es> <20060516124606.6deac871.thierry.ernst@inria.fr> <74f86f393d8f38fffec68a9a079d6497@it.uc3m.es> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP X-Miltered: at nez-perce with ID 4469C906.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by nez-perce.inria.fr id k4GChorQ031054 X-Spam-Score: -2.6 (--) X-Scan-Signature: d890c9ddd0b0a61e8c597ad30c1c2176 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > > Well, do you intend to mean that we should write a deployment > > requirements draft for the aviation industry specifically, in which=20 > > case > > we would do the same for the vehicular industry, and for each other > > existing use cases ? > > >=20 > well, i am not sure about the vehicular technology because i don't > know if they have specific requirements. They do, though they don't speak up yet, because (unfortunately) IETF is not an organization where they used to be involved. But they (or the vendors related to the vehicular industry and the standardization bodies such as ISO and ETSI) will show up when they understand it is important for them to be involved in the debate. Would be interesting to get some input from the Japanese folks who I know are monitoring this ML. I'm not speaking only about the people at Keio University who are academic though who are involved with these people, but the people representing the companies who are in this business.=20 Come on folks, this is the right timing to discuss the deployment requirements for the vehicular industry ! > but following the emails that have been exchanged lately in this ml, > it is my opinion that the aviation case have quite special > requirements and that they need customized solutions for thier > problems that have their own set of deployment issues. I second this. But the vehicular industry is IMHO more important as it would involved tens of vendors, with possibly divergent deployment requirements.=20 > I mean consider that they are moving globally quite rapidly, they have >=20 > wordlwide infrastruture, they need high reliability, and so on, which >=20 > makes their case somehow different from the case of nemos deployed in=20 > buses cars and so on (or at least it seems so to me) Well, cases and thus requirements are different. RFC 3963 may not always apply, but even though, the security, authentication and multihoming considerations are different. > that is why i think that the general requirements and in particular > the deployment requirements for a solution to this particular problem > need to be fleshed out Yes, but what is the best procedure ? Independent draft, one for each use case, or shall we came up straight with common requirements, in which case I would say draft-ietf-nemo-requirements is the best place to gather these deployment scenarios ? =20 > > If yes, then I guess it would rather be individual submissions >=20 > yes i think Terry initial list could be a starting point for this >=20 > > that > > could be used as input for determining a common list of deployment > > requirements. > > >=20 > well depending on whether this requirements fit into the general=20 > requirements, this may be ok.... but i think that they are likely to > be quite differetn from the general case This may not be an issue. The draft could be explicit that these are requirements for that specific use cases where we get some input. Thierry. > > > >>> [I changed the subject line] > >>> > >>> Speaking about "deployment requirements", I would propose to add a > >>> section in draft-ietf-nemo-requirements (actually, I intended to=20 > >>> extend > >>> that draft since the beginning ;-) rather of editing a separate > >>> document. > >>> > >>> Would that make sense to everyone ? > >>> > >> > >> i think that there are some general deployment requirements that > >could> fit in there > >> > >> however, perhaps the case of aviation may have quite specific > >> requirements of their own that may not apply in the general > >case.... i> mean not all of us have worldwide sites and a nemo moving > >around> several of them in a single day :-) > >> > >> Regards, marcelo > >> > >> > >>> Thierry. > >>> > >>> > >>> > >>> On Tue, 16 May 2006 09:19:30 +0300 > >>> marcelo bagnulo braun wrote: > >>> > >>>> > >>>> El 15/05/2006, a las 20:47, T.J.Kniveton escribi=F3: > >>>> > >>>>> On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote: > >>>>> > >>>>>> T.J. > >>>>>> > >>>>>> You'll probably wish that you hadn't asked for this... > >>>>>> > >>>>>> These would be our ideal mobility solution. I realize that=20 > >>>>>> meeting > >>>>>> all > >>>>>> of these is probably an extreme stretch. > >>>>>> > >>>>>> Take care > >>>>>> Terry > >>>>> > >>>>> Terry, > >>>>> > >>>>> I second the request to put your list of items into a draft. It=20 > >>>>> will > >>>>> be helpful to have a concrete list of deployment requirements to > >>>>> refer > >>>>> to. While the WG can't necessarily solve all of the problems for > > > >>>>> one > >>>>> specific deployment, an informational document listing them can > >be>>>> useful for guidance when making engineering design decisions. > >>>>> > >>>>> Would you be willing to do that? Perhaps others in the WG can > >help>>>> with maintaining the document / editing if needed. > >>>>> > >>>> > >>>> i am willing to help Terry on this in case it is needed... > >>>> > >>>> regards, marcelo > >>>> > >>>> > >>>>> TJ > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> --=20 > >>> Thierry ERNST, PhD > >>> INRIA Rocquencourt Projet IMARA > >>> +33 1 39 63 59 30 > >>> > >>> > >> > >> > >> > > > > > > --=20 > > Thierry ERNST, PhD > > INRIA Rocquencourt Projet IMARA > > +33 1 39 63 59 30 > > >=20 >=20 >=20 --=20 Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Tue May 16 10:41:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0jR-0000J1-L6; Tue, 16 May 2006 10:41:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0jQ-0000H5-J4 for nemo@ietf.org; Tue, 16 May 2006 10:41:04 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg0jP-0001WL-6L for nemo@ietf.org; Tue, 16 May 2006 10:41:04 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4GEf2qs031011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 May 2006 07:41:02 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4GEf0Gp017322; Tue, 16 May 2006 07:41:01 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 07:40:59 -0700 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 Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Tue, 16 May 2006 07:40:58 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0028C4E9F@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZ4ZAT2kz3mSXF3TYKhoyIO9ZEaJAAklO0w From: "Tsirtsis, George" To: "T.J. Kniveton" , "Thierry Ernst" X-OriginalArrivalTime: 16 May 2006 14:40:59.0864 (UTC) FILETIME=[BF9CA580:01C678F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org TJ, Since you agree IPv4-only work should be allowed, could you add a sentence to indicate that the WG will work on FA support and dynamic prefix allocation extensions to the NEMOv4 base solution? I will be submitting a draft about these issues before the next meeting. Thanks George > -----Original Message----- > From: T.J. Kniveton [mailto:tj@kniveton.com] > Sent: Monday, May 15, 2006 1:05 PM > To: Thierry Ernst > Cc: nemo@ietf.org > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >=20 >=20 > On May 4, 2006, at 7:16 AM, Thierry Ernst wrote: >=20 > > I have a subtle understanding of what the message should be, and it is > > valid in all organizations: been clear, not confusing, and well > > documented. We cannot develop IPv4 and IPv6 protocols in the same > > group > > (unless, as I said, we are working on interoperability issues). >=20 > I would like to add one comment to this discussion. It seems > appropriate to make a solution for IPv4-only networks, which > thankfully is now underway. At some point it may make sense to form a > separate working group for IPv4-only issues, but it's probably a bit > too early to do that until the work is more mature, and the industry > interest level and engineering participation within the IETF can be > gauged. >=20 > For IPv4-IPv6 mixed networks, it makes sense to me that we continue > to work on that issue here in this group (and in the Mobile IPv6 > working group). >=20 > I understand some people have no interest in working on IPv4-only > protocols, and likewise some people in NEMO probably have little or > no interest in IPv6-only protocols. But in a mixed network, we should > have something to say about how NEMO will work. After all, that > scenario is a growth industry. >=20 > TJ >=20 From nemo-bounces@ietf.org Tue May 16 10:56:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0y2-00050K-N7; Tue, 16 May 2006 10:56:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg0y2-00050F-8K for nemo@ietf.org; Tue, 16 May 2006 10:56:10 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg0xx-0002Rh-Pw for nemo@ietf.org; Tue, 16 May 2006 10:56:10 -0400 Received: from guest-rocq-135223.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k4GEtw9I017625 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 May 2006 16:55:58 +0200 Date: Tue, 16 May 2006 16:57:09 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Message-Id: <20060516165709.61828ceb.thierry.ernst@inria.fr> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0028C4E9F@NAEX06.na.qualcomm.com> References: <1487A357FD2ED544B8AD29E528FF9DF0028C4E9F@NAEX06.na.qualcomm.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 4469E7FE.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I'm not sure we **agree** (as a WG) on IPv4-only work; actually the debate was open with mixed positions on both IPv4-only tasks accepted vs IPv4-only tasks not accepted, with a 3rd possibility that IPv4-IPv6 transition mechanisms would suffice to do what is the most needed. Also, someone pointed that we should better complete the current work and decide for a re-chartering a bit later in the year. I agree with this suggestion, and we could discuss the rechartering a bit further during next or next-next IETF meeting. So, my proposition would be to postpone the new charter. Thierry. On Tue, 16 May 2006 07:40:58 -0700 "Tsirtsis, George" wrote: > TJ, > > Since you agree IPv4-only work should be allowed, could you add a > sentence to indicate that the WG will work on FA support and dynamic > prefix allocation extensions to the NEMOv4 base solution? I will be > submitting a draft about these issues before the next meeting. > > Thanks > George > > > -----Original Message----- > > From: T.J. Kniveton [mailto:tj@kniveton.com] > > Sent: Monday, May 15, 2006 1:05 PM > > To: Thierry Ernst > > Cc: nemo@ietf.org > > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. > > > > > > On May 4, 2006, at 7:16 AM, Thierry Ernst wrote: > > > > > I have a subtle understanding of what the message should be, and it > is > > > valid in all organizations: been clear, not confusing, and well > > > documented. We cannot develop IPv4 and IPv6 protocols in the same > > > group > > > (unless, as I said, we are working on interoperability issues). > > > > I would like to add one comment to this discussion. It seems > > appropriate to make a solution for IPv4-only networks, which > > thankfully is now underway. At some point it may make sense to form a > > separate working group for IPv4-only issues, but it's probably a bit > > too early to do that until the work is more mature, and the industry > > interest level and engineering participation within the IETF can be > > gauged. > > > > For IPv4-IPv6 mixed networks, it makes sense to me that we continue > > to work on that issue here in this group (and in the Mobile IPv6 > > working group). > > > > I understand some people have no interest in working on IPv4-only > > protocols, and likewise some people in NEMO probably have little or > > no interest in IPv6-only protocols. But in a mixed network, we should > > have something to say about how NEMO will work. After all, that > > scenario is a growth industry. > > > > TJ > > > > > -- Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Tue May 16 11:22:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg1NY-00025o-U1; Tue, 16 May 2006 11:22:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg1NX-00025j-RK for nemo@ietf.org; Tue, 16 May 2006 11:22:31 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg1NW-0003iC-Gi for nemo@ietf.org; Tue, 16 May 2006 11:22:31 -0400 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k4GFMREY023166; Tue, 16 May 2006 08:22:27 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id k4GFMQ43000852; Tue, 16 May 2006 10:22:27 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id E3B66865980; Tue, 16 May 2006 17:22:25 +0200 (CEST) Message-ID: <4469EE31.6060908@motorola.com> Date: Tue, 16 May 2006 17:22:25 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF0028C4E9F@NAEX06.na.qualcomm.com> <20060516165709.61828ceb.thierry.ernst@inria.fr> In-Reply-To: <20060516165709.61828ceb.thierry.ernst@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thierry Ernst wrote: > I'm not sure we **agree** (as a WG) on IPv4-only work; actually the > debate was open with mixed positions on both IPv4-only tasks accepted > vs IPv4-only tasks not accepted, with a 3rd possibility that > IPv4-IPv6 transition mechanisms would suffice to do what is the most > needed. > > Also, someone pointed that we should better complete the current work > and decide for a re-chartering a bit later in the year. I agree with > this suggestion, and we could discuss the rechartering a bit further > during next or next-next IETF meeting. > > So, my proposition would be to postpone the new charter. I don't get it... Are you proposing we work on the Charter now and apply it later this year? We've been discussing new Charter extensively. Should we stop discussing Charter? Alex From nemo-bounces@ietf.org Tue May 16 11:22:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg1Nj-00027g-Ef; Tue, 16 May 2006 11:22:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg1Ni-00027b-6r for nemo@ietf.org; Tue, 16 May 2006 11:22:42 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg1Nh-0003l6-Fs for nemo@ietf.org; Tue, 16 May 2006 11:22:42 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4GFMa4S016025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 May 2006 08:22:36 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4GFMZH5029595; Tue, 16 May 2006 08:22:36 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 08:22:34 -0700 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 Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Tue, 16 May 2006 08:22:34 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0028C4F69@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZ4+RbjfxXYvICQRB2cCZ/5gcD/1QAATUrg From: "Tsirtsis, George" To: "Thierry Ernst" , X-OriginalArrivalTime: 16 May 2006 15:22:34.0801 (UTC) FILETIME=[8EB5D210:01C678FC] X-Spam-Score: 0.0 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > -----Original Message----- > From: Thierry Ernst [mailto:thierry.ernst@inria.fr] > Sent: Tuesday, May 16, 2006 10:57 AM > To: nemo@ietf.org > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >=20 >=20 > I'm not sure we **agree** (as a WG) on IPv4-only work; actually the > debate was open with mixed positions on both IPv4-only tasks accepted vs > IPv4-only tasks not accepted,=20 GT> So, "mixed positions" to you means that it should be rejected? People need to realize that the IETF does a lot of things, and even inside a single WG most of the work that is done is irrelevant to most people. This is not a valid argument for rejecting that work. All of us focus on the subset of items that are of interest to either our day to day work or to our geeky curiosity.=20 > with a 3rd possibility that IPv4-IPv6 > transition mechanisms would suffice to do what is the most needed. > GT> I am sorry but this will just not do. In the real world you can not give to the customer a solution based on technology that the customer has no way of testing. The idea that operators will deploy DS-MIPv6 MRs to support NEMOv4 functionality while they have not yet migrated to IPv6 is entirely unrealistic.=20 =20 > Also, someone pointed that we should better complete the current work > and decide for a re-chartering a bit later in the year. I agree with > this suggestion, and we could discuss the rechartering a bit further > during next or next-next IETF meeting. >=20 > So, my proposition would be to postpone the new charter. >=20 GT> I disagree. I have followed this discussion for the last several weeks and the WG has been spending its time debating what it will do in the future while there has been minimal debate on anything else. A handful of us will get the NEMOv4 and its required extensions done in minimal time with minimal effect on the WG. I just fail to understand why you want to prevent willing WG members from doing work that is clearly needed. George > Thierry. >=20 > On Tue, 16 May 2006 07:40:58 -0700 > "Tsirtsis, George" wrote: >=20 > > TJ, > > > > Since you agree IPv4-only work should be allowed, could you add a > > sentence to indicate that the WG will work on FA support and dynamic > > prefix allocation extensions to the NEMOv4 base solution? I will be > > submitting a draft about these issues before the next meeting. > > > > Thanks > > George > > > > > -----Original Message----- > > > From: T.J. Kniveton [mailto:tj@kniveton.com] > > > Sent: Monday, May 15, 2006 1:05 PM > > > To: Thierry Ernst > > > Cc: nemo@ietf.org > > > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. > > > > > > > > > On May 4, 2006, at 7:16 AM, Thierry Ernst wrote: > > > > > > > I have a subtle understanding of what the message should be, and it > > is > > > > valid in all organizations: been clear, not confusing, and well > > > > documented. We cannot develop IPv4 and IPv6 protocols in the same > > > > group > > > > (unless, as I said, we are working on interoperability issues). > > > > > > I would like to add one comment to this discussion. It seems > > > appropriate to make a solution for IPv4-only networks, which > > > thankfully is now underway. At some point it may make sense to form a > > > separate working group for IPv4-only issues, but it's probably a bit > > > too early to do that until the work is more mature, and the industry > > > interest level and engineering participation within the IETF can be > > > gauged. > > > > > > For IPv4-IPv6 mixed networks, it makes sense to me that we continue > > > to work on that issue here in this group (and in the Mobile IPv6 > > > working group). > > > > > > I understand some people have no interest in working on IPv4-only > > > protocols, and likewise some people in NEMO probably have little or > > > no interest in IPv6-only protocols. But in a mixed network, we should > > > have something to say about how NEMO will work. After all, that > > > scenario is a growth industry. > > > > > > TJ > > > > > > > > > >=20 >=20 > -- > Thierry ERNST, PhD > INRIA Rocquencourt Projet IMARA > +33 1 39 63 59 30 >=20 From nemo-bounces@ietf.org Tue May 16 13:29:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg3M1-0008Ey-Nz; Tue, 16 May 2006 13:29:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg3M0-0008Et-NZ for nemo@ietf.org; Tue, 16 May 2006 13:29:04 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg3Lx-0002uP-DH for nemo@ietf.org; Tue, 16 May 2006 13:29:04 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 10:28:55 -0700 Message-ID: <446A0BD3.8090603@azairenet.com> Date: Tue, 16 May 2006 10:28:51 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] New versions of charter References: <4468F985.6070108@azairenet.com> <4469A11A.3070509@motorola.com> In-Reply-To: <4469A11A.3070509@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 17:28:55.0279 (UTC) FILETIME=[3506F7F0:01C6790E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ml-nemo WG , "T.J. Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Alexandru Petrescu wrote: > Vijay Devarapalli wrote: >> hi TJ, >> >> my understanding was that there will also be a general purpose route >> optimization solution. and this solution would not depend on >> geographically distributed HAs. this is not mentioned anywhere in the >> charter. the charter only talks about "Analysis of the Solution >> Space for Route Optimization". >> >>> The working group has work items to describe a basic solution for >>> network mobility in IPv6-only networks, and to design a mechanism to >>> allow mixed IPv4/IPv6 networks, carrying signalling messages that >>> describe both IPv4 and IPv6 addresses and mobile network prefixes. >>> The latter task is shared with the Mobile IPv6 working group, >>> addressed by a joint design team. >> >> this is just DS-MIPv6 (with appropriate extensions for IPv4 mobile >> network prefixes), right? nothing more. > > Maybe something more generic than just DS-MIPv6? DS-MIPv6 addresses > some relevant transition cases but not all (HA fully-v6 is not addressed). well, thats what I was asking TJ. if DS-MIPv6 is what the chairs have in mind for this or it is something more. Vijay From nemo-bounces@ietf.org Tue May 16 14:24:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4DP-0006s1-Ou; Tue, 16 May 2006 14:24:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4DO-0006oz-Iz for nemo@ietf.org; Tue, 16 May 2006 14:24:14 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg4DN-00056t-8d for nemo@ietf.org; Tue, 16 May 2006 14:24:14 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 11:24:11 -0700 Message-ID: <446A18C7.2070100@azairenet.com> Date: Tue, 16 May 2006 11:24:07 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF0028C4E9F@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0028C4E9F@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 18:24:11.0549 (UTC) FILETIME=[EDAD9CD0:01C67915] X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: nemo@ietf.org, "T.J. Kniveton" , Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Tsirtsis, George wrote: > TJ, > > Since you agree IPv4-only work should be allowed, could you add a > sentence to indicate that the WG will work on FA support and dynamic > prefix allocation extensions to the NEMOv4 base solution? I will be > submitting a draft about these issues before the next meeting. from what I saw, most people were *not* interested in taking up new items related to IPv4-only work. Vijay > > Thanks > George > >> -----Original Message----- >> From: T.J. Kniveton [mailto:tj@kniveton.com] >> Sent: Monday, May 15, 2006 1:05 PM >> To: Thierry Ernst >> Cc: nemo@ietf.org >> Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >> >> >> On May 4, 2006, at 7:16 AM, Thierry Ernst wrote: >> >>> I have a subtle understanding of what the message should be, and it > is >>> valid in all organizations: been clear, not confusing, and well >>> documented. We cannot develop IPv4 and IPv6 protocols in the same >>> group >>> (unless, as I said, we are working on interoperability issues). >> I would like to add one comment to this discussion. It seems >> appropriate to make a solution for IPv4-only networks, which >> thankfully is now underway. At some point it may make sense to form a >> separate working group for IPv4-only issues, but it's probably a bit >> too early to do that until the work is more mature, and the industry >> interest level and engineering participation within the IETF can be >> gauged. >> >> For IPv4-IPv6 mixed networks, it makes sense to me that we continue >> to work on that issue here in this group (and in the Mobile IPv6 >> working group). >> >> I understand some people have no interest in working on IPv4-only >> protocols, and likewise some people in NEMO probably have little or >> no interest in IPv6-only protocols. But in a mixed network, we should >> have something to say about how NEMO will work. After all, that >> scenario is a growth industry. >> >> TJ >> > > From nemo-bounces@ietf.org Tue May 16 14:29:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4I5-00005a-J9; Tue, 16 May 2006 14:29:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4I4-00005V-D4 for nemo@ietf.org; Tue, 16 May 2006 14:29:04 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg4I4-0005Io-1B for nemo@ietf.org; Tue, 16 May 2006 14:29:04 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 11:29:01 -0700 Message-ID: <446A19EC.6010607@azairenet.com> Date: Tue, 16 May 2006 11:29:00 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF0028C4F69@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0028C4F69@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 18:29:01.0170 (UTC) FILETIME=[9A4E4520:01C67916] X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Tsirtsis, George wrote: > GT> I am sorry but this will just not do. In the real world you can not > give to the customer a solution based on technology that the customer > has no way of testing. The idea that operators will deploy DS-MIPv6 MRs > to support NEMOv4 functionality while they have not yet migrated to IPv6 > is entirely unrealistic. hmm.. we had an extensive discussion on this on the MIPv4 mailing list. I strongly disagree with all of the above. DS-MIPv6 does not require the operator to upgrade the access network to IPv6. only the clients and the home agent are involved. >> Also, someone pointed that we should better complete the current work >> and decide for a re-chartering a bit later in the year. I agree with >> this suggestion, and we could discuss the rechartering a bit further >> during next or next-next IETF meeting. >> >> So, my proposition would be to postpone the new charter. >> > GT> I disagree. I have followed this discussion for the last several > weeks and the WG has been spending its time debating what it will do in > the future while there has been minimal debate on anything else. A > handful of us will get the NEMOv4 and its required extensions done in > minimal time with minimal effect on the WG. I just fail to understand > why you want to prevent willing WG members from doing work that is > clearly needed. the new proposed charter has too many items already for NEMOv6. many folks want to work on this. you should recognized that. I didn't see enough support for adding NEMOv4-only items to the charter. Vijay > > George > >> Thierry. >> >> On Tue, 16 May 2006 07:40:58 -0700 >> "Tsirtsis, George" wrote: >> >>> TJ, >>> >>> Since you agree IPv4-only work should be allowed, could you add a >>> sentence to indicate that the WG will work on FA support and dynamic >>> prefix allocation extensions to the NEMOv4 base solution? I will be >>> submitting a draft about these issues before the next meeting. >>> >>> Thanks >>> George >>> >>>> -----Original Message----- >>>> From: T.J. Kniveton [mailto:tj@kniveton.com] >>>> Sent: Monday, May 15, 2006 1:05 PM >>>> To: Thierry Ernst >>>> Cc: nemo@ietf.org >>>> Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >>>> >>>> >>>> On May 4, 2006, at 7:16 AM, Thierry Ernst wrote: >>>> >>>>> I have a subtle understanding of what the message should be, and > it >>> is >>>>> valid in all organizations: been clear, not confusing, and well >>>>> documented. We cannot develop IPv4 and IPv6 protocols in the > same >>>>> group >>>>> (unless, as I said, we are working on interoperability issues). >>>> I would like to add one comment to this discussion. It seems >>>> appropriate to make a solution for IPv4-only networks, which >>>> thankfully is now underway. At some point it may make sense to > form a >>>> separate working group for IPv4-only issues, but it's probably a > bit >>>> too early to do that until the work is more mature, and the > industry >>>> interest level and engineering participation within the IETF can > be >>>> gauged. >>>> >>>> For IPv4-IPv6 mixed networks, it makes sense to me that we > continue >>>> to work on that issue here in this group (and in the Mobile IPv6 >>>> working group). >>>> >>>> I understand some people have no interest in working on IPv4-only >>>> protocols, and likewise some people in NEMO probably have little > or >>>> no interest in IPv6-only protocols. But in a mixed network, we > should >>>> have something to say about how NEMO will work. After all, that >>>> scenario is a growth industry. >>>> >>>> TJ >>>> >>> >>> >> >> -- >> Thierry ERNST, PhD >> INRIA Rocquencourt Projet IMARA >> +33 1 39 63 59 30 >> > > From nemo-bounces@ietf.org Tue May 16 14:37:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4QJ-00026A-CC; Tue, 16 May 2006 14:37:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4QI-000265-8X for nemo@ietf.org; Tue, 16 May 2006 14:37:34 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg4QH-0005hw-UP for nemo@ietf.org; Tue, 16 May 2006 14:37:34 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 11:37:32 -0700 Message-ID: <446A1BEC.2060309@azairenet.com> Date: Tue, 16 May 2006 11:37:32 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: [nemo] New versions of charter References: <28c3e7f8ee58e55b015a0ad55f807ae8@it.uc3m.es> In-Reply-To: <28c3e7f8ee58e55b015a0ad55f807ae8@it.uc3m.es> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 18:37:32.0039 (UTC) FILETIME=[CACEB170:01C67917] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: ml-nemo WG , "T.J.Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org marcelo bagnulo braun wrote: > I think that during the charter discussion so far, the only use case we > have for RO is the aviation case, not true. it was the only one that was discussed. does not mean its the only one. Pascal pointed out a few scenarios in addition. > which they have these globally moving > network scenarios, and they have a very clear idea of what the > requirements are for this case. > > I think that it is not straight forward from these preliminary list of > requirements that they need globally distributed HAs, nor a protocol to > coordinate them. (It is neither clear they they do not need different > ISPs for instance, making global HAHA type of solution and contributor > to the global routing table) > > So, as i see it: > > - it is clear that the aviation is a relevant use case for RO in > globally moving networks > - imho we should work to provide a solution for this particular use case not so sure about this. when I talking to Terry at the one of the IETFs, he told that there is some kind of aviation forum that is working on the requirements. I am not sure if the forum is also going to work on solutions. IMO, we shouldn't be committing to spending time on this unless we are told by the aviation folks that they want a solution from the NEMO WG in the IETF. I have only heard Terry say they are *interested*. :) Terry, please correct me if I am wrong. > - however, it is not clear what the solution should be (yet) > > So, i would suggest to include the following items in the charter: > > - Submit a -00 draft describing the requirements for globally moving > networks this we could do. > - Submit a -00 draft describing a solution for globally moving networks > that fulfills the identified requirements not yet. perhaps re-charter again when we conclude based on the requirements that we can provide a solution. Vijay From nemo-bounces@ietf.org Tue May 16 14:52:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4ez-0007Ll-4F; Tue, 16 May 2006 14:52:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4ex-0007Lg-Ia for nemo@ietf.org; Tue, 16 May 2006 14:52:43 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg4ev-0006YU-3P for nemo@ietf.org; Tue, 16 May 2006 14:52:43 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4GIqWoa006706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 16 May 2006 11:52:34 -0700 Received: from NAEXBR02.na.qualcomm.com (naexbr02.qualcomm.com [10.46.92.109]) by crowley.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4GIqHxs017033; Tue, 16 May 2006 11:52:32 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR02.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 11:52:31 -0700 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 Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Tue, 16 May 2006 11:52:37 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF00294EAAF@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZ5Fq6YsvF9YjWbTpO1Y1Tx772BGAAAXKVg From: "Tsirtsis, George" To: "Vijay Devarapalli" X-OriginalArrivalTime: 16 May 2006 18:52:31.0173 (UTC) FILETIME=[E2BBA750:01C67919] X-Spam-Score: 0.0 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Tuesday, May 16, 2006 2:29 PM > To: Tsirtsis, George > Cc: Thierry Ernst; nemo@ietf.org > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >=20 > Tsirtsis, George wrote: >=20 > > GT> I am sorry but this will just not do. In the real world you can not > > give to the customer a solution based on technology that the customer > > has no way of testing. The idea that operators will deploy DS-MIPv6 MRs > > to support NEMOv4 functionality while they have not yet migrated to IPv6 > > is entirely unrealistic. >=20 > hmm.. we had an extensive discussion on this on the MIPv4 > mailing list. I strongly disagree with all of the above. > DS-MIPv6 does not require the operator to upgrade the > access network to IPv6. only the clients and the home > agent are involved. >=20 GT1> An "operator" does not only provide access network services. A lot of operators provide a lot of services on top of access networks. What I am arguing is that an operator that provides mobility services i.e, installs, configures, maintains the HAs, and configures and sells MRs as part of some service (e.g, MRs in cars, plains, homes or whatever) MUST be able to deal with IPv6 to do DS-MIPv6. An IPv4 only operator will not be able to deal with this today. Which part of this is not obvious? > >> Also, someone pointed that we should better complete the current work > >> and decide for a re-chartering a bit later in the year. I agree with > >> this suggestion, and we could discuss the rechartering a bit further > >> during next or next-next IETF meeting. > >> > >> So, my proposition would be to postpone the new charter. > >> > > GT> I disagree. I have followed this discussion for the last several > > weeks and the WG has been spending its time debating what it will do in > > the future while there has been minimal debate on anything else. A > > handful of us will get the NEMOv4 and its required extensions done in > > minimal time with minimal effect on the WG. I just fail to understand > > why you want to prevent willing WG members from doing work that is > > clearly needed. >=20 > the new proposed charter has too many items already for > NEMOv6. many folks want to work on this. you should > recognized that. I didn't see enough support for adding > NEMOv4-only items to the charter. >=20 GT2> What is enough? This is not a system where we need to count votes and find the majority by even a single vote. I know that they are slightly less people actively supporting this work than people not supporting this work. So, what? Most people on the mailing list do not actually care and I bet they are annoyed by this pointless, never ending discussion. George > Vijay >=20 > > > > George > > > >> Thierry. > >> > >> On Tue, 16 May 2006 07:40:58 -0700 > >> "Tsirtsis, George" wrote: > >> > >>> TJ, > >>> > >>> Since you agree IPv4-only work should be allowed, could you add a > >>> sentence to indicate that the WG will work on FA support and dynamic > >>> prefix allocation extensions to the NEMOv4 base solution? I will be > >>> submitting a draft about these issues before the next meeting. > >>> > >>> Thanks > >>> George > >>> > >>>> -----Original Message----- > >>>> From: T.J. Kniveton [mailto:tj@kniveton.com] > >>>> Sent: Monday, May 15, 2006 1:05 PM > >>>> To: Thierry Ernst > >>>> Cc: nemo@ietf.org > >>>> Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. > >>>> > >>>> > >>>> On May 4, 2006, at 7:16 AM, Thierry Ernst wrote: > >>>> > >>>>> I have a subtle understanding of what the message should be, and > > it > >>> is > >>>>> valid in all organizations: been clear, not confusing, and well > >>>>> documented. We cannot develop IPv4 and IPv6 protocols in the > > same > >>>>> group > >>>>> (unless, as I said, we are working on interoperability issues). > >>>> I would like to add one comment to this discussion. It seems > >>>> appropriate to make a solution for IPv4-only networks, which > >>>> thankfully is now underway. At some point it may make sense to > > form a > >>>> separate working group for IPv4-only issues, but it's probably a > > bit > >>>> too early to do that until the work is more mature, and the > > industry > >>>> interest level and engineering participation within the IETF can > > be > >>>> gauged. > >>>> > >>>> For IPv4-IPv6 mixed networks, it makes sense to me that we > > continue > >>>> to work on that issue here in this group (and in the Mobile IPv6 > >>>> working group). > >>>> > >>>> I understand some people have no interest in working on IPv4-only > >>>> protocols, and likewise some people in NEMO probably have little > > or > >>>> no interest in IPv6-only protocols. But in a mixed network, we > > should > >>>> have something to say about how NEMO will work. After all, that > >>>> scenario is a growth industry. > >>>> > >>>> TJ > >>>> > >>> > >>> > >> > >> -- > >> Thierry ERNST, PhD > >> INRIA Rocquencourt Projet IMARA > >> +33 1 39 63 59 30 > >> > > > > From nemo-bounces@ietf.org Tue May 16 15:01:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4nj-0001qD-CW; Tue, 16 May 2006 15:01:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg4nj-0001q8-2R for nemo@ietf.org; Tue, 16 May 2006 15:01:47 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg4ni-0007Q7-Nk for nemo@ietf.org; Tue, 16 May 2006 15:01:47 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 12:01:44 -0700 Message-ID: <446A2198.4060306@azairenet.com> Date: Tue, 16 May 2006 12:01:44 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF00294EAAF@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF00294EAAF@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 19:01:44.0661 (UTC) FILETIME=[2CA33850:01C6791B] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Tsirtsis, George wrote: >> >>> GT> I am sorry but this will just not do. In the real world you can > not >>> give to the customer a solution based on technology that the > customer >>> has no way of testing. The idea that operators will deploy DS-MIPv6 > MRs >>> to support NEMOv4 functionality while they have not yet migrated to > IPv6 >>> is entirely unrealistic. >> hmm.. we had an extensive discussion on this on the MIPv4 >> mailing list. I strongly disagree with all of the above. >> DS-MIPv6 does not require the operator to upgrade the >> access network to IPv6. only the clients and the home >> agent are involved. >> > > GT1> An "operator" does not only provide access network services. A lot > of operators provide a lot of services on top of access networks. What > I am arguing is that an operator that provides mobility services i.e, > installs, configures, maintains the HAs, and configures and sells MRs as > part of some service (e.g, MRs in cars, plains, homes or whatever) MUST > be able to deal with IPv6 to do DS-MIPv6. An IPv4 only operator will not > be able to deal with this today. Which part of this is not obvious? I am going to avoid getting into this again. we had a really long discussion already on this on the MIPv4 mailing list. >>> GT> I disagree. I have followed this discussion for the last several >>> weeks and the WG has been spending its time debating what it will do > in >>> the future while there has been minimal debate on anything else. A >>> handful of us will get the NEMOv4 and its required extensions done > in >>> minimal time with minimal effect on the WG. I just fail to > understand >>> why you want to prevent willing WG members from doing work that is >>> clearly needed. >> the new proposed charter has too many items already for >> NEMOv6. many folks want to work on this. you should >> recognized that. I didn't see enough support for adding >> NEMOv4-only items to the charter. >> > GT2> What is enough? This is not a system where we need to count votes > and find the majority by even a single vote. I know that they are > slightly less people actively supporting this work than people not > supporting this work. So, what? Most people on the mailing list do not > actually care and I bet they are annoyed by this pointless, never ending > discussion. George, *IMO* I didn't see enough support to add NEMOv4-only work items to the charter. you may have seen different. it is up to the WG chairs to decide. Vijay From nemo-bounces@ietf.org Tue May 16 16:34:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6FR-0006JT-Ka; Tue, 16 May 2006 16:34:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6FQ-0006JO-GU for nemo@ietf.org; Tue, 16 May 2006 16:34:28 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg6FP-0005B8-9E for nemo@ietf.org; Tue, 16 May 2006 16:34:28 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k4GKYIpZ011122; Tue, 16 May 2006 13:34:18 -0700 (MST) Received: from [10.169.5.144] (mvp-10-169-5-144.corp.mot.com [10.169.5.144]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k4GKYG0c020917; Tue, 16 May 2006 15:34:17 -0500 (CDT) Message-ID: <446A3747.5050306@motorola.com> Date: Tue, 16 May 2006 22:34:15 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF00294EAAF@NAEX06.na.qualcomm.com> <446A2198.4060306@azairenet.com> In-Reply-To: <446A2198.4060306@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Vijay Devarapalli wrote: >> GT2> What is enough? This is not a system where we need to count >> votes and find the majority by even a single vote. I know that they >> are slightly less people actively supporting this work than people >> not supporting this work. So, what? Most people on the mailing >> list do not actually care and I bet they are annoyed by this >> pointless, never ending discussion. > > George, *IMO* I didn't see enough support to add NEMOv4-only work > items to the charter. you may have seen different. it is up to the WG > chairs to decide. Vijay, I'm not drawing conclusions, Chairs make decisions. What I've seen is people willing to work on IPv6, others on IPv4 and yet others requiring v4-v6 migration. I haven't seen anybody opposing others' work, except maybe one and now two. I mean nobody who expressed wish to work on IPv6 opposed others to work on IPv4, and vice-versa. These are distinct. Even if voting is done, there are many ways to ask a question. Alex PS: IPv4 is already in the Charter, so not need to "add". It's because since the beginning people were interested in it. From nemo-bounces@ietf.org Tue May 16 17:15:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6sg-0000YU-AW; Tue, 16 May 2006 17:15:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg6se-0000YN-5l for nemo@ietf.org; Tue, 16 May 2006 17:15:00 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg6sc-0007gM-Rn for nemo@ietf.org; Tue, 16 May 2006 17:15:00 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 14:14:55 -0700 Message-ID: <446A40C7.4030207@azairenet.com> Date: Tue, 16 May 2006 14:14:47 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF00294EAAF@NAEX06.na.qualcomm.com> <446A2198.4060306@azairenet.com> <446A3747.5050306@motorola.com> In-Reply-To: <446A3747.5050306@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 May 2006 21:14:55.0340 (UTC) FILETIME=[C77412C0:01C6792D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Alexandru Petrescu wrote: > What I've seen is people willing to work on IPv6, others on IPv4 and yet > others requiring v4-v6 migration. > > I haven't seen anybody opposing others' work, except maybe one and now > two. there were a few emails on the mailing list saying IPv4-only work items should not be added to the charter. Vijay From nemo-bounces@ietf.org Tue May 16 17:50:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7Qr-0005ID-I3; Tue, 16 May 2006 17:50:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fg7Qq-0005I3-R7 for nemo@ietf.org; Tue, 16 May 2006 17:50:20 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fg6EP-00054c-5y for nemo@ietf.org; Tue, 16 May 2006 16:33:25 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fg61W-0002Zl-Uk for nemo@ietf.org; Tue, 16 May 2006 16:20:08 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id PAA10448; Tue, 16 May 2006 15:20:05 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4GKK4G14352; Tue, 16 May 2006 15:20:04 -0500 (CDT) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 16 May 2006 13:19:55 -0700 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 Subject: RE: [nemo] New versions of charter Date: Tue, 16 May 2006 13:19:55 -0700 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21C0D4@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: <446A1BEC.2060309@azairenet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] New versions of charter Thread-Index: AcZ5GP3czoyj7+wjQL2JBTm0DjqreAADDpmA From: "Davis, Terry L" To: "Vijay Devarapalli" , "marcelo bagnulo braun" X-OriginalArrivalTime: 16 May 2006 20:19:55.0903 (UTC) FILETIME=[18D5F0F0:01C67926] X-Spam-Score: -2.6 (--) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ml-nemo WG , "T.J.Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Vijay/TJ/Marcelo I'm polling some of the keys members of the aviation community that would be involved in writing the informational RFC to see what the support for the effort would be. I should have an idea by week end or early next week. Take care Terry > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Tuesday, May 16, 2006 11:38 AM > To: marcelo bagnulo braun > Cc: ml-nemo WG; T.J.Kniveton > Subject: Re: [nemo] New versions of charter >=20 > marcelo bagnulo braun wrote: >=20 > > I think that during the charter discussion so far, the only use case we > > have for RO is the aviation case, >=20 > not true. it was the only one that was discussed. > does not mean its the only one. Pascal pointed out > a few scenarios in addition. >=20 > > which they have these globally moving > > network scenarios, and they have a very clear idea of what the > > requirements are for this case. > > > > I think that it is not straight forward from these preliminary list of > > requirements that they need globally distributed HAs, nor a protocol to > > coordinate them. (It is neither clear they they do not need different > > ISPs for instance, making global HAHA type of solution and contributor > > to the global routing table) > > > > So, as i see it: > > > > - it is clear that the aviation is a relevant use case for RO in > > globally moving networks > > - imho we should work to provide a solution for this particular use case >=20 > not so sure about this. when I talking to Terry at > the one of the IETFs, he told that there is some > kind of aviation forum that is working on the > requirements. I am not sure if the forum is also > going to work on solutions. IMO, we shouldn't be > committing to spending time on this unless we are > told by the aviation folks that they want a solution > from the NEMO WG in the IETF. >=20 > I have only heard Terry say they are *interested*. :) > Terry, please correct me if I am wrong. >=20 > > - however, it is not clear what the solution should be (yet) > > > > So, i would suggest to include the following items in the charter: > > > > - Submit a -00 draft describing the requirements for globally moving > > networks >=20 > this we could do. >=20 > > - Submit a -00 draft describing a solution for globally moving networks > > that fulfills the identified requirements >=20 > not yet. perhaps re-charter again when we conclude > based on the requirements that we can provide a > solution. >=20 > Vijay From nemo-bounces@ietf.org Wed May 17 02:50:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFrP-0006Sf-W9; Wed, 17 May 2006 02:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFrO-0006Sa-LN for nemo@ietf.org; Wed, 17 May 2006 02:50:18 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgFrL-0004k6-Ie for nemo@ietf.org; Wed, 17 May 2006 02:50:18 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 273E2212C5D; Wed, 17 May 2006 09:50:07 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id E4F95212C59; Wed, 17 May 2006 09:50:06 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id AC4F5BDC40; Wed, 17 May 2006 09:50:06 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id 76C15BDC38; Wed, 17 May 2006 09:50:06 +0300 (EEST) In-Reply-To: <446A1BEC.2060309@azairenet.com> References: <28c3e7f8ee58e55b015a0ad55f807ae8@it.uc3m.es> <446A1BEC.2060309@azairenet.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <43cd0d1e269a38f273531e4988020c39@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] New versions of charter Date: Wed, 17 May 2006 09:50:06 +0300 To: Vijay Devarapalli X-Mailer: Apple Mail (2.624) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ml-nemo WG , "T.J.Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org El 16/05/2006, a las 21:37, Vijay Devarapalli escribi=F3: > marcelo bagnulo braun wrote: > >> I think that during the charter discussion so far, the only use case=20= >> we have for RO is the aviation case, > > not true. it was the only one that was discussed. > does not mean its the only one. Pascal pointed out > a few scenarios in addition. > i must have missed that.... what are the other use cases for RO that there is interest to work=20 on?... i remember TJ asking if there were any people from the vehicular=20= community that were interested, but i don't recall that there was any=20 reply to that request... >> which they have these globally moving network scenarios, and they=20 >> have a very clear idea of what the requirements are for this case. >> I think that it is not straight forward from these preliminary list=20= >> of requirements that they need globally distributed HAs, nor a=20 >> protocol to coordinate them. (It is neither clear they they do not=20 >> need different ISPs for instance, making global HAHA type of solution=20= >> and contributor to the global routing table) >> So, as i see it: >> - it is clear that the aviation is a relevant use case for RO in=20 >> globally moving networks >> - imho we should work to provide a solution for this particular use=20= >> case > > not so sure about this. when I talking to Terry at > the one of the IETFs, he told that there is some > kind of aviation forum that is working on the > requirements. I am not sure if the forum is also > going to work on solutions. IMO, we shouldn't be > committing to spending time on this unless we are > told by the aviation folks that they want a solution > from the NEMO WG in the IETF. > agree > I have only heard Terry say they are *interested*. :) > Terry, please correct me if I am wrong. >> - however, it is not clear what the solution should be (yet) >> So, i would suggest to include the following items in the charter: >> - Submit a -00 draft describing the requirements for globally moving=20= >> networks > > this we could do. > >> - Submit a -00 draft describing a solution for globally moving=20 >> networks that fulfills the identified requirements > > not yet. perhaps re-charter again when we conclude > based on the requirements that we can provide a > solution. > i may agree with this (i just think that it is likely that we are able=20= to find a solution (or more than one :-) (just to be clear, i was considering global haha as one of the=20 candidates solution for this problem, so this charter item was=20 substituting Submit -00 draft on Route Optimization for geographically=20= distributed HAs) regards, marcelo > Vijay > From nemo-bounces@ietf.org Wed May 17 02:57:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFyT-0001Ur-Gw; Wed, 17 May 2006 02:57:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgFyS-0001Um-Jk for nemo@ietf.org; Wed, 17 May 2006 02:57:36 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgFyR-0005BF-Sw for nemo@ietf.org; Wed, 17 May 2006 02:57:36 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 8FFC2212C5D; Wed, 17 May 2006 09:57:34 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id 58282212C59; Wed, 17 May 2006 09:57:34 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id E1793BDC40; Wed, 17 May 2006 09:57:33 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id AD346BDC38; Wed, 17 May 2006 09:57:33 +0300 (EEST) In-Reply-To: <20060516144501.412c4270.thierry.ernst@inria.fr> References: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> <5916B65B-F318-429B-9561-04E9D28EF73E@kniveton.com> <20060516110101.5124f6cd.thierry.ernst@inria.fr> <234519ed78b2bf91be22e01ed3d1f538@it.uc3m.es> <20060516124606.6deac871.thierry.ernst@inria.fr> <74f86f393d8f38fffec68a9a079d6497@it.uc3m.es> <20060516144501.412c4270.thierry.ernst@inria.fr> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Deployment Requirements Date: Wed, 17 May 2006 09:57:32 +0300 To: Thierry Ernst X-Mailer: Apple Mail (2.624) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org El 16/05/2006, a las 15:45, Thierry Ernst escribi=F3: > >>> Well, do you intend to mean that we should write a deployment >>> requirements draft for the aviation industry specifically, in which >>> case >>> we would do the same for the vehicular industry, and for each other >>> existing use cases ? >>> >> >> well, i am not sure about the vehicular technology because i don't >> know if they have specific requirements. > > They do, though they don't speak up yet, because (unfortunately) IETF=20= > is > not an organization where they used to be involved. But they (or the > vendors related to the vehicular industry and the standardization=20 > bodies > such as ISO and ETSI) will show up when they understand it is = important > for them to be involved in the debate. > good i am all for working on other cases if there is interest (FWIW my point about working in aviation and not in other use cases was=20= merely because there was no feedback on those, not because i have any=20 kind of problem in working in other cases) > Would be interesting to get some input from the Japanese folks who I > know are monitoring this ML. I'm not speaking only about the people at > Keio University who are academic though who are involved with these > people, but the people representing the companies who are in this > business. > > Come on folks, this is the right timing to discuss the deployment > requirements for the vehicular industry ! > >> but following the emails that have been exchanged lately in this ml, >> it is my opinion that the aviation case have quite special >> requirements and that they need customized solutions for thier >> problems that have their own set of deployment issues. > > I second this. But the vehicular industry is IMHO more important as it > would involved tens of vendors, with possibly divergent deployment > requirements. > good, let's write those down also and see what is the common=20 requiremetns for all the relevant use cases If the common part is large, we should defineltly include them in the=20 common requiremetns draft that we already have. If the common part is=20 small and there are a lot of diverging requirements then we should go=20 for different drafts i guess but i guess that the first part is to get individual submissions from=20 each of the use cases that people are interested in working on >> I mean consider that they are moving globally quite rapidly, they = have >> >> wordlwide infrastruture, they need high reliability, and so on, = which >> >> makes their case somehow different from the case of nemos deployed in >> buses cars and so on (or at least it seems so to me) > > Well, cases and thus requirements are different. RFC 3963 may not=20 > always > apply, but even though, the security, authentication and multihoming > considerations are different. > >> that is why i think that the general requirements and in particular >> the deployment requirements for a solution to this particular problem >> need to be fleshed out > > Yes, but what is the best procedure ? Independent draft, one for each > use case, or shall we came up straight with common requirements, in > which case I would say draft-ietf-nemo-requirements is the best place=20= > to > gather these deployment scenarios ? > see my suggestion above... i guess that in order to answer this we=20 should first figure out what is the common requiremetns for all the=20 relevant use cases and then we can decide... regards, marcelo >>> If yes, then I guess it would rather be individual submissions >> >> yes i think Terry initial list could be a starting point for this >> >>> that >>> could be used as input for determining a common list of deployment >>> requirements. >>> >> >> well depending on whether this requirements fit into the general >> requirements, this may be ok.... but i think that they are likely to >> be quite differetn from the general case > > This may not be an issue. The draft could be explicit that these are > requirements for that specific use cases where we get some input. > > Thierry. > >>> >>>>> [I changed the subject line] >>>>> >>>>> Speaking about "deployment requirements", I would propose to add a >>>>> section in draft-ietf-nemo-requirements (actually, I intended to >>>>> extend >>>>> that draft since the beginning ;-) rather of editing a separate >>>>> document. >>>>> >>>>> Would that make sense to everyone ? >>>>> >>>> >>>> i think that there are some general deployment requirements that >>> could> fit in there >>>> >>>> however, perhaps the case of aviation may have quite specific >>>> requirements of their own that may not apply in the general >>> case.... i> mean not all of us have worldwide sites and a nemo = moving >>> around> several of them in a single day :-) >>>> >>>> Regards, marcelo >>>> >>>> >>>>> Thierry. >>>>> >>>>> >>>>> >>>>> On Tue, 16 May 2006 09:19:30 +0300 >>>>> marcelo bagnulo braun wrote: >>>>> >>>>>> >>>>>> El 15/05/2006, a las 20:47, T.J.Kniveton escribi=F3: >>>>>> >>>>>>> On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote: >>>>>>> >>>>>>>> T.J. >>>>>>>> >>>>>>>> You'll probably wish that you hadn't asked for this... >>>>>>>> >>>>>>>> These would be our ideal mobility solution. I realize that >>>>>>>> meeting >>>>>>>> all >>>>>>>> of these is probably an extreme stretch. >>>>>>>> >>>>>>>> Take care >>>>>>>> Terry >>>>>>> >>>>>>> Terry, >>>>>>> >>>>>>> I second the request to put your list of items into a draft. It >>>>>>> will >>>>>>> be helpful to have a concrete list of deployment requirements to >>>>>>> refer >>>>>>> to. While the WG can't necessarily solve all of the problems for >>> >>>>>>> one >>>>>>> specific deployment, an informational document listing them can >>> be>>>> useful for guidance when making engineering design decisions. >>>>>>> >>>>>>> Would you be willing to do that? Perhaps others in the WG can >>> help>>>> with maintaining the document / editing if needed. >>>>>>> >>>>>> >>>>>> i am willing to help Terry on this in case it is needed... >>>>>> >>>>>> regards, marcelo >>>>>> >>>>>> >>>>>>> TJ >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> --=20 >>>>> Thierry ERNST, PhD >>>>> INRIA Rocquencourt Projet IMARA >>>>> +33 1 39 63 59 30 >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> --=20 >>> Thierry ERNST, PhD >>> INRIA Rocquencourt Projet IMARA >>> +33 1 39 63 59 30 >>> >> >> >> > > > --=20 > Thierry ERNST, PhD > INRIA Rocquencourt Projet IMARA > +33 1 39 63 59 30 > > From nemo-bounces@ietf.org Wed May 17 04:38:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgHYD-0002lH-AZ; Wed, 17 May 2006 04:38:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgHYB-0002lC-Jw for nemo@ietf.org; Wed, 17 May 2006 04:38:35 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgHY9-0000f9-0L for nemo@ietf.org; Wed, 17 May 2006 04:38:35 -0400 Received: from guest-rocq-135223.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k4H8cSGg022346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 May 2006 10:38:28 +0200 Date: Wed, 17 May 2006 10:39:39 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Deployment Requirements Message-Id: <20060517103939.37ca1203.thierry.ernst@inria.fr> In-Reply-To: References: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> <5916B65B-F318-429B-9561-04E9D28EF73E@kniveton.com> <20060516110101.5124f6cd.thierry.ernst@inria.fr> <234519ed78b2bf91be22e01ed3d1f538@it.uc3m.es> <20060516124606.6deac871.thierry.ernst@inria.fr> <74f86f393d8f38fffec68a9a079d6497@it.uc3m.es> <20060516144501.412c4270.thierry.ernst@inria.fr> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP X-Miltered: at concorde with ID 446AE104.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by concorde.inria.fr id k4H8cSGg022346 X-Spam-Score: 0.0 (/) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, We don't necessarily need a draft to gather the requirements (though a draft is an easiest way to have a document to refer to when debating). I'm happy to initiate a document for the vehicular industry though I'm not sure I will have all the necessary time in the next few weeks. But I need help from other people already involved with the car industry and related vendors. Actaully, I think gathering the deployment requirements is a necessary step before rechartering the WG. Thierry. > >>> Well, do you intend to mean that we should write a deployment > >>> requirements draft for the aviation industry specifically, in which > >>> case > >>> we would do the same for the vehicular industry, and for each other > >>> existing use cases ? > >>> > >> > >> well, i am not sure about the vehicular technology because i don't > >> know if they have specific requirements. > > > > They do, though they don't speak up yet, because (unfortunately) IETF= =20 > > is > > not an organization where they used to be involved. But they (or the > > vendors related to the vehicular industry and the standardization=20 > > bodies > > such as ISO and ETSI) will show up when they understand it is importa= nt > > for them to be involved in the debate. > > >=20 > good i am all for working on other cases if there is interest >=20 > (FWIW my point about working in aviation and not in other use cases was= =20 > merely because there was no feedback on those, not because i have any=20 > kind of problem in working in other cases) >=20 > > Would be interesting to get some input from the Japanese folks who I > > know are monitoring this ML. I'm not speaking only about the people a= t > > Keio University who are academic though who are involved with these > > people, but the people representing the companies who are in this > > business. > > > > Come on folks, this is the right timing to discuss the deployment > > requirements for the vehicular industry ! > > > >> but following the emails that have been exchanged lately in this ml, > >> it is my opinion that the aviation case have quite special > >> requirements and that they need customized solutions for thier > >> problems that have their own set of deployment issues. > > > > I second this. But the vehicular industry is IMHO more important as i= t > > would involved tens of vendors, with possibly divergent deployment > > requirements. > > >=20 > good, let's write those down also and see what is the common=20 > requiremetns for all the relevant use cases >=20 > If the common part is large, we should defineltly include them in the=20 > common requiremetns draft that we already have. If the common part is=20 > small and there are a lot of diverging requirements then we should go=20 > for different drafts i guess >=20 > but i guess that the first part is to get individual submissions from=20 > each of the use cases that people are interested in working on >=20 >=20 >=20 > >> I mean consider that they are moving globally quite rapidly, they ha= ve > >> > >> wordlwide infrastruture, they need high reliability, and so on, whi= ch > >> > >> makes their case somehow different from the case of nemos deployed i= n > >> buses cars and so on (or at least it seems so to me) > > > > Well, cases and thus requirements are different. RFC 3963 may not=20 > > always > > apply, but even though, the security, authentication and multihoming > > considerations are different. > > > >> that is why i think that the general requirements and in particular > >> the deployment requirements for a solution to this particular proble= m > >> need to be fleshed out > > > > Yes, but what is the best procedure ? Independent draft, one for each > > use case, or shall we came up straight with common requirements, in > > which case I would say draft-ietf-nemo-requirements is the best place= =20 > > to > > gather these deployment scenarios ? > > >=20 > see my suggestion above... i guess that in order to answer this we=20 > should first figure out what is the common requiremetns for all the=20 > relevant use cases and then we can decide... >=20 > regards, marcelo >=20 >=20 > >>> If yes, then I guess it would rather be individual submissions > >> > >> yes i think Terry initial list could be a starting point for this > >> > >>> that > >>> could be used as input for determining a common list of deployment > >>> requirements. > >>> > >> > >> well depending on whether this requirements fit into the general > >> requirements, this may be ok.... but i think that they are likely to > >> be quite differetn from the general case > > > > This may not be an issue. The draft could be explicit that these are > > requirements for that specific use cases where we get some input. > > > > Thierry. > > > >>> > >>>>> [I changed the subject line] > >>>>> > >>>>> Speaking about "deployment requirements", I would propose to add = a > >>>>> section in draft-ietf-nemo-requirements (actually, I intended to > >>>>> extend > >>>>> that draft since the beginning ;-) rather of editing a separate > >>>>> document. > >>>>> > >>>>> Would that make sense to everyone ? > >>>>> > >>>> > >>>> i think that there are some general deployment requirements that > >>> could> fit in there > >>>> > >>>> however, perhaps the case of aviation may have quite specific > >>>> requirements of their own that may not apply in the general > >>> case.... i> mean not all of us have worldwide sites and a nemo movi= ng > >>> around> several of them in a single day :-) > >>>> > >>>> Regards, marcelo > >>>> > >>>> > >>>>> Thierry. > >>>>> > >>>>> > >>>>> > >>>>> On Tue, 16 May 2006 09:19:30 +0300 > >>>>> marcelo bagnulo braun wrote: > >>>>> > >>>>>> > >>>>>> El 15/05/2006, a las 20:47, T.J.Kniveton escribi=F3: > >>>>>> > >>>>>>> On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote: > >>>>>>> > >>>>>>>> T.J. > >>>>>>>> > >>>>>>>> You'll probably wish that you hadn't asked for this... > >>>>>>>> > >>>>>>>> These would be our ideal mobility solution. I realize that > >>>>>>>> meeting > >>>>>>>> all > >>>>>>>> of these is probably an extreme stretch. > >>>>>>>> > >>>>>>>> Take care > >>>>>>>> Terry > >>>>>>> > >>>>>>> Terry, > >>>>>>> > >>>>>>> I second the request to put your list of items into a draft. It > >>>>>>> will > >>>>>>> be helpful to have a concrete list of deployment requirements t= o > >>>>>>> refer > >>>>>>> to. While the WG can't necessarily solve all of the problems fo= r > >>> > >>>>>>> one > >>>>>>> specific deployment, an informational document listing them can > >>> be>>>> useful for guidance when making engineering design decisions. > >>>>>>> > >>>>>>> Would you be willing to do that? Perhaps others in the WG can > >>> help>>>> with maintaining the document / editing if needed. > >>>>>>> > >>>>>> > >>>>>> i am willing to help Terry on this in case it is needed... > >>>>>> > >>>>>> regards, marcelo > >>>>>> > >>>>>> > >>>>>>> TJ > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> --=20 > >>>>> Thierry ERNST, PhD > >>>>> INRIA Rocquencourt Projet IMARA > >>>>> +33 1 39 63 59 30 > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> --=20 > >>> Thierry ERNST, PhD > >>> INRIA Rocquencourt Projet IMARA > >>> +33 1 39 63 59 30 > >>> > >> > >> > >> > > > > > > --=20 > > Thierry ERNST, PhD > > INRIA Rocquencourt Projet IMARA > > +33 1 39 63 59 30 > > > > >=20 >=20 >=20 --=20 Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Wed May 17 04:42:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgHbx-00041e-Bh; Wed, 17 May 2006 04:42:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgHbw-00041Z-FP for nemo@ietf.org; Wed, 17 May 2006 04:42:28 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgHbv-00014v-3p for nemo@ietf.org; Wed, 17 May 2006 04:42:28 -0400 Received: from guest-rocq-135223.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k4H8gQII022890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 May 2006 10:42:26 +0200 Date: Wed, 17 May 2006 10:43:37 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Message-Id: <20060517104337.351ef9a1.thierry.ernst@inria.fr> In-Reply-To: <4469EE31.6060908@motorola.com> References: <1487A357FD2ED544B8AD29E528FF9DF0028C4E9F@NAEX06.na.qualcomm.com> <20060516165709.61828ceb.thierry.ernst@inria.fr> <4469EE31.6060908@motorola.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 446AE1F2.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On Tue, 16 May 2006 17:22:25 +0200 Alexandru Petrescu wrote: > Thierry Ernst wrote: > > I'm not sure we **agree** (as a WG) on IPv4-only work; actually the > > debate was open with mixed positions on both IPv4-only tasks accepted > > vs IPv4-only tasks not accepted, with a 3rd possibility that > > IPv4-IPv6 transition mechanisms would suffice to do what is the most > > needed. > > > > Also, someone pointed that we should better complete the current work > > and decide for a re-chartering a bit later in the year. I agree with > > this suggestion, and we could discuss the rechartering a bit further > > during next or next-next IETF meeting. > > > > So, my proposition would be to postpone the new charter. > > I don't get it... Are you proposing we work on the Charter now and apply > it later this year? > > We've been discussing new Charter extensively. Should we stop > discussing Charter? Discussion is fine, but IMHO agreeing and sending a new charter to the IESG is too early at this point of time since there are divergent point of views on what we should do or not. I would rather see this really happening for next-next IETF (November). In the meantime, we can discuss the deployment requirements (see the other thread) so that we really know what is needed. Thierry. From nemo-bounces@ietf.org Wed May 17 04:56:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgHpW-0000xI-V3; Wed, 17 May 2006 04:56:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgHpW-0000xD-Jh for nemo@ietf.org; Wed, 17 May 2006 04:56:30 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgHpW-0002lR-68 for nemo@ietf.org; Wed, 17 May 2006 04:56:30 -0400 Received: from guest-rocq-135223.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k4H8uTbu024819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 17 May 2006 10:56:29 +0200 Date: Wed, 17 May 2006 10:57:40 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] New versions of charter Message-Id: <20060517105740.39c53c27.thierry.ernst@inria.fr> In-Reply-To: <43cd0d1e269a38f273531e4988020c39@it.uc3m.es> References: <28c3e7f8ee58e55b015a0ad55f807ae8@it.uc3m.es> <446A1BEC.2060309@azairenet.com> <43cd0d1e269a38f273531e4988020c39@it.uc3m.es> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP X-Miltered: at concorde with ID 446AE53D.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by concorde.inria.fr id k4H8uTbu024819 X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On Wed, 17 May 2006 09:50:06 +0300 marcelo bagnulo braun wrote: >=20 > El 16/05/2006, a las 21:37, Vijay Devarapalli escribi=F3: >=20 > > marcelo bagnulo braun wrote: > > > >> I think that during the charter discussion so far, the only use case= =20 > >> we have for RO is the aviation case, > > > > not true. it was the only one that was discussed. > > does not mean its the only one. Pascal pointed out > > a few scenarios in addition. > > >=20 > i must have missed that.... >=20 > what are the other use cases for RO that there is interest to work=20 > on?... i remember TJ asking if there were any people from the vehicular= =20 > community that were interested, but i don't recall that there was any=20 > reply to that request... FYI, the car industry forum I'm involved in are considering NEMO Basic Support (RFC 3963) at the core of the communication architecture for vehicle to infrastructure communications. However, they don't necessarily understand the potential extensions (HAHA, RO, etc) nor the tradeoff, so they are rather in the process of investigating what they need, though they already told me they would need RO in some cases. Right now, the most important concern they have is the IPR issues (I've told them to check with their lawyers if CISCO and Nokia statements are an issue or not) On the very negative side, they are not directly involved with the IETF so they don't know how to get involved right now and this is why so far we haven't seen them taking part in the debate. So, I'm urging any one involved with the car industry on this list to speak up now, particurlary regarding deployment issues. Thierry. > >> which they have these globally moving network scenarios, and they=20 > >> have a very clear idea of what the requirements are for this case. > >> I think that it is not straight forward from these preliminary list=20 > >> of requirements that they need globally distributed HAs, nor a=20 > >> protocol to coordinate them. (It is neither clear they they do not=20 > >> need different ISPs for instance, making global HAHA type of solutio= n=20 > >> and contributor to the global routing table) > >> So, as i see it: > >> - it is clear that the aviation is a relevant use case for RO in=20 > >> globally moving networks > >> - imho we should work to provide a solution for this particular use=20 > >> case > > > > not so sure about this. when I talking to Terry at > > the one of the IETFs, he told that there is some > > kind of aviation forum that is working on the > > requirements. I am not sure if the forum is also > > going to work on solutions. IMO, we shouldn't be > > committing to spending time on this unless we are > > told by the aviation folks that they want a solution > > from the NEMO WG in the IETF. > > >=20 > agree >=20 > > I have only heard Terry say they are *interested*. :) > > Terry, please correct me if I am wrong. >=20 > >> - however, it is not clear what the solution should be (yet) > >> So, i would suggest to include the following items in the charter: > >> - Submit a -00 draft describing the requirements for globally moving= =20 > >> networks > > > > this we could do. > > > >> - Submit a -00 draft describing a solution for globally moving=20 > >> networks that fulfills the identified requirements > > > > not yet. perhaps re-charter again when we conclude > > based on the requirements that we can provide a > > solution. > > >=20 > i may agree with this (i just think that it is likely that we are able=20 > to find a solution (or more than one :-) >=20 > (just to be clear, i was considering global haha as one of the=20 > candidates solution for this problem, so this charter item was=20 > substituting Submit -00 draft on Route Optimization for geographically=20 > distributed HAs) >=20 > regards, marcelo >=20 >=20 >=20 > > Vijay > > >=20 >=20 >=20 --=20 Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Wed May 17 05:44:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgIZQ-00074c-PL; Wed, 17 May 2006 05:43:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgIZP-00074X-E4 for nemo@ietf.org; Wed, 17 May 2006 05:43:55 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgIZM-0005uj-Lv for nemo@ietf.org; Wed, 17 May 2006 05:43:55 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E9D41212C5D; Wed, 17 May 2006 12:43:42 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id 831EB212C59; Wed, 17 May 2006 12:43:42 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id 0CB0CBDC40; Wed, 17 May 2006 12:43:42 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id 9AEFFBDC38; Wed, 17 May 2006 12:43:41 +0300 (EEST) In-Reply-To: <20060517103939.37ca1203.thierry.ernst@inria.fr> References: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> <5916B65B-F318-429B-9561-04E9D28EF73E@kniveton.com> <20060516110101.5124f6cd.thierry.ernst@inria.fr> <234519ed78b2bf91be22e01ed3d1f538@it.uc3m.es> <20060516124606.6deac871.thierry.ernst@inria.fr> <74f86f393d8f38fffec68a9a079d6497@it.uc3m.es> <20060516144501.412c4270.thierry.ernst@inria.fr> <20060517103939.37ca1203.thierry.ernst@inria.fr> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <2f43d0e2521bf3298a8a9852dcc1b2ee@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Deployment Requirements Date: Wed, 17 May 2006 12:43:40 +0300 To: Thierry Ernst X-Mailer: Apple Mail (2.624) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: f8ee348dcc4be4a59bc395f7cd6343ad Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org El 17/05/2006, a las 11:39, Thierry Ernst escribi=F3: > > Hi, > > We don't necessarily need a draft to gather the requirements (though a > draft is an easiest way to have a document to refer to when debating). > agree > I'm happy to initiate a document for the vehicular industry though I'm > not sure I will have all the necessary time in the next few weeks. But=20= > I > need help from other people already involved with the car industry and > related vendors. > > Actaully, I think gathering the deployment requirements is a necessary > step before rechartering the WG. > very much agree regards, marcelo > Thierry. > >>>>> Well, do you intend to mean that we should write a deployment >>>>> requirements draft for the aviation industry specifically, in = which >>>>> case >>>>> we would do the same for the vehicular industry, and for each = other >>>>> existing use cases ? >>>>> >>>> >>>> well, i am not sure about the vehicular technology because i don't >>>> know if they have specific requirements. >>> >>> They do, though they don't speak up yet, because (unfortunately) = IETF >>> is >>> not an organization where they used to be involved. But they (or the >>> vendors related to the vehicular industry and the standardization >>> bodies >>> such as ISO and ETSI) will show up when they understand it is=20 >>> important >>> for them to be involved in the debate. >>> >> >> good i am all for working on other cases if there is interest >> >> (FWIW my point about working in aviation and not in other use cases=20= >> was >> merely because there was no feedback on those, not because i have any >> kind of problem in working in other cases) >> >>> Would be interesting to get some input from the Japanese folks who I >>> know are monitoring this ML. I'm not speaking only about the people=20= >>> at >>> Keio University who are academic though who are involved with these >>> people, but the people representing the companies who are in this >>> business. >>> >>> Come on folks, this is the right timing to discuss the deployment >>> requirements for the vehicular industry ! >>> >>>> but following the emails that have been exchanged lately in this = ml, >>>> it is my opinion that the aviation case have quite special >>>> requirements and that they need customized solutions for thier >>>> problems that have their own set of deployment issues. >>> >>> I second this. But the vehicular industry is IMHO more important as=20= >>> it >>> would involved tens of vendors, with possibly divergent deployment >>> requirements. >>> >> >> good, let's write those down also and see what is the common >> requiremetns for all the relevant use cases >> >> If the common part is large, we should defineltly include them in the >> common requiremetns draft that we already have. If the common part is >> small and there are a lot of diverging requirements then we should go >> for different drafts i guess >> >> but i guess that the first part is to get individual submissions from >> each of the use cases that people are interested in working on >> >> >> >>>> I mean consider that they are moving globally quite rapidly, they=20= >>>> have >>>> >>>> wordlwide infrastruture, they need high reliability, and so on,=20 >>>> which >>>> >>>> makes their case somehow different from the case of nemos deployed=20= >>>> in >>>> buses cars and so on (or at least it seems so to me) >>> >>> Well, cases and thus requirements are different. RFC 3963 may not >>> always >>> apply, but even though, the security, authentication and multihoming >>> considerations are different. >>> >>>> that is why i think that the general requirements and in particular >>>> the deployment requirements for a solution to this particular=20 >>>> problem >>>> need to be fleshed out >>> >>> Yes, but what is the best procedure ? Independent draft, one for = each >>> use case, or shall we came up straight with common requirements, in >>> which case I would say draft-ietf-nemo-requirements is the best = place >>> to >>> gather these deployment scenarios ? >>> >> >> see my suggestion above... i guess that in order to answer this we >> should first figure out what is the common requiremetns for all the >> relevant use cases and then we can decide... >> >> regards, marcelo >> >> >>>>> If yes, then I guess it would rather be individual submissions >>>> >>>> yes i think Terry initial list could be a starting point for this >>>> >>>>> that >>>>> could be used as input for determining a common list of deployment >>>>> requirements. >>>>> >>>> >>>> well depending on whether this requirements fit into the general >>>> requirements, this may be ok.... but i think that they are likely = to >>>> be quite differetn from the general case >>> >>> This may not be an issue. The draft could be explicit that these are >>> requirements for that specific use cases where we get some input. >>> >>> Thierry. >>> >>>>> >>>>>>> [I changed the subject line] >>>>>>> >>>>>>> Speaking about "deployment requirements", I would propose to add=20= >>>>>>> a >>>>>>> section in draft-ietf-nemo-requirements (actually, I intended to >>>>>>> extend >>>>>>> that draft since the beginning ;-) rather of editing a separate >>>>>>> document. >>>>>>> >>>>>>> Would that make sense to everyone ? >>>>>>> >>>>>> >>>>>> i think that there are some general deployment requirements that >>>>> could> fit in there >>>>>> >>>>>> however, perhaps the case of aviation may have quite specific >>>>>> requirements of their own that may not apply in the general >>>>> case.... i> mean not all of us have worldwide sites and a nemo=20 >>>>> moving >>>>> around> several of them in a single day :-) >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>>> Thierry. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, 16 May 2006 09:19:30 +0300 >>>>>>> marcelo bagnulo braun wrote: >>>>>>> >>>>>>>> >>>>>>>> El 15/05/2006, a las 20:47, T.J.Kniveton escribi=F3: >>>>>>>> >>>>>>>>> On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote: >>>>>>>>> >>>>>>>>>> T.J. >>>>>>>>>> >>>>>>>>>> You'll probably wish that you hadn't asked for this... >>>>>>>>>> >>>>>>>>>> These would be our ideal mobility solution. I realize that >>>>>>>>>> meeting >>>>>>>>>> all >>>>>>>>>> of these is probably an extreme stretch. >>>>>>>>>> >>>>>>>>>> Take care >>>>>>>>>> Terry >>>>>>>>> >>>>>>>>> Terry, >>>>>>>>> >>>>>>>>> I second the request to put your list of items into a draft. = It >>>>>>>>> will >>>>>>>>> be helpful to have a concrete list of deployment requirements=20= >>>>>>>>> to >>>>>>>>> refer >>>>>>>>> to. While the WG can't necessarily solve all of the problems=20= >>>>>>>>> for >>>>> >>>>>>>>> one >>>>>>>>> specific deployment, an informational document listing them = can >>>>> be>>>> useful for guidance when making engineering design=20 >>>>> decisions. >>>>>>>>> >>>>>>>>> Would you be willing to do that? Perhaps others in the WG can >>>>> help>>>> with maintaining the document / editing if needed. >>>>>>>>> >>>>>>>> >>>>>>>> i am willing to help Terry on this in case it is needed... >>>>>>>> >>>>>>>> regards, marcelo >>>>>>>> >>>>>>>> >>>>>>>>> TJ >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> --=20 >>>>>>> Thierry ERNST, PhD >>>>>>> INRIA Rocquencourt Projet IMARA >>>>>>> +33 1 39 63 59 30 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> --=20 >>>>> Thierry ERNST, PhD >>>>> INRIA Rocquencourt Projet IMARA >>>>> +33 1 39 63 59 30 >>>>> >>>> >>>> >>>> >>> >>> >>> --=20 >>> Thierry ERNST, PhD >>> INRIA Rocquencourt Projet IMARA >>> +33 1 39 63 59 30 >>> >>> >> >> >> > > > --=20 > Thierry ERNST, PhD > INRIA Rocquencourt Projet IMARA > +33 1 39 63 59 30 > > From nemo-bounces@ietf.org Wed May 17 14:32:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgQoq-0002Ru-Iq; Wed, 17 May 2006 14:32:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgQop-0002Rp-TU for nemo@ietf.org; Wed, 17 May 2006 14:32:23 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgQon-0008U5-8a for nemo@ietf.org; Wed, 17 May 2006 14:32:23 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 11:32:14 -0700 Message-ID: <446B6C2E.5000700@azairenet.com> Date: Wed, 17 May 2006 11:32:14 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Deployment Requirements References: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> <5916B65B-F318-429B-9561-04E9D28EF73E@kniveton.com> <20060516110101.5124f6cd.thierry.ernst@inria.fr> <234519ed78b2bf91be22e01ed3d1f538@it.uc3m.es> <20060516124606.6deac871.thierry.ernst@inria.fr> <74f86f393d8f38fffec68a9a079d6497@it.uc3m.es> <20060516144501.412c4270.thierry.ernst@inria.fr> <20060517103939.37ca1203.thierry.ernst@inria.fr> In-Reply-To: <20060517103939.37ca1203.thierry.ernst@inria.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 17 May 2006 18:32:14.0562 (UTC) FILETIME=[37FD4C20:01C679E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97c820c82c68af374c4e382a80dc5017 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thierry Ernst wrote: > Actaully, I think gathering the deployment requirements is a necessary > step before rechartering the WG. or it could be part of the WG charter. Vijay > > Thierry. > >>>>> Well, do you intend to mean that we should write a deployment >>>>> requirements draft for the aviation industry specifically, in which >>>>> case >>>>> we would do the same for the vehicular industry, and for each other >>>>> existing use cases ? >>>>> >>>> well, i am not sure about the vehicular technology because i don't >>>> know if they have specific requirements. >>> They do, though they don't speak up yet, because (unfortunately) IETF >>> is >>> not an organization where they used to be involved. But they (or the >>> vendors related to the vehicular industry and the standardization >>> bodies >>> such as ISO and ETSI) will show up when they understand it is important >>> for them to be involved in the debate. >>> >> good i am all for working on other cases if there is interest >> >> (FWIW my point about working in aviation and not in other use cases was >> merely because there was no feedback on those, not because i have any >> kind of problem in working in other cases) >> >>> Would be interesting to get some input from the Japanese folks who I >>> know are monitoring this ML. I'm not speaking only about the people at >>> Keio University who are academic though who are involved with these >>> people, but the people representing the companies who are in this >>> business. >>> >>> Come on folks, this is the right timing to discuss the deployment >>> requirements for the vehicular industry ! >>> >>>> but following the emails that have been exchanged lately in this ml, >>>> it is my opinion that the aviation case have quite special >>>> requirements and that they need customized solutions for thier >>>> problems that have their own set of deployment issues. >>> I second this. But the vehicular industry is IMHO more important as it >>> would involved tens of vendors, with possibly divergent deployment >>> requirements. >>> >> good, let's write those down also and see what is the common >> requiremetns for all the relevant use cases >> >> If the common part is large, we should defineltly include them in the >> common requiremetns draft that we already have. If the common part is >> small and there are a lot of diverging requirements then we should go >> for different drafts i guess >> >> but i guess that the first part is to get individual submissions from >> each of the use cases that people are interested in working on >> >> >> >>>> I mean consider that they are moving globally quite rapidly, they have >>>> >>>> wordlwide infrastruture, they need high reliability, and so on, which >>>> >>>> makes their case somehow different from the case of nemos deployed in >>>> buses cars and so on (or at least it seems so to me) >>> Well, cases and thus requirements are different. RFC 3963 may not >>> always >>> apply, but even though, the security, authentication and multihoming >>> considerations are different. >>> >>>> that is why i think that the general requirements and in particular >>>> the deployment requirements for a solution to this particular problem >>>> need to be fleshed out >>> Yes, but what is the best procedure ? Independent draft, one for each >>> use case, or shall we came up straight with common requirements, in >>> which case I would say draft-ietf-nemo-requirements is the best place >>> to >>> gather these deployment scenarios ? >>> >> see my suggestion above... i guess that in order to answer this we >> should first figure out what is the common requiremetns for all the >> relevant use cases and then we can decide... >> >> regards, marcelo >> >> >>>>> If yes, then I guess it would rather be individual submissions >>>> yes i think Terry initial list could be a starting point for this >>>> >>>>> that >>>>> could be used as input for determining a common list of deployment >>>>> requirements. >>>>> >>>> well depending on whether this requirements fit into the general >>>> requirements, this may be ok.... but i think that they are likely to >>>> be quite differetn from the general case >>> This may not be an issue. The draft could be explicit that these are >>> requirements for that specific use cases where we get some input. >>> >>> Thierry. >>> >>>>>>> [I changed the subject line] >>>>>>> >>>>>>> Speaking about "deployment requirements", I would propose to add a >>>>>>> section in draft-ietf-nemo-requirements (actually, I intended to >>>>>>> extend >>>>>>> that draft since the beginning ;-) rather of editing a separate >>>>>>> document. >>>>>>> >>>>>>> Would that make sense to everyone ? >>>>>>> >>>>>> i think that there are some general deployment requirements that >>>>> could> fit in there >>>>>> however, perhaps the case of aviation may have quite specific >>>>>> requirements of their own that may not apply in the general >>>>> case.... i> mean not all of us have worldwide sites and a nemo moving >>>>> around> several of them in a single day :-) >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>>> Thierry. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, 16 May 2006 09:19:30 +0300 >>>>>>> marcelo bagnulo braun wrote: >>>>>>> >>>>>>>> El 15/05/2006, a las 20:47, T.J.Kniveton escribi�: >>>>>>>> >>>>>>>>> On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote: >>>>>>>>> >>>>>>>>>> T.J. >>>>>>>>>> >>>>>>>>>> You'll probably wish that you hadn't asked for this... >>>>>>>>>> >>>>>>>>>> These would be our ideal mobility solution. I realize that >>>>>>>>>> meeting >>>>>>>>>> all >>>>>>>>>> of these is probably an extreme stretch. >>>>>>>>>> >>>>>>>>>> Take care >>>>>>>>>> Terry >>>>>>>>> Terry, >>>>>>>>> >>>>>>>>> I second the request to put your list of items into a draft. It >>>>>>>>> will >>>>>>>>> be helpful to have a concrete list of deployment requirements to >>>>>>>>> refer >>>>>>>>> to. While the WG can't necessarily solve all of the problems for >>>>>>>>> one >>>>>>>>> specific deployment, an informational document listing them can >>>>> be>>>> useful for guidance when making engineering design decisions. >>>>>>>>> Would you be willing to do that? Perhaps others in the WG can >>>>> help>>>> with maintaining the document / editing if needed. >>>>>>>> i am willing to help Terry on this in case it is needed... >>>>>>>> >>>>>>>> regards, marcelo >>>>>>>> >>>>>>>> >>>>>>>>> TJ >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Thierry ERNST, PhD >>>>>>> INRIA Rocquencourt Projet IMARA >>>>>>> +33 1 39 63 59 30 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Thierry ERNST, PhD >>>>> INRIA Rocquencourt Projet IMARA >>>>> +33 1 39 63 59 30 >>>>> >>>> >>>> >>> >>> -- >>> Thierry ERNST, PhD >>> INRIA Rocquencourt Projet IMARA >>> +33 1 39 63 59 30 >>> >>> >> >> > > From nemo-bounces@ietf.org Wed May 17 14:34:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgQr6-0003qg-22; Wed, 17 May 2006 14:34:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgQr4-0003qb-Ah for nemo@ietf.org; Wed, 17 May 2006 14:34:42 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgQr4-0000DN-1c for nemo@ietf.org; Wed, 17 May 2006 14:34:42 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 17 May 2006 11:34:40 -0700 Message-ID: <446B6CC0.4020301@azairenet.com> Date: Wed, 17 May 2006 11:34:40 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF0028C4E9F@NAEX06.na.qualcomm.com> <20060516165709.61828ceb.thierry.ernst@inria.fr> <4469EE31.6060908@motorola.com> <20060517104337.351ef9a1.thierry.ernst@inria.fr> In-Reply-To: <20060517104337.351ef9a1.thierry.ernst@inria.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 May 2006 18:34:40.0825 (UTC) FILETIME=[8F2B4290:01C679E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thierry Ernst wrote: > Discussion is fine, but IMHO agreeing and sending a new charter to the > IESG is too early at this point of time since there are divergent point > of views on what we should do or not. I would rather see this really > happening for next-next IETF (November). In the meantime, we can discuss > the deployment requirements (see the other thread) so that we really > know what is needed. I don't think it is a good idea to put off re-chartering for this long. you can infact re-charter once more in November if you want once we have a clearer picture of what solutions are needed. working on the requirements could be part of the new charter and we can send the charter to the IESG right away. we shouldn't let other items proposed items in the charter suffer because we want to gather "deployment requirements". Vijay From nemo-bounces@ietf.org Thu May 18 03:15:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgcjW-0001M7-It; Thu, 18 May 2006 03:15:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgcjV-0001Jw-0V for nemo@ietf.org; Thu, 18 May 2006 03:15:41 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgcjS-0003Rl-Mk for nemo@ietf.org; Thu, 18 May 2006 03:15:40 -0400 Received: from stl-av-01.boeing.com ([192.76.190.6]) by slb-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id AAA01261; Thu, 18 May 2006 00:15:24 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id k4I7FQG16609; Thu, 18 May 2006 02:15:26 -0500 (CDT) Received: from XCH-NW-8V1.nw.nos.boeing.com ([130.247.55.69]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 00:15:24 -0700 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 Subject: RE: [nemo] Rewording of RO work in the charter Date: Thu, 18 May 2006 00:15:24 -0700 Message-ID: <0D090F1E0F5536449C7E6527AFFA280A21C0FB@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: <5916B65B-F318-429B-9561-04E9D28EF73E@kniveton.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Rewording of RO work in the charter Thread-Index: AcZ4ZFxjrUhzNpFDROmzsoAQiPA4nwB5cT9w From: "Davis, Terry L" To: "T.J. Kniveton" , "ivancic" X-OriginalArrivalTime: 18 May 2006 07:15:24.0768 (UTC) FILETIME=[D5143E00:01C67A4A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org TJ I have received the backing of the Arinc Air Data Networking committee (an aviation standards organization) to work on this. I expect to have a rough draft of an informational RFC covering aviation network mobility requirements for Montreal. Take care Terry > -----Original Message----- > From: T.J. Kniveton [mailto:tj@kniveton.com] > Sent: Monday, May 15, 2006 10:47 AM > To: Davis, Terry L > Cc: ml-nemo WG > Subject: Re: [nemo] Rewording of RO work in the charter >=20 > On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote: >=20 > > T.J. > > > > You'll probably wish that you hadn't asked for this... > > > > These would be our ideal mobility solution. I realize that meeting > > all > > of these is probably an extreme stretch. > > > > Take care > > Terry >=20 > Terry, >=20 > I second the request to put your list of items into a draft. It will > be helpful to have a concrete list of deployment requirements to > refer to. While the WG can't necessarily solve all of the problems > for one specific deployment, an informational document listing them > can be useful for guidance when making engineering design decisions. >=20 > Would you be willing to do that? Perhaps others in the WG can help > with maintaining the document / editing if needed. >=20 > TJ >=20 From nemo-bounces@ietf.org Thu May 18 06:57:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FggBf-0001PU-3a; Thu, 18 May 2006 06:56:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FggBd-0001PP-JJ for nemo@ietf.org; Thu, 18 May 2006 06:56:57 -0400 Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FggBc-0007dy-7Q for nemo@ietf.org; Thu, 18 May 2006 06:56:57 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id EF66FEC83E; Thu, 18 May 2006 19:56:41 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (neutrino.hsc.kddilabs.jp [2001:200:601:200::60]) by mandala.kddilabs.jp (Postfix) with ESMTP id B4FC5EC833; Thu, 18 May 2006 19:56:41 +0900 (JST) Received: from [IPv6:2001:200:601:200:d8e4:c4f5:7d13:3394] (unknown [IPv6:2001:200:601:200:d8e4:c4f5:7d13:3394]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id F39552E02E; Thu, 18 May 2006 19:48:59 +0900 (JST) Message-ID: <446C5297.3080409@kddilabs.jp> Date: Thu, 18 May 2006 19:55:19 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Vijay Devarapalli Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF0028C4E9F@NAEX06.na.qualcomm.com> <20060516165709.61828ceb.thierry.ernst@inria.fr> <4469EE31.6060908@motorola.com> <20060517104337.351ef9a1.thierry.ernst@inria.fr> <446B6CC0.4020301@azairenet.com> In-Reply-To: <446B6CC0.4020301@azairenet.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On 2006/05/18 3:34, Vijay Devarapalli wrote: > Thierry Ernst wrote: > >> Discussion is fine, but IMHO agreeing and sending a new charter to the >> IESG is too early at this point of time since there are divergent point >> of views on what we should do or not. I would rather see this really >> happening for next-next IETF (November). In the meantime, we can discuss >> the deployment requirements (see the other thread) so that we really >> know what is needed. > > I don't think it is a good idea to put off re-chartering > for this long. you can infact re-charter once more in > November if you want once we have a clearer picture of > what solutions are needed. working on the requirements > could be part of the new charter and we can send the > charter to the IESG right away. we shouldn't let other > items proposed items in the charter suffer because we > want to gather "deployment requirements". I agree. I think we could recharter now with work on the requirements, and leave other work on solutions for later rechartering. watari From nemo-bounces@ietf.org Thu May 18 07:04:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FggIU-0003Gd-Ar; Thu, 18 May 2006 07:04:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FggIT-0003GY-Qf for nemo@ietf.org; Thu, 18 May 2006 07:04:01 -0400 Received: from yui.nc.u-tokyo.ac.jp ([130.69.251.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FggIS-0008TF-V1 for nemo@ietf.org; Thu, 18 May 2006 07:04:01 -0400 Received: from [203.178.143.221] (dhcp-143-221.sfc.wide.ad.jp [203.178.143.221]) (authenticated bits=0) by yui.nc.u-tokyo.ac.jp (8.12.10/8.12.3/Debian-6.4) with ESMTP id k4IB3wUl028357; Thu, 18 May 2006 20:03:58 +0900 In-Reply-To: <20060517103939.37ca1203.thierry.ernst@inria.fr> References: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> <5916B65B-F318-429B-9561-04E9D28EF73E@kniveton.com> <20060516110101.5124f6cd.thierry.ernst@inria.fr> <234519ed78b2bf91be22e01ed3d1f538@it.uc3m.es> <20060516124606.6deac871.thierry.ernst@inria.fr> <74f86f393d8f38fffec68a9a079d6497@it.uc3m.es> <20060516144501.412c4270.thierry.ernst@inria.fr> <20060517103939.37ca1203.thierry.ernst@inria.fr> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <8C7220B9-7229-43D3-B8FD-7BCC10599BAB@sfc.wide.ad.jp> Content-Transfer-Encoding: quoted-printable From: Ryuji Wakikawa Subject: Re: [nemo] Deployment Requirements Date: Thu, 18 May 2006 20:03:37 +0900 To: Thierry Ernst X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 453b1bfcf0292bffe4cab90ba115f503 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Thierry i think the requirements from vehicle industry are summarized by ISO. Each vehicle company has slightly different requirements, but ISO =20 tried to define a common network architecture for vehicles. There was a presentation about ISO activity at IETFXX (forgot which =20 IETF). We can point to the ISO document if there are. It maybe time to come close between NEMO WG and ISO. regards, ryuji On 2006/05/17, at 17:39, Thierry Ernst wrote: > > Hi, > > We don't necessarily need a draft to gather the requirements (though a > draft is an easiest way to have a document to refer to when debating). > > I'm happy to initiate a document for the vehicular industry though I'm > not sure I will have all the necessary time in the next few weeks. =20 > But I > need help from other people already involved with the car industry and > related vendors. > > Actaully, I think gathering the deployment requirements is a necessary > step before rechartering the WG. > > Thierry. > >>>>> Well, do you intend to mean that we should write a deployment >>>>> requirements draft for the aviation industry specifically, in =20 >>>>> which >>>>> case >>>>> we would do the same for the vehicular industry, and for each =20 >>>>> other >>>>> existing use cases ? >>>>> >>>> >>>> well, i am not sure about the vehicular technology because i don't >>>> know if they have specific requirements. >>> >>> They do, though they don't speak up yet, because (unfortunately) =20 >>> IETF >>> is >>> not an organization where they used to be involved. But they (or the >>> vendors related to the vehicular industry and the standardization >>> bodies >>> such as ISO and ETSI) will show up when they understand it is =20 >>> important >>> for them to be involved in the debate. >>> >> >> good i am all for working on other cases if there is interest >> >> (FWIW my point about working in aviation and not in other use =20 >> cases was >> merely because there was no feedback on those, not because i have any >> kind of problem in working in other cases) >> >>> Would be interesting to get some input from the Japanese folks who I >>> know are monitoring this ML. I'm not speaking only about the =20 >>> people at >>> Keio University who are academic though who are involved with these >>> people, but the people representing the companies who are in this >>> business. >>> >>> Come on folks, this is the right timing to discuss the deployment >>> requirements for the vehicular industry ! >>> >>>> but following the emails that have been exchanged lately in this =20= >>>> ml, >>>> it is my opinion that the aviation case have quite special >>>> requirements and that they need customized solutions for thier >>>> problems that have their own set of deployment issues. >>> >>> I second this. But the vehicular industry is IMHO more important =20 >>> as it >>> would involved tens of vendors, with possibly divergent deployment >>> requirements. >>> >> >> good, let's write those down also and see what is the common >> requiremetns for all the relevant use cases >> >> If the common part is large, we should defineltly include them in the >> common requiremetns draft that we already have. If the common part is >> small and there are a lot of diverging requirements then we should go >> for different drafts i guess >> >> but i guess that the first part is to get individual submissions from >> each of the use cases that people are interested in working on >> >> >> >>>> I mean consider that they are moving globally quite rapidly, =20 >>>> they have >>>> >>>> wordlwide infrastruture, they need high reliability, and so on, =20= >>>> which >>>> >>>> makes their case somehow different from the case of nemos =20 >>>> deployed in >>>> buses cars and so on (or at least it seems so to me) >>> >>> Well, cases and thus requirements are different. RFC 3963 may not >>> always >>> apply, but even though, the security, authentication and multihoming >>> considerations are different. >>> >>>> that is why i think that the general requirements and in particular >>>> the deployment requirements for a solution to this particular =20 >>>> problem >>>> need to be fleshed out >>> >>> Yes, but what is the best procedure ? Independent draft, one for =20 >>> each >>> use case, or shall we came up straight with common requirements, in >>> which case I would say draft-ietf-nemo-requirements is the best =20 >>> place >>> to >>> gather these deployment scenarios ? >>> >> >> see my suggestion above... i guess that in order to answer this we >> should first figure out what is the common requiremetns for all the >> relevant use cases and then we can decide... >> >> regards, marcelo >> >> >>>>> If yes, then I guess it would rather be individual submissions >>>> >>>> yes i think Terry initial list could be a starting point for this >>>> >>>>> that >>>>> could be used as input for determining a common list of deployment >>>>> requirements. >>>>> >>>> >>>> well depending on whether this requirements fit into the general >>>> requirements, this may be ok.... but i think that they are =20 >>>> likely to >>>> be quite differetn from the general case >>> >>> This may not be an issue. The draft could be explicit that these are >>> requirements for that specific use cases where we get some input. >>> >>> Thierry. >>> >>>>> >>>>>>> [I changed the subject line] >>>>>>> >>>>>>> Speaking about "deployment requirements", I would propose to =20 >>>>>>> add a >>>>>>> section in draft-ietf-nemo-requirements (actually, I intended to >>>>>>> extend >>>>>>> that draft since the beginning ;-) rather of editing a separate >>>>>>> document. >>>>>>> >>>>>>> Would that make sense to everyone ? >>>>>>> >>>>>> >>>>>> i think that there are some general deployment requirements that >>>>> could> fit in there >>>>>> >>>>>> however, perhaps the case of aviation may have quite specific >>>>>> requirements of their own that may not apply in the general >>>>> case.... i> mean not all of us have worldwide sites and a nemo =20 >>>>> moving >>>>> around> several of them in a single day :-) >>>>>> >>>>>> Regards, marcelo >>>>>> >>>>>> >>>>>>> Thierry. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, 16 May 2006 09:19:30 +0300 >>>>>>> marcelo bagnulo braun wrote: >>>>>>> >>>>>>>> >>>>>>>> El 15/05/2006, a las 20:47, T.J.Kniveton escribi=EF=BF=BD: >>>>>>>> >>>>>>>>> On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote: >>>>>>>>> >>>>>>>>>> T.J. >>>>>>>>>> >>>>>>>>>> You'll probably wish that you hadn't asked for this... >>>>>>>>>> >>>>>>>>>> These would be our ideal mobility solution. I realize that >>>>>>>>>> meeting >>>>>>>>>> all >>>>>>>>>> of these is probably an extreme stretch. >>>>>>>>>> >>>>>>>>>> Take care >>>>>>>>>> Terry >>>>>>>>> >>>>>>>>> Terry, >>>>>>>>> >>>>>>>>> I second the request to put your list of items into a =20 >>>>>>>>> draft. It >>>>>>>>> will >>>>>>>>> be helpful to have a concrete list of deployment =20 >>>>>>>>> requirements to >>>>>>>>> refer >>>>>>>>> to. While the WG can't necessarily solve all of the =20 >>>>>>>>> problems for >>>>> >>>>>>>>> one >>>>>>>>> specific deployment, an informational document listing them =20= >>>>>>>>> can >>>>> be>>>> useful for guidance when making engineering design =20 >>>>> decisions. >>>>>>>>> >>>>>>>>> Would you be willing to do that? Perhaps others in the WG can >>>>> help>>>> with maintaining the document / editing if needed. >>>>>>>>> >>>>>>>> >>>>>>>> i am willing to help Terry on this in case it is needed... >>>>>>>> >>>>>>>> regards, marcelo >>>>>>>> >>>>>>>> >>>>>>>>> TJ >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> --=20 >>>>>>> Thierry ERNST, PhD >>>>>>> INRIA Rocquencourt Projet IMARA >>>>>>> +33 1 39 63 59 30 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> --=20 >>>>> Thierry ERNST, PhD >>>>> INRIA Rocquencourt Projet IMARA >>>>> +33 1 39 63 59 30 >>>>> >>>> >>>> >>>> >>> >>> >>> --=20 >>> Thierry ERNST, PhD >>> INRIA Rocquencourt Projet IMARA >>> +33 1 39 63 59 30 >>> >>> >> >> >> > > > --=20 > Thierry ERNST, PhD > INRIA Rocquencourt Projet IMARA > +33 1 39 63 59 30 > From nemo-bounces@ietf.org Thu May 18 07:19:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FggXA-0000CF-Ix; Thu, 18 May 2006 07:19:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FggX8-0000CA-Pf for nemo@ietf.org; Thu, 18 May 2006 07:19:10 -0400 Received: from yui.nc.u-tokyo.ac.jp ([130.69.251.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FggX7-0001Z9-6u for nemo@ietf.org; Thu, 18 May 2006 07:19:10 -0400 Received: from [203.178.143.221] (dhcp-143-221.sfc.wide.ad.jp [203.178.143.221]) (authenticated bits=0) by yui.nc.u-tokyo.ac.jp (8.12.10/8.12.3/Debian-6.4) with ESMTP id k4IBJ4Ul030262; Thu, 18 May 2006 20:19:04 +0900 In-Reply-To: <446B6CC0.4020301@azairenet.com> References: <1487A357FD2ED544B8AD29E528FF9DF0028C4E9F@NAEX06.na.qualcomm.com> <20060516165709.61828ceb.thierry.ernst@inria.fr> <4469EE31.6060908@motorola.com> <20060517104337.351ef9a1.thierry.ernst@inria.fr> <446B6CC0.4020301@azairenet.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Date: Thu, 18 May 2006 20:18:43 +0900 To: Vijay Devarapalli X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I agree, too. We should proceed this re-charter right away. I have a question on IPv4 only work. Are there any ID for FA support and prefix allocation? I only saw the discussion whether we need these or not, but not requirements, solutions, i.e. technical stuff. IPv4 folks can work on this in NEMO WG and chairs and WG can decide whether we really need this specification as RFC in this WG, later. If there are only a few arguments on this IPv4 related stuff, maybe these items should be discussed in MIP4 or IPv4-NEMO WG. regards, ryuji On 2006/05/18, at 3:34, Vijay Devarapalli wrote: > Thierry Ernst wrote: > >> Discussion is fine, but IMHO agreeing and sending a new charter to >> the >> IESG is too early at this point of time since there are divergent >> point >> of views on what we should do or not. I would rather see this really >> happening for next-next IETF (November). In the meantime, we can >> discuss >> the deployment requirements (see the other thread) so that we really >> know what is needed. > > I don't think it is a good idea to put off re-chartering > for this long. you can infact re-charter once more in > November if you want once we have a clearer picture of > what solutions are needed. working on the requirements > could be part of the new charter and we can send the > charter to the IESG right away. we shouldn't let other > items proposed items in the charter suffer because we > want to gather "deployment requirements". > > Vijay > From nemo-bounces@ietf.org Thu May 18 07:22:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FggaP-0000ix-G4; Thu, 18 May 2006 07:22:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FggaO-0000is-W8 for nemo@ietf.org; Thu, 18 May 2006 07:22:32 -0400 Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FggaO-0001xr-CF for nemo@ietf.org; Thu, 18 May 2006 07:22:32 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 06B78EC841; Thu, 18 May 2006 20:22:31 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (neutrino.hsc.kddilabs.jp [2001:200:601:200::60]) by mandala.kddilabs.jp (Postfix) with ESMTP id 5D5B6EC83F; Thu, 18 May 2006 20:22:30 +0900 (JST) Received: from [IPv6:2001:200:601:200:d8e4:c4f5:7d13:3394] (unknown [IPv6:2001:200:601:200:d8e4:c4f5:7d13:3394]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id 832992E02E; Thu, 18 May 2006 20:14:48 +0900 (JST) Message-ID: <446C58A4.6090504@kddilabs.jp> Date: Thu, 18 May 2006 20:21:08 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF00294EAAF@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF00294EAAF@NAEX06.na.qualcomm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: nemo@ietf.org, Thierry Ernst , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On 2006/05/17 3:52, Tsirtsis, George wrote: >>>> So, my proposition would be to postpone the new charter. >>>> >>> GT> I disagree. I have followed this discussion for the last several >>> weeks and the WG has been spending its time debating what it will do > in >>> the future while there has been minimal debate on anything else. A >>> handful of us will get the NEMOv4 and its required extensions done > in >>> minimal time with minimal effect on the WG. I just fail to > understand >>> why you want to prevent willing WG members from doing work that is >>> clearly needed. >> the new proposed charter has too many items already for >> NEMOv6. many folks want to work on this. you should >> recognized that. I didn't see enough support for adding >> NEMOv4-only items to the charter. >> > > GT2> What is enough? This is not a system where we need to count votes > and find the majority by even a single vote. I know that they are > slightly less people actively supporting this work than people not > supporting this work. So, what? Most people on the mailing list do not > actually care and I bet they are annoyed by this pointless, never ending > discussion. Then maybe this isn't the right place for this work, or maybe now is not the right time for it. The voices on the list is important for the WG, and not the read-only-members. watari > George > >> Vijay >> >>> George >>> >>>> Thierry. >>>> >>>> On Tue, 16 May 2006 07:40:58 -0700 >>>> "Tsirtsis, George" wrote: >>>> >>>>> TJ, >>>>> >>>>> Since you agree IPv4-only work should be allowed, could you add a >>>>> sentence to indicate that the WG will work on FA support and > dynamic >>>>> prefix allocation extensions to the NEMOv4 base solution? I will > be >>>>> submitting a draft about these issues before the next meeting. >>>>> >>>>> Thanks >>>>> George >>>>> >>>>>> -----Original Message----- >>>>>> From: T.J. Kniveton [mailto:tj@kniveton.com] >>>>>> Sent: Monday, May 15, 2006 1:05 PM >>>>>> To: Thierry Ernst >>>>>> Cc: nemo@ietf.org >>>>>> Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >>>>>> >>>>>> >>>>>> On May 4, 2006, at 7:16 AM, Thierry Ernst wrote: >>>>>> >>>>>>> I have a subtle understanding of what the message should be, and >>> it >>>>> is >>>>>>> valid in all organizations: been clear, not confusing, and well >>>>>>> documented. We cannot develop IPv4 and IPv6 protocols in the >>> same >>>>>>> group >>>>>>> (unless, as I said, we are working on interoperability issues). >>>>>> I would like to add one comment to this discussion. It seems >>>>>> appropriate to make a solution for IPv4-only networks, which >>>>>> thankfully is now underway. At some point it may make sense to >>> form a >>>>>> separate working group for IPv4-only issues, but it's probably a >>> bit >>>>>> too early to do that until the work is more mature, and the >>> industry >>>>>> interest level and engineering participation within the IETF can >>> be >>>>>> gauged. >>>>>> >>>>>> For IPv4-IPv6 mixed networks, it makes sense to me that we >>> continue >>>>>> to work on that issue here in this group (and in the Mobile IPv6 >>>>>> working group). >>>>>> >>>>>> I understand some people have no interest in working on IPv4-only >>>>>> protocols, and likewise some people in NEMO probably have little >>> or >>>>>> no interest in IPv6-only protocols. But in a mixed network, we >>> should >>>>>> have something to say about how NEMO will work. After all, that >>>>>> scenario is a growth industry. >>>>>> >>>>>> TJ >>>>>> >>>>> >>>> -- >>>> Thierry ERNST, PhD >>>> INRIA Rocquencourt Projet IMARA >>>> +33 1 39 63 59 30 >>>> >>> > > > From nemo-bounces@ietf.org Thu May 18 07:49:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgh0G-0002s3-U7; Thu, 18 May 2006 07:49:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgh0G-0002ry-4U for nemo@ietf.org; Thu, 18 May 2006 07:49:16 -0400 Received: from motgate2.mot.com ([144.189.100.101]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgh0D-00051q-Ot for nemo@ietf.org; Thu, 18 May 2006 07:49:16 -0400 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motgate2) with ESMTP id k4IBn46h020898; Thu, 18 May 2006 04:49:09 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id k4IBn283027872; Thu, 18 May 2006 06:49:03 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 3BA1D865980; Thu, 18 May 2006 13:49:02 +0200 (CEST) Message-ID: <446C5F2E.50307@motorola.com> Date: Thu, 18 May 2006 13:49:02 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Masafumi Watari Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF0028C4E9F@NAEX06.na.qualcomm.com> <20060516165709.61828ceb.thierry.ernst@inria.fr> <4469EE31.6060908@motorola.com> <20060517104337.351ef9a1.thierry.ernst@inria.fr> <446B6CC0.4020301@azairenet.com> <446C5297.3080409@kddilabs.jp> In-Reply-To: <446C5297.3080409@kddilabs.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: nemo@ietf.org, Thierry Ernst , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Masafumi Watari wrote: > On 2006/05/18 3:34, Vijay Devarapalli wrote: >> Thierry Ernst wrote: >> >>> Discussion is fine, but IMHO agreeing and sending a new charter >>> to the IESG is too early at this point of time since there are >>> divergent point of views on what we should do or not. I would >>> rather see this really happening for next-next IETF (November). >>> In the meantime, we can discuss the deployment requirements (see >>> the other thread) so that we really know what is needed. >> >> I don't think it is a good idea to put off re-chartering for this >> long. you can infact re-charter once more in November if you want >> once we have a clearer picture of what solutions are needed. >> working on the requirements could be part of the new charter and we >> can send the charter to the IESG right away. we shouldn't let >> other items proposed items in the charter suffer because we want >> to gather "deployment requirements". > > I agree. I think we could recharter now with work on the > requirements, and leave other work on solutions for later > rechartering. One of the customers for vehicular-like industry I work for cares a lot about IPv4. It is for vehicles used in emergency situations. A little bit like the aviation industry, this is equipment deployed, tried, tested and proved for years, in sun rain fire. Any modification to it is happening very slowly. IPv6 _is_ in the roadmaps but for now just use IPv4 modifications, and not very many :-) It's much easier to incrementally upgrade such a network from IPv4 to NEMOv4 than is to upgrade every IP-addressable entity to IPv6 and then to NEMOv6. Maybe this IPv4 aspect from vehicular industry could be taken into account by the deployment requirements. Other vehicular industry one sees in many places today is the rental limousines offering wifi in the car. It's v4. Trains offering wifi to passengers. It's v4. Even Columbia in space used Mobile IPv4, not v6. That said, I am far from opposing IPv6 work on network mobility, I strongly support it too. Alex From nemo-bounces@ietf.org Thu May 18 07:51:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgh2R-0003rp-6y; Thu, 18 May 2006 07:51:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgh2P-0003rk-Uh for nemo@ietf.org; Thu, 18 May 2006 07:51:29 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgh2N-0005F2-MH for nemo@ietf.org; Thu, 18 May 2006 07:51:29 -0400 Received: from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k4IBpNaJ005189; Thu, 18 May 2006 04:51:23 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr01.mot.com (8.13.5/8.13.0) with ESMTP id k4IBpMWJ026560; Thu, 18 May 2006 06:51:23 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 9A8BA865980; Thu, 18 May 2006 13:51:22 +0200 (CEST) Message-ID: <446C5FBA.4070401@motorola.com> Date: Thu, 18 May 2006 13:51:22 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Thierry Ernst Subject: Re: [nemo] Deployment Requirements References: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> <5916B65B-F318-429B-9561-04E9D28EF73E@kniveton.com> <20060516110101.5124f6cd.thierry.ernst@inria.fr> <234519ed78b2bf91be22e01ed3d1f538@it.uc3m.es> <20060516124606.6deac871.thierry.ernst@inria.fr> <74f86f393d8f38fffec68a9a079d6497@it.uc3m.es> <20060516144501.412c4270.thierry.ernst@inria.fr> <20060517103939.37ca1203.thierry.ernst@inria.fr> In-Reply-To: <20060517103939.37ca1203.thierry.ernst@inria.fr> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Thierry Ernst wrote: > Hi, > > We don't necessarily need a draft to gather the requirements (though > a draft is an easiest way to have a document to refer to when > debating). > > I'm happy to initiate a document for the vehicular industry though > I'm not sure I will have all the necessary time in the next few > weeks. But I need help from other people already involved with the > car industry and related vendors. I can provide text about the IPv4 need in a particular industry where vehicles on four or more wheels are used. Would this be considered? Alex From nemo-bounces@ietf.org Thu May 18 08:14:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FghOG-00046b-JG; Thu, 18 May 2006 08:14:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FghOE-00046W-U1 for nemo@ietf.org; Thu, 18 May 2006 08:14:02 -0400 Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FghO8-0006MY-MY for nemo@ietf.org; Thu, 18 May 2006 08:14:02 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id AED16EC82F; Thu, 18 May 2006 21:13:52 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (neutrino.hsc.kddilabs.jp [2001:200:601:200::60]) by mandala.kddilabs.jp (Postfix) with ESMTP id 5D794EC83F; Thu, 18 May 2006 21:13:52 +0900 (JST) Received: from [IPv6:2001:200:601:200:d8e4:c4f5:7d13:3394] (unknown [IPv6:2001:200:601:200:d8e4:c4f5:7d13:3394]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id 583AE2E02E; Thu, 18 May 2006 21:06:10 +0900 (JST) Message-ID: <446C64AD.80900@kddilabs.jp> Date: Thu, 18 May 2006 21:12:29 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF0028C4E9F@NAEX06.na.qualcomm.com> <20060516165709.61828ceb.thierry.ernst@inria.fr> <4469EE31.6060908@motorola.com> <20060517104337.351ef9a1.thierry.ernst@inria.fr> <446B6CC0.4020301@azairenet.com> <446C5297.3080409@kddilabs.jp> <446C5F2E.50307@motorola.com> In-Reply-To: <446C5F2E.50307@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: nemo@ietf.org, Thierry Ernst , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On 2006/05/18 20:49, Alexandru Petrescu wrote: > Masafumi Watari wrote: >> On 2006/05/18 3:34, Vijay Devarapalli wrote: >>> Thierry Ernst wrote: >>> >>>> Discussion is fine, but IMHO agreeing and sending a new charter to >>>> the IESG is too early at this point of time since there are >>>> divergent point of views on what we should do or not. I would >>>> rather see this really happening for next-next IETF (November). In >>>> the meantime, we can discuss the deployment requirements (see the >>>> other thread) so that we really know what is needed. >>> >>> I don't think it is a good idea to put off re-chartering for this >>> long. you can infact re-charter once more in November if you want >>> once we have a clearer picture of what solutions are needed. working >>> on the requirements could be part of the new charter and we >>> can send the charter to the IESG right away. we shouldn't let other >>> items proposed items in the charter suffer because we want to gather >>> "deployment requirements". >> >> I agree. I think we could recharter now with work on the >> requirements, and leave other work on solutions for later rechartering. > > One of the customers for vehicular-like industry I work for cares a lot > about IPv4. It is for vehicles used in emergency situations. A little > bit like the aviation industry, this is equipment deployed, tried, > tested and proved for years, in sun rain fire. Any modification to it > is happening very slowly. IPv6 _is_ in the roadmaps but for now just > use IPv4 modifications, and not very many :-) It's much easier to > incrementally upgrade such a network from IPv4 to NEMOv4 than is to > upgrade every IP-addressable entity to IPv6 and then to NEMOv6. > > Maybe this IPv4 aspect from vehicular industry could be taken into > account by the deployment requirements. So you are speaking for requirements on deploying NEMOv4, right? I think we need to be clear when we say "deployment requirements." > Other vehicular industry one sees in many places today is the rental > limousines offering wifi in the car. It's v4. Trains offering wifi to > passengers. It's v4. Even Columbia in space used Mobile IPv4, not v6. > > That said, I am far from opposing IPv6 work on network mobility, I > strongly support it too. You mean opposing IPv4? I'm confused :( watari From nemo-bounces@ietf.org Thu May 18 08:28:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fghc1-0007wc-6q; Thu, 18 May 2006 08:28:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fghc0-0007wX-EA for nemo@ietf.org; Thu, 18 May 2006 08:28:16 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fghc0-00075j-5I for nemo@ietf.org; Thu, 18 May 2006 08:28:16 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k4ICRLYM013984; Thu, 18 May 2006 05:27:26 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k4ICRKu7021914; Thu, 18 May 2006 07:27:20 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id C54D0865980; Thu, 18 May 2006 14:27:19 +0200 (CEST) Message-ID: <446C6827.8090004@motorola.com> Date: Thu, 18 May 2006 14:27:19 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Masafumi Watari Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF0028C4E9F@NAEX06.na.qualcomm.com> <20060516165709.61828ceb.thierry.ernst@inria.fr> <4469EE31.6060908@motorola.com> <20060517104337.351ef9a1.thierry.ernst@inria.fr> <446B6CC0.4020301@azairenet.com> <446C5297.3080409@kddilabs.jp> <446C5F2E.50307@motorola.com> <446C64AD.80900@kddilabs.jp> In-Reply-To: <446C64AD.80900@kddilabs.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: nemo@ietf.org, Thierry Ernst , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Masafumi Watari wrote: > On 2006/05/18 20:49, Alexandru Petrescu wrote: >> Masafumi Watari wrote: >>> On 2006/05/18 3:34, Vijay Devarapalli wrote: >>>> Thierry Ernst wrote: >>>> >>>>> Discussion is fine, but IMHO agreeing and sending a new >>>>> charter to the IESG is too early at this point of time since >>>>> there are divergent point of views on what we should do or >>>>> not. I would rather see this really happening for next-next >>>>> IETF (November). In the meantime, we can discuss the >>>>> deployment requirements (see the other thread) so that we >>>>> really know what is needed. >>>> >>>> I don't think it is a good idea to put off re-chartering for >>>> this long. you can infact re-charter once more in November if >>>> you want once we have a clearer picture of what solutions are >>>> needed. working on the requirements could be part of the new >>>> charter and we can send the charter to the IESG right away. we >>>> shouldn't let other items proposed items in the charter >>>> suffer because we want to gather "deployment requirements". >>> >>> I agree. I think we could recharter now with work on the >>> requirements, and leave other work on solutions for later >>> rechartering. >> >> One of the customers for vehicular-like industry I work for cares a >> lot about IPv4. It is for vehicles used in emergency situations. >> A little bit like the aviation industry, this is equipment >> deployed, tried, tested and proved for years, in sun rain fire. Any >> modification to it is happening very slowly. IPv6 _is_ in the >> roadmaps but for now just use IPv4 modifications, and not very many >> :-) It's much easier to incrementally upgrade such a network from >> IPv4 to NEMOv4 than is to upgrade every IP-addressable entity to >> IPv6 and then to NEMOv6. >> >> Maybe this IPv4 aspect from vehicular industry could be taken into >> account by the deployment requirements. > > So you are speaking for requirements on deploying NEMOv4, right? I > think we need to be clear when we say "deployment requirements." YEs, I agree we should be clear on what "deployment requirements" means. I think we can't write a document requiring deployments to, for example, use IPv6 and DS-MIPv6 and not IPv4. IETF documents are not requirements to hand down to deployers. There may be requirements (or better said "goals") for a protocol design to achieve, but not requiring people to deploy something. What do you think this "deployment requirements" should be? >> Other vehicular industry one sees in many places today is the >> rental limousines offering wifi in the car. It's v4. Trains >> offering wifi to passengers. It's v4. Even Columbia in space used >> Mobile IPv4, not v6. >> >> That said, I am far from opposing IPv6 work on network mobility, I >> strongly support it too. > > You mean opposing IPv4? I'm confused :( I support both IPv4 _and_ IPv6 work. I support basic NEMOv6, basic NEMOv4 and DS-MIPv6 work. Pushing for IPv4 does not mean I oppose work on IPv6. How about you? I am confused by the assumption that supporting IPv4 work is interpreted as rejecting IPv6 work. Look at DNS - it's v4 and v6. Can be queried in v4 for v6 results and in v6 for v4 results. Can run as v6-exclusively or v4-exclusively. Alex From nemo-bounces@ietf.org Thu May 18 09:05:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgiBk-0004pt-N7; Thu, 18 May 2006 09:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgiBj-0004po-Jc for nemo@ietf.org; Thu, 18 May 2006 09:05:11 -0400 Received: from mandala.kddilabs.jp ([192.26.91.6]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgiBi-00008b-Ue for nemo@ietf.org; Thu, 18 May 2006 09:05:11 -0400 Received: from localhost (localhost [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 57C67EC841; Thu, 18 May 2006 22:05:06 +0900 (JST) Received: from neutrino.hsc.kddilabs.jp (neutrino.hsc.kddilabs.jp [2001:200:601:200::60]) by mandala.kddilabs.jp (Postfix) with ESMTP id B57D0EC83F; Thu, 18 May 2006 22:05:05 +0900 (JST) Received: from [IPv6:2001:200:601:200:d8e4:c4f5:7d13:3394] (unknown [IPv6:2001:200:601:200:d8e4:c4f5:7d13:3394]) by neutrino.hsc.kddilabs.jp (Postfix) with ESMTP id 841A52E02E; Thu, 18 May 2006 21:57:23 +0900 (JST) Message-ID: <446C70AF.9010103@kddilabs.jp> Date: Thu, 18 May 2006 22:03:43 +0900 From: Masafumi Watari Organization: KDDI R&D Laboratories Inc. User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF0028C4E9F@NAEX06.na.qualcomm.com> <20060516165709.61828ceb.thierry.ernst@inria.fr> <4469EE31.6060908@motorola.com> <20060517104337.351ef9a1.thierry.ernst@inria.fr> <446B6CC0.4020301@azairenet.com> <446C5297.3080409@kddilabs.jp> <446C5F2E.50307@motorola.com> <446C64AD.80900@kddilabs.jp> <446C6827.8090004@motorola.com> In-Reply-To: <446C6827.8090004@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: nemo@ietf.org, Thierry Ernst , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On 2006/05/18 21:27, Alexandru Petrescu wrote: >>>>>> Discussion is fine, but IMHO agreeing and sending a new charter to >>>>>> the IESG is too early at this point of time since >>>>>> there are divergent point of views on what we should do or not. >>>>>> I would rather see this really happening for next-next >>>>>> IETF (November). In the meantime, we can discuss the deployment >>>>>> requirements (see the other thread) so that we really know what is >>>>>> needed. >>>>> >>>>> I don't think it is a good idea to put off re-chartering for this >>>>> long. you can infact re-charter once more in November if you want >>>>> once we have a clearer picture of what solutions are needed. >>>>> working on the requirements could be part of the new charter and we >>>>> can send the charter to the IESG right away. we >>>>> shouldn't let other items proposed items in the charter >>>>> suffer because we want to gather "deployment requirements". >>>> >>>> I agree. I think we could recharter now with work on the >>>> requirements, and leave other work on solutions for later rechartering. >>> >>> One of the customers for vehicular-like industry I work for cares a >>> lot about IPv4. It is for vehicles used in emergency situations. >>> A little bit like the aviation industry, this is equipment deployed, >>> tried, tested and proved for years, in sun rain fire. Any >>> modification to it is happening very slowly. IPv6 _is_ in the >>> roadmaps but for now just use IPv4 modifications, and not very many >>> :-) It's much easier to incrementally upgrade such a network from >>> IPv4 to NEMOv4 than is to upgrade every IP-addressable entity to >>> IPv6 and then to NEMOv6. >>> >>> Maybe this IPv4 aspect from vehicular industry could be taken into >>> account by the deployment requirements. >> >> So you are speaking for requirements on deploying NEMOv4, right? I >> think we need to be clear when we say "deployment requirements." > > YEs, I agree we should be clear on what "deployment requirements" means. > I think we can't write a document requiring deployments to, for > example, use IPv6 and DS-MIPv6 and not IPv4. IETF documents are not > requirements to hand down to deployers. There may be requirements (or > better said "goals") for a protocol design to achieve, but not requiring > people to deploy something. > > What do you think this "deployment requirements" should be? Alex, that wasn't what I meant, and I think we are on the same rail. If the requirement from the industry is a need for a pure IPv4 NEMO, then sure we could write one. But I don't think that fits the original goal of this WG. >>> Other vehicular industry one sees in many places today is the rental >>> limousines offering wifi in the car. It's v4. Trains offering wifi >>> to passengers. It's v4. Even Columbia in space used >>> Mobile IPv4, not v6. >>> >>> That said, I am far from opposing IPv6 work on network mobility, I >>> strongly support it too. >> >> You mean opposing IPv4? I'm confused :( > > I support both IPv4 _and_ IPv6 work. I support basic NEMOv6, basic > NEMOv4 and DS-MIPv6 work. Pushing for IPv4 does not mean I oppose work > on IPv6. How about you? I support IPv6, but that does not mean I oppose IPv4 either. > I am confused by the assumption that supporting IPv4 work is interpreted > as rejecting IPv6 work. Just to be clear, I didn't mean that. > Look at DNS - it's v4 and v6. Can be queried in v4 for v6 results and > in v6 for v4 results. Can run as v6-exclusively or v4-exclusively. watari From nemo-bounces@ietf.org Thu May 18 09:13:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgiJK-0007SS-ML; Thu, 18 May 2006 09:13:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgiJJ-0007Rh-FX for nemo@ietf.org; Thu, 18 May 2006 09:13:01 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgiJI-0000Rx-R4 for nemo@ietf.org; Thu, 18 May 2006 09:13:01 -0400 Received: from guest-rocq-135223.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k4IDCo1Y012576 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 May 2006 15:12:51 +0200 Date: Thu, 18 May 2006 15:14:03 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Deployment Requirements Message-Id: <20060518151403.6dcb1ab0.thierry.ernst@inria.fr> In-Reply-To: <8C7220B9-7229-43D3-B8FD-7BCC10599BAB@sfc.wide.ad.jp> References: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> <5916B65B-F318-429B-9561-04E9D28EF73E@kniveton.com> <20060516110101.5124f6cd.thierry.ernst@inria.fr> <234519ed78b2bf91be22e01ed3d1f538@it.uc3m.es> <20060516124606.6deac871.thierry.ernst@inria.fr> <74f86f393d8f38fffec68a9a079d6497@it.uc3m.es> <20060516144501.412c4270.thierry.ernst@inria.fr> <20060517103939.37ca1203.thierry.ernst@inria.fr> <8C7220B9-7229-43D3-B8FD-7BCC10599BAB@sfc.wide.ad.jp> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP X-Miltered: at concorde with ID 446C72D2.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by concorde.inria.fr id k4IDCo1Y012576 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f402fbded34a6df606921f56b8bdd8 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Ryuji, Well, this could suffice (and thanks for recalling this presentation "ISO Activities on NEMO BS", which can be found in the archives at http://www3.ietf.org/proceedings/05aug/index.html under the NEMO WG proceedings). However, this would weight more if there were people from the vehicle industry and related business in Europe and Asia (where IPv6 is more favored) expressing their views on this ML right now. ISO TC204 WG16 is surely developing a communication system based on IPv6 and there are a number of related projects in Europe developing a complete architecture around NEMO (RFC 3963). However, most of the folks involved in these groups are following the output of the IETF, but are not taking part in the WG discussions, besides a few people.=20 Thierry. > i think the requirements from vehicle industry are summarized by ISO. > Each vehicle company has slightly different requirements, but ISO =20 > tried to > define a common network architecture for vehicles. > There was a presentation about ISO activity at IETFXX (forgot which =20 > IETF). >=20 > We can point to the ISO document if there are. > It maybe time to come close between NEMO WG and ISO. >=20 > regards, > ryuji >=20 > On 2006/05/17, at 17:39, Thierry Ernst wrote: >=20 > > > > Hi, > > > > We don't necessarily need a draft to gather the requirements (though > > a draft is an easiest way to have a document to refer to when > > debating). > > > > I'm happy to initiate a document for the vehicular industry though > > I'm not sure I will have all the necessary time in the next few > > weeks. But I > > need help from other people already involved with the car industry > > and related vendors. > > > > Actaully, I think gathering the deployment requirements is a > > necessary step before rechartering the WG. > > > > Thierry. > > > >>>>> Well, do you intend to mean that we should write a deployment > >>>>> requirements draft for the aviation industry specifically, in =20 > >>>>> which > >>>>> case > >>>>> we would do the same for the vehicular industry, and for each =20 > >>>>> other > >>>>> existing use cases ? > >>>>> > >>>> > >>>> well, i am not sure about the vehicular technology because i > >don't>>> know if they have specific requirements. > >>> > >>> They do, though they don't speak up yet, because (unfortunately) =20 > >>> IETF > >>> is > >>> not an organization where they used to be involved. But they (or > >the>> vendors related to the vehicular industry and the > >standardization>> bodies > >>> such as ISO and ETSI) will show up when they understand it is =20 > >>> important > >>> for them to be involved in the debate. > >>> > >> > >> good i am all for working on other cases if there is interest > >> > >> (FWIW my point about working in aviation and not in other use =20 > >> cases was > >> merely because there was no feedback on those, not because i have > >any> kind of problem in working in other cases) > >> > >>> Would be interesting to get some input from the Japanese folks who > >I>> know are monitoring this ML. I'm not speaking only about the =20 > >>> people at > >>> Keio University who are academic though who are involved with > >these>> people, but the people representing the companies who are in > >this>> business. > >>> > >>> Come on folks, this is the right timing to discuss the deployment > >>> requirements for the vehicular industry ! > >>> > >>>> but following the emails that have been exchanged lately in this=20 > > > >>>> ml, > >>>> it is my opinion that the aviation case have quite special > >>>> requirements and that they need customized solutions for thier > >>>> problems that have their own set of deployment issues. > >>> > >>> I second this. But the vehicular industry is IMHO more important =20 > >>> as it > >>> would involved tens of vendors, with possibly divergent deployment > >>> requirements. > >>> > >> > >> good, let's write those down also and see what is the common > >> requiremetns for all the relevant use cases > >> > >> If the common part is large, we should defineltly include them in > >the> common requiremetns draft that we already have. If the common > >part is> small and there are a lot of diverging requirements then we > >should go> for different drafts i guess > >> > >> but i guess that the first part is to get individual submissions > >from> each of the use cases that people are interested in working on > >> > >> > >> > >>>> I mean consider that they are moving globally quite rapidly, =20 > >>>> they have > >>>> > >>>> wordlwide infrastruture, they need high reliability, and so on,=20 > > > >>>> which > >>>> > >>>> makes their case somehow different from the case of nemos =20 > >>>> deployed in > >>>> buses cars and so on (or at least it seems so to me) > >>> > >>> Well, cases and thus requirements are different. RFC 3963 may not > >>> always > >>> apply, but even though, the security, authentication and > >multihoming>> considerations are different. > >>> > >>>> that is why i think that the general requirements and in > >particular>>> the deployment requirements for a solution to this > >particular >>> problem > >>>> need to be fleshed out > >>> > >>> Yes, but what is the best procedure ? Independent draft, one for =20 > >>> each > >>> use case, or shall we came up straight with common requirements, > >in>> which case I would say draft-ietf-nemo-requirements is the best=20 > > > >>> place > >>> to > >>> gather these deployment scenarios ? > >>> > >> > >> see my suggestion above... i guess that in order to answer this we > >> should first figure out what is the common requiremetns for all the > >> relevant use cases and then we can decide... > >> > >> regards, marcelo > >> > >> > >>>>> If yes, then I guess it would rather be individual submissions > >>>> > >>>> yes i think Terry initial list could be a starting point for this > >>>> > >>>>> that > >>>>> could be used as input for determining a common list of > >deployment>>>> requirements. > >>>>> > >>>> > >>>> well depending on whether this requirements fit into the general > >>>> requirements, this may be ok.... but i think that they are =20 > >>>> likely to > >>>> be quite differetn from the general case > >>> > >>> This may not be an issue. The draft could be explicit that these > >are>> requirements for that specific use cases where we get some > >input.>> > >>> Thierry. > >>> > >>>>> > >>>>>>> [I changed the subject line] > >>>>>>> > >>>>>>> Speaking about "deployment requirements", I would propose to =20 > >>>>>>> add a > >>>>>>> section in draft-ietf-nemo-requirements (actually, I intended > >to>>>>>> extend > >>>>>>> that draft since the beginning ;-) rather of editing a > >separate>>>>>> document. > >>>>>>> > >>>>>>> Would that make sense to everyone ? > >>>>>>> > >>>>>> > >>>>>> i think that there are some general deployment requirements > >that>>>> could> fit in there > >>>>>> > >>>>>> however, perhaps the case of aviation may have quite specific > >>>>>> requirements of their own that may not apply in the general > >>>>> case.... i> mean not all of us have worldwide sites and a nemo =20 > >>>>> moving > >>>>> around> several of them in a single day :-) > >>>>>> > >>>>>> Regards, marcelo > >>>>>> > >>>>>> > >>>>>>> Thierry. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> On Tue, 16 May 2006 09:19:30 +0300 > >>>>>>> marcelo bagnulo braun wrote: > >>>>>>> > >>>>>>>> > >>>>>>>> El 15/05/2006, a las 20:47, T.J.Kniveton escribi=EF=BF=BD: > >>>>>>>> > >>>>>>>>> On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote: > >>>>>>>>> > >>>>>>>>>> T.J. > >>>>>>>>>> > >>>>>>>>>> You'll probably wish that you hadn't asked for this... > >>>>>>>>>> > >>>>>>>>>> These would be our ideal mobility solution. I realize that > >>>>>>>>>> meeting > >>>>>>>>>> all > >>>>>>>>>> of these is probably an extreme stretch. > >>>>>>>>>> > >>>>>>>>>> Take care > >>>>>>>>>> Terry > >>>>>>>>> > >>>>>>>>> Terry, > >>>>>>>>> > >>>>>>>>> I second the request to put your list of items into a =20 > >>>>>>>>> draft. It > >>>>>>>>> will > >>>>>>>>> be helpful to have a concrete list of deployment =20 > >>>>>>>>> requirements to > >>>>>>>>> refer > >>>>>>>>> to. While the WG can't necessarily solve all of the =20 > >>>>>>>>> problems for > >>>>> > >>>>>>>>> one > >>>>>>>>> specific deployment, an informational document listing them=20 > > > >>>>>>>>> can > >>>>> be>>>> useful for guidance when making engineering design =20 > >>>>> decisions. > >>>>>>>>> > >>>>>>>>> Would you be willing to do that? Perhaps others in the WG > >can>>>> help>>>> with maintaining the document / editing if needed. > >>>>>>>>> > >>>>>>>> > >>>>>>>> i am willing to help Terry on this in case it is needed... > >>>>>>>> > >>>>>>>> regards, marcelo > >>>>>>>> > >>>>>>>> > >>>>>>>>> TJ > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> --=20 > >>>>>>> Thierry ERNST, PhD > >>>>>>> INRIA Rocquencourt Projet IMARA > >>>>>>> +33 1 39 63 59 30 > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> --=20 > >>>>> Thierry ERNST, PhD > >>>>> INRIA Rocquencourt Projet IMARA > >>>>> +33 1 39 63 59 30 > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> --=20 > >>> Thierry ERNST, PhD > >>> INRIA Rocquencourt Projet IMARA > >>> +33 1 39 63 59 30 > >>> > >>> > >> > >> > >> > > > > > > --=20 > > Thierry ERNST, PhD > > INRIA Rocquencourt Projet IMARA > > +33 1 39 63 59 30 > > >=20 >=20 >=20 --=20 Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Thu May 18 09:28:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgiYI-00048F-9F; Thu, 18 May 2006 09:28:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgiYH-00047k-Ba for nemo@ietf.org; Thu, 18 May 2006 09:28:29 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgiM0-0000YC-Bv for nemo@ietf.org; Thu, 18 May 2006 09:15:49 -0400 Received: from guest-rocq-135223.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k4IDFlkh012941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 18 May 2006 15:15:47 +0200 Date: Thu, 18 May 2006 15:17:00 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] Deployment Requirements Message-Id: <20060518151700.0513acfd.thierry.ernst@inria.fr> In-Reply-To: <446C5FBA.4070401@motorola.com> References: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> <5916B65B-F318-429B-9561-04E9D28EF73E@kniveton.com> <20060516110101.5124f6cd.thierry.ernst@inria.fr> <234519ed78b2bf91be22e01ed3d1f538@it.uc3m.es> <20060516124606.6deac871.thierry.ernst@inria.fr> <74f86f393d8f38fffec68a9a079d6497@it.uc3m.es> <20060516144501.412c4270.thierry.ernst@inria.fr> <20060517103939.37ca1203.thierry.ernst@inria.fr> <446C5FBA.4070401@motorola.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 446C7383.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, >From a requirement point of view, yes, it should. Thierry > > We don't necessarily need a draft to gather the requirements (though > > a draft is an easiest way to have a document to refer to when > > debating). > > > > I'm happy to initiate a document for the vehicular industry though > > I'm not sure I will have all the necessary time in the next few > > weeks. But I need help from other people already involved with the > > car industry and related vendors. > > I can provide text about the IPv4 need in a particular industry where > vehicles on four or more wheels are used. Would this be considered? From nemo-bounces@ietf.org Thu May 18 10:43:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgjid-00067T-VB; Thu, 18 May 2006 10:43:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgjic-00067O-5H for nemo@ietf.org; Thu, 18 May 2006 10:43:14 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgjiZ-00065j-PB for nemo@ietf.org; Thu, 18 May 2006 10:43:14 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4IEgvWP001153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 May 2006 07:42:58 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4IEgv7m003436; Thu, 18 May 2006 07:42:57 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 07:42:56 -0700 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 Subject: RE: [nemo] Extensions to NEMOv4 base for the Charter. Date: Thu, 18 May 2006 07:43:00 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0029BCE82@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Extensions to NEMOv4 base for the Charter. Thread-Index: AcZ6bRoNV1QTYytQTo+M11g62Uge4gAHBhJg From: "Tsirtsis, George" To: "Ryuji Wakikawa" , "Vijay Devarapalli" X-OriginalArrivalTime: 18 May 2006 14:42:56.0901 (UTC) FILETIME=[5A329350:01C67A89] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Ryuji, The draft will be available before the deadline for this IETF. Remember that NEMOv4 base protocol is already done in the context of this working group. The new draft just proposes some extensions to it. George > -----Original Message----- > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > Sent: Thursday, May 18, 2006 7:19 AM > To: Vijay Devarapalli > Cc: nemo@ietf.org; Thierry Ernst > Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >=20 > I agree, too. > We should proceed this re-charter right away. >=20 > I have a question on IPv4 only work. > Are there any ID for FA support and prefix allocation? > I only saw the discussion whether we need these or not, but not > requirements, solutions, i.e. technical stuff. > IPv4 folks can work on this in NEMO WG and chairs and WG can decide > whether we really need this specification as RFC in this WG, later. > If there are only a few arguments on this IPv4 related stuff, maybe > these items should be discussed in MIP4 or IPv4-NEMO WG. >=20 > regards, > ryuji >=20 >=20 >=20 > On 2006/05/18, at 3:34, Vijay Devarapalli wrote: >=20 > > Thierry Ernst wrote: > > > >> Discussion is fine, but IMHO agreeing and sending a new charter to > >> the > >> IESG is too early at this point of time since there are divergent > >> point > >> of views on what we should do or not. I would rather see this really > >> happening for next-next IETF (November). In the meantime, we can > >> discuss > >> the deployment requirements (see the other thread) so that we really > >> know what is needed. > > > > I don't think it is a good idea to put off re-chartering > > for this long. you can infact re-charter once more in > > November if you want once we have a clearer picture of > > what solutions are needed. working on the requirements > > could be part of the new charter and we can send the > > charter to the IESG right away. we shouldn't let other > > items proposed items in the charter suffer because we > > want to gather "deployment requirements". > > > > Vijay > > >=20 From nemo-bounces@ietf.org Thu May 18 12:03:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgkyI-0003OX-2K; Thu, 18 May 2006 12:03:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgkyG-0003OS-FS for nemo@ietf.org; Thu, 18 May 2006 12:03:28 -0400 Received: from yui.nc.u-tokyo.ac.jp ([130.69.251.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgkyF-00035K-Si for nemo@ietf.org; Thu, 18 May 2006 12:03:28 -0400 Received: from [203.178.143.221] (dhcp-143-221.sfc.wide.ad.jp [203.178.143.221]) (authenticated bits=0) by yui.nc.u-tokyo.ac.jp (8.12.10/8.12.3/Debian-6.4) with ESMTP id k4IG3JUl028431; Fri, 19 May 2006 01:03:19 +0900 In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0029BCE82@NAEX06.na.qualcomm.com> References: <1487A357FD2ED544B8AD29E528FF9DF0029BCE82@NAEX06.na.qualcomm.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Date: Fri, 19 May 2006 01:02:58 +0900 To: "Tsirtsis, George" X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: nemo@ietf.org, Thierry Ernst , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org George Well, NEMO is an extension to MIP6 :-) We always had enough discussions on how to proceed an extension to some work. I recommend you to publish a draft which has PS and Requirement and maybe Solution. You understand why you need this work because you are working on this, but most of members are unaware of this necessity and work overhead, etc. Since it's obvious that only few member express interests to v4 related topic, it's too early to decide this as NEMO WG topic. However, it does not mean we exclude this work from NEMO WG forever. We can move forward whenever the work becomes ready in terms of discussion and I-D. ryuji On 2006/05/18, at 23:43, Tsirtsis, George wrote: > Ryuji, > > The draft will be available before the deadline for this IETF. > Remember > that NEMOv4 base protocol is already done in the context of this > working > group. The new draft just proposes some extensions to it. > > George > >> -----Original Message----- >> From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] >> Sent: Thursday, May 18, 2006 7:19 AM >> To: Vijay Devarapalli >> Cc: nemo@ietf.org; Thierry Ernst >> Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. >> >> I agree, too. >> We should proceed this re-charter right away. >> >> I have a question on IPv4 only work. >> Are there any ID for FA support and prefix allocation? >> I only saw the discussion whether we need these or not, but not >> requirements, solutions, i.e. technical stuff. >> IPv4 folks can work on this in NEMO WG and chairs and WG can decide >> whether we really need this specification as RFC in this WG, later. >> If there are only a few arguments on this IPv4 related stuff, maybe >> these items should be discussed in MIP4 or IPv4-NEMO WG. >> >> regards, >> ryuji >> >> >> >> On 2006/05/18, at 3:34, Vijay Devarapalli wrote: >> >>> Thierry Ernst wrote: >>> >>>> Discussion is fine, but IMHO agreeing and sending a new charter to >>>> the >>>> IESG is too early at this point of time since there are divergent >>>> point >>>> of views on what we should do or not. I would rather see this > really >>>> happening for next-next IETF (November). In the meantime, we can >>>> discuss >>>> the deployment requirements (see the other thread) so that we > really >>>> know what is needed. >>> >>> I don't think it is a good idea to put off re-chartering >>> for this long. you can infact re-charter once more in >>> November if you want once we have a clearer picture of >>> what solutions are needed. working on the requirements >>> could be part of the new charter and we can send the >>> charter to the IESG right away. we shouldn't let other >>> items proposed items in the charter suffer because we >>> want to gather "deployment requirements". >>> >>> Vijay >>> >> > From nemo-bounces@ietf.org Thu May 18 12:14:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgl8l-00007B-9k; Thu, 18 May 2006 12:14:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgl8j-000073-M1 for nemo@ietf.org; Thu, 18 May 2006 12:14:17 -0400 Received: from yui.nc.u-tokyo.ac.jp ([130.69.251.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fgl8j-0003gv-41 for nemo@ietf.org; Thu, 18 May 2006 12:14:17 -0400 Received: from [203.178.143.221] (dhcp-143-221.sfc.wide.ad.jp [203.178.143.221]) (authenticated bits=0) by yui.nc.u-tokyo.ac.jp (8.12.10/8.12.3/Debian-6.4) with ESMTP id k4IGDsUl029462; Fri, 19 May 2006 01:13:54 +0900 In-Reply-To: <446C5F2E.50307@motorola.com> References: <1487A357FD2ED544B8AD29E528FF9DF0028C4E9F@NAEX06.na.qualcomm.com> <20060516165709.61828ceb.thierry.ernst@inria.fr> <4469EE31.6060908@motorola.com> <20060517104337.351ef9a1.thierry.ernst@inria.fr> <446B6CC0.4020301@azairenet.com> <446C5297.3080409@kddilabs.jp> <446C5F2E.50307@motorola.com> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <03FAC4A7-527A-412D-B9B6-1E85FD8EF711@sfc.wide.ad.jp> Content-Transfer-Encoding: 7bit From: Ryuji Wakikawa Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. Date: Fri, 19 May 2006 01:13:33 +0900 To: Alexandru Petrescu X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: nemo@ietf.org, Thierry Ernst , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Alex On 2006/05/18, at 20:49, Alexandru Petrescu wrote: > Masafumi Watari wrote: >> On 2006/05/18 3:34, Vijay Devarapalli wrote: >>> Thierry Ernst wrote: >>>> Discussion is fine, but IMHO agreeing and sending a new charter >>>> to the IESG is too early at this point of time since there are >>>> divergent point of views on what we should do or not. I would >>>> rather see this really happening for next-next IETF (November). >>>> In the meantime, we can discuss the deployment requirements (see >>>> the other thread) so that we really know what is needed. >>> I don't think it is a good idea to put off re-chartering for this >>> long. you can infact re-charter once more in November if you want >>> once we have a clearer picture of what solutions are needed. >>> working on the requirements could be part of the new charter and we >>> can send the charter to the IESG right away. we shouldn't let >>> other items proposed items in the charter suffer because we want >>> to gather "deployment requirements". >> I agree. I think we could recharter now with work on the >> requirements, and leave other work on solutions for later >> rechartering. > > One of the customers for vehicular-like industry I work for cares a > lot > about IPv4. It is for vehicles used in emergency situations. A > little > bit like the aviation industry, this is equipment deployed, tried, > tested and proved for years, in sun rain fire. Any modification to it > is happening very slowly. IPv6 _is_ in the roadmaps but for now just > use IPv4 modifications, and not very many :-) It's much easier to > incrementally upgrade such a network from IPv4 to NEMOv4 than is to > upgrade every IP-addressable entity to IPv6 and then to NEMOv6. > > Maybe this IPv4 aspect from vehicular industry could be taken into > account by the deployment requirements. > > Other vehicular industry one sees in many places today is the rental > limousines offering wifi in the car. It's v4. Trains offering > wifi to > passengers. It's v4. Even Columbia in space used Mobile IPv4, not > v6. > > That said, I am far from opposing IPv6 work on network mobility, I > strongly support it too. You have NEMOv4 for this requirement, right?? Above requirement can fulfill with NEMOv4. I knew dynamic configuration can not be made, but this WG has several topics related to NEMO BS and we have to prioritize items. Remember there were few comments to NEMOv4 spec on this ML. ryuji ryuji From nemo-bounces@ietf.org Thu May 18 12:42:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglZx-0002KD-6C; Thu, 18 May 2006 12:42:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FglZw-0002K8-IT for nemo@ietf.org; Thu, 18 May 2006 12:42:24 -0400 Received: from yui.nc.u-tokyo.ac.jp ([130.69.251.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FglZv-00056p-KI for nemo@ietf.org; Thu, 18 May 2006 12:42:24 -0400 Received: from [203.178.143.221] (dhcp-143-221.sfc.wide.ad.jp [203.178.143.221]) (authenticated bits=0) by yui.nc.u-tokyo.ac.jp (8.12.10/8.12.3/Debian-6.4) with ESMTP id k4IGgMUl032432; Fri, 19 May 2006 01:42:22 +0900 In-Reply-To: <20060518151403.6dcb1ab0.thierry.ernst@inria.fr> References: <0D090F1E0F5536449C7E6527AFFA280A21BFCB@XCH-NW-8V1.nw.nos.boeing.com> <5916B65B-F318-429B-9561-04E9D28EF73E@kniveton.com> <20060516110101.5124f6cd.thierry.ernst@inria.fr> <234519ed78b2bf91be22e01ed3d1f538@it.uc3m.es> <20060516124606.6deac871.thierry.ernst@inria.fr> <74f86f393d8f38fffec68a9a079d6497@it.uc3m.es> <20060516144501.412c4270.thierry.ernst@inria.fr> <20060517103939.37ca1203.thierry.ernst@inria.fr> <8C7220B9-7229-43D3-B8FD-7BCC10599BAB@sfc.wide.ad.jp> <20060518151403.6dcb1ab0.thierry.ernst@inria.fr> Mime-Version: 1.0 (Apple Message framework v750) Content-Type: text/plain; charset=UTF-8; delsp=yes; format=flowed Message-Id: <765F3C78-C07F-465F-B26B-89FA4D2440DD@sfc.wide.ad.jp> Content-Transfer-Encoding: quoted-printable From: Ryuji Wakikawa Subject: Re: [nemo] Deployment Requirements Date: Fri, 19 May 2006 01:42:00 +0900 To: Thierry Ernst X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: bc102ac530ba955ef81f1f75b8bebe44 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Thierry On 2006/05/18, at 22:14, Thierry Ernst wrote: > > Hi Ryuji, > > Well, this could suffice (and thanks for recalling this presentation > "ISO Activities on NEMO BS", which can be found in the archives at > http://www3.ietf.org/proceedings/05aug/index.html under the NEMO WG > proceedings). However, this would weight more if there were people =20 > from > the vehicle industry and related business in Europe and Asia (where =20= > IPv6 > is more favored) expressing their views on this ML right now. yes, this is. > ISO TC204 WG16 is surely developing a communication system based on =20= > IPv6 > and there are a number of related projects in Europe developing a > complete architecture around NEMO (RFC 3963). However, most of the =20 > folks > involved in these groups are following the output of the IETF, but are > not taking part in the WG discussions, besides a few people. I am not so positive that those people will participate the =20 discussion here, since not all vehicle industry develop network system by own.. It's impossible to have completed requirements from all the industry, I don't know how these partial deployment requirements will have =20 "meaning" in this WG. If somebody come to this ML and express the idea from vehicle =20 industry, of course that will be great. regards, ryuji > Thierry. > >> i think the requirements from vehicle industry are summarized by ISO. >> Each vehicle company has slightly different requirements, but ISO >> tried to >> define a common network architecture for vehicles. >> There was a presentation about ISO activity at IETFXX (forgot which >> IETF). >> >> We can point to the ISO document if there are. >> It maybe time to come close between NEMO WG and ISO. >> >> regards, >> ryuji >> >> On 2006/05/17, at 17:39, Thierry Ernst wrote: >> >>> >>> Hi, >>> >>> We don't necessarily need a draft to gather the requirements (though >>> a draft is an easiest way to have a document to refer to when >>> debating). >>> >>> I'm happy to initiate a document for the vehicular industry though >>> I'm not sure I will have all the necessary time in the next few >>> weeks. But I >>> need help from other people already involved with the car industry >>> and related vendors. >>> >>> Actaully, I think gathering the deployment requirements is a >>> necessary step before rechartering the WG. >>> >>> Thierry. >>> >>>>>>> Well, do you intend to mean that we should write a deployment >>>>>>> requirements draft for the aviation industry specifically, in >>>>>>> which >>>>>>> case >>>>>>> we would do the same for the vehicular industry, and for each >>>>>>> other >>>>>>> existing use cases ? >>>>>>> >>>>>> >>>>>> well, i am not sure about the vehicular technology because i >>> don't>>> know if they have specific requirements. >>>>> >>>>> They do, though they don't speak up yet, because (unfortunately) >>>>> IETF >>>>> is >>>>> not an organization where they used to be involved. But they (or >>> the>> vendors related to the vehicular industry and the >>> standardization>> bodies >>>>> such as ISO and ETSI) will show up when they understand it is >>>>> important >>>>> for them to be involved in the debate. >>>>> >>>> >>>> good i am all for working on other cases if there is interest >>>> >>>> (FWIW my point about working in aviation and not in other use >>>> cases was >>>> merely because there was no feedback on those, not because i have >>> any> kind of problem in working in other cases) >>>> >>>>> Would be interesting to get some input from the Japanese folks who >>> I>> know are monitoring this ML. I'm not speaking only about the >>>>> people at >>>>> Keio University who are academic though who are involved with >>> these>> people, but the people representing the companies who are in >>> this>> business. >>>>> >>>>> Come on folks, this is the right timing to discuss the deployment >>>>> requirements for the vehicular industry ! >>>>> >>>>>> but following the emails that have been exchanged lately in this >>> >>>>>> ml, >>>>>> it is my opinion that the aviation case have quite special >>>>>> requirements and that they need customized solutions for thier >>>>>> problems that have their own set of deployment issues. >>>>> >>>>> I second this. But the vehicular industry is IMHO more important >>>>> as it >>>>> would involved tens of vendors, with possibly divergent deployment >>>>> requirements. >>>>> >>>> >>>> good, let's write those down also and see what is the common >>>> requiremetns for all the relevant use cases >>>> >>>> If the common part is large, we should defineltly include them in >>> the> common requiremetns draft that we already have. If the common >>> part is> small and there are a lot of diverging requirements then we >>> should go> for different drafts i guess >>>> >>>> but i guess that the first part is to get individual submissions >>> from> each of the use cases that people are interested in working on >>>> >>>> >>>> >>>>>> I mean consider that they are moving globally quite rapidly, >>>>>> they have >>>>>> >>>>>> wordlwide infrastruture, they need high reliability, and so on, >>> >>>>>> which >>>>>> >>>>>> makes their case somehow different from the case of nemos >>>>>> deployed in >>>>>> buses cars and so on (or at least it seems so to me) >>>>> >>>>> Well, cases and thus requirements are different. RFC 3963 may not >>>>> always >>>>> apply, but even though, the security, authentication and >>> multihoming>> considerations are different. >>>>> >>>>>> that is why i think that the general requirements and in >>> particular>>> the deployment requirements for a solution to this >>> particular >>> problem >>>>>> need to be fleshed out >>>>> >>>>> Yes, but what is the best procedure ? Independent draft, one for >>>>> each >>>>> use case, or shall we came up straight with common requirements, >>> in>> which case I would say draft-ietf-nemo-requirements is the best >>> >>>>> place >>>>> to >>>>> gather these deployment scenarios ? >>>>> >>>> >>>> see my suggestion above... i guess that in order to answer this we >>>> should first figure out what is the common requiremetns for all the >>>> relevant use cases and then we can decide... >>>> >>>> regards, marcelo >>>> >>>> >>>>>>> If yes, then I guess it would rather be individual submissions >>>>>> >>>>>> yes i think Terry initial list could be a starting point for this >>>>>> >>>>>>> that >>>>>>> could be used as input for determining a common list of >>> deployment>>>> requirements. >>>>>>> >>>>>> >>>>>> well depending on whether this requirements fit into the general >>>>>> requirements, this may be ok.... but i think that they are >>>>>> likely to >>>>>> be quite differetn from the general case >>>>> >>>>> This may not be an issue. The draft could be explicit that these >>> are>> requirements for that specific use cases where we get some >>> input.>> >>>>> Thierry. >>>>> >>>>>>> >>>>>>>>> [I changed the subject line] >>>>>>>>> >>>>>>>>> Speaking about "deployment requirements", I would propose to >>>>>>>>> add a >>>>>>>>> section in draft-ietf-nemo-requirements (actually, I intended >>> to>>>>>> extend >>>>>>>>> that draft since the beginning ;-) rather of editing a >>> separate>>>>>> document. >>>>>>>>> >>>>>>>>> Would that make sense to everyone ? >>>>>>>>> >>>>>>>> >>>>>>>> i think that there are some general deployment requirements >>> that>>>> could> fit in there >>>>>>>> >>>>>>>> however, perhaps the case of aviation may have quite specific >>>>>>>> requirements of their own that may not apply in the general >>>>>>> case.... i> mean not all of us have worldwide sites and a nemo >>>>>>> moving >>>>>>> around> several of them in a single day :-) >>>>>>>> >>>>>>>> Regards, marcelo >>>>>>>> >>>>>>>> >>>>>>>>> Thierry. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, 16 May 2006 09:19:30 +0300 >>>>>>>>> marcelo bagnulo braun wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> El 15/05/2006, a las 20:47, T.J.Kniveton escribi=EF=BF=BD=EF=BF= =BD=EF=BF=BD: >>>>>>>>>> >>>>>>>>>>> On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote: >>>>>>>>>>> >>>>>>>>>>>> T.J. >>>>>>>>>>>> >>>>>>>>>>>> You'll probably wish that you hadn't asked for this... >>>>>>>>>>>> >>>>>>>>>>>> These would be our ideal mobility solution. I realize that >>>>>>>>>>>> meeting >>>>>>>>>>>> all >>>>>>>>>>>> of these is probably an extreme stretch. >>>>>>>>>>>> >>>>>>>>>>>> Take care >>>>>>>>>>>> Terry >>>>>>>>>>> >>>>>>>>>>> Terry, >>>>>>>>>>> >>>>>>>>>>> I second the request to put your list of items into a >>>>>>>>>>> draft. It >>>>>>>>>>> will >>>>>>>>>>> be helpful to have a concrete list of deployment >>>>>>>>>>> requirements to >>>>>>>>>>> refer >>>>>>>>>>> to. While the WG can't necessarily solve all of the >>>>>>>>>>> problems for >>>>>>> >>>>>>>>>>> one >>>>>>>>>>> specific deployment, an informational document listing them >>> >>>>>>>>>>> can >>>>>>> be>>>> useful for guidance when making engineering design >>>>>>> decisions. >>>>>>>>>>> >>>>>>>>>>> Would you be willing to do that? Perhaps others in the WG >>> can>>>> help>>>> with maintaining the document / editing if needed. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> i am willing to help Terry on this in case it is needed... >>>>>>>>>> >>>>>>>>>> regards, marcelo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> TJ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --=20 >>>>>>>>> Thierry ERNST, PhD >>>>>>>>> INRIA Rocquencourt Projet IMARA >>>>>>>>> +33 1 39 63 59 30 >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> --=20 >>>>>>> Thierry ERNST, PhD >>>>>>> INRIA Rocquencourt Projet IMARA >>>>>>> +33 1 39 63 59 30 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> --=20 >>>>> Thierry ERNST, PhD >>>>> INRIA Rocquencourt Projet IMARA >>>>> +33 1 39 63 59 30 >>>>> >>>>> >>>> >>>> >>>> >>> >>> >>> --=20 >>> Thierry ERNST, PhD >>> INRIA Rocquencourt Projet IMARA >>> +33 1 39 63 59 30 >>> >> >> >> > > > --=20 > Thierry ERNST, PhD > INRIA Rocquencourt Projet IMARA > +33 1 39 63 59 30 > From nemo-bounces@ietf.org Thu May 18 12:46:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgldw-00049e-Nu; Thu, 18 May 2006 12:46:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fgldv-00049Z-2W for nemo@ietf.org; Thu, 18 May 2006 12:46:31 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fglds-0005FI-Pc for nemo@ietf.org; Thu, 18 May 2006 12:46:31 -0400 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k4IGkErc027148; Thu, 18 May 2006 09:46:19 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id k4IGkDdC001109; Thu, 18 May 2006 11:46:14 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 72C3A865980; Thu, 18 May 2006 18:46:13 +0200 (CEST) Message-ID: <446CA4D5.30505@motorola.com> Date: Thu, 18 May 2006 18:46:13 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF0029BCE82@NAEX06.na.qualcomm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: nemo@ietf.org, Thierry Ernst , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Ryuji Wakikawa wrote: > George > > Well, NEMO is an extension to MIP6 :-) We always had enough > discussions on how to proceed an extension to some work. I agree. > I recommend you to publish a draft which has PS and Requirement and > maybe Solution. NEMOv4 draft has a short section 3 on problem statement and requirements. It mainly points to 3344 not supporting moving networks and requires a solution to do both explicit and implicit, not modify the 3344 FAs for NEMOv4 to work and support various mobile entities. For NEMOv4 FA support this could be extended to say that if FAs are enhanced from 3344 to NEMOv4 then certain advantages could be obtained. I could help writing such Problem Statement and Reqs draft, would you review? > You understand why you need this work because you are working on > this, but most of members are unaware of this necessity and work > overhead, etc. > > Since it's obvious that only few member express interests to v4 > related topic, it's too early to decide this as NEMO WG topic. > However, it does not mean we exclude this work from NEMO WG forever. > We can move forward whenever the work becomes ready in terms of > discussion and I-D. Ok, Alex From nemo-bounces@ietf.org Thu May 18 12:51:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgliI-00065L-EQ; Thu, 18 May 2006 12:51:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgliI-00065G-0B for nemo@ietf.org; Thu, 18 May 2006 12:51:02 -0400 Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgliH-0005Pn-Nw for nemo@ietf.org; Thu, 18 May 2006 12:51:01 -0400 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motgate7) with ESMTP id k4IGokBs028367; Thu, 18 May 2006 09:50:46 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id k4IGojdk011330; Thu, 18 May 2006 11:50:45 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id D7F8A865980; Thu, 18 May 2006 18:50:44 +0200 (CEST) Message-ID: <446CA5E4.3040409@motorola.com> Date: Thu, 18 May 2006 18:50:44 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Ryuji Wakikawa Subject: Re: [nemo] Extensions to NEMOv4 base for the Charter. References: <1487A357FD2ED544B8AD29E528FF9DF0028C4E9F@NAEX06.na.qualcomm.com> <20060516165709.61828ceb.thierry.ernst@inria.fr> <4469EE31.6060908@motorola.com> <20060517104337.351ef9a1.thierry.ernst@inria.fr> <446B6CC0.4020301@azairenet.com> <446C5297.3080409@kddilabs.jp> <446C5F2E.50307@motorola.com> <03FAC4A7-527A-412D-B9B6-1E85FD8EF711@sfc.wide.ad.jp> In-Reply-To: <03FAC4A7-527A-412D-B9B6-1E85FD8EF711@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: nemo@ietf.org, Thierry Ernst , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Ryuji Wakikawa wrote: > Hi Alex > > > On 2006/05/18, at 20:49, Alexandru Petrescu wrote: > >> Masafumi Watari wrote: >>> On 2006/05/18 3:34, Vijay Devarapalli wrote: >>>> Thierry Ernst wrote: >>>>> Discussion is fine, but IMHO agreeing and sending a new >>>>> charter to the IESG is too early at this point of time since >>>>> there are divergent point of views on what we should do or >>>>> not. I would rather see this really happening for next-next >>>>> IETF (November). In the meantime, we can discuss the >>>>> deployment requirements (see the other thread) so that we >>>>> really know what is needed. >>>> I don't think it is a good idea to put off re-chartering for >>>> this long. you can infact re-charter once more in November if >>>> you want once we have a clearer picture of what solutions are >>>> needed. working on the requirements could be part of the new >>>> charter and we can send the charter to the IESG right away. we >>>> shouldn't let other items proposed items in the charter suffer >>>> because we want to gather "deployment requirements". >>> I agree. I think we could recharter now with work on the >>> requirements, and leave other work on solutions for later >>> rechartering. >> >> One of the customers for vehicular-like industry I work for cares a >> lot about IPv4. It is for vehicles used in emergency situations. >> A little bit like the aviation industry, this is equipment >> deployed, tried, tested and proved for years, in sun rain fire. Any >> modification to it is happening very slowly. IPv6 _is_ in the >> roadmaps but for now just use IPv4 modifications, and not very many >> :-) It's much easier to incrementally upgrade such a network from >> IPv4 to NEMOv4 than is to upgrade every IP-addressable entity to >> IPv6 and then to NEMOv6. >> >> Maybe this IPv4 aspect from vehicular industry could be taken into >> account by the deployment requirements. >> >> Other vehicular industry one sees in many places today is the >> rental limousines offering wifi in the car. It's v4. Trains >> offering wifi to passengers. It's v4. Even Columbia in space used >> Mobile IPv4, not v6. >> >> That said, I am far from opposing IPv6 work on network mobility, I >> strongly support it too. > > You have NEMOv4 for this requirement, right?? I think you meant NEMOv6 - right we have NEMOv6 for that requirement. But I think there is a number of comments that were sent on NEMOv6 base spec, most are simple to deal with, some editorial errors too. I consider this NEMOv6 work. I also consider NEMOv6 work to be the prefix delegation from HA to MR with DHCPv6 or MIP6 (to be decided). And I support this too. > Above requirement can fulfill with NEMOv4. Yes, v4 requirements from vehicular and aviation industry can be fulfilled with the NEMOv4 spec. > I knew dynamic configuration can not be made, but this WG has several > topics related to NEMO BS and we have to prioritize items. Remember > there were few comments to NEMOv4 spec on this ML. I agree. Do you have your own preference for prioritization? What would that be? Alex From nemo-bounces@ietf.org Thu May 18 13:40:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgmTY-0006yo-2N; Thu, 18 May 2006 13:39:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgmTW-0006yj-Br for nemo@ietf.org; Thu, 18 May 2006 13:39:50 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgmTV-0007oJ-1u for nemo@ietf.org; Thu, 18 May 2006 13:39:50 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 18 May 2006 10:39:46 -0700 Message-ID: <446CB162.2060208@azairenet.com> Date: Thu, 18 May 2006 10:39:46 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: "Davis, Terry L" Subject: Re: [nemo] Rewording of RO work in the charter References: <0D090F1E0F5536449C7E6527AFFA280A21C0FB@XCH-NW-8V1.nw.nos.boeing.com> In-Reply-To: <0D090F1E0F5536449C7E6527AFFA280A21C0FB@XCH-NW-8V1.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 18 May 2006 17:39:46.0490 (UTC) FILETIME=[0E0161A0:01C67AA2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ml-nemo WG , "T.J. Kniveton" , ivancic X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Davis, Terry L wrote: > I have received the backing of the Arinc Air Data Networking committee > (an aviation standards organization) to work on this. I expect to have > a rough draft of an informational RFC covering aviation network mobility > requirements for Montreal. sounds good. Vijay > > Take care > Terry > >> -----Original Message----- >> From: T.J. Kniveton [mailto:tj@kniveton.com] >> Sent: Monday, May 15, 2006 10:47 AM >> To: Davis, Terry L >> Cc: ml-nemo WG >> Subject: Re: [nemo] Rewording of RO work in the charter >> >> On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote: >> >>> T.J. >>> >>> You'll probably wish that you hadn't asked for this... >>> >>> These would be our ideal mobility solution. I realize that meeting >>> all >>> of these is probably an extreme stretch. >>> >>> Take care >>> Terry >> Terry, >> >> I second the request to put your list of items into a draft. It will >> be helpful to have a concrete list of deployment requirements to >> refer to. While the WG can't necessarily solve all of the problems >> for one specific deployment, an informational document listing them >> can be useful for guidance when making engineering design decisions. >> >> Would you be willing to do that? Perhaps others in the WG can help >> with maintaining the document / editing if needed. >> >> TJ >> > > From nemo-bounces@ietf.org Fri May 19 03:28:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgzOm-0002BZ-LD; Fri, 19 May 2006 03:27:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FgzOl-0002BU-Bp for nemo@ietf.org; Fri, 19 May 2006 03:27:47 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FgzOl-00020J-93 for nemo@ietf.org; Fri, 19 May 2006 03:27:47 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FgzOc-0004tN-9S for nemo@ietf.org; Fri, 19 May 2006 03:27:42 -0400 Message-ID: <00bc01c67b15$d2e12d20$546015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "Vijay Devarapalli" , "T.J. Kniveton" References: <4468F985.6070108@azairenet.com> Subject: Re: [nemo] New versions of charter Date: Fri, 19 May 2006 00:28:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Vijay, Do you believe the route optimzation problem is well enough understood, from a research standpoint, that standardization of a general solution is possible? From the reading I've done, it seems like there is a considerable diversity of opinion about the most technically optimal approach. jak ----- Original Message ----- From: "Vijay Devarapalli" To: "T.J. Kniveton" Cc: "ml-nemo WG" Sent: Monday, May 15, 2006 2:58 PM Subject: Re: [nemo] New versions of charter > hi TJ, > > my understanding was that there will also be a general > purpose route optimization solution. and this solution > would not depend on geographically distributed HAs. > this is not mentioned anywhere in the charter. the > charter only talks about "Analysis of the Solution > Space for Route Optimization". > >> The working group has work items to describe a basic solution for >> network mobility in IPv6-only networks, and to design a mechanism to >> allow mixed IPv4/IPv6 networks, carrying signalling messages that >> describe both IPv4 and IPv6 addresses and mobile network prefixes. The >> latter task is shared with the Mobile IPv6 working group, addressed by >> a joint design team. > > this is just DS-MIPv6 (with appropriate extensions for > IPv4 mobile network prefixes), right? nothing more. > > Vijay > > T.J. Kniveton wrote: >> I have posted a new version of the proposed charter (on the web page) to >> replace the April 30 version. Some of the changes include: >> >> - Added some text about v6, v4 and v4/v6 solution distinctions. >> - Added some additional text throughout the tasks/nontasks >> - Added editing and typo fixes as suggested >> - Other suggested changes >> >> One remaining comment which I have not addressed yet: >> >> James Kempf wrote: >>> I am very much in favor of making WG charters very specific. It helps to >>> avoid ambiguity about what the WG is intending to accomplish, and also >>> helps focus the energy of the WG and avoid having it become distracted >>> by other proposals that tend to pop up, until the originally promised >>> work is completed. Therefore, I would recommend that the charter include >>> a bulleted list with three items corresponding to each of these new >>> drafts, with each item giving a concise but complete description of what >>> the promised draft is intended to accomplish. If there are existing >>> individual drafts that cover these, the descriptions can be based on the >>> individual drafts. Also, it might be helpful to be more specific about >>> the goals and their timing. Rather than just a single goal, have a list >>> that correspond to the process: 00 WG draft selected by this time, WG >>> last call by this time, submission to IESG by this time. >> >> (Some help would be appreciated with this one). I think we still have to >> adjust the milestones a bit more to make sure everything is explicitly >> spelled out. I have tried to make the charter as concrete as possible, >> while still short enough to be manageable/readable. I would like the next >> revision to focus on the milestones. >> >> Can people please read this over and make comments/suggestions, with >> proposed text changes? That would be helpful. >> >> Thanks, >> TJ >> >> > > > From nemo-bounces@ietf.org Fri May 19 12:51:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8Bj-0000pO-3d; Fri, 19 May 2006 12:50:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh8Bi-0000pI-5m for nemo@ietf.org; Fri, 19 May 2006 12:50:54 -0400 Received: from motgate5.mot.com ([144.189.100.105]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh8Bg-00045P-OK for nemo@ietf.org; Fri, 19 May 2006 12:50:54 -0400 Received: from az33exr04.mot.com (az33exr04.mot.com [10.64.251.234]) by motgate5.mot.com (8.12.11/Motgate5) with ESMTP id k4JGon0d011130 for ; Fri, 19 May 2006 09:50:49 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by az33exr04.mot.com (8.13.1/8.13.0) with ESMTP id k4JGomHe003686 for ; Fri, 19 May 2006 11:50:49 -0500 (CDT) Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id 28B65865980 for ; Fri, 19 May 2006 18:50:48 +0200 (CEST) Message-ID: <446DF767.7020706@motorola.com> Date: Fri, 19 May 2006 18:50:47 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ml-nemo WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-White-List-Member: TRUE X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [nemo] Potential conflict on NEMOv4 Type and FA-ERR Type X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I've been pointed that there seems to be a potential conflict on NEMOv4 Mobile Network Extension Type and FA-Err Type. NEMOv4 uses a new Type (to be assigned by IANA) in Mobile Network Extension. We suggested in the draft that it be 45. FA-ERR draft-ietf-mip4-faerr-02.txt uses Type 45 for FA Error Extension (already assigned by IANA). The draft does not specify 45, just says TBA by IANA. IANA seems to have assigned it, see http://www.iana.org/assignments/mobileip-numbers. draft-ietf-mobileip-gen-key-01.txt implemented in dynamics 0.8.1 uses 45 too, but I think this can be ignored, because I think this work has been evolved into draft-rfc3012bis which uses Type 24. To solve the issue between NEMOv4 and FA-ERR I suggest that we use Type 46 - and not 45 - in NEMOv4 implementation, until IANA assigns a Type for NEMOv4 Mobile Network Extension. What do you think? Alex From nemo-bounces@ietf.org Fri May 19 13:45:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh92l-0001c8-Gb; Fri, 19 May 2006 13:45:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh92k-0001c1-2d for nemo@ietf.org; Fri, 19 May 2006 13:45:42 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh92h-0008IS-Ka for nemo@ietf.org; Fri, 19 May 2006 13:45:42 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 10:45:37 -0700 Message-ID: <446E0440.9090402@azairenet.com> Date: Fri, 19 May 2006 10:45:36 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: James Kempf Subject: Re: [nemo] New versions of charter References: <4468F985.6070108@azairenet.com> <00bc01c67b15$d2e12d20$546015ac@dcml.docomolabsusa.com> In-Reply-To: <00bc01c67b15$d2e12d20$546015ac@dcml.docomolabsusa.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2006 17:45:37.0246 (UTC) FILETIME=[097C3FE0:01C67B6C] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: ml-nemo WG , "T.J. Kniveton" X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org James Kempf wrote: > Vijay, > > Do you believe the route optimzation problem is well enough understood, > from a research standpoint, that standardization of a general solution > is possible? From the reading I've done, it seems like there is a > considerable diversity of opinion about the most technically optimal > approach. I need to do some reading myself. I haven't kept up to date on many of the route optimization solution drafts. :( well, we have a bunch of solutions and a draft that analyzes the solution space. http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-02.txt based on this, we either decide to go ahead with working on a solution or decide we are not going to standardize a solution. another option is to standardize two or more solution drafts as experimental RFCs and see how it goes. the wording in the proposed charter is vague. it just says continue investigating (or something like that) the route optimization problem. Vijay > > jak > > ----- Original Message ----- From: "Vijay Devarapalli" > > To: "T.J. Kniveton" > Cc: "ml-nemo WG" > Sent: Monday, May 15, 2006 2:58 PM > Subject: Re: [nemo] New versions of charter > > >> hi TJ, >> >> my understanding was that there will also be a general >> purpose route optimization solution. and this solution >> would not depend on geographically distributed HAs. >> this is not mentioned anywhere in the charter. the >> charter only talks about "Analysis of the Solution >> Space for Route Optimization". >> >>> The working group has work items to describe a basic solution for >>> network mobility in IPv6-only networks, and to design a mechanism to >>> allow mixed IPv4/IPv6 networks, carrying signalling messages that >>> describe both IPv4 and IPv6 addresses and mobile network prefixes. The >>> latter task is shared with the Mobile IPv6 working group, addressed by >>> a joint design team. >> >> this is just DS-MIPv6 (with appropriate extensions for >> IPv4 mobile network prefixes), right? nothing more. >> >> Vijay >> >> T.J. Kniveton wrote: >>> I have posted a new version of the proposed charter (on the web page) >>> to replace the April 30 version. Some of the changes include: >>> >>> - Added some text about v6, v4 and v4/v6 solution distinctions. >>> - Added some additional text throughout the tasks/nontasks >>> - Added editing and typo fixes as suggested >>> - Other suggested changes >>> >>> One remaining comment which I have not addressed yet: >>> >>> James Kempf wrote: >>>> I am very much in favor of making WG charters very specific. It >>>> helps to avoid ambiguity about what the WG is intending to >>>> accomplish, and also helps focus the energy of the WG and avoid >>>> having it become distracted by other proposals that tend to pop up, >>>> until the originally promised work is completed. Therefore, I would >>>> recommend that the charter include a bulleted list with three items >>>> corresponding to each of these new drafts, with each item giving a >>>> concise but complete description of what the promised draft is >>>> intended to accomplish. If there are existing individual drafts that >>>> cover these, the descriptions can be based on the individual drafts. >>>> Also, it might be helpful to be more specific about the goals and >>>> their timing. Rather than just a single goal, have a list that >>>> correspond to the process: 00 WG draft selected by this time, WG >>>> last call by this time, submission to IESG by this time. >>> >>> (Some help would be appreciated with this one). I think we still have >>> to adjust the milestones a bit more to make sure everything is >>> explicitly spelled out. I have tried to make the charter as concrete >>> as possible, while still short enough to be manageable/readable. I >>> would like the next revision to focus on the milestones. >>> >>> Can people please read this over and make comments/suggestions, with >>> proposed text changes? That would be helpful. >>> >>> Thanks, >>> TJ >>> >>> >> >> >> > > From nemo-bounces@ietf.org Fri May 19 14:06:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9MK-0005o9-Rq; Fri, 19 May 2006 14:05:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9MJ-0005o4-Ny for nemo@ietf.org; Fri, 19 May 2006 14:05:55 -0400 Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9MI-00013F-Ac for nemo@ietf.org; Fri, 19 May 2006 14:05:55 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4JI5ocb014367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 May 2006 11:05:53 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4JI5meX003278; Fri, 19 May 2006 11:05:50 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 11:05:26 -0700 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 Subject: RE: [nemo] Potential conflict on NEMOv4 Type and FA-ERR Type Date: Fri, 19 May 2006 11:05:25 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB84882B16@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Potential conflict on NEMOv4 Type and FA-ERR Type Thread-Index: AcZ7ZK/HAAS9bVODSmafdrd333h8mAAChnqQ From: "Narayanan, Vidya" To: "Alexandru Petrescu" , "ml-nemo WG" X-OriginalArrivalTime: 19 May 2006 18:05:26.0057 (UTC) FILETIME=[CE126990:01C67B6E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Sounds good to me. =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com]=20 > Sent: Friday, May 19, 2006 9:51 AM > To: ml-nemo WG > Subject: [nemo] Potential conflict on NEMOv4 Type and FA-ERR Type >=20 > I've been pointed that there seems to be a potential conflict=20 > on NEMOv4 Mobile Network Extension Type and FA-Err Type. >=20 > NEMOv4 uses a new Type (to be assigned by IANA) in Mobile=20 > Network Extension. We suggested in the draft that it be 45. >=20 > FA-ERR draft-ietf-mip4-faerr-02.txt uses Type 45 for FA Error=20 > Extension (already assigned by IANA). The draft does not=20 > specify 45, just says TBA by IANA. IANA seems to have=20 > assigned it, see http://www.iana.org/assignments/mobileip-numbers. >=20 > draft-ietf-mobileip-gen-key-01.txt implemented in dynamics=20 > 0.8.1 uses 45 too, but I think this can be ignored, because =20 > I think this work has been evolved into draft-rfc3012bis=20 > which uses Type 24. >=20 > To solve the issue between NEMOv4 and FA-ERR I suggest that=20 > we use Type > 46 - and not 45 - in NEMOv4 implementation, until IANA=20 > assigns a Type for NEMOv4 Mobile Network Extension. >=20 > What do you think? >=20 > Alex >=20 >=20 From nemo-bounces@ietf.org Fri May 19 14:21:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9b0-0000nG-Gz; Fri, 19 May 2006 14:21:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9az-0000mz-Hu for nemo@ietf.org; Fri, 19 May 2006 14:21:05 -0400 Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9ax-0001lq-OP for nemo@ietf.org; Fri, 19 May 2006 14:21:05 -0400 Received: from [10.1.201.8] ([10.1.201.8]) by bart.corp.azairenet.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 11:20:58 -0700 Message-ID: <446E0C8A.2010302@azairenet.com> Date: Fri, 19 May 2006 11:20:58 -0700 From: Vijay Devarapalli User-Agent: Thunderbird 1.5.0.2 (Windows/20060308) MIME-Version: 1.0 To: Alexandru Petrescu Subject: Re: [nemo] Potential conflict on NEMOv4 Type and FA-ERR Type References: <446DF767.7020706@motorola.com> In-Reply-To: <446DF767.7020706@motorola.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 May 2006 18:20:58.0687 (UTC) FILETIME=[F9F674F0:01C67B70] X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Alexandru Petrescu wrote: > I've been pointed that there seems to be a potential conflict on NEMOv4 > Mobile Network Extension Type and FA-Err Type. > > NEMOv4 uses a new Type (to be assigned by IANA) in Mobile Network > Extension. We suggested in the draft that it be 45. > > FA-ERR draft-ietf-mip4-faerr-02.txt uses Type 45 for FA Error Extension > (already assigned by IANA). The draft does not specify 45, just says > TBA by IANA. IANA seems to have assigned it, see > http://www.iana.org/assignments/mobileip-numbers. > > draft-ietf-mobileip-gen-key-01.txt implemented in dynamics 0.8.1 uses 45 > too, but I think this can be ignored, because I think this work has > been evolved into draft-rfc3012bis which uses Type 24. > > To solve the issue between NEMOv4 and FA-ERR I suggest that we use Type > 46 - and not 45 - in NEMOv4 implementation, until IANA assigns a Type > for NEMOv4 Mobile Network Extension. > > What do you think? IMO, you should leave it to be assigned by the IANA. not suggest any value at all. IANA will just pick the next available one. Vijay From nemo-bounces@ietf.org Fri May 19 14:33:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9my-0006KX-AZ; Fri, 19 May 2006 14:33:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fh9mw-0006KS-G2 for nemo@ietf.org; Fri, 19 May 2006 14:33:26 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fh9mw-0002Sc-3J for nemo@ietf.org; Fri, 19 May 2006 14:33:26 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4JIXMS3009459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 19 May 2006 11:33:23 -0700 Received: from NAEXBR04.na.qualcomm.com (naexbr04.qualcomm.com [10.46.141.42]) by magus.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4JIXG5n013752; Fri, 19 May 2006 11:33:21 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR04.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 19 May 2006 11:33:19 -0700 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 Subject: RE: [nemo] Potential conflict on NEMOv4 Type and FA-ERR Type Date: Fri, 19 May 2006 11:32:28 -0700 Message-ID: <1487A357FD2ED544B8AD29E528FF9DF0029BDB96@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Potential conflict on NEMOv4 Type and FA-ERR Type Thread-Index: AcZ7cS410OynI4zwT66n3f3ybIJnlAAAQ1BQ From: "Tsirtsis, George" To: "Vijay Devarapalli" , "Alexandru Petrescu" X-OriginalArrivalTime: 19 May 2006 18:33:19.0098 (UTC) FILETIME=[B34835A0:01C67B72] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Yes, I think Vijay is right. It is up to IANA and implementations need to be ready to change to the assigned numbers when the IANA decides. In the mean time I-D authors can suggest reasonable values just in case they get it right and so they do not have to change ;-) > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] > Sent: Friday, May 19, 2006 2:21 PM > To: Alexandru Petrescu > Cc: ml-nemo WG > Subject: Re: [nemo] Potential conflict on NEMOv4 Type and FA-ERR Type >=20 > Alexandru Petrescu wrote: > > I've been pointed that there seems to be a potential conflict on NEMOv4 > > Mobile Network Extension Type and FA-Err Type. > > > > NEMOv4 uses a new Type (to be assigned by IANA) in Mobile Network > > Extension. We suggested in the draft that it be 45. > > > > FA-ERR draft-ietf-mip4-faerr-02.txt uses Type 45 for FA Error Extension > > (already assigned by IANA). The draft does not specify 45, just says > > TBA by IANA. IANA seems to have assigned it, see > > http://www.iana.org/assignments/mobileip-numbers. > > > > draft-ietf-mobileip-gen-key-01.txt implemented in dynamics 0.8.1 uses 45 > > too, but I think this can be ignored, because I think this work has > > been evolved into draft-rfc3012bis which uses Type 24. > > > > To solve the issue between NEMOv4 and FA-ERR I suggest that we use Type > > 46 - and not 45 - in NEMOv4 implementation, until IANA assigns a Type > > for NEMOv4 Mobile Network Extension. > > > > What do you think? >=20 > IMO, you should leave it to be assigned by the IANA. > not suggest any value at all. IANA will just pick > the next available one. >=20 > Vijay From nemo-bounces@ietf.org Mon May 22 04:27:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi5lY-0006y9-TN; Mon, 22 May 2006 04:27:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi5lW-0006y3-So for nemo@ietf.org; Mon, 22 May 2006 04:27:50 -0400 Received: from concorde.inria.fr ([192.93.2.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi5lV-00048L-Ar for nemo@ietf.org; Mon, 22 May 2006 04:27:50 -0400 Received: from guest-rocq-135223.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k4M8Rlpg008182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 May 2006 10:27:48 +0200 Date: Mon, 22 May 2006 10:29:04 +0200 From: Thierry Ernst To: nemo@ietf.org Message-Id: <20060522102904.69ae4b8d.thierry.ernst@inria.fr> In-Reply-To: <446E0440.9090402@azairenet.com> References: <4468F985.6070108@azairenet.com> <00bc01c67b15$d2e12d20$546015ac@dcml.docomolabsusa.com> <446E0440.9090402@azairenet.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 44717604.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Subject: [nemo] NEMO RO on the charter X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi James, I would say that yes, the problem is well enough understood, there exists solutions, and even implementations (e.g. based on SHISA). The question is rather what RO we would like to do (between MNNs in the same nested NEMO, between MNNs located in separated NEMO, or between the MNNs and the infrastructure). I've also received personal comments that NEMO RO is needed for deployment of RFC 3963 at a wide scale. The wording of the new charter should be more explicit on RO - Unfortunately I was not watching the mailing list during the March-April time frame and the re-chartering discussion took me by surprise. I have to manage time to propose some text on this. To conclude, we do have the 2 drafts (RO Problem Statement and RO solution space analysis). These drafts are providing good input for deciding what is reasonable to do, so I would recommend everyone to read them if it's not already done, and to take a look at the presentation material from Vancouver. Thierry. On Fri, 19 May 2006 10:45:36 -0700 Vijay Devarapalli wrote: > James Kempf wrote: > > Vijay, > > > > Do you believe the route optimzation problem is well enough understood, > > from a research standpoint, that standardization of a general solution > > is possible? From the reading I've done, it seems like there is a > > considerable diversity of opinion about the most technically optimal > > approach. > > I need to do some reading myself. I haven't kept > up to date on many of the route optimization > solution drafts. :( > > well, we have a bunch of solutions and a draft > that analyzes the solution space. > http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-02.txt > > based on this, we either decide to go ahead with > working on a solution or decide we are not going > to standardize a solution. another option is to > standardize two or more solution drafts as > experimental RFCs and see how it goes. > > the wording in the proposed charter is vague. it > just says continue investigating (or something > like that) the route optimization problem. > > Vijay > > > > > > jak > > > > ----- Original Message ----- From: "Vijay Devarapalli" > > > > To: "T.J. Kniveton" > > Cc: "ml-nemo WG" > > Sent: Monday, May 15, 2006 2:58 PM > > Subject: Re: [nemo] New versions of charter > > > > > >> hi TJ, > >> > >> my understanding was that there will also be a general > >> purpose route optimization solution. and this solution > >> would not depend on geographically distributed HAs. > >> this is not mentioned anywhere in the charter. the > >> charter only talks about "Analysis of the Solution > >> Space for Route Optimization". > >> > >>> The working group has work items to describe a basic solution for > >>> network mobility in IPv6-only networks, and to design a mechanism to > >>> allow mixed IPv4/IPv6 networks, carrying signalling messages that > >>> describe both IPv4 and IPv6 addresses and mobile network prefixes. The > >>> latter task is shared with the Mobile IPv6 working group, addressed by > >>> a joint design team. > >> > >> this is just DS-MIPv6 (with appropriate extensions for > >> IPv4 mobile network prefixes), right? nothing more. > >> > >> Vijay > >> > >> T.J. Kniveton wrote: > >>> I have posted a new version of the proposed charter (on the web page) > >>> to replace the April 30 version. Some of the changes include: > >>> > >>> - Added some text about v6, v4 and v4/v6 solution distinctions. > >>> - Added some additional text throughout the tasks/nontasks > >>> - Added editing and typo fixes as suggested > >>> - Other suggested changes > >>> > >>> One remaining comment which I have not addressed yet: > >>> > >>> James Kempf wrote: > >>>> I am very much in favor of making WG charters very specific. It > >>>> helps to avoid ambiguity about what the WG is intending to > >>>> accomplish, and also helps focus the energy of the WG and avoid > >>>> having it become distracted by other proposals that tend to pop up, > >>>> until the originally promised work is completed. Therefore, I would > >>>> recommend that the charter include a bulleted list with three items > >>>> corresponding to each of these new drafts, with each item giving a > >>>> concise but complete description of what the promised draft is > >>>> intended to accomplish. If there are existing individual drafts that > >>>> cover these, the descriptions can be based on the individual drafts. > >>>> Also, it might be helpful to be more specific about the goals and > >>>> their timing. Rather than just a single goal, have a list that > >>>> correspond to the process: 00 WG draft selected by this time, WG > >>>> last call by this time, submission to IESG by this time. > >>> > >>> (Some help would be appreciated with this one). I think we still have > >>> to adjust the milestones a bit more to make sure everything is > >>> explicitly spelled out. I have tried to make the charter as concrete > >>> as possible, while still short enough to be manageable/readable. I > >>> would like the next revision to focus on the milestones. > >>> > >>> Can people please read this over and make comments/suggestions, with > >>> proposed text changes? That would be helpful. > >>> > >>> Thanks, > >>> TJ > >>> > >>> > >> > >> > >> > > > > > > -- Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Mon May 22 05:39:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi6st-00034l-UD; Mon, 22 May 2006 05:39:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi6ss-00034g-EY for nemo@ietf.org; Mon, 22 May 2006 05:39:30 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi6sp-00074I-ML for nemo@ietf.org; Mon, 22 May 2006 05:39:30 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id E3836212C5F; Mon, 22 May 2006 12:39:25 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id A8FD6212C5D; Mon, 22 May 2006 12:39:25 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id D96E1BDC41; Mon, 22 May 2006 12:39:24 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id 9FC3DBDC40; Mon, 22 May 2006 12:39:24 +0300 (EEST) In-Reply-To: <20060522102904.69ae4b8d.thierry.ernst@inria.fr> References: <4468F985.6070108@azairenet.com> <00bc01c67b15$d2e12d20$546015ac@dcml.docomolabsusa.com> <446E0440.9090402@azairenet.com> <20060522102904.69ae4b8d.thierry.ernst@inria.fr> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <5e81795c03948e25b67357279351498e@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] NEMO RO on the charter Date: Mon, 22 May 2006 12:39:24 +0300 To: Thierry Ernst X-Mailer: Apple Mail (2.624) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org El 22/05/2006, a las 11:29, Thierry Ernst escribi=F3: > > Hi James, > > I would say that yes, the problem is well enough understood, there > exists solutions, and even implementations (e.g. based on SHISA). The > question is rather what RO we would like to do i agree with this in particular i think we have saw during this charter discussion that =20= there are different use cases that may or may not have different =20 requirements for the RO solution, so, work is needed to characterize =20 this scenarios and decide which solutions fits better for those. so i agree that there are solutions that have been proposed that are =20 well understood but more work is needed in the definition of the use =20 cases. So i don't think this is reasearch and could perfectly be done =20= here (however it may well be the case that once we have characterized =20= the use cases, none of the solutions we have provides the required =20 features and we need to fall back to research mode to figure out a =20 solution...) Regards, marcelo > (between MNNs in the same > nested NEMO, between MNNs located in separated NEMO, or between the =20= > MNNs > and the infrastructure). I've also received personal comments that = NEMO > RO is needed for deployment of RFC 3963 at a wide scale. > > The wording of the new charter should be more explicit on RO - > Unfortunately I was not watching the mailing list during the =20 > March-April > time frame and the re-chartering discussion took me by surprise. I = have > to manage time to propose some text on this. > > To conclude, we do have the 2 drafts (RO Problem Statement and RO > solution space analysis). These drafts are providing good input for > deciding what is reasonable to do, so I would recommend everyone to =20= > read > them if it's not already done, and to take a look at the presentation > material from Vancouver. > > Thierry. > > > On Fri, 19 May 2006 10:45:36 -0700 > Vijay Devarapalli wrote: > >> James Kempf wrote: >>> Vijay, >>> >>> Do you believe the route optimzation problem is well enough =20 >>> understood, >>> from a research standpoint, that standardization of a general =20 >>> solution >>> is possible? =46rom the reading I've done, it seems like there is a >>> considerable diversity of opinion about the most technically optimal >>> approach. >> >> I need to do some reading myself. I haven't kept >> up to date on many of the route optimization >> solution drafts. :( >> >> well, we have a bunch of solutions and a draft >> that analyzes the solution space. >> http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-=20 >> analysis-02.txt >> >> based on this, we either decide to go ahead with >> working on a solution or decide we are not going >> to standardize a solution. another option is to >> standardize two or more solution drafts as >> experimental RFCs and see how it goes. >> >> the wording in the proposed charter is vague. it >> just says continue investigating (or something >> like that) the route optimization problem. >> >> Vijay >> >> >>> >>> jak >>> >>> ----- Original Message ----- From: "Vijay Devarapalli" >>> >>> To: "T.J. Kniveton" >>> Cc: "ml-nemo WG" >>> Sent: Monday, May 15, 2006 2:58 PM >>> Subject: Re: [nemo] New versions of charter >>> >>> >>>> hi TJ, >>>> >>>> my understanding was that there will also be a general >>>> purpose route optimization solution. and this solution >>>> would not depend on geographically distributed HAs. >>>> this is not mentioned anywhere in the charter. the >>>> charter only talks about "Analysis of the Solution >>>> Space for Route Optimization". >>>> >>>>> The working group has work items to describe a basic solution for >>>>> network mobility in IPv6-only networks, and to design a mechanism =20= >>>>> to >>>>> allow mixed IPv4/IPv6 networks, carrying signalling messages that >>>>> describe both IPv4 and IPv6 addresses and mobile network prefixes. = =20 >>>>> The >>>>> latter task is shared with the Mobile IPv6 working group, =20 >>>>> addressed by >>>>> a joint design team. >>>> >>>> this is just DS-MIPv6 (with appropriate extensions for >>>> IPv4 mobile network prefixes), right? nothing more. >>>> >>>> Vijay >>>> >>>> T.J. Kniveton wrote: >>>>> I have posted a new version of the proposed charter (on the web =20= >>>>> page) >>>>> to replace the April 30 version. Some of the changes include: >>>>> >>>>> - Added some text about v6, v4 and v4/v6 solution distinctions. >>>>> - Added some additional text throughout the tasks/nontasks >>>>> - Added editing and typo fixes as suggested >>>>> - Other suggested changes >>>>> >>>>> One remaining comment which I have not addressed yet: >>>>> >>>>> James Kempf wrote: >>>>>> I am very much in favor of making WG charters very specific. It >>>>>> helps to avoid ambiguity about what the WG is intending to >>>>>> accomplish, and also helps focus the energy of the WG and avoid >>>>>> having it become distracted by other proposals that tend to pop =20= >>>>>> up, >>>>>> until the originally promised work is completed. Therefore, I =20 >>>>>> would >>>>>> recommend that the charter include a bulleted list with three =20 >>>>>> items >>>>>> corresponding to each of these new drafts, with each item giving = a >>>>>> concise but complete description of what the promised draft is >>>>>> intended to accomplish. If there are existing individual drafts =20= >>>>>> that >>>>>> cover these, the descriptions can be based on the individual =20 >>>>>> drafts. >>>>>> Also, it might be helpful to be more specific about the goals and >>>>>> their timing. Rather than just a single goal, have a list that >>>>>> correspond to the process: 00 WG draft selected by this time, WG >>>>>> last call by this time, submission to IESG by this time. >>>>> >>>>> (Some help would be appreciated with this one). I think we still =20= >>>>> have >>>>> to adjust the milestones a bit more to make sure everything is >>>>> explicitly spelled out. I have tried to make the charter as =20 >>>>> concrete >>>>> as possible, while still short enough to be manageable/readable. I >>>>> would like the next revision to focus on the milestones. >>>>> >>>>> Can people please read this over and make comments/suggestions, =20= >>>>> with >>>>> proposed text changes? That would be helpful. >>>>> >>>>> Thanks, >>>>> TJ >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> > > > --=20 > Thierry ERNST, PhD > INRIA Rocquencourt Projet IMARA > +33 1 39 63 59 30 > > From nemo-bounces@ietf.org Mon May 22 07:28:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi8ah-0001f7-Sp; Mon, 22 May 2006 07:28:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi8ag-0001f2-HW for nemo@ietf.org; Mon, 22 May 2006 07:28:50 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi8ad-0003gL-Td for nemo@ietf.org; Mon, 22 May 2006 07:28:50 -0400 Message-ID: <017f01c67d93$0575ab60$566015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "marcelo bagnulo braun" , "Thierry Ernst" References: <4468F985.6070108@azairenet.com><00bc01c67b15$d2e12d20$546015ac@dcml.docomolabsusa.com><446E0440.9090402@azairenet.com><20060522102904.69ae4b8d.thierry.ernst@inria.fr> <5e81795c03948e25b67357279351498e@it.uc3m.es> Subject: Re: [nemo] NEMO RO on the charter Date: Mon, 22 May 2006 04:29:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: quoted-printable X-Spam-Score: 3.1 (+++) X-Scan-Signature: 612a16ba5c5f570bfc42b3ac5606ac53 Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I think it would be useful then to have a couple of concrete use cases. I= f=20 these are not in the problem statement and solution space analysis, then = I=20 think it would be best to add them. It has been a while since I took a l= ook=20 at these drafts, perhaps someone can post the file names or URLs so we ca= n=20 read them or are they already WG drafts? jak ----- Original Message -----=20 From: "marcelo bagnulo braun" To: "Thierry Ernst" Cc: Sent: Monday, May 22, 2006 2:39 AM Subject: Re: [nemo] NEMO RO on the charter El 22/05/2006, a las 11:29, Thierry Ernst escribi=F3: > > Hi James, > > I would say that yes, the problem is well enough understood, there > exists solutions, and even implementations (e.g. based on SHISA). The > question is rather what RO we would like to do i agree with this in particular i think we have saw during this charter discussion that there are different use cases that may or may not have different requirements for the RO solution, so, work is needed to characterize this scenarios and decide which solutions fits better for those. so i agree that there are solutions that have been proposed that are well understood but more work is needed in the definition of the use cases. So i don't think this is reasearch and could perfectly be done here (however it may well be the case that once we have characterized the use cases, none of the solutions we have provides the required features and we need to fall back to research mode to figure out a solution...) Regards, marcelo > (between MNNs in the same > nested NEMO, between MNNs located in separated NEMO, or between the MN= Ns > and the infrastructure). I've also received personal comments that NEMO > RO is needed for deployment of RFC 3963 at a wide scale. > > The wording of the new charter should be more explicit on RO - > Unfortunately I was not watching the mailing list during the March-Apr= il > time frame and the re-chartering discussion took me by surprise. I have > to manage time to propose some text on this. > > To conclude, we do have the 2 drafts (RO Problem Statement and RO > solution space analysis). These drafts are providing good input for > deciding what is reasonable to do, so I would recommend everyone to re= ad > them if it's not already done, and to take a look at the presentation > material from Vancouver. > > Thierry. > > > On Fri, 19 May 2006 10:45:36 -0700 > Vijay Devarapalli wrote: > >> James Kempf wrote: >>> Vijay, >>> >>> Do you believe the route optimzation problem is well enough understo= od, >>> from a research standpoint, that standardization of a general soluti= on >>> is possible? From the reading I've done, it seems like there is a >>> considerable diversity of opinion about the most technically optimal >>> approach. >> >> I need to do some reading myself. I haven't kept >> up to date on many of the route optimization >> solution drafts. :( >> >> well, we have a bunch of solutions and a draft >> that analyzes the solution space. >> http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-=20 >> analysis-02.txt >> >> based on this, we either decide to go ahead with >> working on a solution or decide we are not going >> to standardize a solution. another option is to >> standardize two or more solution drafts as >> experimental RFCs and see how it goes. >> >> the wording in the proposed charter is vague. it >> just says continue investigating (or something >> like that) the route optimization problem. >> >> Vijay >> >> >>> >>> jak >>> >>> ----- Original Message ----- From: "Vijay Devarapalli" >>> >>> To: "T.J. Kniveton" >>> Cc: "ml-nemo WG" >>> Sent: Monday, May 15, 2006 2:58 PM >>> Subject: Re: [nemo] New versions of charter >>> >>> >>>> hi TJ, >>>> >>>> my understanding was that there will also be a general >>>> purpose route optimization solution. and this solution >>>> would not depend on geographically distributed HAs. >>>> this is not mentioned anywhere in the charter. the >>>> charter only talks about "Analysis of the Solution >>>> Space for Route Optimization". >>>> >>>>> The working group has work items to describe a basic solution for >>>>> network mobility in IPv6-only networks, and to design a mechanism = to >>>>> allow mixed IPv4/IPv6 networks, carrying signalling messages that >>>>> describe both IPv4 and IPv6 addresses and mobile network prefixes.=20 >>>>> The >>>>> latter task is shared with the Mobile IPv6 working group, addresse= d=20 >>>>> by >>>>> a joint design team. >>>> >>>> this is just DS-MIPv6 (with appropriate extensions for >>>> IPv4 mobile network prefixes), right? nothing more. >>>> >>>> Vijay >>>> >>>> T.J. Kniveton wrote: >>>>> I have posted a new version of the proposed charter (on the web pa= ge) >>>>> to replace the April 30 version. Some of the changes include: >>>>> >>>>> - Added some text about v6, v4 and v4/v6 solution distinctions. >>>>> - Added some additional text throughout the tasks/nontasks >>>>> - Added editing and typo fixes as suggested >>>>> - Other suggested changes >>>>> >>>>> One remaining comment which I have not addressed yet: >>>>> >>>>> James Kempf wrote: >>>>>> I am very much in favor of making WG charters very specific. It >>>>>> helps to avoid ambiguity about what the WG is intending to >>>>>> accomplish, and also helps focus the energy of the WG and avoid >>>>>> having it become distracted by other proposals that tend to pop u= p, >>>>>> until the originally promised work is completed. Therefore, I wou= ld >>>>>> recommend that the charter include a bulleted list with three ite= ms >>>>>> corresponding to each of these new drafts, with each item giving a >>>>>> concise but complete description of what the promised draft is >>>>>> intended to accomplish. If there are existing individual drafts t= hat >>>>>> cover these, the descriptions can be based on the individual draf= ts. >>>>>> Also, it might be helpful to be more specific about the goals and >>>>>> their timing. Rather than just a single goal, have a list that >>>>>> correspond to the process: 00 WG draft selected by this time, WG >>>>>> last call by this time, submission to IESG by this time. >>>>> >>>>> (Some help would be appreciated with this one). I think we still h= ave >>>>> to adjust the milestones a bit more to make sure everything is >>>>> explicitly spelled out. I have tried to make the charter as concre= te >>>>> as possible, while still short enough to be manageable/readable. I >>>>> would like the next revision to focus on the milestones. >>>>> >>>>> Can people please read this over and make comments/suggestions, wi= th >>>>> proposed text changes? That would be helpful. >>>>> >>>>> Thanks, >>>>> TJ >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> > > > --=20 > Thierry ERNST, PhD > INRIA Rocquencourt Projet IMARA > +33 1 39 63 59 30 > > From nemo-bounces@ietf.org Mon May 22 07:36:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi8hi-0004GD-6Y; Mon, 22 May 2006 07:36:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi8hg-0004G8-PU for nemo@ietf.org; Mon, 22 May 2006 07:36:04 -0400 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi8hf-00046x-0c for nemo@ietf.org; Mon, 22 May 2006 07:36:04 -0400 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 6FE68212C63; Mon, 22 May 2006 14:36:01 +0300 (EEST) Received: from outside.nomadiclab.com (d146.nomadiclab.com [193.234.218.146]) by n2.nomadiclab.com (Postfix) with ESMTP id 0B433212C61; Mon, 22 May 2006 14:36:01 +0300 (EEST) Received: from outside.nomadiclab.com (localhost [127.0.0.1]) by outside.nomadiclab.com (Postfix) with ESMTP id 949FCBDC41; Mon, 22 May 2006 14:36:00 +0300 (EEST) Received: from [193.234.219.179] (w179.nomadiclab.com [193.234.219.179]) by outside.nomadiclab.com (Postfix) with ESMTP id 2FD20BDC40; Mon, 22 May 2006 14:36:00 +0300 (EEST) In-Reply-To: <017f01c67d93$0575ab60$566015ac@dcml.docomolabsusa.com> References: <4468F985.6070108@azairenet.com><00bc01c67b15$d2e12d20$546015ac@dcml.docomolabsusa.com><446E0440.9090402@azairenet.com><20060522102904.69ae4b8d.thierry.ernst@inria.fr> <5e81795c03948e25b67357279351498e@it.uc3m.es> <017f01c67d93$0575ab60$566015ac@dcml.docomolabsusa.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <96a76cdf496dcfb6b6ade05090a76f66@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] NEMO RO on the charter Date: Mon, 22 May 2006 14:35:58 +0300 To: "James Kempf" X-Mailer: Apple Mail (2.624) X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org actually, i think that the idea is to have independent drafts first in=20= order to figure out how speific are the requirements for each case... i=20= think that they are already working in the case for aviation=20 requirements (there was a preliminary requirements list ported by Terry=20= in the ml) If the result is that the different requirements for the different use=20= cases are somehow compatible then the idea would be to included them in=20= the general nemo requirement draft. If they are very specific, we may=20 well need separate drafts and even specific solutions for the different=20= use cases... (at least this is what i understood from the previous discussion on the=20= ml so far...) regards, marcelo El 22/05/2006, a las 14:29, James Kempf escribi=F3: > I think it would be useful then to have a couple of concrete use=20 > cases. If these are not in the problem statement and solution space=20 > analysis, then I think it would be best to add them. It has been a=20 > while since I took a look at these drafts, perhaps someone can post=20 > the file names or URLs so we can read them or are they already WG=20 > drafts? > > jak > > ----- Original Message ----- From: "marcelo bagnulo braun"=20 > > To: "Thierry Ernst" > Cc: > Sent: Monday, May 22, 2006 2:39 AM > Subject: Re: [nemo] NEMO RO on the charter > > > > El 22/05/2006, a las 11:29, Thierry Ernst escribi=F3: > >> >> Hi James, >> >> I would say that yes, the problem is well enough understood, there >> exists solutions, and even implementations (e.g. based on SHISA). The >> question is rather what RO we would like to do > > i agree with this > > in particular i think we have saw during this charter discussion that > there are different use cases that may or may not have different > requirements for the RO solution, so, work is needed to characterize > this scenarios and decide which solutions fits better for those. > > so i agree that there are solutions that have been proposed that are > well understood but more work is needed in the definition of the use > cases. So i don't think this is reasearch and could perfectly be done > here (however it may well be the case that once we have characterized > the use cases, none of the solutions we have provides the required > features and we need to fall back to research mode to figure out a > solution...) > > Regards, marcelo > >> (between MNNs in the same >> nested NEMO, between MNNs located in separated NEMO, or between the =20= >> MNNs >> and the infrastructure). I've also received personal comments that=20 >> NEMO >> RO is needed for deployment of RFC 3963 at a wide scale. >> >> The wording of the new charter should be more explicit on RO - >> Unfortunately I was not watching the mailing list during the =20 >> March-April >> time frame and the re-chartering discussion took me by surprise. I=20 >> have >> to manage time to propose some text on this. >> >> To conclude, we do have the 2 drafts (RO Problem Statement and RO >> solution space analysis). These drafts are providing good input for >> deciding what is reasonable to do, so I would recommend everyone to =20= >> read >> them if it's not already done, and to take a look at the presentation >> material from Vancouver. >> >> Thierry. >> >> >> On Fri, 19 May 2006 10:45:36 -0700 >> Vijay Devarapalli wrote: >> >>> James Kempf wrote: >>>> Vijay, >>>> >>>> Do you believe the route optimzation problem is well enough =20 >>>> understood, >>>> from a research standpoint, that standardization of a general =20 >>>> solution >>>> is possible? =46rom the reading I've done, it seems like there is a >>>> considerable diversity of opinion about the most technically = optimal >>>> approach. >>> >>> I need to do some reading myself. I haven't kept >>> up to date on many of the route optimization >>> solution drafts. :( >>> >>> well, we have a bunch of solutions and a draft >>> that analyzes the solution space. >>> http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-=20 >>> analysis-02.txt >>> >>> based on this, we either decide to go ahead with >>> working on a solution or decide we are not going >>> to standardize a solution. another option is to >>> standardize two or more solution drafts as >>> experimental RFCs and see how it goes. >>> >>> the wording in the proposed charter is vague. it >>> just says continue investigating (or something >>> like that) the route optimization problem. >>> >>> Vijay >>> >>> >>>> >>>> jak >>>> >>>> ----- Original Message ----- From: "Vijay Devarapalli" >>>> >>>> To: "T.J. Kniveton" >>>> Cc: "ml-nemo WG" >>>> Sent: Monday, May 15, 2006 2:58 PM >>>> Subject: Re: [nemo] New versions of charter >>>> >>>> >>>>> hi TJ, >>>>> >>>>> my understanding was that there will also be a general >>>>> purpose route optimization solution. and this solution >>>>> would not depend on geographically distributed HAs. >>>>> this is not mentioned anywhere in the charter. the >>>>> charter only talks about "Analysis of the Solution >>>>> Space for Route Optimization". >>>>> >>>>>> The working group has work items to describe a basic solution for >>>>>> network mobility in IPv6-only networks, and to design a mechanism=20= >>>>>> to >>>>>> allow mixed IPv4/IPv6 networks, carrying signalling messages that >>>>>> describe both IPv4 and IPv6 addresses and mobile network=20 >>>>>> prefixes. The >>>>>> latter task is shared with the Mobile IPv6 working group, =20 >>>>>> addressed by >>>>>> a joint design team. >>>>> >>>>> this is just DS-MIPv6 (with appropriate extensions for >>>>> IPv4 mobile network prefixes), right? nothing more. >>>>> >>>>> Vijay >>>>> >>>>> T.J. Kniveton wrote: >>>>>> I have posted a new version of the proposed charter (on the web =20= >>>>>> page) >>>>>> to replace the April 30 version. Some of the changes include: >>>>>> >>>>>> - Added some text about v6, v4 and v4/v6 solution distinctions. >>>>>> - Added some additional text throughout the tasks/nontasks >>>>>> - Added editing and typo fixes as suggested >>>>>> - Other suggested changes >>>>>> >>>>>> One remaining comment which I have not addressed yet: >>>>>> >>>>>> James Kempf wrote: >>>>>>> I am very much in favor of making WG charters very specific. It >>>>>>> helps to avoid ambiguity about what the WG is intending to >>>>>>> accomplish, and also helps focus the energy of the WG and avoid >>>>>>> having it become distracted by other proposals that tend to pop =20= >>>>>>> up, >>>>>>> until the originally promised work is completed. Therefore, I =20= >>>>>>> would >>>>>>> recommend that the charter include a bulleted list with three =20= >>>>>>> items >>>>>>> corresponding to each of these new drafts, with each item giving=20= >>>>>>> a >>>>>>> concise but complete description of what the promised draft is >>>>>>> intended to accomplish. If there are existing individual drafts =20= >>>>>>> that >>>>>>> cover these, the descriptions can be based on the individual =20 >>>>>>> drafts. >>>>>>> Also, it might be helpful to be more specific about the goals = and >>>>>>> their timing. Rather than just a single goal, have a list that >>>>>>> correspond to the process: 00 WG draft selected by this time, WG >>>>>>> last call by this time, submission to IESG by this time. >>>>>> >>>>>> (Some help would be appreciated with this one). I think we still =20= >>>>>> have >>>>>> to adjust the milestones a bit more to make sure everything is >>>>>> explicitly spelled out. I have tried to make the charter as =20 >>>>>> concrete >>>>>> as possible, while still short enough to be manageable/readable. = I >>>>>> would like the next revision to focus on the milestones. >>>>>> >>>>>> Can people please read this over and make comments/suggestions, =20= >>>>>> with >>>>>> proposed text changes? That would be helpful. >>>>>> >>>>>> Thanks, >>>>>> TJ >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >> --=20 >> Thierry ERNST, PhD >> INRIA Rocquencourt Projet IMARA >> +33 1 39 63 59 30 >> >> > > > > From nemo-bounces@ietf.org Mon May 22 07:45:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi8r2-000757-1H; Mon, 22 May 2006 07:45:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi8r1-00072V-6m for nemo@ietf.org; Mon, 22 May 2006 07:45:43 -0400 Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi8qz-0004iT-IP for nemo@ietf.org; Mon, 22 May 2006 07:45:43 -0400 Message-ID: <01bd01c67d95$6297c330$566015ac@dcml.docomolabsusa.com> From: "James Kempf" To: "marcelo bagnulo braun" References: <4468F985.6070108@azairenet.com><00bc01c67b15$d2e12d20$546015ac@dcml.docomolabsusa.com><446E0440.9090402@azairenet.com><20060522102904.69ae4b8d.thierry.ernst@inria.fr> <5e81795c03948e25b67357279351498e@it.uc3m.es> <017f01c67d93$0575ab60$566015ac@dcml.docomolabsusa.com> <96a76cdf496dcfb6b6ade05090a76f66@it.uc3m.es> Subject: Re: [nemo] NEMO RO on the charter Date: Mon, 22 May 2006 04:46:32 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: quoted-printable X-Spam-Score: 3.1 (+++) X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1 Cc: nemo@ietf.org, Thierry Ernst X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Sounds fine. jak ----- Original Message -----=20 From: "marcelo bagnulo braun" To: "James Kempf" Cc: "Thierry Ernst" ; Sent: Monday, May 22, 2006 4:35 AM Subject: Re: [nemo] NEMO RO on the charter actually, i think that the idea is to have independent drafts first in order to figure out how speific are the requirements for each case... i think that they are already working in the case for aviation requirements (there was a preliminary requirements list ported by Terry in the ml) If the result is that the different requirements for the different use cases are somehow compatible then the idea would be to included them in the general nemo requirement draft. If they are very specific, we may well need separate drafts and even specific solutions for the different use cases... (at least this is what i understood from the previous discussion on the ml so far...) regards, marcelo El 22/05/2006, a las 14:29, James Kempf escribi=F3: > I think it would be useful then to have a couple of concrete use cases.= If=20 > these are not in the problem statement and solution space analysis, the= n I=20 > think it would be best to add them. It has been a while since I took a= =20 > look at these drafts, perhaps someone can post the file names or URLs s= o=20 > we can read them or are they already WG drafts? > > jak > > ----- Original Message ----- From: "marcelo bagnulo braun"=20 > > To: "Thierry Ernst" > Cc: > Sent: Monday, May 22, 2006 2:39 AM > Subject: Re: [nemo] NEMO RO on the charter > > > > El 22/05/2006, a las 11:29, Thierry Ernst escribi=F3: > >> >> Hi James, >> >> I would say that yes, the problem is well enough understood, there >> exists solutions, and even implementations (e.g. based on SHISA). The >> question is rather what RO we would like to do > > i agree with this > > in particular i think we have saw during this charter discussion that > there are different use cases that may or may not have different > requirements for the RO solution, so, work is needed to characterize > this scenarios and decide which solutions fits better for those. > > so i agree that there are solutions that have been proposed that are > well understood but more work is needed in the definition of the use > cases. So i don't think this is reasearch and could perfectly be done > here (however it may well be the case that once we have characterized > the use cases, none of the solutions we have provides the required > features and we need to fall back to research mode to figure out a > solution...) > > Regards, marcelo > >> (between MNNs in the same >> nested NEMO, between MNNs located in separated NEMO, or between the M= NNs >> and the infrastructure). I've also received personal comments that NEM= O >> RO is needed for deployment of RFC 3963 at a wide scale. >> >> The wording of the new charter should be more explicit on RO - >> Unfortunately I was not watching the mailing list during the March-Ap= ril >> time frame and the re-chartering discussion took me by surprise. I hav= e >> to manage time to propose some text on this. >> >> To conclude, we do have the 2 drafts (RO Problem Statement and RO >> solution space analysis). These drafts are providing good input for >> deciding what is reasonable to do, so I would recommend everyone to r= ead >> them if it's not already done, and to take a look at the presentation >> material from Vancouver. >> >> Thierry. >> >> >> On Fri, 19 May 2006 10:45:36 -0700 >> Vijay Devarapalli wrote: >> >>> James Kempf wrote: >>>> Vijay, >>>> >>>> Do you believe the route optimzation problem is well enough=20 >>>> understood, >>>> from a research standpoint, that standardization of a general solut= ion >>>> is possible? From the reading I've done, it seems like there is a >>>> considerable diversity of opinion about the most technically optimal >>>> approach. >>> >>> I need to do some reading myself. I haven't kept >>> up to date on many of the route optimization >>> solution drafts. :( >>> >>> well, we have a bunch of solutions and a draft >>> that analyzes the solution space. >>> http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-=20 >>> analysis-02.txt >>> >>> based on this, we either decide to go ahead with >>> working on a solution or decide we are not going >>> to standardize a solution. another option is to >>> standardize two or more solution drafts as >>> experimental RFCs and see how it goes. >>> >>> the wording in the proposed charter is vague. it >>> just says continue investigating (or something >>> like that) the route optimization problem. >>> >>> Vijay >>> >>> >>>> >>>> jak >>>> >>>> ----- Original Message ----- From: "Vijay Devarapalli" >>>> >>>> To: "T.J. Kniveton" >>>> Cc: "ml-nemo WG" >>>> Sent: Monday, May 15, 2006 2:58 PM >>>> Subject: Re: [nemo] New versions of charter >>>> >>>> >>>>> hi TJ, >>>>> >>>>> my understanding was that there will also be a general >>>>> purpose route optimization solution. and this solution >>>>> would not depend on geographically distributed HAs. >>>>> this is not mentioned anywhere in the charter. the >>>>> charter only talks about "Analysis of the Solution >>>>> Space for Route Optimization". >>>>> >>>>>> The working group has work items to describe a basic solution for >>>>>> network mobility in IPv6-only networks, and to design a mechanism = to >>>>>> allow mixed IPv4/IPv6 networks, carrying signalling messages that >>>>>> describe both IPv4 and IPv6 addresses and mobile network prefixes.= =20 >>>>>> The >>>>>> latter task is shared with the Mobile IPv6 working group, address= ed=20 >>>>>> by >>>>>> a joint design team. >>>>> >>>>> this is just DS-MIPv6 (with appropriate extensions for >>>>> IPv4 mobile network prefixes), right? nothing more. >>>>> >>>>> Vijay >>>>> >>>>> T.J. Kniveton wrote: >>>>>> I have posted a new version of the proposed charter (on the web=20 >>>>>> page) >>>>>> to replace the April 30 version. Some of the changes include: >>>>>> >>>>>> - Added some text about v6, v4 and v4/v6 solution distinctions. >>>>>> - Added some additional text throughout the tasks/nontasks >>>>>> - Added editing and typo fixes as suggested >>>>>> - Other suggested changes >>>>>> >>>>>> One remaining comment which I have not addressed yet: >>>>>> >>>>>> James Kempf wrote: >>>>>>> I am very much in favor of making WG charters very specific. It >>>>>>> helps to avoid ambiguity about what the WG is intending to >>>>>>> accomplish, and also helps focus the energy of the WG and avoid >>>>>>> having it become distracted by other proposals that tend to pop = up, >>>>>>> until the originally promised work is completed. Therefore, I wo= uld >>>>>>> recommend that the charter include a bulleted list with three it= ems >>>>>>> corresponding to each of these new drafts, with each item giving = a >>>>>>> concise but complete description of what the promised draft is >>>>>>> intended to accomplish. If there are existing individual drafts=20 >>>>>>> that >>>>>>> cover these, the descriptions can be based on the individual=20 >>>>>>> drafts. >>>>>>> Also, it might be helpful to be more specific about the goals and >>>>>>> their timing. Rather than just a single goal, have a list that >>>>>>> correspond to the process: 00 WG draft selected by this time, WG >>>>>>> last call by this time, submission to IESG by this time. >>>>>> >>>>>> (Some help would be appreciated with this one). I think we still=20 >>>>>> have >>>>>> to adjust the milestones a bit more to make sure everything is >>>>>> explicitly spelled out. I have tried to make the charter as concr= ete >>>>>> as possible, while still short enough to be manageable/readable. I >>>>>> would like the next revision to focus on the milestones. >>>>>> >>>>>> Can people please read this over and make comments/suggestions, w= ith >>>>>> proposed text changes? That would be helpful. >>>>>> >>>>>> Thanks, >>>>>> TJ >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >> --=20 >> Thierry ERNST, PhD >> INRIA Rocquencourt Projet IMARA >> +33 1 39 63 59 30 >> >> > > > > From nemo-bounces@ietf.org Mon May 22 07:53:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi8yR-0000TI-4C; Mon, 22 May 2006 07:53:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fi8yQ-0000TD-0d for nemo@ietf.org; Mon, 22 May 2006 07:53:22 -0400 Received: from nez-perce.inria.fr ([192.93.2.78]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fi8yO-0005C6-CK for nemo@ietf.org; Mon, 22 May 2006 07:53:21 -0400 Received: from guest-rocq-135223.inria.fr (dhcp-rocq-97.inria.fr [128.93.62.97]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k4MBrJq0031197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 May 2006 13:53:19 +0200 Date: Mon, 22 May 2006 13:54:35 +0200 From: Thierry Ernst To: nemo@ietf.org Subject: Re: [nemo] NEMO RO on the charter Message-Id: <20060522135435.4165abc4.thierry.ernst@inria.fr> In-Reply-To: <017f01c67d93$0575ab60$566015ac@dcml.docomolabsusa.com> References: <4468F985.6070108@azairenet.com> <00bc01c67b15$d2e12d20$546015ac@dcml.docomolabsusa.com> <446E0440.9090402@azairenet.com> <20060522102904.69ae4b8d.thierry.ernst@inria.fr> <5e81795c03948e25b67357279351498e@it.uc3m.es> <017f01c67d93$0575ab60$566015ac@dcml.docomolabsusa.com> Organization: INRIA X-Mailer: Sylpheed version 0.9.12 (GTK+ 1.2.10; powerpc-apple-darwin7.8.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP X-Miltered: at nez-perce with ID 4471A62F.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by nez-perce.inria.fr id k4MBrJq0031197 X-Spam-Score: 0.0 (/) X-Scan-Signature: ed68cc91cc637fea89623888898579ba X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org On Mon, 22 May 2006 04:29:37 -0700 "James Kempf" wrote: > I think it would be useful then to have a couple of concrete use cases.= If=20 > these are not in the problem statement and solution space analysis, the= n I=20 > think it would be best to add them. It has been a while since I took a= look=20 > at these drafts, perhaps someone can post the file names or URLs so we = can=20 > read them or are they already WG drafts? They are WG document and as such are available on the NEMO WG charter page. Note that these documents have reached WG last call and have been / are being sent to the IESG. Thierry. > jak >=20 > ----- Original Message -----=20 > From: "marcelo bagnulo braun" > To: "Thierry Ernst" > Cc: > Sent: Monday, May 22, 2006 2:39 AM > Subject: Re: [nemo] NEMO RO on the charter >=20 >=20 >=20 > El 22/05/2006, a las 11:29, Thierry Ernst escribi=F3: >=20 > > > > Hi James, > > > > I would say that yes, the problem is well enough understood, there > > exists solutions, and even implementations (e.g. based on SHISA). The > > question is rather what RO we would like to do >=20 > i agree with this >=20 > in particular i think we have saw during this charter discussion that > there are different use cases that may or may not have different > requirements for the RO solution, so, work is needed to characterize > this scenarios and decide which solutions fits better for those. >=20 > so i agree that there are solutions that have been proposed that are > well understood but more work is needed in the definition of the use > cases. So i don't think this is reasearch and could perfectly be done > here (however it may well be the case that once we have characterized > the use cases, none of the solutions we have provides the required > features and we need to fall back to research mode to figure out a > solution...) >=20 > Regards, marcelo >=20 > > (between MNNs in the same > > nested NEMO, between MNNs located in separated NEMO, or between the = MNNs > > and the infrastructure). I've also received personal comments that NE= MO > > RO is needed for deployment of RFC 3963 at a wide scale. > > > > The wording of the new charter should be more explicit on RO - > > Unfortunately I was not watching the mailing list during the March-A= pril > > time frame and the re-chartering discussion took me by surprise. I ha= ve > > to manage time to propose some text on this. > > > > To conclude, we do have the 2 drafts (RO Problem Statement and RO > > solution space analysis). These drafts are providing good input for > > deciding what is reasonable to do, so I would recommend everyone to = read > > them if it's not already done, and to take a look at the presentation > > material from Vancouver. > > > > Thierry. > > > > > > On Fri, 19 May 2006 10:45:36 -0700 > > Vijay Devarapalli wrote: > > > >> James Kempf wrote: > >>> Vijay, > >>> > >>> Do you believe the route optimzation problem is well enough unders= tood, > >>> from a research standpoint, that standardization of a general solu= tion > >>> is possible? From the reading I've done, it seems like there is a > >>> considerable diversity of opinion about the most technically optima= l > >>> approach. > >> > >> I need to do some reading myself. I haven't kept > >> up to date on many of the route optimization > >> solution drafts. :( > >> > >> well, we have a bunch of solutions and a draft > >> that analyzes the solution space. > >> http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-=20 > >> analysis-02.txt > >> > >> based on this, we either decide to go ahead with > >> working on a solution or decide we are not going > >> to standardize a solution. another option is to > >> standardize two or more solution drafts as > >> experimental RFCs and see how it goes. > >> > >> the wording in the proposed charter is vague. it > >> just says continue investigating (or something > >> like that) the route optimization problem. > >> > >> Vijay > >> > >> > >>> > >>> jak > >>> > >>> ----- Original Message ----- From: "Vijay Devarapalli" > >>> > >>> To: "T.J. Kniveton" > >>> Cc: "ml-nemo WG" > >>> Sent: Monday, May 15, 2006 2:58 PM > >>> Subject: Re: [nemo] New versions of charter > >>> > >>> > >>>> hi TJ, > >>>> > >>>> my understanding was that there will also be a general > >>>> purpose route optimization solution. and this solution > >>>> would not depend on geographically distributed HAs. > >>>> this is not mentioned anywhere in the charter. the > >>>> charter only talks about "Analysis of the Solution > >>>> Space for Route Optimization". > >>>> > >>>>> The working group has work items to describe a basic solution for > >>>>> network mobility in IPv6-only networks, and to design a mechanism= to > >>>>> allow mixed IPv4/IPv6 networks, carrying signalling messages that > >>>>> describe both IPv4 and IPv6 addresses and mobile network prefixes= .=20 > >>>>> The > >>>>> latter task is shared with the Mobile IPv6 working group, addres= sed=20 > >>>>> by > >>>>> a joint design team. > >>>> > >>>> this is just DS-MIPv6 (with appropriate extensions for > >>>> IPv4 mobile network prefixes), right? nothing more. > >>>> > >>>> Vijay > >>>> > >>>> T.J. Kniveton wrote: > >>>>> I have posted a new version of the proposed charter (on the web = page) > >>>>> to replace the April 30 version. Some of the changes include: > >>>>> > >>>>> - Added some text about v6, v4 and v4/v6 solution distinctions. > >>>>> - Added some additional text throughout the tasks/nontasks > >>>>> - Added editing and typo fixes as suggested > >>>>> - Other suggested changes > >>>>> > >>>>> One remaining comment which I have not addressed yet: > >>>>> > >>>>> James Kempf wrote: > >>>>>> I am very much in favor of making WG charters very specific. It > >>>>>> helps to avoid ambiguity about what the WG is intending to > >>>>>> accomplish, and also helps focus the energy of the WG and avoid > >>>>>> having it become distracted by other proposals that tend to pop = up, > >>>>>> until the originally promised work is completed. Therefore, I w= ould > >>>>>> recommend that the charter include a bulleted list with three i= tems > >>>>>> corresponding to each of these new drafts, with each item giving= a > >>>>>> concise but complete description of what the promised draft is > >>>>>> intended to accomplish. If there are existing individual drafts = that > >>>>>> cover these, the descriptions can be based on the individual dr= afts. > >>>>>> Also, it might be helpful to be more specific about the goals an= d > >>>>>> their timing. Rather than just a single goal, have a list that > >>>>>> correspond to the process: 00 WG draft selected by this time, WG > >>>>>> last call by this time, submission to IESG by this time. > >>>>> > >>>>> (Some help would be appreciated with this one). I think we still = have > >>>>> to adjust the milestones a bit more to make sure everything is > >>>>> explicitly spelled out. I have tried to make the charter as conc= rete > >>>>> as possible, while still short enough to be manageable/readable. = I > >>>>> would like the next revision to focus on the milestones. > >>>>> > >>>>> Can people please read this over and make comments/suggestions, = with > >>>>> proposed text changes? That would be helpful. > >>>>> > >>>>> Thanks, > >>>>> TJ > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >> > >> > > > > > > --=20 > > Thierry ERNST, PhD > > INRIA Rocquencourt Projet IMARA > > +33 1 39 63 59 30 > > > > >=20 >=20 >=20 >=20 >=20 >=20 --=20 Thierry ERNST, PhD INRIA Rocquencourt Projet IMARA +33 1 39 63 59 30 From nemo-bounces@ietf.org Tue May 23 05:20:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiT4J-00052g-Ub; Tue, 23 May 2006 05:20:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiT4J-00052b-BX for nemo@ietf.org; Tue, 23 May 2006 05:20:47 -0400 Received: from av7-1-sn3.vrr.skanova.net ([81.228.9.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiT4H-0004ja-SW for nemo@ietf.org; Tue, 23 May 2006 05:20:47 -0400 Received: by av7-1-sn3.vrr.skanova.net (Postfix, from userid 502) id 0176D38035; Tue, 23 May 2006 10:56:26 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av7-1-sn3.vrr.skanova.net (Postfix) with ESMTP id E65FF37F9B; Tue, 23 May 2006 10:56:26 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id E70D337E43; Tue, 23 May 2006 11:20:44 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.61) (envelope-from ) id 1FiT41-0004mw-Jm; Tue, 23 May 2006 11:20:40 +0200 Message-ID: <4472D3DD.306@levkowetz.com> Date: Tue, 23 May 2006 11:20:29 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: "Narayanan, Vidya" Subject: Re: [nemo] Potential conflict on NEMOv4 Type and FA-ERR Type References: <2EBB8025B6D1BA41B567DB32C1D8DB84882B16@NAEX06.na.qualcomm.com> In-Reply-To: <2EBB8025B6D1BA41B567DB32C1D8DB84882B16@NAEX06.na.qualcomm.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi, I'd strongly suggest that you *don't* code in any specific extension number - that will just make for more trouble up the line. For experimental and test deployment, you should instead use the experimental type numbers (and if needed message number) defined by RFC 4064, and listed on http://www.iana.org/assignments/mobileip-numbers - one reason they were added were previous instances of collisions between IANA-assigned numbers and 'self-assigned' numbers such as 45/46 below, and many man-hours of work spent disentangling such collisions. Regards, Henrik on 2006-05-19 20:05 Narayanan, Vidya said the following: > Sounds good to me. > >> -----Original Message----- >> From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] >> Sent: Friday, May 19, 2006 9:51 AM >> To: ml-nemo WG >> Subject: [nemo] Potential conflict on NEMOv4 Type and FA-ERR Type >> >> I've been pointed that there seems to be a potential conflict >> on NEMOv4 Mobile Network Extension Type and FA-Err Type. >> >> NEMOv4 uses a new Type (to be assigned by IANA) in Mobile >> Network Extension. We suggested in the draft that it be 45. >> >> FA-ERR draft-ietf-mip4-faerr-02.txt uses Type 45 for FA Error >> Extension (already assigned by IANA). The draft does not >> specify 45, just says TBA by IANA. IANA seems to have >> assigned it, see http://www.iana.org/assignments/mobileip-numbers. >> >> draft-ietf-mobileip-gen-key-01.txt implemented in dynamics >> 0.8.1 uses 45 too, but I think this can be ignored, because >> I think this work has been evolved into draft-rfc3012bis >> which uses Type 24. >> >> To solve the issue between NEMOv4 and FA-ERR I suggest that >> we use Type >> 46 - and not 45 - in NEMOv4 implementation, until IANA >> assigns a Type for NEMOv4 Mobile Network Extension. >> >> What do you think? >> >> Alex >> >> > > From nemo-bounces@ietf.org Tue May 23 05:22:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiT6M-00068L-8w; Tue, 23 May 2006 05:22:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FiT6L-00068G-61 for nemo@ietf.org; Tue, 23 May 2006 05:22:53 -0400 Received: from av6-2-sn3.vrr.skanova.net ([81.228.9.180]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FiT6J-0004p0-NW for nemo@ietf.org; Tue, 23 May 2006 05:22:53 -0400 Received: by av6-2-sn3.vrr.skanova.net (Postfix, from userid 502) id 1E63C3823D; Tue, 23 May 2006 11:22:51 +0200 (CEST) Received: from smtp3-2-sn3.vrr.skanova.net (smtp3-2-sn3.vrr.skanova.net [81.228.9.102]) by av6-2-sn3.vrr.skanova.net (Postfix) with ESMTP id 10A8538193; Tue, 23 May 2006 11:22:51 +0200 (CEST) Received: from shiraz.levkowetz.com (81-232-110-214-no16.tbcn.telia.com [81.232.110.214]) by smtp3-2-sn3.vrr.skanova.net (Postfix) with ESMTP id A653137E51; Tue, 23 May 2006 11:22:47 +0200 (CEST) Received: from localhost ([127.0.0.1]) by shiraz.levkowetz.com with esmtp (Exim 4.61) (envelope-from ) id 1FiT65-0002RS-6G; Tue, 23 May 2006 11:22:37 +0200 Message-ID: <4472D45D.5030008@levkowetz.com> Date: Tue, 23 May 2006 11:22:37 +0200 From: Henrik Levkowetz User-Agent: Thunderbird 1.5.0.2 (Macintosh/20060308) MIME-Version: 1.0 To: "Tsirtsis, George" Subject: Re: [nemo] Potential conflict on NEMOv4 Type and FA-ERR Type References: <1487A357FD2ED544B8AD29E528FF9DF0029BDB96@NAEX06.na.qualcomm.com> In-Reply-To: <1487A357FD2ED544B8AD29E528FF9DF0029BDB96@NAEX06.na.qualcomm.com> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Scanned: No (on shiraz.levkowetz.com); SAEximRunCond expanded to false X-Spam-Score: 0.1 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: ml-nemo WG , Vijay Devarapalli X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi George, on 2006-05-19 20:32 Tsirtsis, George said the following: > Yes, I think Vijay is right. It is up to IANA and implementations need > to be ready to change to the assigned numbers when the IANA decides. In > the mean time I-D authors can suggest reasonable values just in case > they get it right and so they do not have to change ;-) No, please don't do this. Instead, as I just mentioned in my note to Vidya, please use the values assigned for experimental work, and leave the value in the draft as TBA. Regards, Henrik >> -----Original Message----- >> From: Vijay Devarapalli [mailto:vijay.devarapalli@azairenet.com] >> Sent: Friday, May 19, 2006 2:21 PM >> To: Alexandru Petrescu >> Cc: ml-nemo WG >> Subject: Re: [nemo] Potential conflict on NEMOv4 Type and FA-ERR Type >> >> Alexandru Petrescu wrote: >> > I've been pointed that there seems to be a potential conflict on > NEMOv4 >> > Mobile Network Extension Type and FA-Err Type. >> > >> > NEMOv4 uses a new Type (to be assigned by IANA) in Mobile Network >> > Extension. We suggested in the draft that it be 45. >> > >> > FA-ERR draft-ietf-mip4-faerr-02.txt uses Type 45 for FA Error > Extension >> > (already assigned by IANA). The draft does not specify 45, just > says >> > TBA by IANA. IANA seems to have assigned it, see >> > http://www.iana.org/assignments/mobileip-numbers. >> > >> > draft-ietf-mobileip-gen-key-01.txt implemented in dynamics 0.8.1 > uses 45 >> > too, but I think this can be ignored, because I think this work has >> > been evolved into draft-rfc3012bis which uses Type 24. >> > >> > To solve the issue between NEMOv4 and FA-ERR I suggest that we use > Type >> > 46 - and not 45 - in NEMOv4 implementation, until IANA assigns a > Type >> > for NEMOv4 Mobile Network Extension. >> > >> > What do you think? >> >> IMO, you should leave it to be assigned by the IANA. >> not suggest any value at all. IANA will just pick >> the next available one. >> >> Vijay > > > From nemo-bounces@ietf.org Tue May 23 14:06:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FibHA-0008OS-SB; Tue, 23 May 2006 14:06:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FibH9-0008ON-Gs for nemo@ietf.org; Tue, 23 May 2006 14:06:35 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FibH7-0003B9-NX for nemo@ietf.org; Tue, 23 May 2006 14:06:35 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AA4969536A for ; Tue, 23 May 2006 20:06:32 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 82399951E6 for ; Tue, 23 May 2006 20:06:32 +0200 (CEST) Received: from kone74.eurocity3.vip.fi (kone74.eurocity3.vip.fi [212.149.115.75]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Tue, 23 May 2006 20:06:30 +0200 Message-ID: <20060523200630.ghd4ecsek5mscggw@webcartero01.uc3m.es> Date: Tue, 23 May 2006 20:06:30 +0200 From: MARCELO BAGNULO BRAUN To: nemo@ietf.org Subject: Re: [nemo] NEMO RO on the charter References: <4468F985.6070108@azairenet.com><00bc01c67b15$d2e12d20$546015ac@dcml.docomolabsusa.com><446E0440.9090402@azairenet.com><20060522102904.69ae4b8d.thierry.ernst@inria.fr> <5e81795c03948e25b67357279351498e@it.uc3m.es> <017f01c67d93$0575ab60$566015ac@dcml.docomolabsusa.com> In-Reply-To: <017f01c67d93$0575ab60$566015ac@dcml.docomolabsusa.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Spam-Score: 0.0 (/) X-Scan-Signature: a4a24b484706be629f915bfb1a3e4771 X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org here they are: http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-problem-statement-02= .txt http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space-analysis-02.tx= t regards, marcelo James Kempf dijo: > I think it would be useful then to have a couple of concrete use > cases. If these are not in the problem statement and solution space > analysis, then I think it would be best to add them. It has been a > while since I took a look at these drafts, perhaps someone can post > the file names or URLs so we can read them or are they already WG > drafts? > > jak > > ----- Original Message ----- From: "marcelo bagnulo braun" > > To: "Thierry Ernst" > Cc: > Sent: Monday, May 22, 2006 2:39 AM > Subject: Re: [nemo] NEMO RO on the charter > > > > El 22/05/2006, a las 11:29, Thierry Ernst escribi=F3: > >> >> Hi James, >> >> I would say that yes, the problem is well enough understood, there >> exists solutions, and even implementations (e.g. based on SHISA). The >> question is rather what RO we would like to do > > i agree with this > > in particular i think we have saw during this charter discussion that > there are different use cases that may or may not have different > requirements for the RO solution, so, work is needed to characterize > this scenarios and decide which solutions fits better for those. > > so i agree that there are solutions that have been proposed that are > well understood but more work is needed in the definition of the use > cases. So i don't think this is reasearch and could perfectly be done > here (however it may well be the case that once we have characterized > the use cases, none of the solutions we have provides the required > features and we need to fall back to research mode to figure out a > solution...) > > Regards, marcelo > >> (between MNNs in the same >> nested NEMO, between MNNs located in separated NEMO, or between the MNN= s >> and the infrastructure). I've also received personal comments that NEMO >> RO is needed for deployment of RFC 3963 at a wide scale. >> >> The wording of the new charter should be more explicit on RO - >> Unfortunately I was not watching the mailing list during the March-Apri= l >> time frame and the re-chartering discussion took me by surprise. I have >> to manage time to propose some text on this. >> >> To conclude, we do have the 2 drafts (RO Problem Statement and RO >> solution space analysis). These drafts are providing good input for >> deciding what is reasonable to do, so I would recommend everyone to rea= d >> them if it's not already done, and to take a look at the presentation >> material from Vancouver. >> >> Thierry. >> >> >> On Fri, 19 May 2006 10:45:36 -0700 >> Vijay Devarapalli wrote: >> >>> James Kempf wrote: >>>> Vijay, >>>> >>>> Do you believe the route optimzation problem is well enough understoo= d, >>>> from a research standpoint, that standardization of a general solutio= n >>>> is possible? From the reading I've done, it seems like there is a >>>> considerable diversity of opinion about the most technically optimal >>>> approach. >>> >>> I need to do some reading myself. I haven't kept >>> up to date on many of the route optimization >>> solution drafts. :( >>> >>> well, we have a bunch of solutions and a draft >>> that analyzes the solution space. >>> http://www.ietf.org/internet-drafts/draft-ietf-nemo-ro-space- >>> analysis-02.txt >>> >>> based on this, we either decide to go ahead with >>> working on a solution or decide we are not going >>> to standardize a solution. another option is to >>> standardize two or more solution drafts as >>> experimental RFCs and see how it goes. >>> >>> the wording in the proposed charter is vague. it >>> just says continue investigating (or something >>> like that) the route optimization problem. >>> >>> Vijay >>> >>> >>>> >>>> jak >>>> >>>> ----- Original Message ----- From: "Vijay Devarapalli" >>>> >>>> To: "T.J. Kniveton" >>>> Cc: "ml-nemo WG" >>>> Sent: Monday, May 15, 2006 2:58 PM >>>> Subject: Re: [nemo] New versions of charter >>>> >>>> >>>>> hi TJ, >>>>> >>>>> my understanding was that there will also be a general >>>>> purpose route optimization solution. and this solution >>>>> would not depend on geographically distributed HAs. >>>>> this is not mentioned anywhere in the charter. the >>>>> charter only talks about "Analysis of the Solution >>>>> Space for Route Optimization". >>>>> >>>>>> The working group has work items to describe a basic solution for >>>>>> network mobility in IPv6-only networks, and to design a mechanism t= o >>>>>> allow mixed IPv4/IPv6 networks, carrying signalling messages that >>>>>> describe both IPv4 and IPv6 addresses and mobile network prefixes. T= he >>>>>> latter task is shared with the Mobile IPv6 working group, addressed= by >>>>>> a joint design team. >>>>> >>>>> this is just DS-MIPv6 (with appropriate extensions for >>>>> IPv4 mobile network prefixes), right? nothing more. >>>>> >>>>> Vijay >>>>> >>>>> T.J. Kniveton wrote: >>>>>> I have posted a new version of the proposed charter (on the web pag= e) >>>>>> to replace the April 30 version. Some of the changes include: >>>>>> >>>>>> - Added some text about v6, v4 and v4/v6 solution distinctions. >>>>>> - Added some additional text throughout the tasks/nontasks >>>>>> - Added editing and typo fixes as suggested >>>>>> - Other suggested changes >>>>>> >>>>>> One remaining comment which I have not addressed yet: >>>>>> >>>>>> James Kempf wrote: >>>>>>> I am very much in favor of making WG charters very specific. It >>>>>>> helps to avoid ambiguity about what the WG is intending to >>>>>>> accomplish, and also helps focus the energy of the WG and avoid >>>>>>> having it become distracted by other proposals that tend to pop up= , >>>>>>> until the originally promised work is completed. Therefore, I woul= d >>>>>>> recommend that the charter include a bulleted list with three item= s >>>>>>> corresponding to each of these new drafts, with each item giving a >>>>>>> concise but complete description of what the promised draft is >>>>>>> intended to accomplish. If there are existing individual drafts th= at >>>>>>> cover these, the descriptions can be based on the individual draft= s. >>>>>>> Also, it might be helpful to be more specific about the goals and >>>>>>> their timing. Rather than just a single goal, have a list that >>>>>>> correspond to the process: 00 WG draft selected by this time, WG >>>>>>> last call by this time, submission to IESG by this time. >>>>>> >>>>>> (Some help would be appreciated with this one). I think we still ha= ve >>>>>> to adjust the milestones a bit more to make sure everything is >>>>>> explicitly spelled out. I have tried to make the charter as concret= e >>>>>> as possible, while still short enough to be manageable/readable. I >>>>>> would like the next revision to focus on the milestones. >>>>>> >>>>>> Can people please read this over and make comments/suggestions, wit= h >>>>>> proposed text changes? That would be helpful. >>>>>> >>>>>> Thanks, >>>>>> TJ >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> >> -- >> Thierry ERNST, PhD >> INRIA Rocquencourt Projet IMARA >> +33 1 39 63 59 30 >> >> > > > > > > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid From nemo-bounces@ietf.org Tue May 23 14:51:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fibyg-0000J5-5X; Tue, 23 May 2006 14:51:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FibyK-0000AM-Bk for nemo@ietf.org; Tue, 23 May 2006 14:51:12 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FibyH-000569-Ir for nemo@ietf.org; Tue, 23 May 2006 14:51:12 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4NIp44r013532 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 23 May 2006 11:51:05 -0700 Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by sabrina.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id k4NIp361009741; Tue, 23 May 2006 11:51:04 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.160]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 May 2006 11:51:02 -0700 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 Subject: RE: [nemo] Potential conflict on NEMOv4 Type and FA-ERR Type Date: Tue, 23 May 2006 11:51:02 -0700 Message-ID: <2EBB8025B6D1BA41B567DB32C1D8DB8488303E@NAEX06.na.qualcomm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Potential conflict on NEMOv4 Type and FA-ERR Type Thread-Index: AcZ+TmZbI5CNOFnBQsGlaC6uWf1UowAS1nBA From: "Narayanan, Vidya" To: "Henrik Levkowetz" X-OriginalArrivalTime: 23 May 2006 18:51:02.0909 (UTC) FILETIME=[D703E2D0:01C67E99] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org I stand corrected - Henrik's suggestions makes perfect sense to me.=20 Thanks, Vidya=20 > -----Original Message----- > From: Henrik Levkowetz [mailto:henrik@levkowetz.com]=20 > Sent: Tuesday, May 23, 2006 2:20 AM > To: Narayanan, Vidya > Cc: ml-nemo WG > Subject: Re: [nemo] Potential conflict on NEMOv4 Type and FA-ERR Type >=20 > Hi, >=20 > I'd strongly suggest that you *don't* code in any specific=20 > extension number - that will just make for more trouble up=20 > the line. For experimental and test deployment, you should=20 > instead use the experimental type numbers (and if needed=20 > message number) defined by RFC 4064, and listed on=20 > http://www.iana.org/assignments/mobileip-numbers > - one reason they were added were previous instances of=20 > collisions between IANA-assigned numbers and 'self-assigned'=20 > numbers such as > 45/46 below, and many man-hours of work spent disentangling=20 > such collisions. >=20 > Regards, >=20 > Henrik >=20 > on 2006-05-19 20:05 Narayanan, Vidya said the following: > > Sounds good to me. =20 > >=20 > >> -----Original Message----- > >> From: Alexandru Petrescu [mailto:alexandru.petrescu@motorola.com] > >> Sent: Friday, May 19, 2006 9:51 AM > >> To: ml-nemo WG > >> Subject: [nemo] Potential conflict on NEMOv4 Type and FA-ERR Type > >>=20 > >> I've been pointed that there seems to be a potential conflict on=20 > >> NEMOv4 Mobile Network Extension Type and FA-Err Type. > >>=20 > >> NEMOv4 uses a new Type (to be assigned by IANA) in Mobile Network=20 > >> Extension. We suggested in the draft that it be 45. > >>=20 > >> FA-ERR draft-ietf-mip4-faerr-02.txt uses Type 45 for FA Error=20 > >> Extension (already assigned by IANA). The draft does not=20 > specify 45,=20 > >> just says TBA by IANA. IANA seems to have assigned it, see=20 > >> http://www.iana.org/assignments/mobileip-numbers. > >>=20 > >> draft-ietf-mobileip-gen-key-01.txt implemented in dynamics > >> 0.8.1 uses 45 too, but I think this can be ignored,=20 > because I think=20 > >> this work has been evolved into draft-rfc3012bis which=20 > uses Type 24. > >>=20 > >> To solve the issue between NEMOv4 and FA-ERR I suggest that we use=20 > >> Type > >> 46 - and not 45 - in NEMOv4 implementation, until IANA=20 > assigns a Type=20 > >> for NEMOv4 Mobile Network Extension. > >>=20 > >> What do you think? > >>=20 > >> Alex > >>=20 > >>=20 > >=20 > >=20 >=20 From nemo-bounces@ietf.org Mon May 29 04:13:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkcsd-0007NF-5Z; Mon, 29 May 2006 04:13:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkcsb-0007NA-Sz for nemo@ietf.org; Mon, 29 May 2006 04:13:37 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkcsY-00083I-1y for nemo@ietf.org; Mon, 29 May 2006 04:13:37 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 2C4232007D5F; Mon, 29 May 2006 10:13:49 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24035-01; Mon, 29 May 2006 10:13:49 +0200 (CEST) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 08A8E20001B8; Mon, 29 May 2006 10:13:49 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Deployment Requirements Date: Mon, 29 May 2006 10:13:29 +0200 Message-ID: <6D28EBC684A4D94096217AD2FE400873650776@venus.office> In-Reply-To: <765F3C78-C07F-465F-B26B-89FA4D2440DD@sfc.wide.ad.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Deployment Requirements thread-index: AcZ6migcb7w/yQxgQT6V8ugUzxXDIwIW2QnQ From: "Roberto Baldessari" To: "Ryuji Wakikawa" , "Thierry Ernst" X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.1 (/) X-Scan-Signature: 14278aea5bdd1edf35ec09ffb7b61f9d Cc: nemo@ietf.org X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Dear all, Sorry for reacting with delay. We have followed the discussion on this mailing list for quite some time and have noticed that vehicular scenarios are getting more attention in NEMO. We are happy about this development. In Europe, the Car to Car Communication Consortium (http://www.car-2-car.org/) aims at standardizing intervehicle communication in Europe.=20 Other national projects like Network On Wheels in Germany (http://www.network-on-wheels.de/) deal with that. NEMO support is taken into consideration as candidate to provide global IP mobility (and not only that). Unfortunately, RFC 3963 does not meet all the requirements needed to be deployed in this scenario. Nevertheless, we think that vehicular communications are potentially one of the main scenarios where NEMO could be used. Therefore, it would be beneficial for both the WG and the companies involved in the projects if a NEMO evolution in this direction will take place. In the mentioned projects, vehicles form an ad hoc network which operates in a licensed frequency band (5.9 GHz) using a communication standard derived from 802.11 family (something similar to the US in progress 802.11p standard). The system is mainly oriented to road safety, but entertainment and convenient applications will definitely have an important role, using different channels or an additional network interface. A position based approach is used as routing protocol in the ad hoc domain and IPv6 was chosen as default protocol for IP-based applications. If you are interested, we can continue discussing about the scenario and how NEMO BS could be extended in order to be deployable in there. Kind regards, Andreas Festag Roberto Baldessari =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Roberto Baldessari Research Associate Network Laboratories, NEC Europe Ltd. Kurfuerstenanlage 36, D-69115 Heidelberg Tel. +49 (0)6221 90511-167 Fax: +49 (0)6221 90511-55 e-mail: roberto.baldessari@netlab.nec.de web: http://www.netlab.nec.de/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=20 > -----Original Message----- > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp]=20 > Sent: Thursday, May 18, 2006 6:42 PM > To: Thierry Ernst > Cc: nemo@ietf.org > Subject: Re: [nemo] Deployment Requirements >=20 > Hi Thierry >=20 > On 2006/05/18, at 22:14, Thierry Ernst wrote: >=20 > > > > Hi Ryuji, > > > > Well, this could suffice (and thanks for recalling this=20 > presentation=20 > > "ISO Activities on NEMO BS", which can be found in the archives at=20 > > http://www3.ietf.org/proceedings/05aug/index.html under the NEMO WG=20 > > proceedings). However, this would weight more if there were people=20 > > from the vehicle industry and related business in Europe and Asia=20 > > (where > > IPv6 > > is more favored) expressing their views on this ML right now. >=20 > yes, this is. >=20 > > ISO TC204 WG16 is surely developing a communication system based on > > IPv6 > > and there are a number of related projects in Europe developing a=20 > > complete architecture around NEMO (RFC 3963). However, most of the=20 > > folks involved in these groups are following the output of=20 > the IETF,=20 > > but are not taking part in the WG discussions, besides a few people. >=20 > I am not so positive that those people will participate the=20 > discussion here, since not all vehicle industry develop=20 > network system by own.. >=20 > It's impossible to have completed requirements from all the=20 > industry, I don't know how these partial deployment=20 > requirements will have "meaning" in this WG. >=20 > If somebody come to this ML and express the idea from vehicle=20 > industry, of course that will be great. >=20 > regards, > ryuji >=20 >=20 >=20 >=20 >=20 > > Thierry. > > > >> i think the requirements from vehicle industry are=20 > summarized by ISO. > >> Each vehicle company has slightly different requirements, but ISO=20 > >> tried to define a common network architecture for vehicles. > >> There was a presentation about ISO activity at IETFXX =20 > (forgot which=20 > >> IETF). > >> > >> We can point to the ISO document if there are. > >> It maybe time to come close between NEMO WG and ISO. > >> > >> regards, > >> ryuji > >> > >> On 2006/05/17, at 17:39, Thierry Ernst wrote: > >> > >>> > >>> Hi, > >>> > >>> We don't necessarily need a draft to gather the=20 > requirements (though=20 > >>> a draft is an easiest way to have a document to refer to when=20 > >>> debating). > >>> > >>> I'm happy to initiate a document for the vehicular=20 > industry though=20 > >>> I'm not sure I will have all the necessary time in the next few=20 > >>> weeks. But I need help from other people already=20 > involved with the=20 > >>> car industry and related vendors. > >>> > >>> Actaully, I think gathering the deployment requirements is a=20 > >>> necessary step before rechartering the WG. > >>> > >>> Thierry. > >>> > >>>>>>> Well, do you intend to mean that we should write a deployment=20 > >>>>>>> requirements draft for the aviation industry specifically, in=20 > >>>>>>> which case we would do the same for the vehicular=20 > industry, and=20 > >>>>>>> for each other existing use cases ? > >>>>>>> > >>>>>> > >>>>>> well, i am not sure about the vehicular technology because i > >>> don't>>> know if they have specific requirements. > >>>>> > >>>>> They do, though they don't speak up yet, because=20 > (unfortunately)=20 > >>>>> IETF is not an organization where they used to be involved. But=20 > >>>>> they (or > >>> the>> vendors related to the vehicular industry and the > >>> standardization>> bodies > >>>>> such as ISO and ETSI) will show up when they understand it is=20 > >>>>> important for them to be involved in the debate. > >>>>> > >>>> > >>>> good i am all for working on other cases if there is interest > >>>> > >>>> (FWIW my point about working in aviation and not in other use > >>>> cases was > >>>> merely because there was no feedback on those, not because i have > >>> any> kind of problem in working in other cases) > >>>> > >>>>> Would be interesting to get some input from the=20 > Japanese folks who > >>> I>> know are monitoring this ML. I'm not speaking only about the > >>>>> people at > >>>>> Keio University who are academic though who are involved with > >>> these>> people, but the people representing the companies=20 > who are in > >>> this>> business. > >>>>> > >>>>> Come on folks, this is the right timing to discuss the=20 > deployment > >>>>> requirements for the vehicular industry ! > >>>>> > >>>>>> but following the emails that have been exchanged=20 > lately in this > >>> > >>>>>> ml, > >>>>>> it is my opinion that the aviation case have quite special > >>>>>> requirements and that they need customized solutions for thier > >>>>>> problems that have their own set of deployment issues. > >>>>> > >>>>> I second this. But the vehicular industry is IMHO more important > >>>>> as it > >>>>> would involved tens of vendors, with possibly divergent=20 > deployment > >>>>> requirements. > >>>>> > >>>> > >>>> good, let's write those down also and see what is the common > >>>> requiremetns for all the relevant use cases > >>>> > >>>> If the common part is large, we should defineltly include them in > >>> the> common requiremetns draft that we already have. If the common > >>> part is> small and there are a lot of diverging=20 > requirements then we > >>> should go> for different drafts i guess > >>>> > >>>> but i guess that the first part is to get individual submissions > >>> from> each of the use cases that people are interested in=20 > working on > >>>> > >>>> > >>>> > >>>>>> I mean consider that they are moving globally quite rapidly, > >>>>>> they have > >>>>>> > >>>>>> wordlwide infrastruture, they need high reliability, =20 > and so on, > >>> > >>>>>> which > >>>>>> > >>>>>> makes their case somehow different from the case of nemos > >>>>>> deployed in > >>>>>> buses cars and so on (or at least it seems so to me) > >>>>> > >>>>> Well, cases and thus requirements are different. RFC=20 > 3963 may not > >>>>> always > >>>>> apply, but even though, the security, authentication and > >>> multihoming>> considerations are different. > >>>>> > >>>>>> that is why i think that the general requirements and in > >>> particular>>> the deployment requirements for a solution to this > >>> particular >>> problem > >>>>>> need to be fleshed out > >>>>> > >>>>> Yes, but what is the best procedure ? Independent draft, one for > >>>>> each > >>>>> use case, or shall we came up straight with common requirements, > >>> in>> which case I would say draft-ietf-nemo-requirements=20 > is the best > >>> > >>>>> place > >>>>> to > >>>>> gather these deployment scenarios ? > >>>>> > >>>> > >>>> see my suggestion above... i guess that in order to=20 > answer this we > >>>> should first figure out what is the common requiremetns=20 > for all the > >>>> relevant use cases and then we can decide... > >>>> > >>>> regards, marcelo > >>>> > >>>> > >>>>>>> If yes, then I guess it would rather be individual submissions > >>>>>> > >>>>>> yes i think Terry initial list could be a starting=20 > point for this > >>>>>> > >>>>>>> that > >>>>>>> could be used as input for determining a common list of > >>> deployment>>>> requirements. > >>>>>>> > >>>>>> > >>>>>> well depending on whether this requirements fit into=20 > the general > >>>>>> requirements, this may be ok.... but i think that they are > >>>>>> likely to > >>>>>> be quite differetn from the general case > >>>>> > >>>>> This may not be an issue. The draft could be explicit that these > >>> are>> requirements for that specific use cases where we get some > >>> input.>> > >>>>> Thierry. > >>>>> > >>>>>>> > >>>>>>>>> [I changed the subject line] > >>>>>>>>> > >>>>>>>>> Speaking about "deployment requirements", I would propose to > >>>>>>>>> add a > >>>>>>>>> section in draft-ietf-nemo-requirements (actually,=20 > I intended > >>> to>>>>>> extend > >>>>>>>>> that draft since the beginning ;-) rather of editing a > >>> separate>>>>>> document. > >>>>>>>>> > >>>>>>>>> Would that make sense to everyone ? > >>>>>>>>> > >>>>>>>> > >>>>>>>> i think that there are some general deployment requirements > >>> that>>>> could> fit in there > >>>>>>>> > >>>>>>>> however, perhaps the case of aviation may have quite specific > >>>>>>>> requirements of their own that may not apply in the general > >>>>>>> case.... i> mean not all of us have worldwide sites and a nemo > >>>>>>> moving > >>>>>>> around> several of them in a single day :-) > >>>>>>>> > >>>>>>>> Regards, marcelo > >>>>>>>> > >>>>>>>> > >>>>>>>>> Thierry. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Tue, 16 May 2006 09:19:30 +0300 > >>>>>>>>> marcelo bagnulo braun wrote: > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> El 15/05/2006, a las 20:47, T.J.Kniveton escribi : > >>>>>>>>>> > >>>>>>>>>>> On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote: > >>>>>>>>>>> > >>>>>>>>>>>> T.J. > >>>>>>>>>>>> > >>>>>>>>>>>> You'll probably wish that you hadn't asked for this... > >>>>>>>>>>>> > >>>>>>>>>>>> These would be our ideal mobility solution. I=20 > realize that > >>>>>>>>>>>> meeting > >>>>>>>>>>>> all > >>>>>>>>>>>> of these is probably an extreme stretch. > >>>>>>>>>>>> > >>>>>>>>>>>> Take care > >>>>>>>>>>>> Terry > >>>>>>>>>>> > >>>>>>>>>>> Terry, > >>>>>>>>>>> > >>>>>>>>>>> I second the request to put your list of items into a > >>>>>>>>>>> draft. It > >>>>>>>>>>> will > >>>>>>>>>>> be helpful to have a concrete list of deployment > >>>>>>>>>>> requirements to > >>>>>>>>>>> refer > >>>>>>>>>>> to. While the WG can't necessarily solve all of the > >>>>>>>>>>> problems for > >>>>>>> > >>>>>>>>>>> one > >>>>>>>>>>> specific deployment, an informational document=20 > listing them > >>> > >>>>>>>>>>> can > >>>>>>> be>>>> useful for guidance when making engineering design > >>>>>>> decisions. > >>>>>>>>>>> > >>>>>>>>>>> Would you be willing to do that? Perhaps others in the WG > >>> can>>>> help>>>> with maintaining the document / editing=20 > if needed. > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> i am willing to help Terry on this in case it is needed... > >>>>>>>>>> > >>>>>>>>>> regards, marcelo > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> TJ > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> --=20 > >>>>>>>>> Thierry ERNST, PhD > >>>>>>>>> INRIA Rocquencourt Projet IMARA > >>>>>>>>> +33 1 39 63 59 30 > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> --=20 > >>>>>>> Thierry ERNST, PhD > >>>>>>> INRIA Rocquencourt Projet IMARA > >>>>>>> +33 1 39 63 59 30 > >>>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> --=20 > >>>>> Thierry ERNST, PhD > >>>>> INRIA Rocquencourt Projet IMARA > >>>>> +33 1 39 63 59 30 > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>> > >>> > >>> --=20 > >>> Thierry ERNST, PhD > >>> INRIA Rocquencourt Projet IMARA > >>> +33 1 39 63 59 30 > >>> > >> > >> > >> > > > > > > --=20 > > Thierry ERNST, PhD > > INRIA Rocquencourt Projet IMARA > > +33 1 39 63 59 30 > > >=20 >=20 >=20 From nemo-bounces@ietf.org Mon May 29 05:37:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkeBt-0007Ps-Ks; Mon, 29 May 2006 05:37:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkeBs-0007Pn-BI for nemo@ietf.org; Mon, 29 May 2006 05:37:36 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkeBq-0007rM-8x for nemo@ietf.org; Mon, 29 May 2006 05:37:36 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4BFB295E33; Mon, 29 May 2006 11:37:33 +0200 (CEST) Received: from [163.117.203.122] (unknown [163.117.203.122]) by smtp02.uc3m.es (Postfix) with ESMTP id 78A1795E59; Mon, 29 May 2006 11:37:32 +0200 (CEST) In-Reply-To: <6D28EBC684A4D94096217AD2FE400873650776@venus.office> References: <6D28EBC684A4D94096217AD2FE400873650776@venus.office> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <3f014622f0b81ada305157b4c7c29f1e@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [nemo] Deployment Requirements Date: Mon, 29 May 2006 12:37:37 +0300 To: "Roberto Baldessari" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: dadeebe491e67c033a493fd3c7d6792b Cc: ml-nemo WG X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi Roberto, thank you for this input, i think it is very valuable... El 29/05/2006, a las 11:13, Roberto Baldessari escribi=F3: > > Dear all, > > Sorry for reacting with delay. > > We have followed the discussion on this mailing list for quite some=20 > time > and have noticed that vehicular scenarios are getting more attention = in > NEMO. We are happy about this development. > > In Europe, the Car to Car Communication Consortium > (http://www.car-2-car.org/) aims at standardizing intervehicle > communication in Europe. > Other national projects like Network On Wheels in Germany > (http://www.network-on-wheels.de/) deal with that. > > NEMO support is taken into consideration as candidate to provide = global > IP mobility (and not only that). > Unfortunately, RFC 3963 does not meet all the requirements needed to = be > deployed in this scenario. ok, which are those? could you state the specific requirements of the=20 vehicular scenario so that extensions to nemo could be designed to=20 support those? (maybe an ID would be the best option for this...?) > Nevertheless, we think that vehicular > communications are potentially one of the main scenarios where NEMO > could be used. Therefore, it would be beneficial for both the WG and=20= > the > companies involved in the projects if a NEMO evolution in this=20 > direction > will take place. > > In the mentioned projects, vehicles form an ad hoc network which > operates in a licensed frequency band (5.9 GHz) using a communication > standard derived from 802.11 family (something similar to the US in > progress 802.11p standard). The system is mainly oriented to road > safety, but entertainment and convenient applications will definitely > have an important role, using different channels or an additional > network interface. A position based approach is used as routing=20 > protocol > in the ad hoc domain and IPv6 was chosen as default protocol for > IP-based applications. > > If you are interested, we can continue discussing about the scenario=20= > and > how NEMO BS could be extended in order to be deployable in there. > imho this is very interesting regards, marcelo > Kind regards, > > Andreas Festag > Roberto Baldessari > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Roberto Baldessari > Research Associate > Network Laboratories, NEC Europe Ltd. > Kurfuerstenanlage 36, D-69115 Heidelberg > Tel. +49 (0)6221 90511-167 > Fax: +49 (0)6221 90511-55 > e-mail: roberto.baldessari@netlab.nec.de > web: http://www.netlab.nec.de/ > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > >> -----Original Message----- >> From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] >> Sent: Thursday, May 18, 2006 6:42 PM >> To: Thierry Ernst >> Cc: nemo@ietf.org >> Subject: Re: [nemo] Deployment Requirements >> >> Hi Thierry >> >> On 2006/05/18, at 22:14, Thierry Ernst wrote: >> >>> >>> Hi Ryuji, >>> >>> Well, this could suffice (and thanks for recalling this >> presentation >>> "ISO Activities on NEMO BS", which can be found in the archives at >>> http://www3.ietf.org/proceedings/05aug/index.html under the NEMO WG >>> proceedings). However, this would weight more if there were people >>> from the vehicle industry and related business in Europe and Asia >>> (where >>> IPv6 >>> is more favored) expressing their views on this ML right now. >> >> yes, this is. >> >>> ISO TC204 WG16 is surely developing a communication system based on >>> IPv6 >>> and there are a number of related projects in Europe developing a >>> complete architecture around NEMO (RFC 3963). However, most of the >>> folks involved in these groups are following the output of >> the IETF, >>> but are not taking part in the WG discussions, besides a few people. >> >> I am not so positive that those people will participate the >> discussion here, since not all vehicle industry develop >> network system by own.. >> >> It's impossible to have completed requirements from all the >> industry, I don't know how these partial deployment >> requirements will have "meaning" in this WG. >> >> If somebody come to this ML and express the idea from vehicle >> industry, of course that will be great. >> >> regards, >> ryuji >> >> >> >> >> >>> Thierry. >>> >>>> i think the requirements from vehicle industry are >> summarized by ISO. >>>> Each vehicle company has slightly different requirements, but ISO >>>> tried to define a common network architecture for vehicles. >>>> There was a presentation about ISO activity at IETFXX >> (forgot which >>>> IETF). >>>> >>>> We can point to the ISO document if there are. >>>> It maybe time to come close between NEMO WG and ISO. >>>> >>>> regards, >>>> ryuji >>>> >>>> On 2006/05/17, at 17:39, Thierry Ernst wrote: >>>> >>>>> >>>>> Hi, >>>>> >>>>> We don't necessarily need a draft to gather the >> requirements (though >>>>> a draft is an easiest way to have a document to refer to when >>>>> debating). >>>>> >>>>> I'm happy to initiate a document for the vehicular >> industry though >>>>> I'm not sure I will have all the necessary time in the next few >>>>> weeks. But I need help from other people already >> involved with the >>>>> car industry and related vendors. >>>>> >>>>> Actaully, I think gathering the deployment requirements is a >>>>> necessary step before rechartering the WG. >>>>> >>>>> Thierry. >>>>> >>>>>>>>> Well, do you intend to mean that we should write a deployment >>>>>>>>> requirements draft for the aviation industry specifically, in >>>>>>>>> which case we would do the same for the vehicular >> industry, and >>>>>>>>> for each other existing use cases ? >>>>>>>>> >>>>>>>> >>>>>>>> well, i am not sure about the vehicular technology because i >>>>> don't>>> know if they have specific requirements. >>>>>>> >>>>>>> They do, though they don't speak up yet, because >> (unfortunately) >>>>>>> IETF is not an organization where they used to be involved. But >>>>>>> they (or >>>>> the>> vendors related to the vehicular industry and the >>>>> standardization>> bodies >>>>>>> such as ISO and ETSI) will show up when they understand it is >>>>>>> important for them to be involved in the debate. >>>>>>> >>>>>> >>>>>> good i am all for working on other cases if there is interest >>>>>> >>>>>> (FWIW my point about working in aviation and not in other use >>>>>> cases was >>>>>> merely because there was no feedback on those, not because i have >>>>> any> kind of problem in working in other cases) >>>>>> >>>>>>> Would be interesting to get some input from the >> Japanese folks who >>>>> I>> know are monitoring this ML. I'm not speaking only about the >>>>>>> people at >>>>>>> Keio University who are academic though who are involved with >>>>> these>> people, but the people representing the companies >> who are in >>>>> this>> business. >>>>>>> >>>>>>> Come on folks, this is the right timing to discuss the >> deployment >>>>>>> requirements for the vehicular industry ! >>>>>>> >>>>>>>> but following the emails that have been exchanged >> lately in this >>>>> >>>>>>>> ml, >>>>>>>> it is my opinion that the aviation case have quite special >>>>>>>> requirements and that they need customized solutions for thier >>>>>>>> problems that have their own set of deployment issues. >>>>>>> >>>>>>> I second this. But the vehicular industry is IMHO more important >>>>>>> as it >>>>>>> would involved tens of vendors, with possibly divergent >> deployment >>>>>>> requirements. >>>>>>> >>>>>> >>>>>> good, let's write those down also and see what is the common >>>>>> requiremetns for all the relevant use cases >>>>>> >>>>>> If the common part is large, we should defineltly include them in >>>>> the> common requiremetns draft that we already have. If the common >>>>> part is> small and there are a lot of diverging >> requirements then we >>>>> should go> for different drafts i guess >>>>>> >>>>>> but i guess that the first part is to get individual submissions >>>>> from> each of the use cases that people are interested in >> working on >>>>>> >>>>>> >>>>>> >>>>>>>> I mean consider that they are moving globally quite rapidly, >>>>>>>> they have >>>>>>>> >>>>>>>> wordlwide infrastruture, they need high reliability, >> and so on, >>>>> >>>>>>>> which >>>>>>>> >>>>>>>> makes their case somehow different from the case of nemos >>>>>>>> deployed in >>>>>>>> buses cars and so on (or at least it seems so to me) >>>>>>> >>>>>>> Well, cases and thus requirements are different. RFC >> 3963 may not >>>>>>> always >>>>>>> apply, but even though, the security, authentication and >>>>> multihoming>> considerations are different. >>>>>>> >>>>>>>> that is why i think that the general requirements and in >>>>> particular>>> the deployment requirements for a solution to this >>>>> particular >>> problem >>>>>>>> need to be fleshed out >>>>>>> >>>>>>> Yes, but what is the best procedure ? Independent draft, one for >>>>>>> each >>>>>>> use case, or shall we came up straight with common requirements, >>>>> in>> which case I would say draft-ietf-nemo-requirements >> is the best >>>>> >>>>>>> place >>>>>>> to >>>>>>> gather these deployment scenarios ? >>>>>>> >>>>>> >>>>>> see my suggestion above... i guess that in order to >> answer this we >>>>>> should first figure out what is the common requiremetns >> for all the >>>>>> relevant use cases and then we can decide... >>>>>> >>>>>> regards, marcelo >>>>>> >>>>>> >>>>>>>>> If yes, then I guess it would rather be individual submissions >>>>>>>> >>>>>>>> yes i think Terry initial list could be a starting >> point for this >>>>>>>> >>>>>>>>> that >>>>>>>>> could be used as input for determining a common list of >>>>> deployment>>>> requirements. >>>>>>>>> >>>>>>>> >>>>>>>> well depending on whether this requirements fit into >> the general >>>>>>>> requirements, this may be ok.... but i think that they are >>>>>>>> likely to >>>>>>>> be quite differetn from the general case >>>>>>> >>>>>>> This may not be an issue. The draft could be explicit that these >>>>> are>> requirements for that specific use cases where we get some >>>>> input.>> >>>>>>> Thierry. >>>>>>> >>>>>>>>> >>>>>>>>>>> [I changed the subject line] >>>>>>>>>>> >>>>>>>>>>> Speaking about "deployment requirements", I would propose to >>>>>>>>>>> add a >>>>>>>>>>> section in draft-ietf-nemo-requirements (actually, >> I intended >>>>> to>>>>>> extend >>>>>>>>>>> that draft since the beginning ;-) rather of editing a >>>>> separate>>>>>> document. >>>>>>>>>>> >>>>>>>>>>> Would that make sense to everyone ? >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> i think that there are some general deployment requirements >>>>> that>>>> could> fit in there >>>>>>>>>> >>>>>>>>>> however, perhaps the case of aviation may have quite specific >>>>>>>>>> requirements of their own that may not apply in the general >>>>>>>>> case.... i> mean not all of us have worldwide sites and a nemo >>>>>>>>> moving >>>>>>>>> around> several of them in a single day :-) >>>>>>>>>> >>>>>>>>>> Regards, marcelo >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Thierry. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Tue, 16 May 2006 09:19:30 +0300 >>>>>>>>>>> marcelo bagnulo braun wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> El 15/05/2006, a las 20:47, T.J.Kniveton escribi : >>>>>>>>>>>> >>>>>>>>>>>>> On Apr 28, 2006, at 9:45 PM, Davis, Terry L wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> T.J. >>>>>>>>>>>>>> >>>>>>>>>>>>>> You'll probably wish that you hadn't asked for this... >>>>>>>>>>>>>> >>>>>>>>>>>>>> These would be our ideal mobility solution. I >> realize that >>>>>>>>>>>>>> meeting >>>>>>>>>>>>>> all >>>>>>>>>>>>>> of these is probably an extreme stretch. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Take care >>>>>>>>>>>>>> Terry >>>>>>>>>>>>> >>>>>>>>>>>>> Terry, >>>>>>>>>>>>> >>>>>>>>>>>>> I second the request to put your list of items into a >>>>>>>>>>>>> draft. It >>>>>>>>>>>>> will >>>>>>>>>>>>> be helpful to have a concrete list of deployment >>>>>>>>>>>>> requirements to >>>>>>>>>>>>> refer >>>>>>>>>>>>> to. While the WG can't necessarily solve all of the >>>>>>>>>>>>> problems for >>>>>>>>> >>>>>>>>>>>>> one >>>>>>>>>>>>> specific deployment, an informational document >> listing them >>>>> >>>>>>>>>>>>> can >>>>>>>>> be>>>> useful for guidance when making engineering design >>>>>>>>> decisions. >>>>>>>>>>>>> >>>>>>>>>>>>> Would you be willing to do that? Perhaps others in the WG >>>>> can>>>> help>>>> with maintaining the document / editing >> if needed. >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> i am willing to help Terry on this in case it is needed... >>>>>>>>>>>> >>>>>>>>>>>> regards, marcelo >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> TJ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --=20 >>>>>>>>>>> Thierry ERNST, PhD >>>>>>>>>>> INRIA Rocquencourt Projet IMARA >>>>>>>>>>> +33 1 39 63 59 30 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --=20 >>>>>>>>> Thierry ERNST, PhD >>>>>>>>> INRIA Rocquencourt Projet IMARA >>>>>>>>> +33 1 39 63 59 30 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> --=20 >>>>>>> Thierry ERNST, PhD >>>>>>> INRIA Rocquencourt Projet IMARA >>>>>>> +33 1 39 63 59 30 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> --=20 >>>>> Thierry ERNST, PhD >>>>> INRIA Rocquencourt Projet IMARA >>>>> +33 1 39 63 59 30 >>>>> >>>> >>>> >>>> >>> >>> >>> --=20 >>> Thierry ERNST, PhD >>> INRIA Rocquencourt Projet IMARA >>> +33 1 39 63 59 30 >>> >> >> >> > From nemo-bounces@ietf.org Mon May 29 06:07:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkee7-0004qU-Mm; Mon, 29 May 2006 06:06:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkee6-0004qP-0p for nemo@ietf.org; Mon, 29 May 2006 06:06:46 -0400 Received: from smtp.mei.co.jp ([133.183.129.25] helo=smtp1.mei.co.jp) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkee4-00020T-An for nemo@ietf.org; Mon, 29 May 2006 06:06:45 -0400 Received: from mail-gw.jp.panasonic.com (dodgers.mei.co.jp [157.8.1.150]) by smtp1.mei.co.jp (8.12.11.20060308/3.7W/bulls) with ESMTP id k4TA6dht013443; Mon, 29 May 2006 19:06:39 +0900 (JST) Received: by mail-gw.jp.panasonic.com (8.11.6p2/3.7W/somlx2) with ESMTP id k4TA6f102972; Mon, 29 May 2006 19:06:41 +0900 (JST) Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/whitesox) with ESMTP id k4TA6VI14885; Mon, 29 May 2006 19:06:35 +0900 (JST) Received: from bach.sg.panasonic.com ([10.81.113.99]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.1830); Mon, 29 May 2006 18:03:53 +0800 Received: by bach.sg.panasonic.com (Postfix, from userid 1000) id 73A87D544A; Mon, 29 May 2006 18:16:12 +0800 (SGT) Subject: RE: [nemo] Deployment Requirements From: Chan-Wah Ng To: Roberto Baldessari In-Reply-To: <6D28EBC684A4D94096217AD2FE400873650776@venus.office> References: <6D28EBC684A4D94096217AD2FE400873650776@venus.office> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 29 May 2006 18:16:12 +0800 Message-Id: <1148897772.762.151.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.4.2.1 X-OriginalArrivalTime: 29 May 2006 10:03:54.0010 (UTC) FILETIME=[313367A0:01C68307] X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: nemo@ietf.org, Thierry Ernst , Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hello Roberto, Thanks for the input. Very encouraging indeed to see more deployment scenario! On Mon, 2006-05-29 at 10:13 +0200, Roberto Baldessari wrote: > Dear all, > > Sorry for reacting with delay. > > We have followed the discussion on this mailing list for quite some time > and have noticed that vehicular scenarios are getting more attention in > NEMO. We are happy about this development. > > In Europe, the Car to Car Communication Consortium > (http://www.car-2-car.org/) aims at standardizing intervehicle > communication in Europe. > Other national projects like Network On Wheels in Germany > (http://www.network-on-wheels.de/) deal with that. > > NEMO support is taken into consideration as candidate to provide global > IP mobility (and not only that). > Unfortunately, RFC 3963 does not meet all the requirements needed to be > deployed in this scenario. Nevertheless, we think that vehicular > communications are potentially one of the main scenarios where NEMO > could be used. Therefore, it would be beneficial for both the WG and the > companies involved in the projects if a NEMO evolution in this direction > will take place. Specifically why NEMO-BS (i.e. RFC3963) does not meet the requirements? > > In the mentioned projects, vehicles form an ad hoc network which > operates in a licensed frequency band (5.9 GHz) using a communication > standard derived from 802.11 family (something similar to the US in > progress 802.11p standard). The system is mainly oriented to road > safety, but entertainment and convenient applications will definitely > have an important role, using different channels or an additional > network interface. A position based approach is used as routing protocol > in the ad hoc domain and IPv6 was chosen as default protocol for > IP-based applications. > So the cars are communicating with each other using ad hoc mode. How about intra-vehicular? I expect that's where NEMO would step in. Is it within the scope of the consortium as well? > If you are interested, we can continue discussing about the scenario and > how NEMO BS could be extended in order to be deployable in there. > Based on your scenario, I would expect that cars to talk to cars in ad-moc mode, but with in each car a NEMO is formed, being using the CAN protocol, Ethernet or Bluetooth. I think NEMO will be involved when the components within a car network need to talk to (A) another component in the another car, or (B) some other nodes in the global internet (possibly using other cars as relay to the base station). >From the route optimization standpoint, I guess for (A), you need some form intra-nested NEMO optimization. It would be, I imagine, unacceptable to go through the nested tunnels if the communications involves accident prevention signalling, where any extra delay would be fatal. For (B), I suspect you need a form of nested tunnel optimization, or maybe a way to flatten the NEMO. Would a global HA-HA solution be of any help here? /rgds /cwng From nemo-bounces@ietf.org Mon May 29 08:39:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkh1T-0004Tc-WD; Mon, 29 May 2006 08:39:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkh1T-0004Qn-Cv for nemo@ietf.org; Mon, 29 May 2006 08:39:03 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkh1O-0000Xt-TZ for nemo@ietf.org; Mon, 29 May 2006 08:39:03 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 29 May 2006 05:38:58 -0700 X-IronPort-AV: i="4.05,184,1146466800"; d="scan'208"; a="284620990:sNHT84183748" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id k4TCcvMo022895; Mon, 29 May 2006 05:38:57 -0700 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4TCcgLj028589; Mon, 29 May 2006 14:38:55 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 29 May 2006 14:38:47 +0200 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 Subject: RE: [nemo] Deployment Requirements Date: Mon, 29 May 2006 14:38:40 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC023C8AD5@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Deployment Requirements Thread-Index: AcaDB+X6p5SVbZ/ATn2A1w/qtM/cdAAE6XZg From: "Pascal Thubert \(pthubert\)" To: "Chan-Wah Ng" , "Roberto Baldessari" X-OriginalArrivalTime: 29 May 2006 12:38:47.0147 (UTC) FILETIME=[D45793B0:01C6831C] DKIM-Signature: a=rsa-sha1; q=dns; l=4195; t=1148906338; x=1149770338; c=relaxed/simple; s=sjdkim1001; h=From:Subject; d=cisco.com; i=pthubert@cisco.com; z=From:=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:RE=3A=20[nemo]=20Deployment=20Requirements; X=v=3Dcisco.com=3B=20h=3DTZ50zzOkkhDSb/Z4em7RIPIHbhk=3D; b=nPjFLaI55voAGAk/7pAPvdXvbwkMJkQrrBK+6cRtMCijvhPNhr3a4Dz8nor3JEJ41itlEUk1 nJ6iXEoCdFj7hiV0s9t7CSsWwyq/TtlI7JcytZH9fWiJKnwOv40LQFPX; Authentication-Results: sj-dkim-1.cisco.com; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Cc: nemo@ietf.org, Thierry Ernst , Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi: Please note that=20 1) we started a similar discussion on the thread called:=20 "Distributing the Mobile Prefix in the visited network" last November. 2) I pointed out to Roberto that there is a MANEMO ML. Since that thread, no big news on MANEMO; we are still working on the Problem statement, and version 03 of Tree Discovery was published: http://www.ietf.org/internet-drafts/draft-thubert-tree-discovery-03.txt TD extends ND to build a logical tree structure out of scattered Mobile Routers to shape the nested NEMO. While this type of operation is now flourishing at layer 2 in the context of mesh networks, we are still missing a similar technology at layer 3, in the context of Mobile Routers in particular. Pascal >-----Original Message----- >From: Chan-Wah Ng [mailto:chanwah.ng@sg.panasonic.com] >Sent: Monday, May 29, 2006 12:16 PM >To: Roberto Baldessari >Cc: nemo@ietf.org; Thierry Ernst; Ryuji Wakikawa >Subject: RE: [nemo] Deployment Requirements > >Hello Roberto, > >Thanks for the input. Very encouraging indeed to see more deployment >scenario! > >On Mon, 2006-05-29 at 10:13 +0200, Roberto Baldessari wrote: >> Dear all, >> >> Sorry for reacting with delay. >> >> We have followed the discussion on this mailing list for quite some time >> and have noticed that vehicular scenarios are getting more attention in >> NEMO. We are happy about this development. >> >> In Europe, the Car to Car Communication Consortium >> (http://www.car-2-car.org/) aims at standardizing intervehicle >> communication in Europe. >> Other national projects like Network On Wheels in Germany >> (http://www.network-on-wheels.de/) deal with that. >> >> NEMO support is taken into consideration as candidate to provide global >> IP mobility (and not only that). >> Unfortunately, RFC 3963 does not meet all the requirements needed to be >> deployed in this scenario. Nevertheless, we think that vehicular >> communications are potentially one of the main scenarios where NEMO >> could be used. Therefore, it would be beneficial for both the WG and the >> companies involved in the projects if a NEMO evolution in this direction >> will take place. > >Specifically why NEMO-BS (i.e. RFC3963) does not meet the >requirements? > >> >> In the mentioned projects, vehicles form an ad hoc network which >> operates in a licensed frequency band (5.9 GHz) using a communication >> standard derived from 802.11 family (something similar to the US in >> progress 802.11p standard). The system is mainly oriented to road >> safety, but entertainment and convenient applications will definitely >> have an important role, using different channels or an additional >> network interface. A position based approach is used as routing protocol >> in the ad hoc domain and IPv6 was chosen as default protocol for >> IP-based applications. >> > >So the cars are communicating with each other using ad hoc mode. How >about intra-vehicular? I expect that's where NEMO would step in. Is it >within the scope of the consortium as well? > >> If you are interested, we can continue discussing about the scenario and >> how NEMO BS could be extended in order to be deployable in there. >> > >Based on your scenario, I would expect that cars to talk to cars in >ad-moc mode, but with in each car a NEMO is formed, being using the CAN >protocol, Ethernet or Bluetooth. > >I think NEMO will be involved when the components within a car network >need to talk to (A) another component in the another car, or (B) some >other nodes in the global internet (possibly using other cars as relay >to the base station). > >>From the route optimization standpoint, I guess for (A), you need some >form intra-nested NEMO optimization. It would be, I imagine, >unacceptable to go through the nested tunnels if the communications >involves accident prevention signalling, where any extra delay would be >fatal. > >For (B), I suspect you need a form of nested tunnel optimization, or >maybe a way to flatten the NEMO. Would a global HA-HA solution be of >any help here? > >/rgds >/cwng > > From nemo-bounces@ietf.org Tue May 30 03:27:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkydk-0002Cd-Og; Tue, 30 May 2006 03:27:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fkydi-0002CY-Ik for nemo@ietf.org; Tue, 30 May 2006 03:27:42 -0400 Received: from smtp0.netlab.nec.de ([195.37.70.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fkydh-0002Vx-3I for nemo@ietf.org; Tue, 30 May 2006 03:27:42 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 70D762007D5F; Tue, 30 May 2006 09:27:58 +0200 (CEST) Received: from smtp0.netlab.nec.de ([127.0.0.1]) by localhost (atlas1.office [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09155-10; Tue, 30 May 2006 09:27:58 +0200 (CEST) Received: from venus.office (europa.netlab.nec.de [10.1.1.25]) by smtp0.netlab.nec.de (Postfix) with ESMTP id 51DCD20001B6; Tue, 30 May 2006 09:27:58 +0200 (CEST) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [nemo] Deployment Requirements Date: Tue, 30 May 2006 09:27:39 +0200 Message-ID: <6D28EBC684A4D94096217AD2FE400873650863@venus.office> In-Reply-To: <7892795E1A87F04CADFCCF41FADD00FC023C8AD5@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Deployment Requirements thread-index: AcaDB+X6p5SVbZ/ATn2A1w/qtM/cdAAE6XZgAANc3UA= From: "Roberto Baldessari" To: "Pascal Thubert (pthubert)" , "Chan-Wah Ng" X-Virus-Scanned: Amavisd on Debian GNU/Linux (atlas1.office) X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Cc: nemo@ietf.org, Thierry Ernst , Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org Hi all, I try to summarize answers in one mail. Please see comments inline. =20 > 1) we started a similar discussion on the thread called:=20 > "Distributing the Mobile Prefix in the visited network" last November. >=20 > 2) I pointed out to Roberto that there is a MANEMO ML. Since=20 > that thread, no big news on MANEMO; we are still working on=20 > the Problem statement, and version 03 of Tree Discovery was published: > http://www.ietf.org/internet-drafts/draft-thubert-tree-discove > ry-03.txt Thanks Pascal. I think that at that time I didn't understand that MANEMO targets a slightly different scenario: - In our scenario, we don't focus on nested NEMO (MANET inside a mobile network) but on MANETs formed by mobile networks. As far as I understand, MANEMO and TD focus on nested NEMO. Do you see applications of the TD strategy in the scenario we consider? - In our opinion, the adhoc routing should be indipendent from the NEMO protocol. We assume that a routing protocol takes care of delivering packets from node A to node B in the adhoc domain, so that node A and node B are 'logically' on the same link, even if they communicate through multihop. This can be achieved with various strategies. It is, maybe, an implementation related concept. Nevertheless, we think it allows to keep NEMO (or other mobility management approaches) indipendent from the specific routing protocol of the MANET > > > >Specifically why NEMO-BS (i.e. RFC3963) does not meet the=20 > requirements? > > NEMO BS, being essentially derived from Mobile IP, is an infrastructure-based mobility protocol. In intervehicle communications, the infrastructure access via 802.11 will be rather limited (i.e. urban areas). It is still not clear whether vehicles will be equipped with additional interfaces (Wifi, 3+ G etc.). At the moment, and also because car companies have concerns about costs, we focus on 802.11, which is the basis of the system for road safety. Considering that, what Intervehicle Communication would like to have is: - global mobility when the infrastructure is available (and NEMO BS offers already that) - "RO with infrastructure" - exchanging packets directly from a vehicle network to another one when the Infrastructure is not available, or, in other words, "RO without infrastructure". But still assuming, as I said before, that the two MRs are "logically" on the same link. > >> > >Based on your scenario, I would expect that cars to talk to cars in=20 > >ad-moc mode, but with in each car a NEMO is formed, being=20 > using the CAN=20 > >protocol, Ethernet or Bluetooth. We are not considering how the packets are routed inside the mobile network. We don't think that adhoc mode inside the car will be used. This simplifies a bit the scenario. > > > >I think NEMO will be involved when the components within a=20 > car network=20 > >need to talk to (A) another component in the another car, or=20 > (B) some=20 > >other nodes in the global internet (possibly using other=20 > cars as relay=20 > >to the base station). > > > >>From the route optimization standpoint, I guess for (A),=20 > you need some > >form intra-nested NEMO optimization. It would be, I imagine,=20 > >unacceptable to go through the nested tunnels if the communications=20 > >involves accident prevention signalling, where any extra=20 > delay would be=20 > >fatal. > > > >For (B), I suspect you need a form of nested tunnel optimization, or=20 > >maybe a way to flatten the NEMO. Would a global HA-HA=20 > solution be of=20 > >any help here? For (B), as we assume that there is already a routing protocol that takes care of routing the packets from the vehicle to the infrastructure point of attachment, we have not considered this kind of solution. Anyway, global HA-HA is interesting and introduces a Mobile IP Proxy in the Infrastructure.=20 We have been working on a slightly different concept with the same name: essentially running a MIP Proxy in the MR. But there are Ipsec security issues in this approach that discourage us. Roberto=20 From nemo-bounces@ietf.org Tue May 30 04:06:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkzEq-0006uY-VI; Tue, 30 May 2006 04:06:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FkzEp-0006uT-OH for nemo@ietf.org; Tue, 30 May 2006 04:06:03 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FkzEm-0006G7-AH for nemo@ietf.org; Tue, 30 May 2006 04:06:03 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 30 May 2006 01:05:59 -0700 X-IronPort-AV: i="4.05,188,1146466800"; d="scan'208"; a="1815049865:sNHT32866336" Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id k4U85wLS027776; Tue, 30 May 2006 01:05:59 -0700 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k4U85tLf010571; Tue, 30 May 2006 10:05:56 +0200 (MEST) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.0); Tue, 30 May 2006 10:05:55 +0200 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 Subject: RE: [nemo] Deployment Requirements Date: Tue, 30 May 2006 10:05:49 +0200 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC023C8D35@xmb-ams-337.emea.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [nemo] Deployment Requirements Thread-Index: AcaDB+X6p5SVbZ/ATn2A1w/qtM/cdAAE6XZgAANc3UAAJM0sUA== From: "Pascal Thubert \(pthubert\)" To: "Roberto Baldessari" , "Chan-Wah Ng" X-OriginalArrivalTime: 30 May 2006 08:05:55.0316 (UTC) FILETIME=[E0622B40:01C683BF] DKIM-Signature: a=rsa-sha1; q=dns; l=2818; t=1148976359; x=1149840359; c=relaxed/simple; s=sjdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pthubert@cisco.com; z=From:=22Pascal=20Thubert=20\(pthubert\)=22=20 |Subject:RE=3A=20[nemo]=20Deployment=20Requirements; X=v=3Dcisco.com=3B=20h=3DAFmhyG9oKRWCdMLq5x1g3QOv5Ek=3D; b=AJ7JG9ww4WCtD4FAZ0Z81mWsztDnA4S2iomzL8wuiOXTFKZsRXm9zhT9oGyIj9CXV5xXvWMz 7LMAJWvRdDYk8uqHNa6jWaMVU26sJohkTWsKC2V7wo2dbxMBSfebKh9E; Authentication-Results: sj-dkim-2.cisco.com; header.From=pthubert@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: nemo@ietf.org, Thierry Ernst , Ryuji Wakikawa X-BeenThere: nemo@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: NEMO Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: nemo-bounces@ietf.org > >> 1) we started a similar discussion on the thread called: >> "Distributing the Mobile Prefix in the visited network" last November. >> >> 2) I pointed out to Roberto that there is a MANEMO ML. Since >> that thread, no big news on MANEMO; we are still working on >> the Problem statement, and version 03 of Tree Discovery was published: >> http://www.ietf.org/internet-drafts/draft-thubert-tree-discove >> ry-03.txt > >Thanks Pascal. [Pascal] Hi Roberto >I think that at that time I didn't understand that MANEMO targets a >slightly different scenario: > >- In our scenario, we don't focus on nested NEMO (MANET inside a mobile >network) but on MANETs formed by mobile networks. As far as I >understand, MANEMO and TD focus on nested NEMO. Do you see applications >of the TD strategy in the scenario we consider? [Pascal] MRs own Mobile Networks. As MRs form a nested NEMO dynamically, don't they form a MANET of Mobile Networks? I'm sorry I fail to see the distinction. Could you please elaborate? Please note that when routers move together as a solid, this is a single NEMO not a nested one. >- In our opinion, the adhoc routing should be indipendent from the NEMO >protocol. We assume that a routing protocol takes care of delivering >packets from node A to node B in the adhoc domain, so that node A and >node B are 'logically' on the same link, even if they communicate >through multihop. This can be achieved with various strategies. It is, >maybe, an implementation related concept. Nevertheless, we think it >allows to keep NEMO (or other mobility management approaches) >indipendent from the specific routing protocol of the MANET [Pascal] Using a number of routing protocols is a usual thing. At the extreme, NEMO will inject a default route in the RIB while MANET will inject host routes. In fact, there is a fuzzy zone where both a MANET and NEMO-RO can inject prefixes and potentially cause the conflict. The redistribution rules will take care of the precedence in such a case, based on security policies and costs. Then again, I'm not sure what you mean by independent. It is a single router and sharing the RIB is a form of interaction. MANET can provide a structure to the nested NEMO (like TD does) and find the default route to the Internet so that MRs can bind Home over one another. MANET can even locate a HA for NEMO in the case of a Mobile Home. IMHO, there is value in understanding such interactions. The interaction between TD and RRH for instance, is a proof of such a value. This enables to design a simple MANET that provides for the nested NEMO needs. As a result, the MR gets both local and global routing integrated in its RIB. This is the MANEMO concept, at the end of the day.=20 What do you think? Pascal