From autoconf-bounces@ietf.org Mon Jul 02 07:28:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5K4Z-0006Y8-RJ; Mon, 02 Jul 2007 07:28:03 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I5K4Y-0006Y1-De for autoconf-confirm+ok@megatron.ietf.org; Mon, 02 Jul 2007 07:28:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5K4Y-0006Xt-45 for autoconf@ietf.org; Mon, 02 Jul 2007 07:28:02 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I5K4U-0006x4-KA for autoconf@ietf.org; Mon, 02 Jul 2007 07:28:02 -0400 Received: from smtpb.greenlnk.net (smtpb.greenlnk.net [10.15.160.219]) by smtp2.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l62BRueJ007972 for ; Mon, 2 Jul 2007 12:27:57 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpb.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l62BRuI0006234 for ; Mon, 2 Jul 2007 12:27:56 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 02 Jul 2007 12:27:56 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Jul 2007 12:27:56 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Jul 2007 12:27:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: manetarch-03 Thread-Index: Ace8nAkmgNW3DWP8T3CjC18NyMqcvw== From: "Dearlove, Christopher \(UK\)" To: X-OriginalArrivalTime: 02 Jul 2007 11:27:56.0306 (UTC) FILETIME=[0976F720:01C7BC9C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 Cc: Thomas Clausen Subject: [Autoconf] manetarch-03 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Some comments on manetarch-03. I'm not reporting typographic errors (if the authors want those I'll send them - at the moment they are ink on paper). - I think it's worth a comment somewhere that MANETs are about dynamic networks but, the M in MANET notwithstanding, dynamic is not the same as mobile. Plenty of ad hoc networks are dynamic, even if their nodes don't actually move. Examples of reasons why include radio propagation issues (including other things than the nodes being mobile - e.g. introducing obstacles or more subtle effects), node behaviour changes (e.g. changing transmit power) and node loss (battery exhaustion, other effects). The reason I think this matters is because otherwise people can say "I don't need a MANET, my network isn't mobile". - Section 2, "to list a few". Why not list all? (by which I mean at least one source of each, not of course all possible sources of each). Does any terminology come from RFC 2501? - I'm not convinced that using "node" to include MANET protocol unaware hosts isn't sufficiently different from usual MANET usage so as not to be confusing - not here, but it used without explanation elsewhere. RFC 2501 for example considers a node to be combined router+hosts, not each of these to be separate nodes. (I would tend to think of a node as the entity that is internally wired, externally wireless. But that's not a definition.) - It's been said before, but this usage of reflexive is not in accordance with standard mathematical terminology. See for example http://mathworld.wolfram.com/Reflexive.html The characteristic considered here is symmetry, see for example http://mathworld.wolfram.com/SymmetricRelation.html Note that what you are really saying by "asymmetric reachability" is that (assuming a node can reach itself, i.e. it is reflexive in the proper sense) that reachability is not an equivalence relation. Also see the next point. - Also on what's called asymmetric reachability, this is said to be a property of a link. But transitivity is not about a link, it's about more than one link (two that exist and one that may not). I'd have said it's about interfaces, what you are saying is that reachability is not an equivalence relation on interfaces (but - with the definition that a node can reach itself - it is on an Ethernet, for example). Note that I'm not necessarily suggesting introducing the equivalence relation (though it works for me) I'm just suggesting reflexive -> symmetric and that this is about interfaces, not links. (Non- equivalent reachability is probably technically a better term.) - The definition of Neighbour looks like a definition of a symmetric neighbour ("exchange" is two way). Later, under FBI, the undefined term symmetric neighbour is used. (It might be worth looking at NHDP also.) - The Broadcast Interface definition doesn't appear to me to be quite right if a node has multiple MANET interfaces, but I may be wrong. - Site. Is a site a set of links, or a set of nodes? - Flooding uses "devices". What's a device? - MANET Neighbours/MANET N-Neighbourhood. Should the former also be neighbourhood? Has reachable been defined? Which direction(s)? - Penultimate paragraph in 2.2. Is "will" be right about merger. That suggests it always happens, but it might not - especially with a reactive protocol. (Partitioning yes, can't stop that happening.) - Section 5.2 - should IPv6 LL addresses get a reference? Actually there's a wider issue - which IP features should be referenced to RFC this and that, and which are so well known they are just referred to? (Personally I often need the reference to things that are obvious to the wider IETF community.) - Are we admitting that we are using link local IPv6 addresses beyond the mandate in RFC 4291, which says "Routers must not forward any packets with Link-Local source or destination addresses to other links.". If a MANET interface address is a link local address, it is going beyond that link, isn't it? (I have no alternative - other than undeprecating site local addresses, and I've no intention of suggesting that.) - Section 5.3 vaguely refers to MANET protocols, without references, and also discusses WGs which will have been closed (we ought to hope) within the lifespan of this document once it's an RFC. Is this good style? (This also in Section 6.) - Unreliability may also be important here. If you had all interfaces able to hear all others, but packets were lost 50% of the time, then you still would have problems treating it as an Ethernet wouldn't you? Of course you can put in acknowledgements to make it reliable, probably. - I didn't understand the point being made in the second half of the last paragraph of 8.2. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Jul 05 00:53:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6JL0-0005e1-2A; Thu, 05 Jul 2007 00:53:06 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I6JKy-0005du-3R for autoconf-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 00:53:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6JKx-0005dm-Of for autoconf@ietf.org; Thu, 05 Jul 2007 00:53:03 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6JKs-0001Or-VB for autoconf@ietf.org; Thu, 05 Jul 2007 00:53:03 -0400 Received: from epmmp2 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JKO00896W8798@mailout1.samsung.com> for autoconf@ietf.org; Thu, 05 Jul 2007 13:52:55 +0900 (KST) Received: from Shubhranshu ([107.108.4.124]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0JKO004JGW869N@mmp2.samsung.com> for autoconf@ietf.org; Thu, 05 Jul 2007 13:52:56 +0900 (KST) Date: Thu, 05 Jul 2007 10:29:42 +0530 From: Shubhranshu To: autoconf@ietf.org Message-id: <02c101c7bec1$4d822990$7c046c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Mailer: Microsoft Outlook Express 6.00.2900.3028 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: manemo@mobileip.jp Subject: [Autoconf] IETF-69 Autoconf WG meeting agenda X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1457952453==" Errors-To: autoconf-bounces@ietf.org This is a multi-part message in MIME format. --===============1457952453== Content-type: multipart/alternative; boundary="Boundary_(ID_GeaSbGxot2aHpOvdwuXJ1w)" This is a multi-part message in MIME format. --Boundary_(ID_GeaSbGxot2aHpOvdwuXJ1w) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Hi All, If you have any agenda item(s) for the upcoming Autoconf WG meeting then please send them to the chairs or to the list. We've two Autoconf WG sessions scheduled for the IETF-69, https://datatracker.ietf.org/meeting/69/agenda.html : AUTOCONF Session 1 (2 hours) Monday, Afternoon Session I 1300-1500 Room Name: Salon 2 AUTOCONF Session 2 (2 hours) Thursday, Afternoon Session I 1300-1500 Room Name: Salon 2 Monday session has been scheduled for discussions related to MANEMO. Autoconf WG specific discussions would be held during the Thursday session. Here are some MANEMO related links: http://www1.ietf.org/mail-archive/web/int-area/current/msg00817.html http://www.arkko.com/ietf/ietf-69/manemo.txt I'll upload the agenda once it is ready, hopefully by 11th of July. - Shubhranshu --Boundary_(ID_GeaSbGxot2aHpOvdwuXJ1w) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Hi All,
 
If you have any agenda item(s) for the upcoming Autoconf WG meeting
then please send them to the chairs or to the list.
 
We've two Autoconf WG sessions scheduled for the IETF-69,
 
AUTOCONF Session 1 (2 hours)
Monday, Afternoon Session I  1300-1500
Room Name: Salon 2
 
AUTOCONF Session 2 (2 hours)
Thursday, Afternoon Session I  1300-1500
Room Name: Salon 2
 
Monday session has been scheduled for discussions related to
MANEMO. Autoconf WG specific discussions would be held
during the Thursday session.
 
Here are some MANEMO related links:
 
 
I'll upload the agenda once it is ready, hopefully by 11th of July.
 
- Shubhranshu
--Boundary_(ID_GeaSbGxot2aHpOvdwuXJ1w)-- --===============1457952453== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf --===============1457952453==-- From autoconf-bounces@ietf.org Thu Jul 05 14:57:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6WWP-0006QN-Ht; Thu, 05 Jul 2007 14:57:45 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I6WWN-000696-D4 for autoconf-confirm+ok@megatron.ietf.org; Thu, 05 Jul 2007 14:57:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I6WWL-00062O-U9 for autoconf@ietf.org; Thu, 05 Jul 2007 14:57:42 -0400 Received: from smtp01.uc3m.es ([163.117.176.131] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I6WVU-0002FY-S7 for autoconf@ietf.org; Thu, 05 Jul 2007 14:57:41 -0400 Received: from localhost (enjambre.it.uc3m.es [163.117.140.72]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by smtp.uc3m.es (Postfix) with ESMTP id 15EE83CBEC; Thu, 5 Jul 2007 20:56:40 +0200 (CEST) From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: autoconf@ietf.org Organization: Universidad Carlos III de Madrid Date: Thu, 05 Jul 2007 20:56:40 +0200 Message-Id: <1183661800.8758.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: MOUSTAFA Hassnaa RD-CORE-ISS Subject: [Autoconf] draft-bernardos-manet-autoconf-survey-01 X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0189073725==" Errors-To: autoconf-bounces@ietf.org --===============0189073725== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-c9V6a0/qqCIPWVdv9KQO" --=-c9V6a0/qqCIPWVdv9KQO Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable Hi, We have updated our draft providing a survey of IP address autoconfiguration mechanisms for MANETs. It can be found at the I-D repository: http://www.ietf.org/internet-drafts/draft-bernardos-manet-autoconf-survey-0= 1.txt Abstract below: This Internet Draft aims at providing a general reference for the AUTOCONF solution space. We present most of the previously proposed IP AUTOCONF mechanisms in MANETs, classifying them according to a number of useful criteria, conforming to the AUTOCONF problem statement draft and the MANET architecture draft. Furthermore, an analysis of each proposed solution is carried out illustrating its key characteristics, advantages and correspondence to the classification criteria. Comments would be appreciated. Kind Regards, Mar=EDa, Hassnaa and Carlos --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: D29B 0A6A 639A A561 93CA 4D55 35DC BA4D D170 4F67 --=-c9V6a0/qqCIPWVdv9KQO Content-Type: application/pgp-signature; name=signature.asc Content-Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGjT7oNdy6TdFwT2cRAuYnAJwOzppDDTuSyw+wyT6yfBiCrVBp/gCeMS07 Bb8V2oGJOah/GRRgLHMY/U8= =u8SW -----END PGP SIGNATURE----- --=-c9V6a0/qqCIPWVdv9KQO-- --===============0189073725== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf --===============0189073725==-- From autoconf-bounces@ietf.org Mon Jul 09 13:15:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7wpq-0007ZA-2z; Mon, 09 Jul 2007 13:15:42 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I7wpl-0007TT-NI for autoconf-confirm+ok@megatron.ietf.org; Mon, 09 Jul 2007 13:15:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I7wpk-0007S6-Jo; Mon, 09 Jul 2007 13:15:36 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I7wpk-00051B-By; Mon, 09 Jul 2007 13:15:36 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 17F0B175C7; Mon, 9 Jul 2007 17:15:06 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I7wpF-00047h-7w; Mon, 09 Jul 2007 13:15:05 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 09 Jul 2007 13:15:05 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: autoconf@ietf.org Subject: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-04.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Ad-Hoc Network Autoconfiguration Working Group of the IETF. Title : Mobile Ad hoc Network Architecture Author(s) : I. Chakeres, et al. Filename : draft-ietf-autoconf-manetarch-04.txt Pages : 21 Date : 2007-7-9 This document discusses Mobile Ad hoc NETworks (MANETs). It introduces basic MANET terms, characteristics, and challenges. This document also defines several MANET entities and architectural concepts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-autoconf-manetarch-04.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-autoconf-manetarch-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-autoconf-manetarch-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2007-7-9123456.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-autoconf-manetarch-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-autoconf-manetarch-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-7-9123456.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf --NextPart-- From autoconf-bounces@ietf.org Wed Jul 11 10:56:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dcZ-0002mF-Ah; Wed, 11 Jul 2007 10:56:51 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I8dcX-0002mA-Rj for autoconf-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 10:56:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8dcW-0002ly-Vm for autoconf@ietf.org; Wed, 11 Jul 2007 10:56:48 -0400 Received: from smtp.bae.co.uk ([20.133.0.11] helo=smtp1.bae.co.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8dcS-0002NE-Ix for autoconf@ietf.org; Wed, 11 Jul 2007 10:56:48 -0400 Received: from smtpc.greenlnk.net (smtpc.greenlnk.net [10.15.160.220]) by smtp1.bae.co.uk (Switch-3.1.10/Switch-3.1.10) with ESMTP id l6BEuhIV005491 for ; Wed, 11 Jul 2007 15:56:43 +0100 (BST) Received: from glkas0002.GREENLNK.NET (glkas0002.greenlnk.net [10.15.184.52]) by smtpc.greenlnk.net (Switch-3.1.9/Switch-3.1.9) with ESMTP id l6BEuhJI004187 for ; Wed, 11 Jul 2007 15:56:43 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Wed, 11 Jul 2007 15:56:42 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 15:56:42 +0100 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: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-04.txt Date: Wed, 11 Jul 2007 15:56:42 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-04.txt Thread-Index: AcfCTNYUfKiLMd38Qi2Pt/vtWb1YDgBfV9ow References: From: "Dearlove, Christopher \(UK\)" To: X-OriginalArrivalTime: 11 Jul 2007 14:56:42.0464 (UTC) FILETIME=[B15ABE00:01C7C3CB] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Thomas Clausen X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org I see that my comments on reflexive and transitive have turned into: > Note: the definitions of non-reflexive and non-transitive > above differ from mathematical terminology. I strongly disagree with this treatment. Actually transitive isn't non-standard, but the inclusion of transitivity makes this not a property of a link, but of a network. Reflexive is wrong, and you don't fix a problem by adding a note that this is wrong, you change it. I think these changes should be made (especially the first two) - That this is not just a property of a link. - Changing reflexive to the proper term, symmetric (which is a reason for the next point, to avoid overloading the term symmetric). - Asymmetric reachability to something else (what you are really saying is that it's not an equivalence relation, but that may be more detail than is needed). I haven't checked how my other comments have been handled. ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jul 11 13:36:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8g6z-0007F8-GA; Wed, 11 Jul 2007 13:36:25 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I8g6y-0007F3-W6 for autoconf-confirm+ok@megatron.ietf.org; Wed, 11 Jul 2007 13:36:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8g6y-0007Ev-Id for autoconf@ietf.org; Wed, 11 Jul 2007 13:36:24 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I8g6r-0000Df-7i for autoconf@ietf.org; Wed, 11 Jul 2007 13:36:24 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6BHZgUD009577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Jul 2007 10:35:43 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6BHZgN4022586; Wed, 11 Jul 2007 10:35:42 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6BHZTqs022039; Wed, 11 Jul 2007 10:35:39 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jul 2007 10:35:39 -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 Date: Wed, 11 Jul 2007 10:35:38 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8FA@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-ietf-autoconf-manetarch-04.txt Thread-Index: AcfCTNYUfKiLMd38Qi2Pt/vtWb1YDgBfV9owAAWB71A= References: From: "Templin, Fred L" To: X-OriginalArrivalTime: 11 Jul 2007 17:35:39.0265 (UTC) FILETIME=[E5BB1710:01C7C3E1] X-Spam-Score: 0.0 (/) X-Scan-Signature: 48472a944c87678fcfe8db15ffecdfff Cc: "Thomas Heide Clausen \(home\)" Subject: [Autoconf] Comments on draft-ietf-autoconf-manetarch-04.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Overall, the document is in reasonably good shape. The most substantial objection is that it consistently uses the term "interface" where the term "link" should be used instead. Also, the MANET router definition seems to assume only a singular "internal addressable host logic" whereas a node may embody an arbitrarily-complex internal network of virtual hosts (e.g., a network of virutal machines running inside a linux box). The following are specific comments and change suggestions for the -04 draft: Fred fred.l.templin@boeing.com=20 1) (comment) Section 2.1, the definition for the term "Link" is acceptable, but would be better served by adopting the full text of the definitions for "link" found in RFCs 2460/2461/3753. 2) (semi-editorial) Section 2.1, the definition for the term "Asymmetric Reachability" - rename as "Asymmetric Reachability Link". 3) (comment) Section 2.1, the definition for the term "interface" is correct as-written, but compare against the way the term is being (mis)used elsewhere throughout the document (see below). 4) (substantial) Section 2.1, remove the definitions for {Broadcast, Full-Broadcast, Semi-Broadcast} Interface. These are describing properties of *links*; not *interfaces*. And, since "Asymmetric Reachability Link" is already defined and covers the same definition space that these are intending to cover, their presence is redundant. (If there is a desire to retain the phrase: "semi-broadcast", this can be added as a new sentence under the "Asymmetric Reachability Link" defininition, i.e., "semi-broadcast" is one property of such links.) 5) (comment) Section 2.2, 'draft-templin-autoconf-dhcp-08.txt' defines several terms that also appear here (e.g., MANET, MANET Router, MANET interface, etc.) and should be consulted for consistency with this document (see below).=20 6) (substantial) Section 2.2, the definition for the term "MANET Router" and accompanying figure seem to assume a singular "internal addressable host logic" whereas a MANET router may contain an arbitrarily-complex internal network of virtual links connecting internal hosts. Also, the term "classical IP interface" is not defined and is insufficient to cover the types of interfaces a MANET router may have - namely, MANET interfaces, ingress interfaces, and egress interfaces (where ingress/egress are the same as defined in RFC3753). See the definition and figure for "MANET Router" in draft-templin-autoconf-dhcp-08.txt. 7) (substantial) Section 2.2, add a definition for "MANET interface" as follows: "MANET Interface a MANET Router's attachment to an asymmetric reachability link. A MANET interface is a "lateral" interface, i.e., it is inherently neither an ingress nor egress interface although it can sometimes exhibit characteristics of both." 8) (editorial) Section 2.2, s/may partitioned/may be partitioned/ 9) (editorial) Section 2.2, s/MANETs' BR/MANET's BRs/ 10) (semi-substantial) Section 3, second paragraph, second sentence, change: "single SBI" to: "single MANET interface". 11) (semi-editorial) Section 3, second paragraph, next-to-last sentence, change: "R1 on its interface" to: "R1 on its MANET interface". 12) (semi-substantial) Section 3, second paragraph, last sentence, remove the leading phrase: "This example also illustrates how SBIs differ from FBIs:". 13) (semi-substantial) Section 3, Figure 2, change: "SBI" to: "MANET Interface". 14) (semi-editorial) Section 3, paragraph immediately following Figure 2, change: "nodes' asymmetric reachability" to: "asymmetric reachability links". 15) (semi-substantial) Section 3, same paragraph as 14), change: "dynamic wireless interface" to: "dynamic wireless link". 16) (semi-substantial) Section 3, next to last paragraph, change: "node and interface" to: "node and link". 17) (semi-substantial) Section 3, last paragraph, change: "heterogeneous interfaces" to: "heterogeneous links". 18) (semi-substantial) Section 4.1, change: "interface" to: "link" in 4 places. 19) (editorial) Section 4.1, third paragraph, s/exacerbates/exacerbate/ 20) (editorial) Section 4.2, s/MANETs/MANET/ 21) (substantial) Section 4.2.1, change title to: "Asymmetric Reachability Links". 22) (semi-substantial) Section 4.2.1, first paragraph, change: "a wireless SBI with asymmetric reachability" to: "an asymmetric reachability link". 23) (semi-substantial) Section 4.2.1, Figure 3, change: "Single SBI" to: "Single MANET Interface" and change figure caption to: "Asymetric Reachability Link and Neighboring Routers". 24) (semi-substantial) Section 4.2.1, paragraph after Figure 3, change: "wireless interface" to "MANET interface". 25) (semi-substantial) Section 4.2.2, first paragraph, change: "interface characteristics" to: "link charachteristics". 26) (substantial) Section 5.1, second sentence, change to: "The attached nodes may be "external" (i.e., attached to the router via interfaces to external networks) or "internal" (i.e., attached to the router via internal virtual interfaces)." (Note that the trailing phrase beginning: "- however the important" should be removed since it is redundant with the following sentence.) =20 27) (substantial) Section 5.1, Figure 5, same comment as for 6) above; a MNR need not have only a singular IAH. See also Figure 1 in draft-templin-autoconf-dhcp-08.txt. 28) (substantial) Section 5.1, paragraph following figure 5, change: "interfaces towards classic IP link(s)" to: "ingress interfaces". Reason being is that delegated prefixes can only be assigned to "downstream" (aka ingress) interfaces; they cannot be assigned to "upstream" (aka egress) interfaces. (They also cannot be assigned to MANET interfaces, which are neither up- nor downstream, but "lateral".) 29) (substantial) Section 5.1, paragraph beginning: "Interface(s) with asymmetric...", change first sentence to: "MANET interfaces and egress interfaces are specifically *NOT* configured with delegated prefixes." 30) (substantial) Section 5.1, paragraph immediately before Figure 6, this paragraph needs to be rewritten in light of the earlier change suggestions. No specific change suggestions at this time. 31) (substantial) Section 5.1, Figure 6, same comment as for 6) and 27) above. 32) (semi-substantial) Section 5.2, first paragraph, first sentence, strike the phrase "semi-broadcast interfaces". 33) (comment) Section 5.2, this paragraph may benefit from adopting the definition for "MANET Local Address (MLA)" found in draft-templin-autoconf-dhcp-08.txt as well as descriptive text in that document that speaks to MLAs. 34) (substantial) Section 6, this entire section seems to say that there is IP-layer (L3) MANET routing and L2 MANET routing (aka bridging) and nothing else in-between. I am aware of use-cases in which MANET routing is applied as neither a pure IP-layer mechanism nor a pure L2 mechanism but rather "something in-between" that could be considered as a grey-area in-between routing and briding. Suggest this entire section be re-written using the term "IP Layer" instead of L3 and "Sub-IP Layer" instead of L2. Also, drop the (wrong) assumption that: "If it isn't IP Layer, then it must be bridging". 35) (semi-substantial) Section 8, change: "inexpensive wireless interfaces" to: "inexpensive wireless link types". 36) (semi-editorial) Section 8.3, under the list of example deployments, add: "aircraft networks, ship-to-ship networks, and many others". (end of comments) _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Jul 12 05:14:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ukq-0000hW-H8; Thu, 12 Jul 2007 05:14:32 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I8uko-0000hE-Tu for autoconf-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 05:14:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I8ukn-0000h5-PA for autoconf@ietf.org; Thu, 12 Jul 2007 05:14:29 -0400 Received: from server9.hosting2go.nl ([83.137.192.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I8ukj-0004AD-0l for autoconf@ietf.org; Thu, 12 Jul 2007 05:14:29 -0400 Received: (qmail 19167 invoked from network); 12 Jul 2007 11:14:23 +0200 Received: from unknown (HELO Teco) (217.169.232.206) by server9.hosting2go.nl with SMTP; 12 Jul 2007 11:14:22 +0200 From: "Teco_Boot" To: "'Templin, Fred L'" , Subject: RE: [Autoconf] Comments on draft-ietf-autoconf-manetarch-04.txt Date: Thu, 12 Jul 2007 11:14:44 +0200 Message-ID: <001f01c7c465$2981c560$fe00800a@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8FA@XCH-NW-7V2.nw.nos.boeing.com> Thread-Index: AcfCTNYUfKiLMd38Qi2Pt/vtWb1YDgBfV9owAAWB71AAHQLLsA== X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: "'Thomas Heide Clausen \(home\)'" X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Comments inline. Teco. > 7) (substantial) Section 2.2, add a definition for "MANET interface" > as follows: > > "MANET Interface > a MANET Router's attachment to an asymmetric reachability > link. A MANET interface is a "lateral" interface, i.e., it > is inherently neither an ingress nor egress interface although > it can sometimes exhibit characteristics of both." [Teco] Please avoid terms ingress and egress interface here. In NEMO context, it is extremely confusing. And Autoconf and NEMO are related. RFC3753 definitions: Ingress interface The interface of a MR attached to a link inside the mobile network. Egress interface The interface of a MR attached to the home link if the MR is at home, or attached to a foreign link if the MR is in a foreign network. > 28) (substantial) Section 5.1, paragraph following figure 5, > change: "interfaces towards classic IP link(s)" to: "ingress > interfaces". Reason being is that delegated prefixes can > only be assigned to "downstream" (aka ingress) interfaces; > they cannot be assigned to "upstream" (aka egress) interfaces. > (They also cannot be assigned to MANET interfaces, which are > neither up- nor downstream, but "lateral".) [Teco] Same story > 29) (substantial) Section 5.1, paragraph beginning: > "Interface(s) with asymmetric...", change first sentence > to: "MANET interfaces and egress interfaces are specifically > *NOT* configured with delegated prefixes." [Teco] Same story _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Jul 12 11:39:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90l4-00086d-Ba; Thu, 12 Jul 2007 11:39:10 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I90l2-00084X-QE for autoconf-confirm+ok@megatron.ietf.org; Thu, 12 Jul 2007 11:39:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I90l2-00084P-GN for autoconf@ietf.org; Thu, 12 Jul 2007 11:39:08 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I90ky-0006Hz-4S for autoconf@ietf.org; Thu, 12 Jul 2007 11:39:08 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6CFclSj014175 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Jul 2007 08:39:02 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6CFcl6b013788; Thu, 12 Jul 2007 08:38:47 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6CFcjNH013683; Thu, 12 Jul 2007 08:38:47 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Jul 2007 08:38: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: [Autoconf] Comments on draft-ietf-autoconf-manetarch-04.txt Date: Thu, 12 Jul 2007 08:38:40 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED903@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <001f01c7c465$2981c560$fe00800a@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Comments on draft-ietf-autoconf-manetarch-04.txt Thread-Index: AcfCTNYUfKiLMd38Qi2Pt/vtWb1YDgBfV9owAAWB71AAHQLLsAARYY7Q References: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8FA@XCH-NW-7V2.nw.nos.boeing.com> <001f01c7c465$2981c560$fe00800a@Teco> From: "Templin, Fred L" To: "Teco_Boot" , X-OriginalArrivalTime: 12 Jul 2007 15:38:46.0454 (UTC) FILETIME=[BC2ECD60:01C7C49A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: "Thomas Heide Clausen \(home\)" X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Teco - see below: > -----Original Message----- > From: Teco_Boot [mailto:teco@inf-net.nl]=20 > Sent: Thursday, July 12, 2007 2:15 AM > To: Templin, Fred L; autoconf@ietf.org > Cc: 'Thomas Heide Clausen (home)' > Subject: RE: [Autoconf] Comments on=20 > draft-ietf-autoconf-manetarch-04.txt >=20 > Comments inline. > Teco. >=20 > > 7) (substantial) Section 2.2, add a definition for "MANET interface" > > as follows: > >=20 > > "MANET Interface > > a MANET Router's attachment to an asymmetric reachability > > link. A MANET interface is a "lateral" interface, i.e., it > > is inherently neither an ingress nor egress=20 > interface although > > it can sometimes exhibit characteristics of both." > [Teco]=20 > Please avoid terms ingress and egress interface here. In NEMO=20 > context, it is > extremely confusing. And Autoconf and NEMO are related. > RFC3753 definitions: > Ingress interface > The interface of a MR attached to a link inside the mobile > network. > Egress interface > The interface of a MR attached to the home link if the MR is at > home, or attached to a foreign link if the MR is in a foreign > network. Please look at the paragraph immediately preceding those two definitions in RFC3753, where it says: "A MR acting as a gateway between an entire mobile network and the rest of the Internet has one or more egress interface(s) and one or more ingress interface(s). Packets forwarded upstream to the rest of the Internet are transmitted through one of the MR's egress interface; packets forwarded downstream to the mobile network are transmitted through one of the MR's ingress interface." By this paragraph, an egress interface is used for forwarding packets "upstream" to the rest of the Internet and an ingress interface is used for forwarding packets "downstream" to a mobile network. This is exactly the sense in which I am intending egress/ingress in my change suggestions. I could have said "upstream/downstream", but that would seem less precise? Fred fred.l.templin@boeing.com =20 > > 28) (substantial) Section 5.1, paragraph following figure 5, > > change: "interfaces towards classic IP link(s)" to: "ingress > > interfaces". Reason being is that delegated prefixes can > > only be assigned to "downstream" (aka ingress) interfaces; > > they cannot be assigned to "upstream" (aka egress) interfaces. > > (They also cannot be assigned to MANET interfaces, which are > > neither up- nor downstream, but "lateral".) > [Teco]=20 > Same story >=20 >=20 > > 29) (substantial) Section 5.1, paragraph beginning: > > "Interface(s) with asymmetric...", change first sentence > > to: "MANET interfaces and egress interfaces are specifically > > *NOT* configured with delegated prefixes." > [Teco]=20 > Same story >=20 >=20 >=20 >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jul 13 03:25:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9FXB-0007GV-7O; Fri, 13 Jul 2007 03:25:49 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I9FX9-0007GP-MI for autoconf-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 03:25:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9FX6-0007G8-9t for autoconf@ietf.org; Fri, 13 Jul 2007 03:25:44 -0400 Received: from hpsmtp-eml15.kpnxchange.com ([213.75.38.115]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9FX1-0005Cl-Kr for autoconf@ietf.org; Fri, 13 Jul 2007 03:25:44 -0400 Received: from hpsmtp-eml07.kpnxchange.com ([213.75.38.107]) by hpsmtp-eml15.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 09:25:38 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml07.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 09:25:37 +0200 From: "Teco Boot" To: "'Templin, Fred L'" Subject: RE: [Autoconf] Comments on draft-ietf-autoconf-manetarch-04.txt Date: Fri, 13 Jul 2007 09:26:31 +0200 Message-ID: <003501c7c51f$231e12e0$0202a8c0@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED903@XCH-NW-7V2.nw.nos.boeing.com> Thread-Index: AcfCTNYUfKiLMd38Qi2Pt/vtWb1YDgBfV9owAAWB71AAHQLLsAARYY7QACCPGCA= X-OriginalArrivalTime: 13 Jul 2007 07:25:37.0631 (UTC) FILETIME=[024876F0:01C7C51F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Fred, Your definition is about a MANET Router (MNR). RFC3753 is about a Mobile Router (MR). Although MR and MNR have many characteristics in common, they are different. MR, Mobile Network, Ingress Interface and Egress Interface are further described in draft-ietf-nemo-terminology-06 (in RFC queue). Combining MR and MNR is work in progress (MANEMO). Maybe we have the same opinion what to do with interface types MANET, Ingress and Egress. We will have a discussion on this in Chicago. Regards, Teco > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: donderdag 12 juli 2007 17:39 > To: Teco_Boot; autoconf@ietf.org > Cc: Thomas Heide Clausen (home) > Subject: RE: [Autoconf] Comments on draft-ietf-autoconf-manetarch-04.txt > > Teco - see below: > > > -----Original Message----- > > From: Teco_Boot [mailto:teco@inf-net.nl] > > Sent: Thursday, July 12, 2007 2:15 AM > > To: Templin, Fred L; autoconf@ietf.org > > Cc: 'Thomas Heide Clausen (home)' > > Subject: RE: [Autoconf] Comments on > > draft-ietf-autoconf-manetarch-04.txt > > > > Comments inline. > > Teco. > > > > > 7) (substantial) Section 2.2, add a definition for "MANET interface" > > > as follows: > > > > > > "MANET Interface > > > a MANET Router's attachment to an asymmetric reachability > > > link. A MANET interface is a "lateral" interface, i.e., it > > > is inherently neither an ingress nor egress > > interface although > > > it can sometimes exhibit characteristics of both." > > [Teco] > > Please avoid terms ingress and egress interface here. In NEMO > > context, it is > > extremely confusing. And Autoconf and NEMO are related. > > RFC3753 definitions: > > Ingress interface > > The interface of a MR attached to a link inside the mobile > > network. > > Egress interface > > The interface of a MR attached to the home link if the MR is at > > home, or attached to a foreign link if the MR is in a foreign > > network. > > Please look at the paragraph immediately preceding those two > definitions in RFC3753, where it says: > > "A MR acting as a gateway between an entire mobile network and the > rest of the Internet has one or more egress interface(s) and one > or more ingress interface(s). Packets forwarded upstream to the > rest of the Internet are transmitted through one of the MR's > egress interface; packets forwarded downstream to the mobile > network are transmitted through one of the MR's ingress > interface." > > By this paragraph, an egress interface is used for forwarding > packets "upstream" to the rest of the Internet and an ingress > interface is used for forwarding packets "downstream" to a > mobile network. This is exactly the sense in which I am > intending egress/ingress in my change suggestions. I could > have said "upstream/downstream", but that would seem less > precise? > > Fred > fred.l.templin@boeing.com > > > > 28) (substantial) Section 5.1, paragraph following figure 5, > > > change: "interfaces towards classic IP link(s)" to: "ingress > > > interfaces". Reason being is that delegated prefixes can > > > only be assigned to "downstream" (aka ingress) interfaces; > > > they cannot be assigned to "upstream" (aka egress) interfaces. > > > (They also cannot be assigned to MANET interfaces, which are > > > neither up- nor downstream, but "lateral".) > > [Teco] > > Same story > > > > > > > 29) (substantial) Section 5.1, paragraph beginning: > > > "Interface(s) with asymmetric...", change first sentence > > > to: "MANET interfaces and egress interfaces are specifically > > > *NOT* configured with delegated prefixes." > > [Teco] > > Same story > > > > > > > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jul 13 04:01:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9G5N-0007HB-TM; Fri, 13 Jul 2007 04:01:09 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I9G5M-0007Ff-K0 for autoconf-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 04:01:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9G5M-0007FU-9l for autoconf@ietf.org; Fri, 13 Jul 2007 04:01:08 -0400 Received: from hpsmtp-eml14.kpnxchange.com ([213.75.38.114]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9G5M-0008Vv-0F for autoconf@ietf.org; Fri, 13 Jul 2007 04:01:08 -0400 Received: from hpsmtp-eml05.kpnxchange.com ([213.75.38.105]) by hpsmtp-eml14.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 10:00:34 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml05.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 13 Jul 2007 10:00:29 +0200 From: "Teco Boot" To: , Date: Fri, 13 Jul 2007 10:01:23 +0200 Message-ID: <003601c7c524$02000a00$0202a8c0@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AcfFJAGEgwSbUR5nSnewwcfLBaPfVw== X-OriginalArrivalTime: 13 Jul 2007 08:00:29.0576 (UTC) FILETIME=[E12DF080:01C7C523] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [Autoconf] New MANEMO documents X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi all, Some new documents are published on MANEMO. Problem Statement & Analysis: http://www.ietf.org/internet-drafts/draft-wakikawa-manemo-problem-statement- 01.txt http://www.ietf.org/internet-drafts/draft-wakikawa-manemoarch-00.txt http://www.ietf.org/internet-drafts/draft-boot-manet-nemo-analysis-01.txt Regards, Teco _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jul 13 11:09:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Mm4-0002R3-1r; Fri, 13 Jul 2007 11:09:40 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I9Mm3-0002Qe-Eo for autoconf-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 11:09:39 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9Mm2-0002QT-NQ for autoconf@ietf.org; Fri, 13 Jul 2007 11:09:38 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9Mln-0005Fh-Fq for autoconf@ietf.org; Fri, 13 Jul 2007 11:09:38 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6DF8Zet016322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 13 Jul 2007 10:08:50 -0500 (CDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6DF8ZKS016915; Fri, 13 Jul 2007 08:08:35 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6DF8TnV016630; Fri, 13 Jul 2007 08:08:34 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 08:08:32 -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: [Autoconf] Comments on draft-ietf-autoconf-manetarch-04.txt Date: Fri, 13 Jul 2007 08:07:37 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED908@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <003501c7c51f$231e12e0$0202a8c0@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Comments on draft-ietf-autoconf-manetarch-04.txt Thread-Index: AcfCTNYUfKiLMd38Qi2Pt/vtWb1YDgBfV9owAAWB71AAHQLLsAARYY7QACCPGCAAECcgAA== References: <39C363776A4E8C4A94691D2BD9D1C9A1029ED903@XCH-NW-7V2.nw.nos.boeing.com> <003501c7c51f$231e12e0$0202a8c0@Teco> From: "Templin, Fred L" To: "Teco Boot" X-OriginalArrivalTime: 13 Jul 2007 15:08:32.0774 (UTC) FILETIME=[AD8EF260:01C7C55F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Teco, > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: Friday, July 13, 2007 12:27 AM > To: Templin, Fred L > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] Comments on=20 > draft-ietf-autoconf-manetarch-04.txt >=20 > Fred, >=20 > Your definition is about a MANET Router (MNR). > RFC3753 is about a Mobile Router (MR). > Although MR and MNR have many characteristics in common, they=20 > are different. Using the RFC3753 definition, IMHO a MNR is essentially a MR that that has MANET interfaces and may participate in routing over them. > MR, Mobile Network, Ingress Interface and Egress Interface are further > described in draft-ietf-nemo-terminology-06 (in RFC queue). > > Combining MR and MNR is work in progress (MANEMO). Perhaps we are making this into something more than it really is (see below). > Maybe we have the same > opinion what to do with interface types MANET, Ingress and Egress. Maybe we do have the same opinion, and IMHO its pretty simple; egress interfaces forward packets upstream (toward the Internet), ingress interfaces forward packets downstream (toward mobile networks) and MANET interfaces forward packets laterally (toward other MANET interfaces). Please see Figure 1 in 'draft-templin-autoconf-dhcp-08.txt' for a graphical depiction of this. Thanks - Fred fred.l.templin@boeing.com > We will have a discussion on this in Chicago. >=20 > Regards, Teco >=20 >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: donderdag 12 juli 2007 17:39 > > To: Teco_Boot; autoconf@ietf.org > > Cc: Thomas Heide Clausen (home) > > Subject: RE: [Autoconf] Comments on=20 > draft-ietf-autoconf-manetarch-04.txt > >=20 > > Teco - see below: > >=20 > > > -----Original Message----- > > > From: Teco_Boot [mailto:teco@inf-net.nl] > > > Sent: Thursday, July 12, 2007 2:15 AM > > > To: Templin, Fred L; autoconf@ietf.org > > > Cc: 'Thomas Heide Clausen (home)' > > > Subject: RE: [Autoconf] Comments on > > > draft-ietf-autoconf-manetarch-04.txt > > > > > > Comments inline. > > > Teco. > > > > > > > 7) (substantial) Section 2.2, add a definition for=20 > "MANET interface" > > > > as follows: > > > > > > > > "MANET Interface > > > > a MANET Router's attachment to an asymmetric reachability > > > > link. A MANET interface is a "lateral"=20 > interface, i.e., it > > > > is inherently neither an ingress nor egress > > > interface although > > > > it can sometimes exhibit characteristics of both." > > > [Teco] > > > Please avoid terms ingress and egress interface here. In NEMO > > > context, it is > > > extremely confusing. And Autoconf and NEMO are related. > > > RFC3753 definitions: > > > Ingress interface > > > The interface of a MR attached to a link inside the mobile > > > network. > > > Egress interface > > > The interface of a MR attached to the home link if=20 > the MR is at > > > home, or attached to a foreign link if the MR is in=20 > a foreign > > > network. > >=20 > > Please look at the paragraph immediately preceding those two > > definitions in RFC3753, where it says: > >=20 > > "A MR acting as a gateway between an entire mobile=20 > network and the > > rest of the Internet has one or more egress=20 > interface(s) and one > > or more ingress interface(s). Packets forwarded=20 > upstream to the > > rest of the Internet are transmitted through one of the MR's > > egress interface; packets forwarded downstream to the mobile > > network are transmitted through one of the MR's ingress > > interface." > >=20 > > By this paragraph, an egress interface is used for forwarding > > packets "upstream" to the rest of the Internet and an ingress > > interface is used for forwarding packets "downstream" to a > > mobile network. This is exactly the sense in which I am > > intending egress/ingress in my change suggestions. I could > > have said "upstream/downstream", but that would seem less > > precise? > >=20 > > Fred > > fred.l.templin@boeing.com > >=20 > > > > 28) (substantial) Section 5.1, paragraph following figure 5, > > > > change: "interfaces towards classic IP link(s)" to: "ingress > > > > interfaces". Reason being is that delegated prefixes can > > > > only be assigned to "downstream" (aka ingress) interfaces; > > > > they cannot be assigned to "upstream" (aka egress) interfaces. > > > > (They also cannot be assigned to MANET interfaces, which are > > > > neither up- nor downstream, but "lateral".) > > > [Teco] > > > Same story > > > > > > > > > > 29) (substantial) Section 5.1, paragraph beginning: > > > > "Interface(s) with asymmetric...", change first sentence > > > > to: "MANET interfaces and egress interfaces are specifically > > > > *NOT* configured with delegated prefixes." > > > [Teco] > > > Same story > > > > > > > > > > > > >=20 >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jul 13 12:06:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9NfQ-00071U-9t; Fri, 13 Jul 2007 12:06:52 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I9NfN-0006q4-Nl for autoconf-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 12:06:49 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9NfN-0006lY-7i for autoconf@ietf.org; Fri, 13 Jul 2007 12:06:49 -0400 Received: from hpsmtp-eml12.kpnxchange.com ([213.75.38.112]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9NfM-0007PY-UW for autoconf@ietf.org; Fri, 13 Jul 2007 12:06:49 -0400 Received: from hpsmtp-eml10.kpnxchange.com ([213.75.38.110]) by hpsmtp-eml12.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 18:06:40 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml10.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 18:05:41 +0200 From: "Teco Boot" To: "'Templin, Fred L'" Subject: RE: [Autoconf] Comments on draft-ietf-autoconf-manetarch-04.txt Date: Fri, 13 Jul 2007 18:06:36 +0200 Message-ID: <008701c7c567$ca51a480$0202a8c0@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED908@XCH-NW-7V2.nw.nos.boeing.com> Thread-Index: AcfCTNYUfKiLMd38Qi2Pt/vtWb1YDgBfV9owAAWB71AAHQLLsAARYY7QACCPGCAAECcgAAABU+aA X-OriginalArrivalTime: 13 Jul 2007 16:05:41.0458 (UTC) FILETIME=[A9369B20:01C7C567] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi Fred, I checked draft-templin-autoconf-dhcp-08.txt. It uses egress in a different context as RFC3753. In 3753, the egress is connected to the home link or to the foreign link, in templin-autoconf-dhcp it is used to forward packets to the Internet. IMHO this is very different. For example, the RFC3753-Ingress-interface can provide connectivity to Internet via another router (MR, MNR or LFR). In templin-autoconf-dhcp, there is little difference in the ingress and egress interfaces. Both have arrows pointing away from the router entity. I think both interface types are bi-directional (incoming and outgoing packets). I think peering to other routers is possible on both interface types. A difference I can think of is that via the egress interface, a link to a next hop neighbor for a default route exists. Or the ingress interface is a stub network, it does not peer to other routers on it. Why not using MANET Architecture figure 1? There, the term Classic IP Interface is used. What is the difference with your ingress and egress interface? Regards, Teco _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jul 13 13:10:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9OfE-0004Xw-49; Fri, 13 Jul 2007 13:10:44 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I9OfC-0004Xl-HN for autoconf-confirm+ok@megatron.ietf.org; Fri, 13 Jul 2007 13:10:42 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9OfC-0004Xd-6z for autoconf@ietf.org; Fri, 13 Jul 2007 13:10:42 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I9OfB-00014H-VQ for autoconf@ietf.org; Fri, 13 Jul 2007 13:10:42 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6DHAGUH014235 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 13 Jul 2007 10:10:17 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6DHAGkY007147 for ; Fri, 13 Jul 2007 12:10:16 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6DH9oJl005889 for ; Fri, 13 Jul 2007 12:10:07 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Jul 2007 10:10:04 -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 Date: Fri, 13 Jul 2007 10:09:18 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED90D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED908@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Autoconf document Thread-Index: AcfCTNYUfKiLMd38Qi2Pt/vtWb1YDgBfV9owAAWB71AAHQLLsAARYY7QACCPGCAAECcgAAAE6Gkg References: <39C363776A4E8C4A94691D2BD9D1C9A1029ED903@XCH-NW-7V2.nw.nos.boeing.com><003501c7c51f$231e12e0$0202a8c0@Teco> <39C363776A4E8C4A94691D2BD9D1C9A1029ED908@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: X-OriginalArrivalTime: 13 Jul 2007 17:10:05.0095 (UTC) FILETIME=[A81ED370:01C7C570] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Subject: [Autoconf] New Autoconf document X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org http://www.ietf.org/internet-drafts/draft-templin-autoconf-dhcp-08.txt _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Jul 15 03:11:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9yGj-0006Ma-Ao; Sun, 15 Jul 2007 03:11:49 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I9yGh-0006MU-4m for autoconf-confirm+ok@megatron.ietf.org; Sun, 15 Jul 2007 03:11:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I9yGg-0006MM-RY for autoconf@ietf.org; Sun, 15 Jul 2007 03:11:46 -0400 Received: from wx-out-0506.google.com ([66.249.82.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I9yGc-0006xF-JY for autoconf@ietf.org; Sun, 15 Jul 2007 03:11:46 -0400 Received: by wx-out-0506.google.com with SMTP id h27so787408wxd for ; Sun, 15 Jul 2007 00:11:42 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=OT8rrtndYMV6aM9gtdpf/ZLuu/7WOm/uIGuOqfQDoeuW/BWALNzHial/6B1cCNd12O9J1kpeemwC7OY8Rw6y05EJ9JutPyBp+lLgDihw8MXmCKBDDehHahl5YtG66u2fajtLLcRaQZoPH1356A1mBvUkyhPs3X9LvlanMgLSm0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type:content-transfer-encoding:content-disposition; b=je7rCjDpTJmd2PjPZnFObSwkRawVkIHmIePio/qt/IVN+klHYaCnJJTj0fTHxgZvAs4B3zxUb753RiikE+gQZ0EmGSE1MNOq3cYe8k7bFhm/BbuK4RKSLQcNrU3bryPC8jGtFPTbEdqFVwTi2w345Zr2HfZIlrP/wzPQETd6r2c= Received: by 10.70.33.8 with SMTP id g8mr5768010wxg.1184483502317; Sun, 15 Jul 2007 00:11:42 -0700 (PDT) Received: by 10.70.42.15 with HTTP; Sun, 15 Jul 2007 00:11:42 -0700 (PDT) Message-ID: Date: Sun, 15 Jul 2007 12:41:42 +0530 From: Shubhranshu To: autoconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: manemo@mobileip.jp Subject: [Autoconf] Draft Agenda for the IETF-69 Autoconf WG meeting X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org I've uploaded the draft agenda for the upcoming Autoconf WG meeting and is available at http://www3.ietf.org/proceedings/07jul/agenda/autoconf.txt If you have any inputs to the agenda then please send them to the chairs or to the list. - Shubhranshu _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Jul 16 12:32:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IATUb-0008Ou-2x; Mon, 16 Jul 2007 12:32:13 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IATUZ-0008Og-T0 for autoconf-confirm+ok@megatron.ietf.org; Mon, 16 Jul 2007 12:32:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IATUZ-0008OW-JM for autoconf@ietf.org; Mon, 16 Jul 2007 12:32:11 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IATUV-0001z1-4K for autoconf@ietf.org; Mon, 16 Jul 2007 12:32:11 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6GGVpQa015424 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Jul 2007 09:32:06 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6GGVo9Z028024; Mon, 16 Jul 2007 11:31:50 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6GGVgXb027673; Mon, 16 Jul 2007 11:31:49 -0500 (CDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Jul 2007 09:31:48 -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: [Autoconf] Comments on draft-ietf-autoconf-manetarch-04.txt Date: Mon, 16 Jul 2007 09:31:48 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED913@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <008701c7c567$ca51a480$0202a8c0@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Comments on draft-ietf-autoconf-manetarch-04.txt Thread-Index: AcfCTNYUfKiLMd38Qi2Pt/vtWb1YDgBfV9owAAWB71AAHQLLsAARYY7QACCPGCAAECcgAAABU+aAAJb0yVA= References: <39C363776A4E8C4A94691D2BD9D1C9A1029ED908@XCH-NW-7V2.nw.nos.boeing.com> <008701c7c567$ca51a480$0202a8c0@Teco> From: "Templin, Fred L" To: "Teco Boot" X-OriginalArrivalTime: 16 Jul 2007 16:31:48.0900 (UTC) FILETIME=[CEB88640:01C7C7C6] X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Teco,=20 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: Friday, July 13, 2007 9:07 AM > To: Templin, Fred L > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] Comments on=20 > draft-ietf-autoconf-manetarch-04.txt >=20 > Hi Fred, >=20 > I checked draft-templin-autoconf-dhcp-08.txt. Thanks for checking, and see below. > It uses egress in a different context as RFC3753. I don't see it as different; in particular, see the paragraph in RFC3753 immediately preceding the definition for "Ingress interface" where it says: "A MR acting as a gateway between an entire mobile network and the rest of the Internet has one or more egress interface(s) and one or more ingress interface(s). Packets forwarded upstream to the rest of the Internet are transmitted through one of the MR's egress interface; packets forwarded downstream to the mobile network are transmitted through one of the MR's ingress interface." This sets the directionality for ingress/egress interfaces in a way that matches what is said in 'draft-templin'. It is essentially the applicability statement for ingress/egress interfaces, and no other use for ingress/egress interfaces is implied in their respective definitions. > In 3753, the egress is connected to the home link or to the=20 > foreign link, in > templin-autoconf-dhcp it is used to forward packets to the Internet. > IMHO this is very different. As above, 'draft-templin' is compatible with the second paragraph of the definition for Mobile Router and hence also compatible with the definition for Egress interface. That said, 'draft-templin' defines MANET Router as: "a node that...". Will fix this in the next version to say: "a Mobile Router that ...". > For example, the=20 > RFC3753-Ingress-interface can > provide connectivity to Internet via another router (MR, MNR or LFR).=20 By RFC3753, Ingress interfaces are a MR's interfaces that connect Mobile networks to the Internet and by the RFC3753 definition for Mobile network, a Mobile network is "An entire network, moving as a unit, which dynamically changes its point of attachment to the Internet...". It is true that a mobile network can connect to the global Internet via one or more MNRs, but what you are saying above implies that the Mobile network can be used as a transit network for the MNR's default route and that does not seem to follow from RFC3753.=20 =20 > In templin-autoconf-dhcp, there is little difference in the=20 > ingress and > egress interfaces. Not true; egress interfaces are "upstream" and ingress interfaces are "downstream", so there is a directionality. > Both have arrows pointing away from the router entity. True. > I think both interface types are bi-directional (incoming > and outgoing packets). True. > I think peering to other routers is possible on=20 > both interface types. True. > A difference I can think of is that via the egress interface,=20 > a link to a next hop neighbor for a default route exists. This seems well-worded and probably also true depending on the sense in which you mean "next hop neighbor". If you mean "next hop neighbor" as a persistent neighbor on the same physical link then I agree. If you mean next hop neighbor as the next IP hop, then I don't necessarily agree, because the next IP hop may be many physical hops away. But, that would make it a MANET interface as opposed to an egress interface. > Or the ingress interface is a stub network, it does not peer > to other routers on it. Not true, mobile networks attached on a MNR's ingress interfaces can be not-so-stubby and have many attached routers (or maybe I misunderstood). =20 > Why not using MANET Architecture figure 1? IMHO, the figure in 'draft-templin' is better. > There, the term Classic IP Interface is used. What is the=20 > difference with > your ingress and egress interface? The difference is in the directionaliy; "Classical IP interface" in the MANET Architecture draft does not capture a directionality. =20 > Regards, Teco Thanks - Fred fred.l.templin@boeing.com=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jul 18 14:02:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDr2-0006tf-A9; Wed, 18 Jul 2007 14:02:28 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IBDr0-0006tW-45 for autoconf-confirm+ok@megatron.ietf.org; Wed, 18 Jul 2007 14:02:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBDqz-0006tO-N0 for autoconf@ietf.org; Wed, 18 Jul 2007 14:02:25 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBDqy-0001Ui-A6 for autoconf@ietf.org; Wed, 18 Jul 2007 14:02:25 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6II2JmS004060 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 18 Jul 2007 13:02:19 -0500 (CDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6II2HQ8007050; Wed, 18 Jul 2007 11:02:18 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6II1vYi005871; Wed, 18 Jul 2007 11:02:03 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jul 2007 11:01: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 Date: Wed, 18 Jul 2007 11:01:54 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED91D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8FA@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: comments on draft-ietf-autoconf-statement-00.txt Thread-Index: AcfCTNYUfKiLMd38Qi2Pt/vtWb1YDgBfV9owAAWB71ABYBcsIA== References: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8FA@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: X-OriginalArrivalTime: 18 Jul 2007 18:01:55.0184 (UTC) FILETIME=[B9F17F00:01C7C965] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Mase@ie.niigata-u.ac.jp, Emmanuel.Baccelli@inria.fr, Shubhranshu , Simone.Ruffino@telecomitalia.it Subject: [Autoconf] comments on draft-ietf-autoconf-statement-00.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org A brief set of comments on this draft follows: =20 Fred fred.l.templin@boeing.com 1) (semi-substantial) Section 1, first sentence of final paragraph (and elsewhere throughout the document), the document should remain agnostic to the particular IP version. Suggest changing first portion of sentence to: "Standard automatic address/prefix assignment solutions (e.g., [5], [3], [4], etc.) ..." 2) (suggestion) Section 2, the definition for "Local address", suggest renaming this to "MANET Local Address (MLA)" (the term "MLA" is used in other autconf-related documents). 3) (substantial) Section 2, the definition for "Local address", strike the second sentence. In the first case, this document is a problem statement and should not be using MUST/SHOULD/MAY, and in the second case at least one anticipated type of MLAs (namely, RFC4193 ULAs) are permitted to be routed between sites - see ([RFC4193], Section 1). Also, strike the RFC2119 language at the beginning of this section. 4) (editorial) Section 3.1, end of second paragraph, the phrase "either either" appears. 5) (semi-editorial) Section 3.2, first paragraph, the term "MBR" is now being called simply: "BR" in [2] (but, I prefer "MNBR"). 6) (editorial) Section 3.3, "scenarii" - spelling? 7) (substantial) Section 4.1, first paragraph is too IPv6- centric and its use of the terms "host interface" and "loopback interface" seem overly precise and potentially too restrictive for this document's scope. Suggested reword for paragraph: "A MANET router needs to configure addresses and/or prefixes on its non-MANET interfaces. Besides, it needs to configure an MLA and/or a link local address on its MANET interface. A MANET router may also configure a prefix shorter than /128 (IPv6) or /32 (IPv4) on its MANET interface provided prefix uniqueness is guaranteed [2]." 8) (editorial) Section 4.2.4, spelling on "partitionning" in 2 places.=20 (end of comments) _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jul 20 11:46:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBugx-0007hf-Hd; Fri, 20 Jul 2007 11:46:55 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IBugw-0007hZ-4o for autoconf-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 11:46:54 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBugv-0007hR-Qt for autoconf@ietf.org; Fri, 20 Jul 2007 11:46:53 -0400 Received: from hpsmtp-eml12.kpnxchange.com ([213.75.38.112]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBugv-0005wL-FS for autoconf@ietf.org; Fri, 20 Jul 2007 11:46:53 -0400 Received: from hpsmtp-eml06.kpnxchange.com ([213.75.38.106]) by hpsmtp-eml12.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 17:46:49 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml06.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 17:46:41 +0200 From: "Teco Boot" To: "'Templin, Fred L'" Subject: RE: [Autoconf] comments on draft-ietf-autoconf-statement-00.txt Date: Fri, 20 Jul 2007 17:47:34 +0200 Message-ID: <013601c7cae5$4aa30e30$0202a8c0@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED91D@XCH-NW-7V2.nw.nos.boeing.com> Thread-Index: AcfCTNYUfKiLMd38Qi2Pt/vtWb1YDgBfV9owAAWB71ABYBcsIABgH9xQ X-OriginalArrivalTime: 20 Jul 2007 15:46:41.0588 (UTC) FILETIME=[2AB07F40:01C7CAE5] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org > 7) (substantial) Section 4.1, first paragraph is too IPv6- > centric and its use of the terms "host interface" and > "loopback interface" seem overly precise and potentially too > restrictive for this document's scope. Suggested reword for > paragraph: > > "A MANET router needs to configure addresses and/or prefixes on its > non-MANET interfaces. Besides, it needs to configure an MLA and/or > a link local address on its MANET interface. A MANET router may also > configure a prefix shorter than /128 (IPv6) or /32 (IPv4) on its > MANET > interface provided prefix uniqueness is guaranteed [2]." [Teco] I think Autoconf is chartered for IPv6 only. So what is wrong with an IPv6-centric approach? _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jul 20 12:07:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBv0f-00011A-BG; Fri, 20 Jul 2007 12:07:17 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IBv0d-0000zI-Gp for autoconf-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 12:07:15 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBv0d-0000zA-65 for autoconf@ietf.org; Fri, 20 Jul 2007 12:07:15 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IBv0c-0006Q5-PP for autoconf@ietf.org; Fri, 20 Jul 2007 12:07:15 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6KG6xQ3012584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 20 Jul 2007 09:07:13 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6KG6xZs003126; Fri, 20 Jul 2007 09:06:59 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6KG6qPO002859; Fri, 20 Jul 2007 09:06:58 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Jul 2007 09:06:37 -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: [Autoconf] comments on draft-ietf-autoconf-statement-00.txt Date: Fri, 20 Jul 2007 09:06:37 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED92B@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <013601c7cae5$4aa30e30$0202a8c0@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] comments on draft-ietf-autoconf-statement-00.txt Thread-Index: AcfCTNYUfKiLMd38Qi2Pt/vtWb1YDgBfV9owAAWB71ABYBcsIABgH9xQAAE2uwA= References: <39C363776A4E8C4A94691D2BD9D1C9A1029ED91D@XCH-NW-7V2.nw.nos.boeing.com> <013601c7cae5$4aa30e30$0202a8c0@Teco> From: "Templin, Fred L" To: "Teco Boot" X-OriginalArrivalTime: 20 Jul 2007 16:06:37.0690 (UTC) FILETIME=[F39F2DA0:01C7CAE7] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Teco, By my read, the Autoconf wg charter calls for the development of IPv6 address autoconfiguration mechanisms and I support that. But at the same time, the charter does not disallow the use of IPv4 in MANETs and so a problem statement should not introduce such a restriction. Therefore, I agree that my use of the phrase "too IPv6-centric" may not have been quite right, but IMHO the change suggestion is appropriate. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: Friday, July 20, 2007 8:48 AM > To: Templin, Fred L > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] comments on=20 > draft-ietf-autoconf-statement-00.txt >=20 > > 7) (substantial) Section 4.1, first paragraph is too IPv6- > > centric and its use of the terms "host interface" and > > "loopback interface" seem overly precise and potentially too > > restrictive for this document's scope. Suggested reword for > > paragraph: > >=20 > > "A MANET router needs to configure addresses and/or=20 > prefixes on its > > non-MANET interfaces. Besides, it needs to configure an=20 > MLA and/or > > a link local address on its MANET interface. A MANET=20 > router may also > > configure a prefix shorter than /128 (IPv6) or /32 (IPv4) on its > > MANET > > interface provided prefix uniqueness is guaranteed [2]." > [Teco]=20 > I think Autoconf is chartered for IPv6 only. So what is wrong with an > IPv6-centric approach? >=20 >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jul 20 15:19:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBy0T-0006Ze-20; Fri, 20 Jul 2007 15:19:17 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IBy0Q-0006ZZ-F6 for autoconf-confirm+ok@megatron.ietf.org; Fri, 20 Jul 2007 15:19:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IBy0Q-0006ZR-5Y for autoconf@ietf.org; Fri, 20 Jul 2007 15:19:14 -0400 Received: from wx-out-0506.google.com ([66.249.82.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IBy0P-000649-PA for autoconf@ietf.org; Fri, 20 Jul 2007 15:19:14 -0400 Received: by wx-out-0506.google.com with SMTP id h27so875652wxd for ; Fri, 20 Jul 2007 12:19:13 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YnUtOOunqWH7zAOiEeC/HfwqOzEK/hR4vfKqksGU+yArl+P4JchAQeJToIDgNeKi3+wPG9ABH9K+VlbS03AmL/SKq+ygeRESj64oxvS1jsX6XOIgxAGquzWZYd4aJCr5Kr04t3C8a/W2THaDsHN6Cz7DB02jJBuHnB0ZK8FvTN0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=QChQhI7RyIUyZkdI3h7K2+BmJvK0aNpMHi2KBOq0BmR+xJg1MFV8yZjCkxc0zIKYYLoz2YtKYGh5JCgV4UMJwssWdI7iyNzF55/DwCoN8VhJbtvV5WthtMIoVLIizmsQStFPXIxM6oyvGS822ryVCoumK+pvbbx58old5w3mwYY= Received: by 10.70.111.2 with SMTP id j2mr1307246wxc.1184959153140; Fri, 20 Jul 2007 12:19:13 -0700 (PDT) Received: by 10.70.42.15 with HTTP; Fri, 20 Jul 2007 12:19:13 -0700 (PDT) Message-ID: Date: Sat, 21 Jul 2007 00:49:13 +0530 From: Shubhranshu To: "Templin, Fred L" In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED91D@XCH-NW-7V2.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <39C363776A4E8C4A94691D2BD9D1C9A1029ED8FA@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED91D@XCH-NW-7V2.nw.nos.boeing.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: autoconf@ietf.org Subject: [Autoconf] Re: comments on draft-ietf-autoconf-statement-00.txt X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Please see inline comments: On 7/18/07, Templin, Fred L wrote: > A brief set of comments on this draft follows: > > Fred > fred.l.templin@boeing.com > > 1) (semi-substantial) Section 1, first sentence of final > paragraph (and elsewhere throughout the document), the > document should remain agnostic to the particular IP > version. Suggest changing first portion of sentence to: > > "Standard automatic address/prefix assignment solutions > (e.g., [5], [3], [4], etc.) ..." I am OK with the suggested changes however we need to scope the Problem statement ID with discussions specific to IPv6 and save our effort in analyzing any IPv4 specific issues, at least when the WG is not charterd to work on IPv4 aspect at this point of time. > > 2) (suggestion) Section 2, the definition for "Local address", > suggest renaming this to "MANET Local Address (MLA)" (the term > "MLA" is used in other autconf-related documents). > Agree. > 3) (substantial) Section 2, the definition for "Local address", > strike the second sentence. In the first case, this document > is a problem statement and should not be using MUST/SHOULD/MAY, > and in the second case at least one anticipated type of MLAs > (namely, RFC4193 ULAs) are permitted to be routed between > sites - see ([RFC4193], Section 1). Also, strike the RFC2119 > language at the beginning of this section. OK > > 4) (editorial) Section 3.1, end of second paragraph, the > phrase "either either" appears. > > 5) (semi-editorial) Section 3.2, first paragraph, the term > "MBR" is now being called simply: "BR" in [2] (but, I prefer > "MNBR"). I'd also prefer to use MNBR. > > 6) (editorial) Section 3.3, "scenarii" - spelling? Yes, needs to be fixed. > > 7) (substantial) Section 4.1, first paragraph is too IPv6- > centric and its use of the terms "host interface" and > "loopback interface" seem overly precise and potentially too > restrictive for this document's scope. Suggested reword for > paragraph: > > "A MANET router needs to configure addresses and/or prefixes on its > non-MANET interfaces. Besides, it needs to configure an MLA and/or > a link local address on its MANET interface. A MANET router may also > configure a prefix shorter than /128 (IPv6) or /32 (IPv4) on its > MANET > interface provided prefix uniqueness is guaranteed [2]." Ok with this. However, please note that MANET interface is allowed to configure global IP address on its interface (and not only MLA/Link-local address). > > 8) (editorial) Section 4.2.4, spelling on "partitionning" in 2 places. > > (end of comments) thanks, Fred - Shubhranshu _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sun Jul 22 16:26:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICi0W-0008Vx-Dt; Sun, 22 Jul 2007 16:26:24 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1ICi0V-0008Vs-LJ for autoconf-confirm+ok@megatron.ietf.org; Sun, 22 Jul 2007 16:26:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ICi0V-0008Vk-9x for autoconf@ietf.org; Sun, 22 Jul 2007 16:26:23 -0400 Received: from hiltonsmtp.worldspice.net ([216.37.94.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ICi0U-0001ep-Ik for autoconf@ietf.org; Sun, 22 Jul 2007 16:26:23 -0400 Received: (qmail 11511 invoked by uid 0); 22 Jul 2007 20:18:46 -0000 Received: by simscan 1.2.0 ppid: 11333, pid: 11494, t: 1.3604s scanners: clamav: 0.90.2/m: spam: 3.1.8 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on hiltonsmtp.worldspice.net X-Spam-Level: **** X-Spam-Status: No, score=4.1 required=6.5 tests=BAYES_95,RDNS_NONE autolearn=disabled version=3.2.1 Received: from unknown (HELO Teco) (67.97.210.2) by hiltonsmtp.worldspice.net with SMTP; 22 Jul 2007 20:18:45 -0000 From: "Teco_Boot" To: "'Templin, Fred L'" Subject: RE: [Autoconf] Comments on draft-ietf-autoconf-manetarch-04.txt Date: Sun, 22 Jul 2007 22:27:02 +0200 Message-ID: <000101c7cc9e$b1647b80$79a91cac@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfCTNYUfKiLMd38Qi2Pt/vtWb1YDgBfV9owAAWB71AAHQLLsAARYY7QACCPGCAAECcgAAABU+aAAJb0yVABIwnrIA== In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED913@XCH-NW-7V2.nw.nos.boeing.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 995b2e24d23b953c94bac5288c432399 Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi Fred, Comments inline. Teco. > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: maandag 16 juli 2007 18:32 > To: Teco Boot > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] Comments on draft-ietf-autoconf-manetarch-04.txt > > Teco, > > > -----Original Message----- > > From: Teco Boot [mailto:teco@inf-net.nl] > > Sent: Friday, July 13, 2007 9:07 AM > > To: Templin, Fred L > > Cc: autoconf@ietf.org > > Subject: RE: [Autoconf] Comments on > > draft-ietf-autoconf-manetarch-04.txt > > > > Hi Fred, > > > > I checked draft-templin-autoconf-dhcp-08.txt. > > Thanks for checking, and see below. > > > It uses egress in a different context as RFC3753. > > I don't see it as different; in particular, see the paragraph > in RFC3753 immediately preceding the definition for "Ingress > interface" where it says: > > "A MR acting as a gateway between an entire mobile network and the > rest of the Internet has one or more egress interface(s) and one > or more ingress interface(s). Packets forwarded upstream to the > rest of the Internet are transmitted through one of the MR's > egress interface; packets forwarded downstream to the mobile > network are transmitted through one of the MR's ingress > interface." > > This sets the directionality for ingress/egress interfaces > in a way that matches what is said in 'draft-templin'. It is > essentially the applicability statement for ingress/egress > interfaces, and no other use for ingress/egress interfaces > is implied in their respective definitions. [Teco] Please explain the templin-autoconf-dhcp egress-interface connected to the home link and to foreign links. Is routing disabled when connected to a foreign link? If not, please explain why not. === (RFC3963) The Mobile Router should be configured not to send any routing protocol messages on its egress interface when it is away from the home link and connected to a visited link. === > > > In 3753, the egress is connected to the home link or to the > > foreign link, in > > templin-autoconf-dhcp it is used to forward packets to the Internet. > > IMHO this is very different. > > As above, 'draft-templin' is compatible with the second > paragraph of the definition for Mobile Router and hence > also compatible with the definition for Egress interface. > > That said, 'draft-templin' defines MANET Router as: "a > node that...". Will fix this in the next version to say: > "a Mobile Router that ...". [Teco] Mobile Router or MANET router? I think a Mobile Router provides macro mobility services to MNNs and a MANET router provides micro mobility for its internal host functionality and connected hosts (Nodes that live behind the router). > > > For example, the > > RFC3753-Ingress-interface can > > provide connectivity to Internet via another router (MR, MNR or LFR). > > By RFC3753, Ingress interfaces are a MR's interfaces that > connect Mobile networks to the Internet and by the RFC3753 > definition for Mobile network, a Mobile network is "An > entire network, moving as a unit, which dynamically changes > its point of attachment to the Internet...". > > It is true that a mobile network can connect to the global > Internet via one or more MNRs, but what you are saying above > implies that the Mobile network can be used as a transit > network for the MNR's default route and that does not seem > to follow from RFC3753. [Teco] Why not? Please check section 8 in RFC3963. Mobile networks can also be multi-homed (RFC4885 section 5.3) and I do not see any reason they cannot provide connectivity to Internet to each other. > > In templin-autoconf-dhcp, there is little difference in the > > ingress and > > egress interfaces. > > Not true; egress interfaces are "upstream" and ingress > interfaces are "downstream", so there is a directionality. [Teco] I do not understand what you mean by this. I thought both interface types were bi-directionally. Maybe the difference is that the ingress interface connects a stub network and on the egress interface, a route to the Internet could exist. I reject this classification, as I explained above. > > > Both have arrows pointing away from the router entity. > > True. > > > I think both interface types are bi-directional (incoming > > and outgoing packets). > > True. > > > I think peering to other routers is possible on > > both interface types. > > True. > > > A difference I can think of is that via the egress interface, > > a link to a next hop neighbor for a default route exists. > > This seems well-worded and probably also true depending > on the sense in which you mean "next hop neighbor". If > you mean "next hop neighbor" as a persistent neighbor on > the same physical link then I agree. If you mean next hop > neighbor as the next IP hop, then I don't necessarily agree, > because the next IP hop may be many physical hops away. But, > that would make it a MANET interface as opposed to an egress > interface. > > > Or the ingress interface is a stub network, it does not peer > > to other routers on it. > > Not true, mobile networks attached on a MNR's ingress > interfaces can be not-so-stubby and have many attached > routers (or maybe I misunderstood). [Teco] OK, but when peering to other routers is supported, the ingress interface can be used for reaching the Internet and thus transforms into an "egress". > > > Why not using MANET Architecture figure 1? > > IMHO, the figure in 'draft-templin' is better. > > > There, the term Classic IP Interface is used. What is the > > difference with > > your ingress and egress interface? > > The difference is in the directionaliy; "Classical IP > interface" in the MANET Architecture draft does not > capture a directionality. [Teco] That is why I prefer the MANET-architecture figure. After this comment on comment I still do not see a reason using ingress and egress interface for what I would call "Classical IP interfaces". > > > Regards, Teco > > Thanks - Fred > fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Jul 23 13:21:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID1bB-0005Vs-Rz; Mon, 23 Jul 2007 13:21:33 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1ID1bB-0005Va-0S for autoconf-confirm+ok@megatron.ietf.org; Mon, 23 Jul 2007 13:21:33 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ID1bA-0005VI-Ke for autoconf@ietf.org; Mon, 23 Jul 2007 13:21:32 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1ID1b9-0003O2-Mx for autoconf@ietf.org; Mon, 23 Jul 2007 13:21:32 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l6NHLELA029107 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Jul 2007 10:21:28 -0700 (PDT) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id l6NHLD6b017431; Mon, 23 Jul 2007 10:21:13 -0700 (PDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l6NHLCkp017346; Mon, 23 Jul 2007 10:21:13 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jul 2007 10:21:12 -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: [Autoconf] Comments on draft-ietf-autoconf-manetarch-04.txt Date: Mon, 23 Jul 2007 10:21:12 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED930@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <000101c7cc9e$b1647b80$79a91cac@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Comments on draft-ietf-autoconf-manetarch-04.txt Thread-Index: AcfCTNYUfKiLMd38Qi2Pt/vtWb1YDgBfV9owAAWB71AAHQLLsAARYY7QACCPGCAAECcgAAABU+aAAJb0yVABIwnrIABAsceA References: <39C363776A4E8C4A94691D2BD9D1C9A1029ED913@XCH-NW-7V2.nw.nos.boeing.com> <000101c7cc9e$b1647b80$79a91cac@Teco> From: "Templin, Fred L" To: "Teco_Boot" X-OriginalArrivalTime: 23 Jul 2007 17:21:12.0275 (UTC) FILETIME=[DDEBEA30:01C7CD4D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 17e5edc4dfd335965c1d21372171c01c Cc: autoconf@ietf.org X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Teco, I am just seeing your message now, but I would only add by way of follow up for now that IMHO: 1) an egress interface is one over which a MR can configure a default route and 2) an ingress interface is one over which a MR can advertise itself as a default router. Some interfaces might not qualify on either point, and IMHO a MANET interface fits that desciption. Other interfaces might qualify on both points, but I would have to think about that more... Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Teco_Boot [mailto:teco@inf-net.nl]=20 > Sent: Sunday, July 22, 2007 1:27 PM > To: Templin, Fred L > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] Comments on=20 > draft-ietf-autoconf-manetarch-04.txt >=20 > Hi Fred, > Comments inline. > Teco. >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: maandag 16 juli 2007 18:32 > > To: Teco Boot > > Cc: autoconf@ietf.org > > Subject: RE: [Autoconf] Comments on=20 > draft-ietf-autoconf-manetarch-04.txt > >=20 > > Teco, > >=20 > > > -----Original Message----- > > > From: Teco Boot [mailto:teco@inf-net.nl] > > > Sent: Friday, July 13, 2007 9:07 AM > > > To: Templin, Fred L > > > Cc: autoconf@ietf.org > > > Subject: RE: [Autoconf] Comments on > > > draft-ietf-autoconf-manetarch-04.txt > > > > > > Hi Fred, > > > > > > I checked draft-templin-autoconf-dhcp-08.txt. > >=20 > > Thanks for checking, and see below. > >=20 > > > It uses egress in a different context as RFC3753. > >=20 > > I don't see it as different; in particular, see the paragraph > > in RFC3753 immediately preceding the definition for "Ingress > > interface" where it says: > >=20 > > "A MR acting as a gateway between an entire mobile=20 > network and the > > rest of the Internet has one or more egress=20 > interface(s) and one > > or more ingress interface(s). Packets forwarded=20 > upstream to the > > rest of the Internet are transmitted through one of the MR's > > egress interface; packets forwarded downstream to the mobile > > network are transmitted through one of the MR's ingress > > interface." > >=20 > > This sets the directionality for ingress/egress interfaces > > in a way that matches what is said in 'draft-templin'. It is > > essentially the applicability statement for ingress/egress > > interfaces, and no other use for ingress/egress interfaces > > is implied in their respective definitions. > [Teco]=20 > Please explain the templin-autoconf-dhcp egress-interface=20 > connected to the > home link and to foreign links. Is routing disabled when=20 > connected to a > foreign link? If not, please explain why not. > =3D=3D=3D (RFC3963) > The Mobile Router should be configured > not to send any routing protocol messages on its egress interface > when it is away from the home link and connected to a visited link. > =3D=3D=3D >=20 >=20 > >=20 > > > In 3753, the egress is connected to the home link or to the > > > foreign link, in > > > templin-autoconf-dhcp it is used to forward packets to=20 > the Internet. > > > IMHO this is very different. > >=20 > > As above, 'draft-templin' is compatible with the second > > paragraph of the definition for Mobile Router and hence > > also compatible with the definition for Egress interface. > >=20 > > That said, 'draft-templin' defines MANET Router as: "a > > node that...". Will fix this in the next version to say: > > "a Mobile Router that ...". > [Teco]=20 > Mobile Router or MANET router? > I think a Mobile Router provides macro mobility services to=20 > MNNs and a MANET > router provides micro mobility for its internal host functionality and > connected hosts (Nodes that live behind the router). >=20 >=20 > >=20 > > > For example, the > > > RFC3753-Ingress-interface can > > > provide connectivity to Internet via another router (MR,=20 > MNR or LFR). > >=20 > > By RFC3753, Ingress interfaces are a MR's interfaces that > > connect Mobile networks to the Internet and by the RFC3753 > > definition for Mobile network, a Mobile network is "An > > entire network, moving as a unit, which dynamically changes > > its point of attachment to the Internet...". > >=20 > > It is true that a mobile network can connect to the global > > Internet via one or more MNRs, but what you are saying above > > implies that the Mobile network can be used as a transit > > network for the MNR's default route and that does not seem > > to follow from RFC3753. > [Teco]=20 > Why not? Please check section 8 in RFC3963. > Mobile networks can also be multi-homed (RFC4885 section 5.3)=20 > and I do not > see any reason they cannot provide connectivity to Internet=20 > to each other. >=20 > =20 > > > In templin-autoconf-dhcp, there is little difference in the > > > ingress and > > > egress interfaces. > >=20 > > Not true; egress interfaces are "upstream" and ingress > > interfaces are "downstream", so there is a directionality. > [Teco]=20 > I do not understand what you mean by this. I thought both=20 > interface types > were bi-directionally. Maybe the difference is that the=20 > ingress interface > connects a stub network and on the egress interface, a route=20 > to the Internet > could exist. I reject this classification, as I explained above. >=20 >=20 > >=20 > > > Both have arrows pointing away from the router entity. > >=20 > > True. > >=20 > > > I think both interface types are bi-directional (incoming > > > and outgoing packets). > >=20 > > True. > >=20 > > > I think peering to other routers is possible on > > > both interface types. > >=20 > > True. > >=20 > > > A difference I can think of is that via the egress interface, > > > a link to a next hop neighbor for a default route exists. > >=20 > > This seems well-worded and probably also true depending > > on the sense in which you mean "next hop neighbor". If > > you mean "next hop neighbor" as a persistent neighbor on > > the same physical link then I agree. If you mean next hop > > neighbor as the next IP hop, then I don't necessarily agree, > > because the next IP hop may be many physical hops away. But, > > that would make it a MANET interface as opposed to an egress > > interface. > >=20 > > > Or the ingress interface is a stub network, it does not peer > > > to other routers on it. > >=20 > > Not true, mobile networks attached on a MNR's ingress > > interfaces can be not-so-stubby and have many attached > > routers (or maybe I misunderstood). > [Teco]=20 > OK, but when peering to other routers is supported, the=20 > ingress interface > can be used for reaching the Internet and thus transforms=20 > into an "egress".=20 >=20 >=20 > >=20 > > > Why not using MANET Architecture figure 1? > >=20 > > IMHO, the figure in 'draft-templin' is better. > >=20 > > > There, the term Classic IP Interface is used. What is the > > > difference with > > > your ingress and egress interface? > >=20 > > The difference is in the directionaliy; "Classical IP > > interface" in the MANET Architecture draft does not > > capture a directionality. > [Teco]=20 > That is why I prefer the MANET-architecture figure.=20 > After this comment on comment I still do not see a reason=20 > using ingress and > egress interface for what I would call "Classical IP interfaces". >=20 >=20 > >=20 > > > Regards, Teco > >=20 > > Thanks - Fred > > fred.l.templin@boeing.com >=20 >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jul 24 12:01:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMpX-0002Pc-3b; Tue, 24 Jul 2007 12:01:47 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IDMpW-0002PC-D8 for autoconf-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 12:01:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDMpW-0002Oy-24 for autoconf@ietf.org; Tue, 24 Jul 2007 12:01:46 -0400 Received: from ccerelbas01.cce.hp.com ([161.114.21.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IDMpV-0002iK-AX for autoconf@ietf.org; Tue, 24 Jul 2007 12:01:46 -0400 Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.81.1.58]) by ccerelbas01.cce.hp.com (Postfix) with ESMTP id EA12F34799 for ; Tue, 24 Jul 2007 11:01:34 -0500 (CDT) Received: from cceexb11.americas.cpqcorp.net ([16.81.1.6]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 11:01:32 -0500 Received: from tayexb12.americas.cpqcorp.net ([16.103.130.102]) by cceexb11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 11:01:32 -0500 Received: from tayexg12.americas.cpqcorp.net ([16.103.130.127]) by tayexb12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 12:01:17 -0400 Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Jul 2007 12:01:11 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 Jul 2007 12:01:08 -0400 Message-ID: <816DD9299957E547B5D758D7F977D6DC022501B6@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MANEMO is not just about Nested Nemo thread-index: AcfOC0YxrIsv2jZDT6CHsubXgfUBKgAAIQdg From: "Bound, Jim" To: X-OriginalArrivalTime: 24 Jul 2007 16:01:11.0543 (UTC) FILETIME=[DAE01870:01C7CE0B] X-Spam-Score: -4.0 (----) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Subject: [Autoconf] FW: MANEMO is not just about Nested Nemo X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org FYI per yesterdays discussion. /jim -----Original Message----- From: Bound, Jim=20 Sent: Tuesday, July 24, 2007 11:57 AM To: manemo@mobileip.jp Subject: MANEMO is not just about Nested Nemo Yesterday at manet autoconfig wg it was suggested MANEMO is just about Nested NEMO. This is very wrong as nested NEMO is only part of what MANEMO is addressing. Here is technical example. Fire Brigade is deployed and three MANETS are set up. Each of them are also attached to Mobile Routers at ingress interface and to the Fire Brigade L3 MESH at the Egress Interface. The Fire Brigade L3 MESH is also attached to the Metro Network fixed network (could be L3 MESH portal or backhaul via Satcom or 802.16x). =20 The Fire Brigade MESH is blow up for some 911 reason and the L3 MESH is gone. Each of the MANETs become MANEMO Fringe Stubs. These MANETs need a means to connect to the Metro Network and converge and be able to use the fixed network as a form for the three MANETs to communicate. The above is a simple use case of MANEMO MFS. Do we have all the protocols required today in the IETF to perform this convergence? Do we have the operational interfaces and ops protocols or BCPs to deal with this? Can we optimize any existing network technology (e.g. Multicast, Anycast, NEMO) or protocols (e.g. IPv6 ND, OLSR/NHDP, DYMO) to address this scenario. NB: If your on this list and you don't know technically in depth wireless, portals, backhauls, etc please speak one must understand technically these paradigms to understand MANEMO and the discussion. We may need an updated spec on this new paradigm in general within the IETF archives simply for training. /jim _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jul 24 13:10:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNtc-0007Ok-Rg; Tue, 24 Jul 2007 13:10:04 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IDNtb-0007OQ-Nf for autoconf-confirm+ok@megatron.ietf.org; Tue, 24 Jul 2007 13:10:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IDNtb-0007OG-CO for autoconf@ietf.org; Tue, 24 Jul 2007 13:10:03 -0400 Received: from hiltonsmtp.worldspice.net ([216.37.94.58]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IDNta-0000df-VZ for autoconf@ietf.org; Tue, 24 Jul 2007 13:10:03 -0400 Received: (qmail 13354 invoked by uid 0); 24 Jul 2007 17:02:27 -0000 Received: by simscan 1.2.0 ppid: 13346, pid: 13347, t: 0.8801s scanners: clamav: 0.90.2/m: spam: 3.1.8 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on hiltonsmtp.worldspice.net X-Spam-Level: **** X-Spam-Status: No, score=4.3 required=6.5 tests=BAYES_99,RDNS_NONE autolearn=disabled version=3.2.1 Received: from unknown (HELO Teco) (67.97.210.2) by hiltonsmtp.worldspice.net with SMTP; 24 Jul 2007 17:02:26 -0000 From: "Teco_Boot" To: Date: Tue, 24 Jul 2007 19:10:53 +0200 Message-ID: <003601c7ce15$988f1f20$2d0e0202@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcfOFZdkcXrD4lHGT1ui8BVkaF83Ng== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Autoconf] autoconf-statement-00 - multiple MBR - topology correct address issue X-BeenThere: autoconf@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Ad-Hoc Network Autoconfiguration WG discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: autoconf-bounces@ietf.org Hi, I have a comment on draft-ietf-autoconf-statement-00, 4.3.3. MANET Border Routers Related Issues: === When a device changes its MBR attachment, some routes may be broken, affecting MANET packet forwarding performance and applications. === I assume ingress filtering could be applied on MBRs (RFC2827/BCP38, RFC3704/BCP84). After any change in the MBR attachment, traffic blocking can occur. This implies a need for immediately switch to a new Autoconf address after a reroute. Agreed? As a consequence, session continuity is not provided, unless Mobile IP (or another trick) is used and BU is triggered by the Autoconf address switch, used as CoA. Agreed? I suggest adding the topology correct address issue in the draft. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf