From mailman-bounces@ietf.org Wed Dec 1 06:39:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17144 for ; Wed, 1 Dec 2004 06:39:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CZS4R-0007jy-2W for nemo-archive@lists.ietf.org; Wed, 01 Dec 2004 05:50:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: nemo-archive@ietf.org X-No-Archive: yes Message-ID: Date: Wed, 01 Dec 2004 05:31:49 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, mailman-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. ********************************************************************** NOTE WELL: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for nemo-archive@lists.ietf.org: List Password // URL ---- -------- nemo@ietf.org koepih https://www1.ietf.org/mailman/options/nemo/nemo-archive%40lists.ietf.org From nemo-bounces@ietf.org Tue Dec 7 20:03:08 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24204 for ; Tue, 7 Dec 2004 20:03:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbq6n-0000zX-1l; Tue, 07 Dec 2004 19:55:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaLyp-0000P2-6M for nemo@megatron.ietf.org; Fri, 03 Dec 2004 17:32:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12538 for ; Fri, 3 Dec 2004 17:32:44 -0500 (EST) Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaM4d-0006t4-N5 for nemo@ietf.org; Fri, 03 Dec 2004 17:38:48 -0500 Received: from slb-av-01.boeing.com ([129.172.13.4]) by stl-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id QAA11985 for ; Fri, 3 Dec 2004 16:32:10 -0600 (CST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id iB3MW9i29252 for ; Fri, 3 Dec 2004 14:32:09 -0800 (PST) Received: from XCH-NW-31.nw.nos.boeing.com ([192.48.4.105]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Dec 2004 14:32:08 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] Announcing the Global HAHA draft Date: Fri, 3 Dec 2004 14:32:07 -0800 Message-ID: Thread-Topic: [nemo] Announcing the Global HAHA draft Thread-Index: AcTNPxV7TPEWbBlHRcS+Jz5sk1ph9AJ2jHNw From: "Dul, Andrew L" To: X-OriginalArrivalTime: 03 Dec 2004 22:32:08.0594 (UTC) FILETIME=[EC90C720:01C4D987] X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 07 Dec 2004 19:55:07 -0500 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Ryuji Wakikawa [mailto:ryuji@sfc.wide.ad.jp] > Sent: Wednesday, November 17, 2004 10:44 PM > At Wed, 17 Nov 2004 08:34:29 -0800, > Dul, Andrew L wrote: > > > > I think one of the reasons why you haven't seen a lot of > interest on > > this draft is that the truly global mobility market is really very > > small. The aircraft industry also tends to move quite slow=20 > compared > > with the speed of technology & adoption in the "Internet" > space. When > > I think about the objects that are really truly globally mobile in > > most cases they are limited to aircraft, maritime vessels,=20 > & people. > > Even when you think about people further, we are mostly regionally > > mobile. Sure we travel to different parts of the globe but=20 > most of us > > are generally only regionally mobile, and when we are > outside of our > > normal region we are often there for only shorter periods of time. > > Jet aircraft are somewhat unique in that they can traverse=20 > the entire > > globe within a single day. >=20 > The airplane is perfectly applicable scenario. There are > also useful cases without globally physical movements. > For example, automobile industry is also interested in this > topic. When considering Europe automobile market, where can=20 > they put HA? 1 HA for each country? Commercial tracks often=20 > drive beyond countries. If I got Japanese car in Europe, MNP=20 > might be configured with the home network in Japan. =20 I would expect for an automobile that the HA would be associated with the service provider that is providing the connectivity service for the automobile. For example if I bought an Japanese car and it is sold & used in Europe, the connectivity service would be provided by a company with service in Europe. This is not to say that the service provider couldn't be based somewhere else and have the HA outside of Europe but my guess is that these types of service providers will be regionally based. I consider an automobile to be generally regionally mobile, not globally mobile. >=20 > > As I read through the draft (4.1.1.) I can see areas where the > > tunneling in a global environment can still cause a large=20 > increase in > > latency. Consider the following case. Service provider A > has a ground > > global-haha network that an aircraft attach to in London & > Sydney, in > > this case the aircraft is owned by company Z with > operations in Chicago > > served by Service provider B. The plane is on the ground=20 > in Sydney and > > maintenance staff are using the onboard IP phone to talk to > operations > > staff in Chicago. Given a set of BGP routing tables it is possible > > that the path through the London HA would be a perceived best path > > from Chicago. In this case the call would be routed from=20 > Chicago to > > London to Sydney instead of directly to Sydney. In the v4 world we > > have used a BGP rehoming solution that can largely negate=20 > this issue. > > At this point it is unclear to me if a similar rehoming solution is > > possible or desirable in the multihomed v6 world. This also may be=20 > > too much of a corner case but it is nonetheless an interesting case. >=20 > Isn't it possible that service provider B joins the > global-haha network of service provider A? And if service=20 > provider A advertise the same prefix from London and Sydney=20 > to BGP, operator in Chicago should pick the path via Sydney=20 > (when IP distance is really shorter). >=20 This could be possible. The real question is if there will be "global-haha peering" between a majority of the service providers. If there are only a few service providers who support this feature then it is not as useful, IMO. Protocols like RSVP come to mind...good ideas, but they aren't very useful if everyone doesn't support it. > > In my opinion I believe that for a global mobility standard to be=20 > > truly successful it must allow for the mobile networks to=20 > roam between=20 > > service providers & BGP ASNs. This aspect brings up=20 > another whole set=20 > > of issues with address allocation, v6 multi-homing, and=20 > integration with BGP. > > (Which maybe outside the scope of the NEMO charter?) I=20 > also note that > > many of these issues are still not finalized in the v6=20 > world from my=20 > > current readings. Authentication & Authorization for MR's=20 > to the mesh=20 > > between ASNs is also a consideration. As Terry Davis one of my=20 > > colleagues stated in a previous mail, it is likely that the=20 > aircraft=20 > > networks will be connected to a number of other networks=20 > via different=20 > > mechanisms, some of them will be satellite based, some=20 > air-to-ground,=20 > > and some ground-to-ground when the aircraft is between flights.=20 > > Specifically for the ground-to-ground links it is unlikely that a=20 > > single service provider would be able to provide global coverage at=20 > > any large majority of world airports. >=20 > Global-HAHA enables full HA operations on IP layer. It means=20 > we can put HAs over ASN if each HA advertise the same home=20 > network prefix by BGP. It might be possible to see some super=20 > ISP beyond ASN for globally mobility in near future:-) >=20 While this is all possible, the question remains if it will be practical, in the real world of network operations. Lots of tunneling also tends to make connectivity problems harder to pinpoint & troubleshoot (I'm personally not a big fan of tunneling) If I am service provider A, I may not want one of my competitors "B" announcing address space for someone who is generally a customer service provider A. There are also lots of security issues when "anyone" could announce the space. How do you know if the prefix being announced is legitimate? Also how do you assign the address space? =20 To make this even reasonable you would have to have a separate address block that only contained mobile platforms. To me this makes the most sense. If we really want to prevent huge growth in the DFZ separate large aggregate blocks for mobile networks will be required. Agreements to exchange mobile network routes will have to be created between Service Providers. In the end, if only a few providers exchange the mobile routes then we lose the ability to have globally optimized routing. Perhaps we want to consider treating the mobility of "large networks" like planes, ships, etc differently than "small networks" like phones & PDAs. There are probably a couple orders of magnitude difference between the number of "small" vs "large" networks. Maybe they need different types of optimization and mobility protocols. Andrew From nemo-bounces@ietf.org Tue Dec 7 20:03:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24267 for ; Tue, 7 Dec 2004 20:03:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cbq6n-0000zc-GP; Tue, 07 Dec 2004 19:55:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CaM29-00028K-VH for nemo@megatron.ietf.org; Fri, 03 Dec 2004 17:36:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13303 for ; Fri, 3 Dec 2004 17:36:11 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CaM7x-000782-NY for nemo@ietf.org; Fri, 03 Dec 2004 17:42:15 -0500 Received: from slb-av-01.boeing.com ([129.172.13.4]) by blv-smtpout-01.boeing.com (8.9.2.MG.10092003/8.8.5-M2) with ESMTP id OAA11903 for ; Fri, 3 Dec 2004 14:35:41 -0800 (PST) Received: from XCH-NWBH-02.nw.nos.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.11.3/8.11.3/MBS-AV-LDAP-01) with ESMTP id iB3MZdi03038 for ; Fri, 3 Dec 2004 14:35:39 -0800 (PST) Received: from XCH-NW-31.nw.nos.boeing.com ([192.48.4.105]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 3 Dec 2004 14:35:40 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] Announcing the Global HAHA draft Date: Fri, 3 Dec 2004 14:35:39 -0800 Message-ID: Thread-Topic: [nemo] Announcing the Global HAHA draft Thread-Index: AcTPXxB512RR+QuyRumBgEkSmLRhfAKJVuLA From: "Dul, Andrew L" To: X-OriginalArrivalTime: 03 Dec 2004 22:35:40.0336 (UTC) FILETIME=[6AC60B00:01C4D988] X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Tue, 07 Dec 2004 19:55:07 -0500 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com]=20 > Sent: Saturday, November 20, 2004 4:14 PM > To: Dul, Andrew L > Cc: pthubert@cisco.com; nemo@ietf.org > Subject: Re: [nemo] Announcing the Global HAHA draft >=20 >=20 > I just wanted to mention that I've just read somewhere that=20 > when BGP routes are allowed to be injected at several ISPs=20 > they must be at most or longer than /19 (v4 space). Is it so? >=20 The smallest network that will be globally propagated today in the Default Free Zone is /24. For our implementation we have chosen that network size for commercial passenger jets. The /24 number however is just what is currently accepted by the largest majority of service providers. If a majority of providers decided to change to /23 tomorrow (unlikely, IMO) then we would have to change our network size to inject the routes in a manner that was useful. If we need more than /24 we could always assign a larger block to a particular aircraft. >=20 > > At this point it is unclear to me if a similar rehoming solution is > > possible or desirable in the multihomed v6 world. This also may be=20 > > too much of a corner case but it is nonetheless an interesting case. >=20 > YEs, I guess so, a case that I'm interested to know. For=20 > example, is it that the router onboard talks BGP, or the one=20 > on the ground? >=20 In our implementation BGP is confined to the ground, but there is no reason why BGP couldn't be deployed in the air if one wanted to. > I also wanted to say it seems to me that passenger=20 > trajectories are usually known knowns (not random as in=20 > mobile handset trajectories). And I have the feeling this may=20 > ease the impact of route injection may have on the core=20 > routing tables. For example, if the ground router at the=20 > destination knows the plane shows above at exactly 02h55gmt=20 > then it could prepare in advance something for it. This may=20 > be far off what BGP can do, I;m not knowledgeable, just=20 > floating an idea. I don't see how this would effect the BGP table, you have to transition from one location to another at some time, whether you can predict the time or not only changes when the change will happen not how the change will happen. In our case we have a limited time to make the transition happen on the order of 10's of minutes, given we've all been on flights that are delayed by hours the trajectory is probably not that deterministic. Trajectories also very daily due to weather conditions.=20 Andrew From nemo-bounces@ietf.org Thu Dec 9 12:26:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12435 for ; Thu, 9 Dec 2004 12:26:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcS1r-00042h-DD; Thu, 09 Dec 2004 12:24:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcRfV-0003GN-7B for nemo@megatron.ietf.org; Thu, 09 Dec 2004 12:01:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10423 for ; Thu, 9 Dec 2004 12:01:26 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcRmT-0001Or-3Y for nemo@ietf.org; Thu, 09 Dec 2004 12:08:44 -0500 Received: from iseran.local (unknown [130.79.91.23]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 2430B4C0DE for ; Fri, 10 Dec 2004 02:00:48 +0900 (JST) Date: Fri, 10 Dec 2004 02:03:54 +0900 From: Thierry Ernst To: nemo Message-Id: <20041210020354.1613406a.ernst@sfc.wide.ad.jp> Organization: Keio University X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; powerpc-apple-darwin7.4.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 1.1 (+) X-Scan-Signature: 2af167865907217f0b49c659e31a77f7 Content-Transfer-Encoding: 7bit Subject: [nemo] Draft Minutes 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear all, Here are the NEMO WG meeting minutes, please check and comment if you find any serious mistakes or wrong statement. Many thanks for Marcelo for taking notes and putting these minutes in shape and also for Masafumi's contribution with additional notes. NEMO Working Group - IETF 61 ============================ Wednesday, November 10, 2004 Scribes: Marcelo Bagnulo, Masafumi Watari Jabber scribes: T.J. Kniveton, Alexandru Petrescu Agenda: ------- 1. Agenda, welcoming, etc .....................................05mins Chairs 2. NEMO WG Status............................................. 05mins Chairs Terminology and Requirements draft-ietf-nemo-terminology-02.txt draft-ietf-nemo-requirements-03.txt Draft Issues: http://www.sfc.wide.ad.jp/~ernst/nemo NEMO Home Network Model draft-ietf-nemo-home-network-models-01.txt IPRs on NEMO Basic Support 3. NEMO Basic Support (draft status).......................... 20mins Vijay Devarapalli draft-ietf-nemo-basic-support-03.txt Draft Issues: http://people.nokia.net/vijayd/nemo/issues.html 4 NEMO MIB Design ........................................... 05mins Sri Gundavelli "NEMO Management Information Base" http://www.ietf.org/internet-drafts/draft-ietf-nemo-mib-00.txt 5. Announcement: 6th TAHI interop test event ................. 05mins Yukiyo Akisada 6. Prefix Delegation ......................................... 10mins TJ Kniveton draft-kniveton-nemo-prefix-delegation-00.txt 7. NEMO Multihoming Issues ................................... 25mins "Analysis of Multihoming in Network Mobility Support" draft-ietf-nemo-multihoming-issues-01.txt Draft Issues: http://www.mobilenetworks.org/nemo/draft-ietf-nemo- multihoming-issues ChanWah Ng (10mins) Discussion (5mins) "Global HAHA" draft-thubert-nemo-global-haha-00.txt draft-wakikawa-mip6-nemo-haha-spec-00.txt draft-wakikawa-mip6-nemo-haha-01.txt Pascal Thubert (10mins) 8. NEMO RO Problem Statement ................................. 30mins "NEMO Route Optimization Problem Statement" draft-clausen-nemo-ro-problem-statement-00.txt Thomas Clausen / Ryuji Wakikawa (5mins) "RO with Nested CNs" draft-watari-nemo-nested-cn-00.txt Masafumi Watari / Thierry Ernst (5mins) "Update of "Taxonomy of RO models in the NEMO context" draft-thubert-nemo-ro-taxonomy-03.txt Pascal Thubert / ChanWah NG (5mins) "NEMO RO Pb Statement, Requirements and Evaluation Considerations" draft-zhao-nemo-ro-ps-00.txt Fan Zhao (5mins) Discussion (10mins) 9. Securing Prefix in Binding Updates ......................... 05mins ChanWah NG "Extending Return Routability Procedure for Network Prefix (RRNP)" draft-ng-nemo-rrnp-00.txt 1. Agenda ========== No comments about the agenda 2. NEMO WG Status - Thierry Ernst ================================== Terminology and Requirements draft-ietf-nemo-terminology-02.txt draft-ietf-nemo-requirements-03.txt Draft Issues: http://www.sfc.wide.ad.jp/~ernst/nemo The drafts have been updated a few weeks ago. There are still some open issues in the Terminology draft Few open issues in the Requirements draft, TJ will update it. The goal is to submit it to the IESG as soon as possible. NEMO Home Network Model draft-ietf-nemo-home-network-models-01.txt Ready for WGLC that will be issued in a couple of days IPRs on NEMO Basic Support Cisco has changed IPR Cisco new statemant: https://datatracker.ietf.org/public/ ipr_detail_show.cgi?&ipr_id=497 Cisco old statement: https://datatracker.ietf.org/public/ ipr_detail_show.cgi?&ipr_id=135 Nokia IPR Nokia statement: https://datatracker.ietf.org/public/ ipr_detail_show.cgi?&ipr_id=136 The new IPR statement from Cisco is easier to interpretate, and facilitates open source code developers to implement the NEMO basic support. With this changes, Cisco IPR is easier to deal with than the Nokia IPR KAME and USAGI are likely to support NEMO after the new IPR. Question: --------- C. Ng: The Threats and Analysis draft has not been updated for while, but this is still a milestone on the wg charter, will those be adopted as wg items? Thierry and T.J.: If there is no additional threats, we should remove the milestone from the charter. This part is now covered with the NEMO Basic Support update. 3. NEMO Basic Support (draft status).......................... 20mins Vijay Devarapalli draft-ietf-nemo-basic-support-03.txt Draft Issues: http://people.nokia.net/vijayd/nemo/issues.html Status - IANA assignments are done - Very close to AUTH48 call - Some issues raised recently by Erik Nordamrk - The question is why changes need/can be done now and which ones can be made later. The proposed classification for changes is: - Critical changes that imply a fundamental problem in the document and would require a new WGLC - Important changes where the text is not clear and may affect interoperability. these changes can be done if there is wg consensus and the IESG approves them - Desirable changes that imply clarifications. These can be done in this document or can be done in future versions - Minor changes mostly editorial, that can be done now since they don't affect the protocol. The proposed changes since IESG approval have been discussed on the WG ML The Draft Issues are at: http://people.nokia.net/vijayd/nemo/issues.html The changes have been classified in the above categories as following: * Critical changes None * Important changes Issue 42 The question is whether to include all the prefix in BU. The consensus in the discussion in the ML was to include all the prefixes in a BU BA status values MR discards BAck with status values 141 and 142 in implicit mode Status value 143 makes no sense in explicit mode. These would only occur in these modes if there is a misconfiguration. However, the current text says to silently discard. Then, the MR user wouldn't know what is happening without an error. The proposed solution is to treat this as a fatal error. This solution does not require any changes on the wire, it is mostly an implementation hint. The use of tunnel encapsulation limit There is text to limit the number of nested mobile routers. However, this is not possible, or would require a complicated solution. The proposed solution is to remove that paragraph. Issue 39 Conflicting wording of SHOULD and MUST The proposed solution is to use SHOULD Another issue to explicitly list authorization of the MR in the security considerations section The solution was to add text to security considerations section Another issue is to clarify text about error code 143 in BAck, without changing IANA considerations. Another issue is about sending routing updates on the visited link This can't be enforced. This was spotted by Alex Z. before the IESG last call, but mistakenly not updated in the doc. * Other changes that fall under the other categories refer to the above URL of the issues list Conclusions: - No critical changes - Few changes are needed - Authors recommendation: only accept changed don't require recycling the doc to the WG - IESG members should be made aware of the changes - Do the changes during AUTH48 Questions: ---------- Pascal: Which is the impact on existing implementations of these changes? No comments were made about this Thierry: Sense of the room: Is is a good idea to submit the draft or we should remove it from RFC queue? Hands for shipping the document ASAP: some hands Hands for retaining the document: none TJ: Is this classification of the changes is good approach? The proposal is to make important and minor changes now and defer the intermediate, any comments or objections? none 4 NEMO MIB Design ........................................... 05mins Sri Gundavelli "NEMO Management Information Base" http://www.ietf.org/internet-drafts/draft-ietf-nemo-mib-00.txt The MIPv6 mib was published and it manages the MIPv6 part. The focus here is NEMO as the managed entity The NEMO mib structure has 4 groups - nemoSystem Group: Provides general information relevant to the implementation and operation of the NEMO protocol - nemoStats Group: statistics related to the NEMO protocol - nemoNotification Group: defines the notification generated by the NEMO entity in response to the operationally interesting protocol state changes - nemoConformance Group: identifies the managed objects that needs to be implemented for conforming This is the first submission and we expect to include more objects in future releases The general question is what additional objects do we need? Additional Issues to be determined - Need to add the objects for HA - What other notification do we need? - Do we need other objects for diagnostics? What's next? - Review the draft based on the WG input - Get it reviewed by a MIB Doctor 5. Announcement: 6th TAHI interop test event ................. 05mins Yukiyo Akisada See http://www.tahi.org/inop/6thinterop.html Test event in Japan, Chiba, 24 Jan (1 week) Interop test: NEMO basic support is included Conformance test: NEMO is included 6. Prefix Delegation ......................................... 10mins TJ Kniveton draft-kniveton-nemo-prefix-delegation-00.txt Prefix delegation is included in the charter of the WG This draft is augmenting the work done by R. Droms The goal is to use NEMO signaling for prefix delegation New protocol elements are defined to carry prefix requests Both Transient (CoA) and Persistent (HoA) prefixes are considered This approach complements DHCP methods. NEMO signaling has some additional mobility related attributes and NEMO based approaches might save flows Question to the wg is: Is the WG interested in DHCPv6 only method? Does it make sense to merge this approach with DHCPv6? Questions: ---------- Vijay: I don't agree with statement that the two approaches are complementary. DHCP can provide a complete solution. TJ: You can have a solution with only DHCP, but there are some nemo specifics elements missing. You can also have a solution using only nemo signaling also. So there are three options only NEMO, DHCP, hybrid. Vijay: Could we have two proposed methods, where we just have the DHCPv6, and the other with this apporach? TJ: We could consider this options. Opinions from the WG? Pascal: The motivation part of the draft says clearly why we need this so please read it if you haven't. Pascal: Do we need to merge this or separate is fine? Vijay: Separate is fine TJ: No sense from the room. We proceed working with Ralph and Pascal and figure out how to integrate those, since there is no sense from the room Vidya: MIP6 agreed on using NAI for HoA, are we just relying on MIP6 for whatever they decide? TJ: NEMO is an extension on MIP6, whatever agreement HA and MN have, they'll be a parallel set of rules for MR Vidya: There needs to be a way for authorizing MR say it's acceptable to own this prefix TJ: This is an implementation/policy decision, how do we decide MR allowed to use a HoA? The same thing happen with prefixes. TJ: In conclusion, since there's really no strong oppinion. We could advance both of these documents (DHCP based and NEMO based) as WG items. Ryuji: Both mechanisms are statefull, do we need two statefull mechanisms? Do we need a stateless mechanism? Erik: This draft will be a wg but i can't find the draft in id directory TJ: It was submitted late and it is not in directory TJ: Ralph's draft is expired 7. NEMO Multihoming Issues ................................... 25mins "Analysis of Multihoming in Network Mobility Support" draft-ietf-nemo-multihoming-issues-01.txt Draft Issues: http://www.mobilenetworks.org/nemo/draft-ietf-nemo- multihoming-issues ChanWah Ng (10mins) Discussion (5mins) List of issues and proposed solutions: Issue 1: fixed Issue 2: rejected Issue 3: accept and remove text Issue 4: remove the word different Issue 5: rejected Issue 6: updated benefits lists Issue 7: updated description Issue 8: explain that it is only an example Issue 9: description of the problem Issue 10: other failure modes explored Issue 11: follow multi6 How to close 12-13? Keep the text as an appendix Move to a separate draft WG opinions: Marcelo: Move it to separete draft TJ: Do both. Keep it as an appendix for now and make a new doc if needed. Which problems should be solved by NEMO WG - Path survival - Path selection - Ingress filtering - Failure Detection - Media Detection - HA sync - Prefix Delegation - Multiple Binding Registration - Source Address Selection - Impact on Routing Infrastructure - Nested Mobile Networks - Split Mobile Networks Questions: ---------- Pascal: Split mobile network should not happen, or must not happen. Marcelo: Path survival may be different in NEMO than in multi6 since on of the goal of NEMO is to support ubiquity. This means that the failure will occur in the access link. It may make sense to optimize this case. In addition, paths in NEMO case may have very different characteristics, so they may be different considerations than in the multi6 case. Finally, in multi6 it is assumed to be multiple prefixes, which may not be the case in NEMO multihoming. Pascal: Can we just say wait for multi6? TJ: We can't expect other WG to solve items we need that is not addressed in the charter. Marcelo: We should identify which can be expected to be covered by multi6 and which needs to be done in NEMO. PAscal: My conclusion is I believe some of it may end up here TJ: Does everybody agree with the categorization presented here? We should really follow up with this offline "Global HAHA" draft-thubert-nemo-global-haha-00.txt draft-wakikawa-mip6-nemo-haha-spec-00.txt draft-wakikawa-mip6-nemo-haha-01.txt Pascal Thubert (10mins) The history of the document is that it started as draft-wakikawa-mip6-nemo-haha and then the document split into 3 documents: The Base document for HAHA gives normative part. Then Global HAHA provides distribution of home across internet and the local HAHA which provides high availability in a link. In this presentation we will focus on Global HAHA. The NEMO requirements include Multlihoming support and that multiple HA has to be distributed both locally and globally. One use case for the global disctributions is the airplane case. Among the problems that are being addressed we have the main target is the HA synchronization Additionally, we propose to obtain a L3 operation for NEMO In both NEMO basic support and MIPv6 Home are anchored to Home Link at L2 This means that the home can not be distributed geographically Then the Home link is a single point of failure So NEMO is an hybrid L2-L3 operation The proposal is to make NEMO full L3 Questions: ---------- Alexandru - Global HAHA implies 2 home agents. So maybe we should have HAHAHAHAHA for multihoming 8. NEMO RO Problem Statement ................................. 30mins "RO with Nested CNs" draft-watari-nemo-nested-cn-00.txt Masafumi Watari / Thierry Ernst (5mins) Short presentation on the status of his new Nested CN route optimization draft "NEMO Route Optimization Problem Statement" draft-clausen-nemo-ro-problem-statement-00.txt Thomas Clausen / Ryuji Wakikawa (5mins) The goals of this draft is to consider a MANET solution to RO problem statement Question to merge with other RO-problem-statements Pascal: Perhaps this is too much solution oriented. similar to local mobility management approaches. may be an overkill for some cases where there is only a default route "NEMO RO Pb Statement, Requirements and Evaluation Considerations" draft-zhao-nemo-ro-ps-00.txt Fan Zhao (5mins) Presentation of the draft. Several scenarios described Scenario 1: CN is in the infrastructure Scenario 2: CN is in the NEMO network "Update of "Taxonomy of RO models in the NEMO context" draft-thubert-nemo-ro-taxonomy-03.txt Pascal Thubert / ChanWah NG (5mins) Important changes from initial versions, in particular the problem statement is more clear, the description of the solutions is moved to the appendix Discussion: ----------- Thierry: We have 4 drafts about RO. We need to select one wg document candidate. The options would be to use the Taxonomy draft as a base wg document or to start from scratch. Alex: Start from scartch Thierry: Motivation for this preference? Alex: Current problem statement draft is too solution oriented. We need a neutral problem statement that is neutral. Thierry: Could you expand on this? Alex: For example the tree discovery approach is stated in the draft Pascal: This was true for version 0 but this version is new. You should read it Thierry: Did you read it? Alex: I don't remeber Tierry: Could you read the draft again and restate the position in the ml Ng: Please read the new version of the draft, since the changes are based in your comments Cristophe J.: We need more time to read the drafts, move it to the ml Erik: The problem is that the taxonomy is based on the solution space . We need to state the problem and not explore the solution space Pascal: There is a huge number of drafts proposed, we can get rid of the detail of the different solutions, but we think it is useful to keep the info about solutions, and pro and cons identified. Alex: Who has considered this?, this was not discussed in the ml Pascal: We are not only providing a problem statement but also we are also providing history Alex: The ml was silent Hesham: We are ratholing, if we just want to do the charter item, 3 pages drafts is enough Alex: The goal is to understand the problem and not based in a solution Hesham: We could simple do a 4 page doc with the problem description Thierry: Move the discussion to the ml Changes in the agenda: ====================== - Point 9. Securing Prefix in Binding Updates was not presented - A new presentation about v4/v6 transition and mobility by Vijay was presented. 9. v4/v6 transition and mobility The problem that is presented is what the NEMO MR should do when it finds itself on an IPv4 access network. This is related to the discussion on v6ops. One option would be something similar to TEREDO, where NEMO runs over a transition mechanism. We can build mobility mechanisms for the transition tunnel (i.e. when the v4 address changes) and another one for the MR tunnel (v6 address). However, the idea would be to collapse all in one tunnel. Questions: ---------- Sri: When you're traversing v4 network, tunneling will be there. When you collapse with HA it's the same. Erik: Are you assuming MR and HA have v4 connectivity with no NAT boxes? Vijay: We want to allow NAT Erik: You're going to end up having every protocol having NAT support Hesham: The problem is that a mobile host ends up in all sorts of access networks. Whether it's a host or router is orthagonal. There are different levels of mobility between host and access network, especially where LMM is being used. there are serious inefficiencies for managing mobility on those two levels. The scope is not bound by nemo or mobile ip for hosts, bit it's a general problem for mobility and transition. So, it would be nice to have a general framework for mobility. Henrik L.: I agree with Hesham. A lot of different aspects to transition in combination with mobility. I've authored a draft showing the full field of all these combinations. We shouldn't jump into this barrel from different directions from 3-5 work groups, we need a more generic approach. Vijay: Need to disagree. I don't think we can come up with a generic mechanism that can cover all mobility solutions. So we should use v6ops tunneling as much as possible. But if MR is v4/v6 and HA is v4/v6, we don't want a NEMO tunnel inside a transition tunnel Henrik: I don't think we disagree. Read the draft. Hesham: There are a few drafts. Different solutions for different problems. Get an idea of the problem, then we can talk solutions for next year. Pascal: I encourage people to read those drafts. This is more critical to us than v4, because you can't do anything w/o v4 Thierry: should we take this as a milestone for the WG? 10. Conclusions and Next Steps ................................. 10mins - More comments expected on terminology and requirements for wg last call. - WG last call for nemo home nw models in a few days - Remove threat analysis from milestones (already done). - NEMO basic support: next action to be taken about new issues. It will happen on ML in the next week - Prefix delegation: we need to discuss whether we accept 1 or 2 documents as wg document. - Multihoming: want to close accepted and rejected issues. - RO problem statement: need to discuss whether taxonomy draft will be WG document, or whether we will make a new, shorter document. - v4/v6 transition will be discussed on mailing list From nemo-bounces@ietf.org Thu Dec 9 15:06:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA28089 for ; Thu, 9 Dec 2004 15:06:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcUTZ-0003vS-Bc; Thu, 09 Dec 2004 15:01:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcULb-0000E1-I9 for nemo@megatron.ietf.org; Thu, 09 Dec 2004 14:53:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26410 for ; Thu, 9 Dec 2004 14:53:06 -0500 (EST) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=deimos.multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcUSe-0005Lh-4o for nemo@ietf.org; Thu, 09 Dec 2004 15:00:24 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id C180961C1 for ; Thu, 9 Dec 2004 11:52:16 -0800 (PST) Received: from deimos.multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88527-10 for ; Thu, 9 Dec 2004 11:52:16 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id 8A8D061E1; Thu, 9 Dec 2004 11:52:16 -0800 (PST) Received: from [192.103.16.145] (unknown [192.103.16.145]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 24A5261BB for ; Thu, 9 Dec 2004 11:52:12 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IETF NEMO WG From: "T.J.Kniveton" Date: Thu, 9 Dec 2004 11:52:34 -0800 X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [nemo] IETF61 minutes 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit The meeting minutes are on the web site. If you have any comments or corrections, please make them (on the list, or to me) before the deadline tomorrow. TJ From nemo-bounces@ietf.org Thu Dec 9 16:47:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14218 for ; Thu, 9 Dec 2004 16:47:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcVOy-0006qS-4J; Thu, 09 Dec 2004 16:00:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcVKj-0003he-3q for nemo@megatron.ietf.org; Thu, 09 Dec 2004 15:56:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03360 for ; Thu, 9 Dec 2004 15:56:15 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcVRm-0006sD-5p for nemo@ietf.org; Thu, 09 Dec 2004 16:03:34 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id iB9KQT031830; Thu, 9 Dec 2004 12:26:29 -0800 X-mProtect: <200412092026> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14171.americas.nokia.com (172.18.141.71, claiming to be "[172.18.141.71]") by darkstar.iprg.nokia.com smtpdo9TyHh; Thu, 09 Dec 2004 12:26:27 PST Message-ID: <41B8BBB1.6080406@iprg.nokia.com> Date: Thu, 09 Dec 2004 12:55:13 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Thierry Ernst , "T.J.Kniveton" Subject: Re: [nemo] Draft Minutes References: <20041210020354.1613406a.ernst@sfc.wide.ad.jp> In-Reply-To: <20041210020354.1613406a.ernst@sfc.wide.ad.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: IETF 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Thierry Ernst wrote: > 9. v4/v6 transition and mobility > > The problem that is presented is what the NEMO MR should do > when it finds itself on an IPv4 access network. This is related > to the discussion on v6ops. One option would be something > similar to TEREDO, where NEMO runs over a transition mechanism. > We can build mobility mechanisms for the transition tunnel > (i.e. when the v4 address changes) and another one for the MR > tunnel (v6 address). However, the idea would be to collapse all > in one tunnel. > snip > Thierry: should we take this as a milestone for the WG? I think there was some support for doing this. but is not captured in the minutes. Vijay From nemo-bounces@ietf.org Fri Dec 10 06:44:44 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06819 for ; Fri, 10 Dec 2004 06:44:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcjAm-0007XO-Cl; Fri, 10 Dec 2004 06:42:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccj4O-0006ON-V9 for nemo@megatron.ietf.org; Fri, 10 Dec 2004 06:36:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06236 for ; Fri, 10 Dec 2004 06:36:18 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcjBW-0002Yu-RY for nemo@ietf.org; Fri, 10 Dec 2004 06:43:46 -0500 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iBABblHu027769; Fri, 10 Dec 2004 04:37:48 -0700 (MST) Received: from zfr01srv02.crm.mot.com (zfr01srv02.crm.mot.com [10.161.201.8]) by il06exr04.mot.com (Motorola/il06exr04) with ESMTP id iBABYmcu025681; Fri, 10 Dec 2004 05:34:48 -0600 Received: from [10.161.201.117] (zfr01-2117.crm.mot.com [10.161.201.117]) by zfr01srv02.crm.mot.com (Postfix) with ESMTP id A781A8659B2; Fri, 10 Dec 2004 12:36:04 +0100 (CET) Message-ID: <41B98A24.4030807@motorola.com> Date: Fri, 10 Dec 2004 12:36:04 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dul, Andrew L" Subject: Re: [nemo] Announcing the Global HAHA draft References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Dul, Andrew L wrote: > The smallest network that will be globally propagated today in the > Default Free Zone is /24. For our implementation we have chosen that > network size for commercial passenger jets. The /24 number however > is just what is currently accepted by the largest majority of service > providers. If a majority of providers decided to change to /23 > tomorrow (unlikely, IMO) then we would have to change our network > size to inject the routes in a manner that was useful. > > If we need more than /24 we could always assign a larger block to a > particular aircraft. You mean several /24s, not a larger block, right? If ISPs only accept max /24 then one couldn't assign /23 to a particular aircraft, or am I wrong somewhere. >> YEs, I guess so, a case that I'm interested to know. For example, >> is it that the router onboard talks BGP, or the one on the ground? > > In our implementation BGP is confined to the ground, but there is no > reason why BGP couldn't be deployed in the air if one wanted to. I see, I understand that if BGP runs on ground it could be easily be put on board. They seem to have a small server farm on-board for entertainment now, so running BGP can work too. OTOH, if your current implementation runs BGP on ground and the onboard router ("mobile router"?) does not run BGP, then what is used on this onboard router to inform the ground BGP router that it arrived? Is this information passed with an L2 protocol? > I don't see how this would effect the BGP table, you have to > transition from one location to another at some time, whether you can > predict the time or not only changes when the change will happen not > how the change will happen. I somehow agree. I think one problem is the one of "converging" routing table entries, or "converging" state of routing protocols is one of time; i.e. it takes too long to stabilize the routing state when a small change occurs. Info I've read mentions in the order of 30minutes. I guess that the timelength can be related to the size of the change. If larger change is requested then longer it takes. With this, if ground router knows 30min in advance about a 30min change that is bound to occur, then it could trigger that change 30min at the right time. In addition, if a /24 needs to be injected then this could be split into several /25s and another /24 such that injecting would not happen at once, but in a sequence with sufficient time laps in between, so probably inducing a lesser "oscillation" in the network. Something like that. > In our case we have a limited time to make the transition happen on > the order of 10's of minutes, given we've all been on flights that > are delayed by hours the trajectory is probably not that > deterministic. Trajectories also very daily due to weather > conditions. Yes, I sense the feeling of the impossibility to plan on this, because of too many random factors. It was just an idea. Alex From nemo-bounces@ietf.org Fri Dec 10 13:18:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04163 for ; Fri, 10 Dec 2004 13:18:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcpBP-0002x2-Ds; Fri, 10 Dec 2004 13:07:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ccp8e-0002GY-JW for nemo@megatron.ietf.org; Fri, 10 Dec 2004 13:05:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03019 for ; Fri, 10 Dec 2004 13:05:05 -0500 (EST) Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcpFs-0001jT-8a for nemo@ietf.org; Fri, 10 Dec 2004 13:12:37 -0500 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 KAA21418; Fri, 10 Dec 2004 10:03:11 -0800 (PST) Received: from XCH-NWBH-02.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 iBAI39t14132; Fri, 10 Dec 2004 12:03:09 -0600 (CST) Received: from XCH-NW-31.nw.nos.boeing.com ([192.48.4.105]) by XCH-NWBH-02.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 10 Dec 2004 10:03:04 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.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] Announcing the Global HAHA draft Date: Fri, 10 Dec 2004 10:03:03 -0800 Message-ID: Thread-Topic: [nemo] Announcing the Global HAHA draft Thread-Index: AcTerHDxFzoRW0HfRMOkm16mtVbAjwAMeVrQ From: "Dul, Andrew L" To: "Alexandru Petrescu" X-OriginalArrivalTime: 10 Dec 2004 18:03:04.0651 (UTC) FILETIME=[7EEAD1B0:01C4DEE2] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Content-Transfer-Encoding: quoted-printable 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Alexandru Petrescu [mailto:Alexandru.Petrescu@motorola.com]=20 > Sent: Friday, December 10, 2004 3:36 AM > To: Dul, Andrew L > Cc: nemo@ietf.org > Subject: Re: [nemo] Announcing the Global HAHA draft >=20 >=20 > Dul, Andrew L wrote: > > The smallest network that will be globally propagated today in the > > Default Free Zone is /24. For our implementation we have=20 > chosen that > > network size for commercial passenger jets. The /24=20 > number however=20 > > is just what is currently accepted by the largest majority=20 > of service > > providers. If a majority of providers decided to change to /23=20 > > tomorrow (unlikely, IMO) then we would have to change our network=20 > > size to inject the routes in a manner that was useful. > >=20 > > If we need more than /24 we could always assign a larger block to a > > particular aircraft. >=20 > You mean several /24s, not a larger block, right? If ISPs=20 > only accept max /24 then one couldn't assign /23 to a=20 > particular aircraft, or am I wrong somewhere. I think we are getting our larger vs. longer confused. :) You could assign a /23 because network operators will allow it to propagate in the global BGP table, you could also do several /24 but that creates unnecessary entries in the table. Almost all providers will not accept a /25 network from their BGP neighbors. >=20 > >> YEs, I guess so, a case that I'm interested to know. For example, > >> is it that the router onboard talks BGP, or the one on the ground? > >=20 > > In our implementation BGP is confined to the ground, but=20 > there is no =20 > > reason why BGP couldn't be deployed in the air if one wanted to. >=20 > I see, I understand that if BGP runs on ground it could be=20 > easily be put on board. They seem to have a small server=20 > farm on-board for entertainment now, so running BGP can work too. >=20 > OTOH, if your current implementation runs BGP on ground and=20 > the onboard=20 > router ("mobile router"?) does not run BGP, then what is used on this=20 > onboard router to inform the ground BGP router that it=20 > arrived? Is this information passed with an L2 protocol? >=20 Currently the movement between regions is controlled by software on the ground, this ground software causes the BGP route updates to be propagated. There currently isn't a routing protocol running between ground & air. =20 > > I don't see how this would effect the BGP table, you have to > > transition from one location to another at some time,=20 > whether you can > > predict the time or not only changes when the change will=20 > happen not > > how the change will happen. >=20 > I somehow agree. I think one problem is the one of=20 > "converging" routing table entries, or "converging" state of=20 > routing protocols is one of time; i.e. it takes too long to=20 > stabilize the routing state when a small change occurs. Info=20 > I've read mentions in the order of 30minutes. I guess that=20 > the timelength can be related to the size of the change. If=20 > larger change is requested then longer it takes. >=20 Generally speaking we see the global route table reconverge within a minute. This reconvergence time is complementary to the time it takes to switch between satellites. > With this, if ground router knows 30min in advance about a=20 > 30min change that is bound to occur, then it could trigger=20 > that change 30min at the right time. >=20 > In addition, if a /24 needs to be injected then this could be=20 > split into=20 > several /25s and another /24 such that injecting would not happen at=20 > once, but in a sequence with sufficient time laps in between, so=20 > probably inducing a lesser "oscillation" in the network. >=20 I think introducing more routes (like the /25s) will actually cause more table churn vs. a single update & withdrawal. Andrew From nemo-bounces@ietf.org Fri Dec 10 14:26:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08701 for ; Fri, 10 Dec 2004 14:26:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcqHS-0007EA-5T; Fri, 10 Dec 2004 14:18:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CcqE7-0006NZ-DL for nemo@megatron.ietf.org; Fri, 10 Dec 2004 14:14:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07953 for ; Fri, 10 Dec 2004 14:14:50 -0500 (EST) Received: from motgate8.mot.com ([129.188.136.8]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcqLL-00036p-Cz for nemo@ietf.org; Fri, 10 Dec 2004 14:22:20 -0500 Received: from il06exr02.mot.com (il06exr02.mot.com [129.188.137.132]) by motgate8.mot.com (Motorola/Motgate8) with ESMTP id iBAJGNHu005970; Fri, 10 Dec 2004 12:16:24 -0700 (MST) Received: from [10.181.32.32] (mvp-10-181-32-32.ea.mot.com [10.181.32.32]) by il06exr02.mot.com (Motorola/il06exr02) with ESMTP id iBAJDMVk020014; Fri, 10 Dec 2004 13:13:23 -0600 Message-ID: <41B9F598.8030402@motorola.com> Date: Fri, 10 Dec 2004 20:14:32 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Dul, Andrew L" Subject: Re: [nemo] Announcing the Global HAHA draft References: In-Reply-To: X-Enigmail-Version: 0.89.0.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010501050507010103050204" X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org This is a cryptographically signed message in MIME format. --------------ms010501050507010103050204 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dul, Andrew L wrote: >> You mean several /24s, not a larger block, right? If ISPs only >> accept max /24 then one couldn't assign /23 to a particular >> aircraft, or am I wrong somewhere. > > I think we are getting our larger vs. longer confused. :) You could > assign a /23 because network operators will allow it to propagate in > the global BGP table, you could also do several /24 but that creates > unnecessary entries in the table. Almost all providers will not > accept a /25 network from their BGP neighbors. Ah I see, yes I made a confusion above. >>>> YEs, I guess so, a case that I'm interested to know. For >>>> example, is it that the router onboard talks BGP, or the one on >>>> the ground? >>> >>> In our implementation BGP is confined to the ground, but there is >>> no reason why BGP couldn't be deployed in the air if one wanted >>> to. >> >> I see, I understand that if BGP runs on ground it could be easily >> be put on board. They seem to have a small server farm on-board >> for entertainment now, so running BGP can work too. >> >> OTOH, if your current implementation runs BGP on ground and the >> onboard router ("mobile router"?) does not run BGP, then what is >> used on this onboard router to inform the ground BGP router that it >> arrived? Is this information passed with an L2 protocol? >> > Currently the movement between regions is controlled by software on > the ground, this ground software causes the BGP route updates to be > propagated. There currently isn't a routing protocol running between > ground & air. Oh, that looks different. Does the software on the ground also offer an IP address to the onboard router with DHCP? (I would assume so). > Generally speaking we see the global route table reconverge within a > minute. This reconvergence time is complementary to the time it > takes to switch between satellites. So 1minute is seen as acceptable. And I guess you are talking about the "global route table convergence" as "global Iinternet", not a particular widelyspread closed core network. >> With this, if ground router knows 30min in advance about a 30min >> change that is bound to occur, then it could trigger that change >> 30min at the right time. >> >> In addition, if a /24 needs to be injected then this could be split >> into several /25s and another /24 such that injecting would not >> happen at once, but in a sequence with sufficient time laps in >> between, so probably inducing a lesser "oscillation" in the >> network. >> > I think introducing more routes (like the /25s) will actually cause > more table churn vs. a single update & withdrawal. Yes... It's just that I'm trying to identify what may be different in this particular aerospace setting that would give hints for a different solution. And I was thinking that the approximate pre-knowledge of the trajectory may be a distinction. Maybe also the fact that during a longest trajectory possibly only 2-3 changes happen. Just some thoughts and thanks for the info about this type of network mobility. Alex --------------ms010501050507010103050204 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOzDCC A10wggJFoAMCAQICCwEAAAAAAPtjjP4sMA0GCSqGSIb3DQEBBQUAMHcxCzAJBgNVBAYTAkJF MRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xh c3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQTAe Fw0wNDAzMTkxNDM2MTVaFw0wNTAzMTkxNDM2MTVaMFoxCzAJBgNVBAYTAkZSMRswGQYDVQQD ExJBbGV4YW5kcnUgUGV0cmVzY3UxLjAsBgkqhkiG9w0BCQEWH2FsZXhhbmRydS5wZXRyZXNj dUBtb3Rvcm9sYS5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANcRvXtDyRkqrlPe Sre3uXYCWkWFMpzBAfnQ6XivCdhZuAlRpYShJBWmJv9GHSZzkI+V5QpcI/TqGsZqLumCrwWL A7+zk1H3aHoPn5a2fzVCi7+0RyLnZPnKh90sdsJ90jm58R8NI271OK5AcdV9ugd7FDss1h4i mwFETBASnV7nAgMBAAGjgYowgYcwEQYJYIZIAYb4QgEBBAQDAgWgMA4GA1UdDwEB/wQEAwIE 8DAfBgNVHSMEGDAWgBRtxCvBfYUQoPkTFg1VKwO6NkwhMTBBBgNVHR8EOjA4MDagNKAyhjBo dHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1BlcnNvbmFsU2lnbkNsYXNzMi5jcmwwDQYJKoZI hvcNAQEFBQADggEBACSXcjWSr6AczkIEmM01J6z16NS4sKnX5oSt8dDZmYdgpQC8UR9wuT19 MJbPhwggg5+y6t7s/d223eW3xQR57rn9yUkV1daqtUKWXa7iosjI6VPG/MTODRP0luCcmg4/ LyJYqSKBheS/A1yTajvzqIB7wzr1l/4u7Hty85CiHYXVVkFGW1kWnhDS1gq5rxuCIH+gvggB zbFasAcywV7IXROr5sfoCiNaJfnr9tt/IO6GVaIkdBkZS7wC0Imt3DoRTbPdWN7am0Y5uS6y a0XBbEjuP5PTmM6Bc+6Mc+aQ1YUKapCPdnxw1vTrB9adPZQDVBgmWXxM/mW5xnsXZV90n9Qw ggNdMIICRaADAgECAgsBAAAAAAD7Y4z+LDANBgkqhkiG9w0BAQUFADB3MQswCQYDVQQGEwJC RTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29uYWxTaWduIENs YXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENsYXNzIDIgQ0Ew HhcNMDQwMzE5MTQzNjE1WhcNMDUwMzE5MTQzNjE1WjBaMQswCQYDVQQGEwJGUjEbMBkGA1UE AxMSQWxleGFuZHJ1IFBldHJlc2N1MS4wLAYJKoZIhvcNAQkBFh9hbGV4YW5kcnUucGV0cmVz Y3VAbW90b3JvbGEuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDXEb17Q8kZKq5T 3kq3t7l2AlpFhTKcwQH50Ol4rwnYWbgJUaWEoSQVpib/Rh0mc5CPleUKXCP06hrGai7pgq8F iwO/s5NR92h6D5+Wtn81Qou/tEci52T5yofdLHbCfdI5ufEfDSNu9TiuQHHVfboHexQ7LNYe IpsBREwQEp1e5wIDAQABo4GKMIGHMBEGCWCGSAGG+EIBAQQEAwIFoDAOBgNVHQ8BAf8EBAMC BPAwHwYDVR0jBBgwFoAUbcQrwX2FEKD5ExYNVSsDujZMITEwQQYDVR0fBDowODA2oDSgMoYw aHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9QZXJzb25hbFNpZ25DbGFzczIuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQAkl3I1kq+gHM5CBJjNNSes9ejUuLCp1+aErfHQ2ZmHYKUAvFEfcLk9 fTCWz4cIIIOfsure7P3dtt3lt8UEee65/clJFdXWqrVCll2u4qLIyOlTxvzEzg0T9JbgnJoO Py8iWKkigYXkvwNck2o786iAe8M69Zf+Lux7cvOQoh2F1VZBRltZFp4Q0tYKua8bgiB/oL4I Ac2xWrAHMsFeyF0Tq+bH6AojWiX56/bbfyDuhlWiJHQZGUu8AtCJrdw6EU2z3Vje2ptGObku smtFwWxI7j+T05jOgXPujHPmkNWFCmqQj3Z8cNb06wfWnT2UA1QYJll8TP5lucZ7F2VfdJ/U MIID4zCCAsugAwIBAgILBAAAAAAA8HYD2XwwDQYJKoZIhvcNAQEFBQAwVzELMAkGA1UEBhMC QkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jvb3QgQ0ExGzAZBgNV BAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05OTAxMjgxMjAwMDBaFw0wOTAxMjgxMjAwMDBa MG0xCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRswGQYDVQQLExJQ cmltYXJ5IENsYXNzIDIgQ0ExJjAkBgNVBAMTHUdsb2JhbFNpZ24gUHJpbWFyeSBDbGFzcyAy IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAkoz+7/RFjhdBbvzYvyFvqwad UsEsAJ0/joW4f0qPvaBjKspJJ65agvR04lWS/8LRqnmitvrVnYIET8ayxl5jpzq62O7rim+f trsoQcAi+05IGgaS17/Xz7nZvThPOw1EblVB/vwJ29i/844h8egStfYTpdPGTJMisAL/7h0M xKhrT3VoVujcKBJQ96gknS4kOfsJBd7lo2RJIdBofnEwkbFg4Dn0UPh6TZgAa3x5uk7OSuK6 Nh23xTYVlZxkQupfxLr1QAW+4TpZvYSnGbjeTVNQzgfR0lHT7w2BbObnbctdfD98zOxPgycl /3BQ9oNZdYQGZlgs3omNAKZJ+aVDdwIDAQABo4GZMIGWMA4GA1UdDwEB/wQEAwIBBjAPBgNV HRMBAf8EBTADAQH/MB0GA1UdDgQWBBR857KxLN6xp2vpdgzho/1ObMe59jAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L1Jvb3QuY3JsMB8GA1UdIwQYMBaA FGB7ZhpFDZfKiVAvfQTNNKj//P1LMA0GCSqGSIb3DQEBBQUAA4IBAQCOSXXBWIDxAxy2Zioi dZVbZLmecRI30bfezE8WYEUUAke+bIj39Rsdpp2qGW58HDqEpMWNqTwx/g3oQt8hUCLucQGB qGQzlPGtnVpbADfipFzkIKpgdJQ967DpIZ0dNKmmNINBXuM6/yEe0hup7XYtvi9PKFx5qeCW kf7KDCruRY51KismvY6uCN2LuVeN/20LqwhGDJ/5gii8H64MclYNd5qgiFd4JziNL3Ur1HFq FEiluobJ33wmE54tbMhb9Wt8HzhnL47U16jZhe0K4PKYadkal6ZQl5zHPSRZbrGhvY2mMhGd VAFbK4Lh/Y3FaEMN4LgmVJ5/E94Qp2n6siqBMIIEHzCCAwegAwIBAgILBAAAAAAA+j3u7Hkw DQYJKoZIhvcNAQEFBQAwbTELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYt c2ExGzAZBgNVBAsTElByaW1hcnkgQ2xhc3MgMiBDQTEmMCQGA1UEAxMdR2xvYmFsU2lnbiBQ cmltYXJ5IENsYXNzIDIgQ0EwHhcNMDQwMTIyMDkwMDAwWhcNMDkwMTI4MTEwMDAwWjB3MQsw CQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEgMB4GA1UECxMXUGVyc29u YWxTaWduIENsYXNzIDIgQ0ExKzApBgNVBAMTIkdsb2JhbFNpZ24gUGVyc29uYWxTaWduIENs YXNzIDIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpGIoCeDYfk4ikDHQ5 gQjc7gUny+ppV8euTaijN9tv1W69R1sdecNf/9e6vCyhf1LFzVmOaZX8X41n93Eu/7L34wHM 192JAKYSJMMkRNi2iYJOqECQEQUsIFxV8uF2iTiGel9k8S74gV6TeE4EVwrkUXgqs+j5JLtJ XkUpi/E3tambQx83cZzEMqvhKgMzvR4fkmr3SVvdKbND7mqreLiUngjpMlAxvmr/9+6KMug0 ccBdnyQFAakOmFkZzfVh5MRihhaTK4gByIj46Oyu8kb9pdw5McWCdps5SHFLXIWLhCSlZAGJ 9PRkKdJewx3CFsdzJtufRyrmNU5y9nSl2TajAgMBAAGjgbUwgbIwDgYDVR0PAQH/BAQDAgEG MBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0OBBYEFG3EK8F9hRCg+RMWDVUrA7o2TCExMDkG A1UdHwQyMDAwLqAsoCqGKGh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5uZXQvcHJpbWNsYXNzMi5j cmwwEQYJYIZIAYb4QgEBBAQDAgEGMB8GA1UdIwQYMBaAFHznsrEs3rGna+l2DOGj/U5sx7n2 MA0GCSqGSIb3DQEBBQUAA4IBAQALrc674tzSl8eLA0DJAIqM2p4mtbmwnc0GISd/zKyNtcNm g27HP83wCEYxI5M1EGWIyEqBLQ12O03AnagXhZdc16O+YaX1EZaumurEd0lzXA+PmqT4nj78 NXL9uUUsWOlHmiDhdyZgCprCY7Cr1Go/y+tPXvr2lrtVfpCpCSvvOS7CHsnAep+TXeR63V1X bmRkqC/PX1FHpF3yUFz5vMWQlhWd2GuA20opRgIhBNQqmNKVS4aZ6XUBbZI5lqQnzRJBomVu ggxb1bvn3KWBE8d+TzzWkUbVnjcmMdvcI3LpDbrOS1nqrE1WdlLzGjsk+KqWemyKhEOzePCn CGlrOgvFMYIDGDCCAxQCAQEwgYYwdzELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNp Z24gbnYtc2ExIDAeBgNVBAsTF1BlcnNvbmFsU2lnbiBDbGFzcyAyIENBMSswKQYDVQQDEyJH bG9iYWxTaWduIFBlcnNvbmFsU2lnbiBDbGFzcyAyIENBAgsBAAAAAAD7Y4z+LDAJBgUrDgMC GgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNDEy MTAxOTE0MzJaMCMGCSqGSIb3DQEJBDEWBBTjXD9ngyhhleFdwk7y+mQxe04bNzBSBgkqhkiG 9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH BgUrDgMCBzANBggqhkiG9w0DAgIBKDCBlwYJKwYBBAGCNxAEMYGJMIGGMHcxCzAJBgNVBAYT AkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24g Q2xhc3MgMiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBD QQILAQAAAAAA+2OM/iwwgZkGCyqGSIb3DQEJEAILMYGJoIGGMHcxCzAJBgNVBAYTAkJFMRkw FwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSAwHgYDVQQLExdQZXJzb25hbFNpZ24gQ2xhc3Mg MiBDQTErMCkGA1UEAxMiR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gQ2xhc3MgMiBDQQILAQAA AAAA+2OM/iwwDQYJKoZIhvcNAQEBBQAEgYC5JnEyQPxbBXoQ8J0CHkBIlnGVz6inr8j3D9Vg 8RANjfVp4vLAdHYV9WZeESl/qD3dlHgyklddYSeicz0e2gU9RiWPwCXpCTc/pzpExOybbTQx 2nZs74pNUBwCuaB9G6ExiC6m0dGGLg7ebArvvgl9dSRNblasLJ/l9YKdP7X7PgAAAAAAAA== --------------ms010501050507010103050204-- From eutcvnnthlnl@yahoo.com Fri Dec 10 16:36:20 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29095; Fri, 10 Dec 2004 16:36:20 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CcsYH-0000td-Sv; Fri, 10 Dec 2004 16:43:51 -0500 Received: from pool-151-200-50-77.res.east.verizon.net ([151.200.50.77]) by mx2.foretec.com with smtp (Exim 4.24) id 1CcsQp-0006Lp-MW; Fri, 10 Dec 2004 16:36:08 -0500 Received: from grist [204.80.21.232] (helo=cankerworm.thoroughgoing.dearriba.com) by smtp2.cistron.nl with esmtp (expurgate 3.35 #1 (loggerhead)) id 923LFL-0014PT-81 Message-ID: <70117973144732.R37496@likewise.noc.freshwater.gr> Sender: freeradius-devel-eutcvnnthlnl@yahoo.com X-Mailman-Version: 2.0.1 Date: Sat, 11 Dec 2004 14:30:58 +0200 From: "Patsy Tabor" To: nat@ietf.org Cc: nat-admin@ietf.org, nat-request@ietf.org, nda@ietf.org, nemo@ietf.org, nemo-admin@ietf.org, nemo-archive@ietf.org, nemo-request@ietf.org, nemo-web-archive@ietf.org Subject: You Need This Nat X-Spam-Score: 5.1 (+++++) X-Spam-Flag: YES X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Our very besstt price of medss: Pain Relief (from $99) (Viicodin, Hydrocodoone, Valliium) Men's Pillls (from $140) (Viiagra, Leviitra) Weight Losss (from $140) (Phentermiine, Xeniical) You Can't find this 0ffers available anywhere. Visit Us T0day! http://www.nosleep4me.com/2/vicodin.php?wid=200007 This is 1 -time mailing. N0-re m0val are re'qui-red oIeoRuof1k1e2DhSMSnI7GZ3fXUBSrq0sz0ZMC From nemo-bounces@ietf.org Mon Dec 13 04:21:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14241 for ; Mon, 13 Dec 2004 04:21:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdmDq-0007U1-Go; Mon, 13 Dec 2004 04:10:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CdmAD-0006lA-6a for nemo@megatron.ietf.org; Mon, 13 Dec 2004 04:06:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12306 for ; Mon, 13 Dec 2004 04:06:39 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CdmHr-0007n6-AB for nemo@ietf.org; Mon, 13 Dec 2004 04:14:43 -0500 Received: from [IPv6:2001:200:0:8410:20c:f1ff:feaa:6c9a] (unknown [IPv6:2001:200:0:8410:20c:f1ff:feaa:6c9a]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id A61374D828 for ; Mon, 13 Dec 2004 18:05:39 +0900 (JST) Message-ID: <41BD5B20.7080404@sfc.wide.ad.jp> Date: Mon, 13 Dec 2004 18:04:32 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, 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: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: 7bit Subject: [nemo] Comments on draft-kniveton-nemo-prefix-delegation-00 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hello, Thank you for this draft. I have some questions and comments about it. > 6.3 Mobile Network Prefix option After a Prefix Delegation procedure, the MR will send periodically a BU to its HA. I guess it sends each time the MNP options with the appropriate new bit set (P, I or D) ? How does the HA handle the MNP options' new bits? I mean, if the P, I or D bit does not fit with what the HA expects, what should happen? > 6.4 Mobile Network Prefix Request option What is a "Private" Prefix Type? Why this type does not appear in the prefix type in the Mobile Network Prefix Confirmation option (section 6.5)? When this option is present, the R bit must be set in the BU (same for Mobile Network Prefix Confirmation option). > 7. Mobile Router Operation Some status are missing (8 to 10). Is it because the expected behaviour is unknown yet? How does MR should act when it receives an BAck with the S bit (Prefix status) set? I guess it should check each prefixes included in the BA with its prefixes, but what happens if some are missing in the BA or others are not registered on the MR? Where does MR saves the corID? and the others new bits (if needed to be saved)? It is written that "the Mobile Router will add either a MNP Option, or a MNPReq Option, or both". I guess that the MR can send a BU with a MNPReq Option (and without MNP option) if the MR first want to ask for a prefix, am I right? If yes I think there is some conflict with draft-ietf-nemo-basic-support-03, section 5.3, where it is said: "The Mobile Router does not include prefix information in the Binding Update in the implicit mode or when it runs a dynamic routing protocol with its Home Agent.". Then there may be some cases where you can not omit the MNP option in the BU. > 8. Home Agent Operation Is this section complete? If the HA receives a BU with S bit set, I guess it includes as many MNPC options in the BAck as there are prefixes for the MR that sent the BU? About step 4, shall the HA include the MNPC options in same order as MNPR options? I think this is easier from an implementation point of view, and this may avoid some interoperability issues. Regards, -- Romain KUNTZ kuntz@sfc.wide.ad.jp From nemo-bounces@ietf.org Tue Dec 21 15:51:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19273 for ; Tue, 21 Dec 2004 15:51:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CgqpA-0006eO-IO; Tue, 21 Dec 2004 15:41:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cgqnf-00064L-PX for nemo@megatron.ietf.org; Tue, 21 Dec 2004 15:40:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17532 for ; Tue, 21 Dec 2004 15:40:05 -0500 (EST) Received: from node-402449f2.sfo.onnet.us.uu.net ([64.36.73.242] helo=deimos.multihop.net) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cgqx8-0006uQ-LH for nemo@ietf.org; Tue, 21 Dec 2004 15:49:55 -0500 Received: from localhost (unknown [127.0.0.1]) by deimos.multihop.net (Postfix) with ESMTP id 369CE61D7; Tue, 21 Dec 2004 12:38:29 -0800 (PST) Received: from deimos.multihop.net ([127.0.0.1]) by localhost (deimos.multihop.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17716-04; Tue, 21 Dec 2004 12:38:28 -0800 (PST) Received: by deimos.multihop.net (Postfix, from userid 1013) id D92A361CB; Tue, 21 Dec 2004 12:38:28 -0800 (PST) Received: from [192.103.16.145] (unknown [192.103.16.145]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by deimos.multihop.net (Postfix) with ESMTP id 9F91A60FA; Tue, 21 Dec 2004 12:38:21 -0800 (PST) In-Reply-To: <41BD5B20.7080404@sfc.wide.ad.jp> References: <41BD5B20.7080404@sfc.wide.ad.jp> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <715DC686-5390-11D9-ACFF-000A95DA08F2@kniveton.com> Content-Transfer-Encoding: 7bit From: "T.J.Kniveton" Subject: Re: [nemo] Comments on draft-kniveton-nemo-prefix-delegation-00 Date: Tue, 21 Dec 2004 12:39:42 -0800 To: Romain KUNTZ X-Mailer: Apple Mail (2.619) X-Virus-Scanned: by amavisd-new at deimos.multihop.net X-Spam-Score: 0.0 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Content-Transfer-Encoding: 7bit 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Thanks for your comments Romain. On Dec 13, 2004, at 1:04 AM, Romain KUNTZ wrote: > Hello, > > Thank you for this draft. I have some questions and comments about it. > > > 6.3 Mobile Network Prefix option > > After a Prefix Delegation procedure, the MR will send periodically a > BU to its HA. I guess it sends each time the MNP options with the > appropriate new bit set (P, I or D) ? > How does the HA handle the MNP options' new bits? I mean, if the P, I > or D bit does not fit with what the HA expects, what should happen? Well, the MR will not use an I flag in a BU.. that would kind of kill the whole point of implicit prefixes. The P flag doesn't have much bearing, so it wouldn't cause much of a problem if the HA got something it didn't expect. The D flag is really used to communicate info from the HA to the MR, so again it doesn't really matter if the HA gets something it doesn't expect - it just means the MR has a bug. > > > 6.4 Mobile Network Prefix Request option > > What is a "Private" Prefix Type? > Why this type does not appear in the prefix type in the Mobile Network > Prefix Confirmation option (section 6.5)? You're right - that was removed, but it should be there. > > When this option is present, the R bit must be set in the BU (same for > Mobile Network Prefix Confirmation option). > > > 7. Mobile Router Operation > > Some status are missing (8 to 10). Is it because the expected > behaviour is unknown yet? It might have been an oversight -- but it is also somewhat implementation/deployment dependent what to do when a requested feature is unsupported. > > How does MR should act when it receives an BAck with the S bit (Prefix > status) set? I guess it should check each prefixes included in the BA > with its prefixes, but what happens if some are missing in the BA or > others are not registered on the MR? Well, it could register those prefixes, depending on what type of prefixes they are and whether they had been attempted registered before. Do you think we should include complete information on how to deal with all possible error conditions? We could do it but it would make a BIG document. > > Where does MR saves the corID? and the others new bits (if needed to > be saved)? Implementation detail. Probably in dynamic RAM, or possibly in non-volatile RAM for more robustness. > > It is written that "the Mobile Router will add either a MNP Option, or > a MNPReq Option, or both". I guess that the MR can send a BU with a > MNPReq Option (and without MNP option) if the MR first want to ask for > a prefix, am I right? If yes I think there is some Yes, that's right. > conflict with draft-ietf-nemo-basic-support-03, section 5.3, where it > is said: > "The Mobile Router does not include prefix information in the Binding > Update in the implicit mode or when it runs a dynamic routing protocol > with its Home Agent.". Then there may be some cases where you can not > omit the MNP option in the BU. Well, if implicit mode is being used and the MR believes a prefix is already registered, it just sends a BU. If the MR doesn't believe a prefix is registered, it uses an MNReq to get one. If it doesn't know, it can send a BU with the S bit set, to get the status. > > > 8. Home Agent Operation > > Is this section complete? > > If the HA receives a BU with S bit set, I guess it includes as many > MNPC options in the BAck as there are prefixes for the MR that sent > the BU? That's correct. You're right, it should be listed in the HA operation. This still leaves an open question -- what if the HA sees prefixes assigned to the MR, but they are not currently in use. I.e. the MR has 3 prefixes, but only 1 was included in explicit mode with the BU. But the BU had the S bit set. > > About step 4, shall the HA include the MNPC options in same order as > MNPR options? I think this is easier from an implementation point of > view, and this may avoid some interoperability issues. I think that requiring this would go against precedent. But you're right, it would be easier from an interoperability point of view. Thanks for your detailed reading. TJ > > > Regards, > > -- > Romain KUNTZ > kuntz@sfc.wide.ad.jp > > From nemo-bounces@ietf.org Fri Dec 24 05:15:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02287 for ; Fri, 24 Dec 2004 05:15:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChmLR-0007RS-HM; Fri, 24 Dec 2004 05:06:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ChmBA-0006Jd-0M for nemo@megatron.ietf.org; Fri, 24 Dec 2004 04:56:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01191 for ; Fri, 24 Dec 2004 04:56:09 -0500 (EST) Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1ChmLC-0006vj-P1 for nemo@ietf.org; Fri, 24 Dec 2004 05:06:36 -0500 Received: from ams-core-1.cisco.com (144.254.224.150) by ams-iport-1.cisco.com with ESMTP; 24 Dec 2004 11:06:26 +0100 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from xbh-ams-331.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 iBO9tMfs008644; Fri, 24 Dec 2004 10:55:32 +0100 (MET) Received: from xmb-ams-337.cisco.com ([144.254.231.82]) by xbh-ams-331.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 24 Dec 2004 10:55:30 +0100 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: FW: [nemo]Re: Comments ondraft-clausen-nemo-ro-problem-statement-00.txt Date: Fri, 24 Dec 2004 10:55:21 +0100 Message-ID: <7892795E1A87F04CADFCCF41FADD00FC6448DB@xmb-ams-337.emea.cisco.com> Thread-Topic: [nemo]Re: Comments ondraft-clausen-nemo-ro-problem-statement-00.txt Thread-Index: AcTS+WVAttGnc85pSYW9XRKufrcp/wWpKQLA From: "Pascal Thubert \(pthubert\)" To: "Ryuji Wakikawa" , , X-OriginalArrivalTime: 24 Dec 2004 09:55:30.0446 (UTC) FILETIME=[B3D5E2E0:01C4E99E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Ryuji and Philippe: This is the mast mail on NEMO about creating a MANEMO list. Quite a few = people including the authors of the ref draft told me they were = interested in the discussion.=20 Ryuji, can you please create the list on your server? That would be very = nice. May I suggest that you copy MANET to try to attract people in the = list? Thanks a lot :) Pascal -----Original Message----- From: Carlos Jes=FAs Bernardos Cano [mailto:cjbc@it.uc3m.es]=20 Sent: Thursday, November 25, 2004 3:16 PM To: Pascal Thubert (pthubert) Cc: Ryuji Wakikawa; nemo@ietf.org; Greg.Daley@eng.monash.edu.au Subject: RE: [nemo]Re: Comments = ondraft-clausen-nemo-ro-problem-statement-00.txt Hi Pascal, and all > Agreed. I would be interested to follow up this discussion with = parties > interested in the specific problem of MANET applicability for the = nested > wireless routers sharing an internet connection. Obviously, nested = NEMO > is a foremost use case, but the question also applies to other domains > such as meshed networking.=20 >=20 > I believe we should set up a separate list for this discussion, and = see > if people from various horizons (MANET, NEMO, Mesh) are interested in > moving forward. What do you think? I support your idea. In fact, I'm very interested on those topics. Kind Regards, Carlos J. >=20 > Pascal --=20 Carlos Jes=FAs Bernardos Cano - http://www.netcoms.net GPG FP: 58C3 4227 AF8D 01D4 5A09 A617 E6F2 B23E DAD6 AA40 From nemo-bounces@ietf.org Tue Dec 28 06:44:35 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17951 for ; Tue, 28 Dec 2004 06:44:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjFkV-0001gF-Hs; Tue, 28 Dec 2004 06:42:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CjFdm-0000M8-It for nemo@megatron.ietf.org; Tue, 28 Dec 2004 06:35:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17278 for ; Tue, 28 Dec 2004 06:35:47 -0500 (EST) Received: from mail.sfc.wide.ad.jp ([203.178.142.146]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CjFof-0007WM-VJ for nemo@ietf.org; Tue, 28 Dec 2004 06:47:07 -0500 Received: from [IPv6:2001:200:0:8410:20c:f1ff:feaa:6c9a] (unknown [IPv6:2001:200:0:8410:20c:f1ff:feaa:6c9a]) by mail.sfc.wide.ad.jp (Postfix) with ESMTP id 626594D852; Tue, 28 Dec 2004 20:35:06 +0900 (JST) Message-ID: <41D14497.6010906@sfc.wide.ad.jp> Date: Tue, 28 Dec 2004 20:33:43 +0900 From: Romain KUNTZ Organization: Keio University User-Agent: Mozilla Thunderbird 0.9 (X11/20041124) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "T.J.Kniveton" , nemo@ietf.org Subject: Re: [nemo] Comments on draft-kniveton-nemo-prefix-delegation-00 References: <41BD5B20.7080404@sfc.wide.ad.jp> <715DC686-5390-11D9-ACFF-000A95DA08F2@kniveton.com> In-Reply-To: <715DC686-5390-11D9-ACFF-000A95DA08F2@kniveton.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit 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: , Sender: nemo-bounces@ietf.org Errors-To: nemo-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi TJ, Thanks for your answer. Few comments inline... T.J.Kniveton wrote: >> How does MR should act when it receives an BAck with the S bit (Prefix >> status) set? I guess it should check each prefixes included in the BA >> with its prefixes, but what happens if some are missing in the BA or >> others are not registered on the MR? > > > Well, it could register those prefixes, depending on what type of > prefixes they are and whether they had been attempted registered before. > Do you think we should include complete information on how to deal with > all possible error conditions? We could do it but it would make a BIG > document. As long as it would not create some possible interoperability problems between different implementations of the draft, I think it's ok. >> Where does MR saves the corID? and the others new bits (if needed to >> be saved)? > > > Implementation detail. Probably in dynamic RAM, or possibly in > non-volatile RAM for more robustness. Actually, what I meant is if it could be interesting to extend the binding cache/binding update list to store these datas. But as you said, it is implementation detail and does not need to be described in the draft. Regards, -- Romain KUNTZ kuntz@sfc.wide.ad.jp