From autoconf-bounces@ietf.org Fri Jun 01 04:26:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu2TJ-0000b6-0e; Fri, 01 Jun 2007 04:26:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu2TH-0000Zz-Ut for autoconf@ietf.org; Fri, 01 Jun 2007 04:26:55 -0400 Received: from hpsmtp-eml19.kpnxchange.com ([213.75.38.84]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu2TF-0006lf-H6 for autoconf@ietf.org; Fri, 01 Jun 2007 04:26:55 -0400 Received: from hpsmtp-eml05.kpnxchange.com ([213.75.38.105]) by hpsmtp-eml19.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 10:26:52 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml05.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Jun 2007 10:26:52 +0200 From: "Teco Boot" To: Subject: RE: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Date: Fri, 1 Jun 2007 10:27:49 +0200 Message-ID: <002901c7a426$be7946c0$05000100@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.3028 Thread-Index: Acej1kgFrOxL9Fl/RUW36hlYLGdDzgAQ/6sg In-Reply-To: X-OriginalArrivalTime: 01 Jun 2007 08:26:52.0125 (UTC) FILETIME=[9B1A40D0:01C7A426] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Ian, Joe and Thomas, Thanks for the updated ID. Here some comments. 4.1. > Many protocols (e.g. neighbor discovery) do not operate in > wireless networks with asymmetric reachability. Is IPv6 ND mentioned? I prefer an exact reference. 4.2.3. > To assist in coordinating among a loosely connected set of MANET > routers, a procedure called flooding is used. MANET flooding consist > of disseminating a packet to all connected MANET routers. Here start a MANET pitfall. By introducing a mechanism allowing flooding to _all connected MANET routers_, scaling of the MANET is bounded. Adding an option for flooding to parts of the MANET provide a remedy. Sample mechanisms are _logical areas_ and _inner MANET border routers_ or limit flooding based on hopcount or path metric. I know such mechanisms could introduce other problems, like multihop Asymmetric Reachability when path metric bounds are used. 5. > MANET interfaces, forming a multihop MANET area, may use a site > prefix; The term _multihop MANET area_ is not defined in the ID. The term _logical areas_ I used above could be meant. 8.1 > In MANET, nodes might assume a service is available locally (within > one IP hop) or within a particular scope (one or more IP hops - MANET, > site, global). As mentioned in 7, cross layer information could be available and such information could be far more important than hop-count. A 2-hop error-free and lightly loaded 100Mbps path could be qualified as better related to a single hop congested error-prone 2400bps link. 8.2 > ... complete number of nodes in a MANET ... > ... cohesive flat routing area ... > ... a single routing region ... Same comments as above, on term _multihop MANET area_. Three terms for something not explained in this ID. I am still confused wat is meant in this section. There is the term _Peer MANET Routers_. It is not _connected MANET routers_ / _connected nodes_ (see text). I am not sure _MAN Neighbors_ is meant. May be a _MANET Peer_ is a potential _MANET Neighbor_ and all _MANET Peers_ are configured for a _single routing region_. But reading 2.2. _MANET_, a _MANET_ is a _routing region_ and _MANETs_ split and merge due to reachability, so _regions_ are based on connectivity and not on configuration. Regards, Teco _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jun 01 05:35: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 1Hu3XL-0006Rx-OW; Fri, 01 Jun 2007 05:35:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu3FJ-0001SW-2I for autoconf@ietf.org; Fri, 01 Jun 2007 05:16:33 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hu3FI-0007Si-LB for autoconf@ietf.org; Fri, 01 Jun 2007 05:16:33 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1180689391!17225270!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.101] Received: (qmail 19546 invoked from network); 1 Jun 2007 09:16:31 -0000 Received: from motgate2.mot.com (HELO motgate2.mot.com) (144.189.100.101) by server-8.tower-119.messagelabs.com with SMTP; 1 Jun 2007 09:16:31 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate2.mot.com (8.12.11/Motorola) with ESMTP id l519GV6t013434 for ; Fri, 1 Jun 2007 02:16:31 -0700 (MST) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l519GUQA014968 for ; Fri, 1 Jun 2007 04:16:31 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l519GSsh014897 for ; Fri, 1 Jun 2007 04:16:29 -0500 (CDT) Message-ID: <465FE3E3.8080601@gmail.com> Date: Fri, 01 Jun 2007 11:16:19 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: autoconf@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000746-0, 30/05/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: e367d58950869b6582535ddf5a673488 Subject: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.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 Hi, I have read large parts of the draft draft-ietf-autoconf-manetarch-02.txt I generally agree with the draft intention, and especially with the parts that say that IP addressing model is the same as classical IP addressing model. > These routers may communicate over wireless links with asymmetric > reachability ... I think you mean asymmetric path characteristics? Like 10mb/1024mtu downlink and 2mb/512mtu uplink? Because asymmetric _reachability_ sounds to me like yes-no like sattelite uni-directional links. I don't think udlr sattelite links are considered in MANET. Are sattelite links considered by MANET? Are there other wireless unidirectional links considered by MANET? (DVB-H terestrial, RFID, other?) > Asymmetric Reachability > > A link where non-reflexive and/or non-transitive reachability is part > of normal operation. Non-reflexive reachability means that packets > from X reach Y but packets from Y don't reach X. I think this is the case only for sattelite wireless links. Is there another wireless link that has this property? All wireless links I can think of (2.4GHz WiFi, WLAN in general, IrDA, bluetooth) are "reflexive" rechability in this sense. Is there another? > Non- transitive reachability means packets from X reach Y, and > packets from Y reach Z, but packets from X don't reach Z. Many radio/ > wireless interfaces exhibit these properties. Ok, but this doesn't sound as asymmetric, not to me. It is the well-known hidden terminal problem. I think we should state that this is the hidden terminal problem. > Neighbor > > If node X can directly exchange IP packets with node Y, then node Y > is node X's neighbor. Packet reception characteristics are often > used to assist devices in determining the quality of neighbors' > communication. I think here we should at least refer to RFC2461's definition of neighbors which is 'nodes attached to the same link'. > Note that an anycast address is syntactically indistinguishable from > a unicast address. Thus, nodes sending packets to anycast addresses > don't generally know that an anycast address is being used. In a sense yes, anycast addresses are syntactically indistinguishable from unicast addresses, in that they're IPv6 128bit addresses represented textually like any unicast address. However, at least some if not all anycast addresses have a IANA-reserved syntax. Thus the node sending a packet to a anycast address _does_ know that an anycast address is being used. > Full-Broadcast Interface (FBI) > > A broadcast interface with reflexive and transitive reachability. All > nodes on the interface can send and receive IP packets directly, all > nodes are symmetric neighbors. An Ethernet segment is an example of > a FBI. I think you mean "a wired 802.3 Ethernet" is an example of FBI. Because WiFi 802.11 does not have this symmetric property: two MSs under a AP can't communicate directly. Then also, why not defining a Multicast Interface? A multicast interface is one that supports link-layer multicast. > Border Router (BR) > > a router that participates in multiple routing regions, and often > multiple routing protocols. A BR defines the border between its > multiple routing regions. A BR is responsible for presenting a > consistent picture of the nodes reachable through itself to each > routing region. A BR determines the routing information to propagate > between different routing regions. Due to similarity, maybe we should refer to OSPF's definition of an Area Border Router and BGP's definition of an AS border router. > MANET Router (MAN) I think this may clash with Metropolitan Area Network. Why not just saying MANET router or so. > MANET interfaces are defined as interfaces that demonstrate > asymmetric reachability and/or neighbor addresses that are not known > a priori. I can understand the first part of the phrase emplying the term asymmetric reachability if it were expanded. It's easier to grasp if it says that MANET interfaces can be unidirectional (if we agree sattelite is part of MANET) and can have the hidden terminal problem. Or that a MANET interface has asymmetric dl/ul (download/upload) link characteristics. I do not understand the last part of the phrase ("neighbor addresses that are not known a priori"). > A MANET router may participate in routing on zero or more MANET > interfaces. If a MANET router does no routing on a MANET interface (or participates in routing on zero MANET interfaces) then it's no longer a MANET router, right? > MANET router may also have zero or more classic IP interfaces to > which other nodes may connect; i.e. the router may be responsible for > several IP prefixes. Sorry, it does not follow. That i.e. ("id est", lat.) makes me think that only because the MANET router has some classic IP interfaces it is in charge for some IP prefixes, and thus maybe if it has no classic IP interfaces then it is _not_ in charge for any IP prefix; this is obviously not true, because if MANET router has a MANET interface then it necessarily has an IP prefix on it. > <~~~~~~+~~~~~~> Routing-MANET > | Interface(s) > ''''''''''|''''''''''''''''' > ' +-------|--------------+ ' > ' | Router Functionality |................... > ' +-------+-+------------+ ' Routing-Classic > ' : : ' IP Interface(s) > ' MANET : +-----------+ ' > ' Router : | Internal | ' > ' : |Addressable| ' > ' : |Host Logic | ' > ' : | (IAH) | ' > ' : +-----------+ ' > '''''''''':''''''''''''''''' > : Nodes that live behind the router > +......+.........+ ============ > : : = : = > +-+-+ +----+----+ =CLASSIC IP= > | N | * * * | Node(s) | =INTERFACES= > +---+ +---------+ ============ This figure is unclear, because there are classic IP interfaces both on the right and on the bottom of the router. Not sure what the ":" means either. Looks like an elipsis (1, 2...3) but then "***" seems to be used for same meaning. > In MANETs there are several architectural scopes. We define the > following scopes: > > MANET Neighbors a set of MANET routers that is reachable via one IP > hop, reachable via link-local messaging. Is it the same as the link-local scope? The link-local scope is defined for IPv6 in a certain RFC. > MANET N-Neighborhood a set of MANET routers that is reachable via > N-hops. These routers usually have a large number of common > neighbors and may directly compete for the same shared wireless > resources. This is very difficult to grasp. Neighbors (in terms of rfc2461) are always on the same link. Here you're saying that MANET neighbors can be on different links. I find this difficult to grasp conceptually, but it may be only me. > 4.2.3. MANET Membership I think it is difficult to talk about 'membership' like that, referring to a node belonging or not to a mobile area network. BEcause, 'membership' is widely used in multicast contexts, see MLD and IGMP for example, and it can easily lead to clashes. At several places in the draft I've been confused by this 'membership' dual meaning. > A MANET router can be delegated zero or more prefixes. I have difficulties in understanding this phrase. I generally agree that a MANET router is in charge of routing for one or more prefixes. If it is zero prefixes then it's not a router. If it is 'delegated' then DHCP-PD was used. I think the use of the words 'delegated' and 'zero' in that phrase is problematic to my reading. > If a MANET router is delegated a prefix p::, this prefix can be > assigned to its classic IP link(s), and nodes can be assigned > addresses from within this prefix, and configured with this prefix as > illustrated in figure 6. This text not only is in disagreement with the figure but also incorrect in itself. If prefix p::/48 is administratively assigned to a router then it can not be (or is usually not) assigned as such on each of its interfaces. Prefixes derived from that p::/48 are assigned to its interfaces (as the figure correctly shows p:1:: p:2:: etc - it should be actually p:1::/64 or so)). Also, this case of a unique p::/48 administratively assigned to a router is a particular case. The more general (and 'classic' in my understanding) case is where different prefixes are assigned to each link to which the router is attached, and these prefixes have nothing in common, but only the first three bits maybe. E.g. MANET Router with three MANET interfaces is administratively assigned the prefixes p::/48, q::/48 and r::/48 and the interfaces are configured with addresses in prefixes p:1::/64, q:1::/64 and r:1::/64. > o MANET interfaces, forming a multihop MANET area, may use a site > prefix; Not sure about this phrase, what site prefix? Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jun 01 11:47:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu9LX-0007vV-VE; Fri, 01 Jun 2007 11:47:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu9LW-0007vQ-3U for autoconf@ietf.org; Fri, 01 Jun 2007 11:47:22 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu9LU-0007qc-8o for autoconf@ietf.org; Fri, 01 Jun 2007 11:47:22 -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 l51FlIjO002639 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2007 10:47:19 -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 l51FlIvH007051; Fri, 1 Jun 2007 08:47:18 -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 l51FlG1W006915; Fri, 1 Jun 2007 08:47:18 -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, 1 Jun 2007 08:47:16 -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] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Date: Fri, 1 Jun 2007 08:47:15 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED814@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <465FE3E3.8080601@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Thread-Index: AcekMChBsLnCP68NS+SP0kxzrIkwCAAMtJ2w References: <465FE3E3.8080601@gmail.com> From: "Templin, Fred L" To: "Alexandru Petrescu" , X-OriginalArrivalTime: 01 Jun 2007 15:47:16.0843 (UTC) FILETIME=[21763BB0:01C7A464] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: 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 > > MANET Router (MAN) >=20 > I think this may clash with Metropolitan Area Network. Why not just > saying MANET router or so. How about either MAR or MARTR (for Mobile Ad-hoc Router)? There was also still the point about acronym collision for LFN in the NEMO terminology. LFN has been used for "Long Fat Network" in the IETF terminology for a long time, and a satellite link is one example of an LFN. Was the acronym overlap intentional? Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jun 01 12:08:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu9fs-0003pu-Ee; Fri, 01 Jun 2007 12:08:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hu9fq-0003nF-DM for autoconf@ietf.org; Fri, 01 Jun 2007 12:08:22 -0400 Received: from hedwig.lancs.ac.uk ([148.88.0.65]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hu9fn-0000Q7-VJ for autoconf@ietf.org; Fri, 01 Jun 2007 12:08:22 -0400 Received: from mail02.lancs.ac.uk ([148.88.1.54]) by hedwig.lancs.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1Hu9fn-0007yb-R5 for autoconf@ietf.org; Fri, 01 Jun 2007 17:08:19 +0100 Received: from [148.88.227.79] (helo=IND031000002) by mail02.lancs.ac.uk with esmtp (Exim 4.66) (envelope-from ) id 1Hu9fn-00063S-43; Fri, 01 Jun 2007 17:08:19 +0100 From: "Ben McCarthy" To: "'Templin, Fred L'" , "'Alexandru Petrescu'" , References: <465FE3E3.8080601@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED814@XCH-NW-7V2.nw.nos.boeing.com> Subject: RE: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Date: Fri, 1 Jun 2007 17:08:18 +0100 Message-ID: <00fd01c7a467$11f871f0$4fe35894@lancs.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED814@XCH-NW-7V2.nw.nos.boeing.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Thread-Index: AcekMChBsLnCP68NS+SP0kxzrIkwCAAMtJ2wAADjJyA= X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: 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, > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: 01 June 2007 16:47 > To: Alexandru Petrescu; autoconf@ietf.org > Subject: RE: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch- > 02.txt > > > > MANET Router (MAN) > > > > I think this may clash with Metropolitan Area Network. Why not just > > saying MANET router or so. > > How about either MAR or MARTR (for Mobile Ad-hoc Router)? > I haven't got any suggestion of my own, but I just thought I'd point out that MAR is already a pretty heavily loaded acronym for Mobile Access Router: http://www.cisilion.com/cisco-3200-series.htm http://research.microsoft.com/~pablo/MAR.htm Hope this is of some help. Cheers, Ben > There was also still the point about acronym collision > for LFN in the NEMO terminology. LFN has been used for > "Long Fat Network" in the IETF terminology for a long > time, and a satellite link is one example of an LFN. > Was the acronym overlap intentional? > > Fred > fred.l.templin@boeing.com > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jun 01 13:20: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 1HuAnp-0000T0-SX; Fri, 01 Jun 2007 13:20:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuAno-0000Sp-Nr for autoconf@ietf.org; Fri, 01 Jun 2007 13:20:40 -0400 Received: from smtp03.uc3m.es ([163.117.176.133] helo=smtp.uc3m.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuAnn-0000Bu-8H for autoconf@ietf.org; Fri, 01 Jun 2007 13:20:40 -0400 Received: from acorde (acorde.it.uc3m.es [163.117.139.72])(using TLSv1 with cipher RC4-MD5 (128/128 bits))(No client certificate requested)by smtp.uc3m.es (Postfix) with ESMTP id 578A71A7CC; Fri, 1 Jun 2007 19:20:38 +0200 (CEST) Subject: RE: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: Ben McCarthy In-Reply-To: <00fd01c7a467$11f871f0$4fe35894@lancs.local> References: <465FE3E3.8080601@gmai l.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED814@XCH-NW-7V2.nw.nos.boeing.com> <00fd01c7a467$11f871f0$4fe35894@lancs.local> Content-Type: text/plain; charset=ISO-8859-15 Organization: Universidad Carlos III de Madrid Date: Fri, 01 Jun 2007 19:20:40 +0200 Message-Id: <1180718440.4485.55.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 X-imss-version: 2.047 X-imss-result: Passed X-imss-scanInfo: M:B L:N SM:2 X-imss-tmaseResult: TT:1 TS:-16.9467 TC:1F TRN:36 TV:3.6.1039(15212.003) X-imss-scores: Clean:100.00000 C:0 M:0 S:0 R:0 X-imss-settings: Baseline:1 C:1 M:1 S:1 R:1 (0.0000 0.0000) Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.1 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: autoconf@ietf.org 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: , Errors-To: autoconf-bounces@ietf.org Hi, I agree that MAR is already heavily loaded. I'd suggest using any other acronym (such as MARO) or just using "MANET Router". Regards, Carlos El vie, 01-06-2007 a las 17:08 +0100, Ben McCarthy escribi=F3: > Hi Fred, >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: 01 June 2007 16:47 > > To: Alexandru Petrescu; autoconf@ietf.org > > Subject: RE: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch- > > 02.txt > >=20 > > > > MANET Router (MAN) > > > > > > I think this may clash with Metropolitan Area Network. Why not jus= t > > > saying MANET router or so. > >=20 > > How about either MAR or MARTR (for Mobile Ad-hoc Router)? > >=20 >=20 > I haven't got any suggestion of my own, but I just thought I'd point ou= t > that MAR is already a pretty heavily loaded acronym for Mobile Access > Router: >=20 > http://www.cisilion.com/cisco-3200-series.htm >=20 > http://research.microsoft.com/~pablo/MAR.htm >=20 > Hope this is of some help. >=20 > Cheers, >=20 > Ben >=20 > > There was also still the point about acronym collision > > for LFN in the NEMO terminology. LFN has been used for > > "Long Fat Network" in the IETF terminology for a long > > time, and a satellite link is one example of an LFN. > > Was the acronym overlap intentional? > >=20 > > Fred > > fred.l.templin@boeing.com > >=20 > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www1.ietf.org/mailman/listinfo/autoconf >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf --=20 =A1AS=D3CIATE! Gratis para estudiantes http://www.telematica.ws Carlos Jes=FAs Bernardos Cano http://www.netcoms.net GPG FP: BFF1 7C7A 6AA7 BCE3 885A 4DF1 ED0C 5952 BF89 B974 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jun 01 16:26:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuDhH-00007K-FJ; Fri, 01 Jun 2007 16:26:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuDhG-00007F-1Y for autoconf@ietf.org; Fri, 01 Jun 2007 16:26:06 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuDhD-00044z-Kn for autoconf@ietf.org; Fri, 01 Jun 2007 16:26:06 -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 l51KPmq2029623 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2007 13:26:03 -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 l51KPm0C024605; Fri, 1 Jun 2007 13:25:48 -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 l51KPkow024538; Fri, 1 Jun 2007 13:25:48 -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, 1 Jun 2007 13:25: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] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Date: Fri, 1 Jun 2007 13:25:45 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED821@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <002901c7a426$be7946c0$05000100@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Thread-Index: Acej1kgFrOxL9Fl/RUW36hlYLGdDzgAQ/6sgABuSQ4A= References: <002901c7a426$be7946c0$05000100@Teco> From: "Templin, Fred L" To: "Teco Boot" , X-OriginalArrivalTime: 01 Jun 2007 20:25:46.0646 (UTC) FILETIME=[0947D360:01C7A48B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Cc: 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 Teco, A term in common use in other context for areas within a MANET is "subnetwork" which is meant in a way that is distinct from the term "subnet", i.e., it makes no statement about IP prefix/netmask assignments. Subnetworks within a MANET can indeed be connected by inner MANET border routers, since they are essetially just smaller MANETs within a larger MANET. So, one way to bound scaling is to bound the sizes of subnetworks within a MANET. Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: Friday, June 01, 2007 1:28 AM > To: autoconf@ietf.org > Subject: RE: [Autoconf] I-D=20 > ACTION:draft-ietf-autoconf-manetarch-02.txt=20 >=20 > Hi Ian, Joe and Thomas,=20 > Thanks for the updated ID. Here some comments. >=20 > 4.1. > > Many protocols (e.g. neighbor discovery) do not operate in > > wireless networks with asymmetric reachability. > Is IPv6 ND mentioned? I prefer an exact reference. >=20 > 4.2.3. > > To assist in coordinating among a loosely connected set of MANET > > routers, a procedure called flooding is used. MANET=20 > flooding consist > > of disseminating a packet to all connected MANET routers. > Here start a MANET pitfall. By introducing a mechanism=20 > allowing flooding to > _all connected MANET routers_, scaling of the MANET is bounded.=20 > Adding an option for flooding to parts of the MANET provide a=20 > remedy. Sample > mechanisms are _logical areas_ and _inner MANET border=20 > routers_ or limit > flooding based on hopcount or path metric. I know such=20 > mechanisms could > introduce other problems, like multihop Asymmetric=20 > Reachability when path > metric bounds are used. >=20 >=20 > 5. > > MANET interfaces, forming a multihop MANET area, may use a site > > prefix; > The term _multihop MANET area_ is not defined in the ID. The=20 > term _logical > areas_ I used above could be meant. >=20 > 8.1 > > In MANET, nodes might assume a service is available locally (within=20 > > one IP hop) or within a particular scope (one or more IP=20 > hops - MANET,=20 > > site, global). > As mentioned in 7, cross layer information could be available and such > information could be far more important than hop-count. A=20 > 2-hop error-free > and lightly loaded 100Mbps path could be qualified as better=20 > related to a > single hop congested error-prone 2400bps link. >=20 > 8.2 > > ... complete number of nodes in a MANET ... > > ... cohesive flat routing area ... > > ... a single routing region ... > Same comments as above, on term _multihop MANET area_. Three terms for > something not explained in this ID. > I am still confused wat is meant in this section. There is=20 > the term _Peer > MANET Routers_. It is not _connected MANET routers_ /=20 > _connected nodes_ (see > text). I am not sure _MAN Neighbors_ is meant. May be a=20 > _MANET Peer_ is a > potential _MANET Neighbor_ and all _MANET Peers_ are configured for a > _single routing region_. > But reading 2.2. _MANET_, a _MANET_ is a _routing region_ and=20 > _MANETs_ split > and merge due to reachability, so _regions_ are based on=20 > connectivity and > not on configuration. >=20 > Regards, Teco >=20 >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jun 01 17:26:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuEdO-0006nK-Fn; Fri, 01 Jun 2007 17:26:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuEdN-0006by-CV for autoconf@ietf.org; Fri, 01 Jun 2007 17:26:09 -0400 Received: from hpsmtp-eml11.kpnxchange.com ([213.75.38.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuEdM-0006wu-2N for autoconf@ietf.org; Fri, 01 Jun 2007 17:26:09 -0400 Received: from hpsmtp-eml05.kpnxchange.com ([213.75.38.105]) by hpsmtp-eml11.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 1 Jun 2007 23:26:07 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml05.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Jun 2007 23:26:06 +0200 From: "Teco Boot" To: "'Templin, Fred L'" Subject: RE: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Date: Fri, 1 Jun 2007 23:27:00 +0200 Message-ID: <004301c7a493$981550b0$05000100@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.3028 Thread-Index: Acej1kgFrOxL9Fl/RUW36hlYLGdDzgAQ/6sgABuSQ4AAAedEYA== In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED821@XCH-NW-7V2.nw.nos.boeing.com> X-OriginalArrivalTime: 01 Jun 2007 21:26:06.0541 (UTC) FILETIME=[76E7F7D0:01C7A493] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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, What about adding a description on scaling mechanisms in the ID? Can you provide references to IETF documents describing such a technology? Is the difference between subnet and subnetwork somewhere defined clearly? I will check RFC3819, but this one discusses a subnetwork as a L2 segment, although references to L3 areas are mentioned. My concern is what to do if nodes get out of reach of others in the same subnetwork, and nodes member of other subnetworks connects them. It can occur with three nearby nodes and one obstacle. Cheers, Teco > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: vrijdag 1 juni 2007 22:26 > To: Teco Boot; autoconf@ietf.org > Subject: RE: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt > > Hi Teco, > > A term in common use in other context for areas within > a MANET is "subnetwork" which is meant in a way that is > distinct from the term "subnet", i.e., it makes no statement > about IP prefix/netmask assignments. Subnetworks within a > MANET can indeed be connected by inner MANET border routers, > since they are essetially just smaller MANETs within a larger > MANET. So, one way to bound scaling is to bound the sizes of > subnetworks within a MANET. > > Fred > fred.l.templin@boeing.com > > > 8.2 > > > ... complete number of nodes in a MANET ... > > > ... cohesive flat routing area ... > > > ... a single routing region ... > > Same comments as above, on term _multihop MANET area_. Three terms for > > something not explained in this ID. > > I am still confused wat is meant in this section. There is > > the term _Peer > > MANET Routers_. It is not _connected MANET routers_ / > > _connected nodes_ (see > > text). I am not sure _MAN Neighbors_ is meant. May be a > > _MANET Peer_ is a > > potential _MANET Neighbor_ and all _MANET Peers_ are configured for a > > _single routing region_. > > But reading 2.2. _MANET_, a _MANET_ is a _routing region_ and > > _MANETs_ split > > and merge due to reachability, so _regions_ are based on > > connectivity and > > not on configuration. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jun 01 17:44:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuEv1-0008Ds-DS; Fri, 01 Jun 2007 17:44:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuEv0-0008Dk-Sm for autoconf@ietf.org; Fri, 01 Jun 2007 17:44:22 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuEuz-0005sZ-H6 for autoconf@ietf.org; Fri, 01 Jun 2007 17:44:22 -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 l51LiEIN018873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2007 14:44:20 -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 l51LiEIS018444; Fri, 1 Jun 2007 16:44:14 -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 l51Li5g3018094; Fri, 1 Jun 2007 16:44:14 -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, 1 Jun 2007 14:44:10 -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] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Date: Fri, 1 Jun 2007 14:44:09 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED826@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <004301c7a493$981550b0$05000100@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Thread-Index: Acej1kgFrOxL9Fl/RUW36hlYLGdDzgAQ/6sgABuSQ4AAAedEYAABDYAw References: <39C363776A4E8C4A94691D2BD9D1C9A1029ED821@XCH-NW-7V2.nw.nos.boeing.com> <004301c7a493$981550b0$05000100@Teco> From: "Templin, Fred L" To: "Teco Boot" X-OriginalArrivalTime: 01 Jun 2007 21:44:10.0407 (UTC) FILETIME=[FCF0CB70:01C7A495] X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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, Yes, RFC3819 is the IETF reference that I am aware of. I have not done a thorough literature search such that I could provide other references at this time, but I do have plans to look into this. Thanks - Fred fred.l.templin@boeing.com > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: Friday, June 01, 2007 2:27 PM > To: Templin, Fred L > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] I-D=20 > ACTION:draft-ietf-autoconf-manetarch-02.txt=20 >=20 > Hi Fred, >=20 > What about adding a description on scaling mechanisms in the ID? > Can you provide references to IETF documents describing such=20 > a technology? > Is the difference between subnet and subnetwork somewhere=20 > defined clearly? >=20 > I will check RFC3819, but this one discusses a subnetwork as=20 > a L2 segment, > although references to L3 areas are mentioned. >=20 > My concern is what to do if nodes get out of reach of others=20 > in the same > subnetwork, and nodes member of other subnetworks connects=20 > them. It can > occur with three nearby nodes and one obstacle. >=20 > Cheers, Teco >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: vrijdag 1 juni 2007 22:26 > > To: Teco Boot; autoconf@ietf.org > > Subject: RE: [Autoconf] I-D=20 > ACTION:draft-ietf-autoconf-manetarch-02.txt > >=20 > > Hi Teco, > >=20 > > A term in common use in other context for areas within > > a MANET is "subnetwork" which is meant in a way that is > > distinct from the term "subnet", i.e., it makes no statement > > about IP prefix/netmask assignments. Subnetworks within a > > MANET can indeed be connected by inner MANET border routers, > > since they are essetially just smaller MANETs within a larger > > MANET. So, one way to bound scaling is to bound the sizes of > > subnetworks within a MANET. > >=20 > > Fred > > fred.l.templin@boeing.com > >=20 > > > 8.2 > > > > ... complete number of nodes in a MANET ... > > > > ... cohesive flat routing area ... > > > > ... a single routing region ... > > > Same comments as above, on term _multihop MANET area_.=20 > Three terms for > > > something not explained in this ID. > > > I am still confused wat is meant in this section. There is > > > the term _Peer > > > MANET Routers_. It is not _connected MANET routers_ / > > > _connected nodes_ (see > > > text). I am not sure _MAN Neighbors_ is meant. May be a > > > _MANET Peer_ is a > > > potential _MANET Neighbor_ and all _MANET Peers_ are=20 > configured for a > > > _single routing region_. > > > But reading 2.2. _MANET_, a _MANET_ is a _routing region_ and > > > _MANETs_ split > > > and merge due to reachability, so _regions_ are based on > > > connectivity and > > > not on configuration. >=20 >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jun 01 17:45: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 1HuEwG-0008T2-HD; Fri, 01 Jun 2007 17:45:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuEwF-0008Sx-Ea for autoconf@ietf.org; Fri, 01 Jun 2007 17:45:39 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HuEwC-0006en-Vw for autoconf@ietf.org; Fri, 01 Jun 2007 17:45:39 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-8.tower-119.messagelabs.com!1180734336!17273017!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16445 invoked from network); 1 Jun 2007 21:45:36 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-8.tower-119.messagelabs.com with SMTP; 1 Jun 2007 21:45:36 -0000 Received: from az33exr02.mot.com ([10.64.251.232]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l51LjZ3X001180; Fri, 1 Jun 2007 14:45:36 -0700 (MST) Received: from az10vts04 (az10vts04.mot.com [10.64.251.245]) by az33exr02.mot.com (8.13.1/Vontu) with SMTP id l51LjZhU023979; Fri, 1 Jun 2007 16:45:35 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-82.corp.mot.com [10.169.4.82]) by az33exr02.mot.com (8.13.1/8.13.0) with ESMTP id l51LjWkq023956; Fri, 1 Jun 2007 16:45:33 -0500 (CDT) Message-ID: <4660937B.20107@gmail.com> Date: Fri, 01 Jun 2007 23:45:31 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: MANET Router terminology (was: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt) References: <465FE3E3.8080601@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED814@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED814@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000746-2, 01/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Templin, Fred L wrote: >>> MANET Router (MAN) >> I think this may clash with Metropolitan Area Network. Why not >> just saying MANET router or so. > > How about either MAR or MARTR (for Mobile Ad-hoc Router)? I think MAR may clash with a Cisco Mobile Access Router (I may be wrong, it's just vague rememberings). MARTR sounds good but maybe too close to begging for an unfortunate y... Maybe something else yet. > There was also still the point about acronym collision for LFN in the > NEMO terminology. LFN has been used for "Long Fat Network" in the > IETF terminology for a long time, and a satellite link is one example > of an LFN. Was the acronym overlap intentional? Generally speaking, I personally agree the acronym collision for LFN should be solved, and that the easiest way to solve it is to change current usage of NEMO LFN. But, authors of that NEMO terminology draft and a shepherding person pushing this through IESG seem to prefer to just leave it as it is - something that I can understand somehow too when the number of documents is so high planning them is stricter. And no, the LFN acronym overlap was not at all intentional, it just came during a discussion around a table without any worry of long-fat networks. And I'm happy the overlap was revealed, at least we're aware of it. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jun 01 17:59:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuF9t-0007lt-GZ; Fri, 01 Jun 2007 17:59:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuF9s-0007kM-SE for autoconf@ietf.org; Fri, 01 Jun 2007 17:59:44 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuF9r-0002wb-Do for autoconf@ietf.org; Fri, 01 Jun 2007 17:59:44 -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 l51Lxfr4026024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 1 Jun 2007 14:59:42 -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 l51LxfCo021478; Fri, 1 Jun 2007 16:59:41 -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 l51LxQkj020833; Fri, 1 Jun 2007 16:59:40 -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, 1 Jun 2007 14:59: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 Subject: RE: MANET Router terminology (was: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt) Date: Fri, 1 Jun 2007 14:59:38 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED827@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4660937B.20107@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MANET Router terminology (was: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt) Thread-Index: AcekljE1n3K763JqTk6uokBZ8ijWOAAATkHQ References: <465FE3E3.8080601@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED814@XCH-NW-7V2.nw.nos.boeing.com> <4660937B.20107@gmail.com> From: "Templin, Fred L" To: "Alexandru Petrescu" X-OriginalArrivalTime: 01 Jun 2007 21:59:39.0899 (UTC) FILETIME=[26F604B0:01C7A498] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Alex,=20 I am fine with just raising awareness for the short term, and revisiting in the longer term whether a change is needed. For instance, it could be quite common in the future that a NEMO/MANET router would have a connection to a Long Fat Network (LFN) via a satellite link. Thanks - Fred fred.l.templin@boeing.com > Generally speaking, I personally agree the acronym collision for LFN > should be solved, and that the easiest way to solve it is to change > current usage of NEMO LFN. But, authors of that NEMO=20 > terminology draft > and a shepherding person pushing this through IESG seem to prefer to > just leave it as it is - something that I can understand somehow too > when the number of documents is so high planning them is stricter. >=20 > And no, the LFN acronym overlap was not at all intentional,=20 > it just came > during a discussion around a table without any worry of long-fat=20 > networks. And I'm happy the overlap was revealed, at least=20 > we're aware=20 > of it. >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sat Jun 02 06:40: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 1HuR29-0003uQ-JQ; Sat, 02 Jun 2007 06:40:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuR28-0003uL-23 for autoconf@ietf.org; Sat, 02 Jun 2007 06:40:32 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuR27-0004oL-L9 for autoconf@ietf.org; Sat, 02 Jun 2007 06:40:32 -0400 Received: by ug-out-1314.google.com with SMTP id j30so1165748ugc for ; Sat, 02 Jun 2007 03:40:26 -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=rM4XskzsaX2qHJ1gZzeMY5ER/DxLpIEqIWoHNscvp7il+kYbI+sC4m4mpyXC8M+UY0RRnCguCZLn8qh7LDlIYxezBdZhViNADYBjtm3GPXfAsIs5xNj4s7VH96TNGVmlutsrqeBMJfenBfLeRmW1cKeXq3jgC6kKg0JLh+p1sIs= 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=gGIP7GQ8sPWCyrYIrjO8NnrIpUk2a4DWHKvK0d7FZT1nnDwchB8XpIO46BYCC5/bmGmanFfkPGl22hCSUF5kdHazes6mESoGc2d39F5IKvViaCR/fz8PhCzEc/cRxHIuFdqoa5w25XHRWyo0O7/EgrIJ3fV+yz6WVZyEAET1HzY= Received: by 10.78.175.8 with SMTP id x8mr1530062hue.1180780826043; Sat, 02 Jun 2007 03:40:26 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Sat, 2 Jun 2007 03:40:25 -0700 (PDT) Message-ID: <374005f30706020340o5d894bf6o1b835fc5d130137@mail.gmail.com> Date: Sat, 2 Jun 2007 16:10:25 +0530 From: "Ian Chakeres" To: "Teco Boot" Subject: Re: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt In-Reply-To: <002901c7a426$be7946c0$05000100@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <002901c7a426$be7946c0$05000100@Teco> X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 Comments inline. On 6/1/07, Teco Boot wrote: > Hi Ian, Joe and Thomas, > Thanks for the updated ID. Here some comments. > > 4.1. > > Many protocols (e.g. neighbor discovery) do not operate in > > wireless networks with asymmetric reachability. > Is IPv6 ND mentioned? I prefer an exact reference. Done. > 4.2.3. > > To assist in coordinating among a loosely connected set of MANET > > routers, a procedure called flooding is used. MANET flooding consist > > of disseminating a packet to all connected MANET routers. > Here start a MANET pitfall. By introducing a mechanism allowing flooding to > _all connected MANET routers_, scaling of the MANET is bounded. > Adding an option for flooding to parts of the MANET provide a remedy. Sample > mechanisms are _logical areas_ and _inner MANET border routers_ or limit > flooding based on hopcount or path metric. I know such mechanisms could > introduce other problems, like multihop Asymmetric Reachability when path > metric bounds are used. I've changed the text to say """ MANET flooding consist of disseminating a piece of information to a connected set of MANET routers. """ I believe that no MANET WG protocols require complete MANET wide flooding. I think that the new text also captures your intent. > > > 5. > > MANET interfaces, forming a multihop MANET area, may use a site > > prefix; > The term _multihop MANET area_ is not defined in the ID. The term _logical > areas_ I used above could be meant. I've removed the bullet all together. > 8.1 > > In MANET, nodes might assume a service is available locally (within > > one IP hop) or within a particular scope (one or more IP hops - MANET, > > site, global). > As mentioned in 7, cross layer information could be available and such > information could be far more important than hop-count. A 2-hop error-free > and lightly loaded 100Mbps path could be qualified as better related to a > single hop congested error-prone 2400bps link. I did not understand your suggestion. Can you please provide me with a clearer textual "fix"? > 8.2 > > ... complete number of nodes in a MANET ... > > ... cohesive flat routing area ... > > ... a single routing region ... > Same comments as above, on term _multihop MANET area_. Three terms for > something not explained in this ID. I believe I've cut all the offending text. > I am still confused wat is meant in this section. There is the term _Peer > MANET Routers_. It is not _connected MANET routers_ / _connected nodes_ (see > text). I am not sure _MAN Neighbors_ is meant. May be a _MANET Peer_ is a > potential _MANET Neighbor_ and all _MANET Peers_ are configured for a > _single routing region_. I've changed the title to "Number of MANET Routers in a MANET. Is that clearer? This section gives people an idea of the current state of MANET routing. We can safely say that MANETs can scale up to a few hundred routers directly interconnected in one routing region (configured or connected). For larger networks, hierarchy (not flat) still needs to be used. > But reading 2.2. _MANET_, a _MANET_ is a _routing region_ and _MANETs_ split > and merge due to reachability, so _regions_ are based on connectivity and > not on configuration. A MANET's routing region is based on both connectivity and configuration. Thanks for the comments. Ian _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sat Jun 02 07:32:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuRqS-0008QI-8Y; Sat, 02 Jun 2007 07:32:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuRqQ-0008KO-VB for autoconf@ietf.org; Sat, 02 Jun 2007 07:32:30 -0400 Received: from ug-out-1314.google.com ([66.249.92.168]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuRqQ-0001Pr-3X for autoconf@ietf.org; Sat, 02 Jun 2007 07:32:30 -0400 Received: by ug-out-1314.google.com with SMTP id j30so1181598ugc for ; Sat, 02 Jun 2007 04:32:29 -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=PutIxGMJ3q1quT1zJBvH/wAbaZMfaOax5gtHDBf81zs8FypIUX0pyEnpFPbpQYdVlPqG50nXM951EVkNRbWalfaqPmmuA+TTdx6ksGK7BJwh/KwEsRPfIvsV5YCbjBrCNrykomleIb9ExKuQJ/ekvAFi3J8fa+rE/a5exm7vFeU= 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=QOUw1uQQhEbHpaJ6sIZr1A9uYz5zUJDX4hNBorhvUx5lk/w67ZeKvlphsLrTifAIIVqS/Upj18oxTkT9Ve6xOb1m2xhsHmCtoF8qWhiG92hv49t/vjVYZAlan232+Rf0vXYWC+nSujlTBIa5OLHDMYmShX1cf49QVrC+3nHGijA= Received: by 10.78.195.9 with SMTP id s9mr1512718huf.1180783949212; Sat, 02 Jun 2007 04:32:29 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Sat, 2 Jun 2007 04:32:29 -0700 (PDT) Message-ID: <374005f30706020432m6dd817e1q881da76fbf4d9222@mail.gmail.com> Date: Sat, 2 Jun 2007 17:02:29 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt In-Reply-To: <465FE3E3.8080601@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <465FE3E3.8080601@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3be09dac38eaa50f02d21c7fcee1128c 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 Comments inline. On 6/1/07, Alexandru Petrescu wrote: > Hi, I have read large parts of the draft > draft-ietf-autoconf-manetarch-02.txt > > I generally agree with the draft intention, and especially with the > parts that say that IP addressing model is the same as classical IP > addressing model. > > > These routers may communicate over wireless links with asymmetric > > reachability ... We mean asymmetric reachability, as defined in the terminology section. More below with your other comments. > I think you mean asymmetric path characteristics? Like 10mb/1024mtu > downlink and 2mb/512mtu uplink? Because asymmetric _reachability_ > sounds to me like yes-no like sattelite uni-directional links. I don't > think udlr sattelite links are considered in MANET. > > Are sattelite links considered by MANET? > > Are there other wireless unidirectional links considered by MANET? > (DVB-H terestrial, RFID, other?) > > > Asymmetric Reachability > > > > A link where non-reflexive and/or non-transitive reachability is part > > of normal operation. Non-reflexive reachability means that packets > > from X reach Y but packets from Y don't reach X. > > I think this is the case only for sattelite wireless links. Is there > another wireless link that has this property? All wireless links I can > think of (2.4GHz WiFi, WLAN in general, IrDA, bluetooth) are "reflexive" > rechability in this sense. Is there another? Most of these links are not necessarily reflexive. Though they are generally used only when the reflexive property is fulfilled. Most of the wireless technologies you mention above exhibit non-reflexive characteristics given certain conditions. For example, asymmetric transmission power in IEEE 802.11 equipment. > > Non- transitive reachability means packets from X reach Y, and > > packets from Y reach Z, but packets from X don't reach Z. Many radio/ > > wireless interfaces exhibit these properties. > > Ok, but this doesn't sound as asymmetric, not to me. It is the > well-known hidden terminal problem. I think we should state that this > is the hidden terminal problem. I think the term "hidden terminal problem" is too specific, as it excludes that this case could occur in non-wireless networks also. For example, poor performing ethernet cables between far devices. Furthermore, the term asymmetric reachability is "well" defined in several RFCs already. > > Neighbor > > > > If node X can directly exchange IP packets with node Y, then node Y > > is node X's neighbor. Packet reception characteristics are often > > used to assist devices in determining the quality of neighbors' > > communication. > > I think here we should at least refer to RFC2461's definition of > neighbors which is 'nodes attached to the same link'. The term link and subnet are extermely overloaded terms. Given the characteristics of MANET, I think the existing definition captures what we are trying to describe. > > Note that an anycast address is syntactically indistinguishable from > > a unicast address. Thus, nodes sending packets to anycast addresses > > don't generally know that an anycast address is being used. > > In a sense yes, anycast addresses are syntactically indistinguishable > from unicast addresses, in that they're IPv6 128bit addresses > represented textually like any unicast address. However, at least some > if not all anycast addresses have a IANA-reserved syntax. Thus the > node sending a packet to a anycast address _does_ know that an anycast > address is being used. I could not find anycast in the text, I think this is a copy/paste error. > > Full-Broadcast Interface (FBI) > > > > A broadcast interface with reflexive and transitive reachability. All > > nodes on the interface can send and receive IP packets directly, all > > nodes are symmetric neighbors. An Ethernet segment is an example of > > a FBI. > > I think you mean "a wired 802.3 Ethernet" is an example of FBI. Because > WiFi 802.11 does not have this symmetric property: two MSs under a AP > can't communicate directly. At the IP layer two clients on the same IP (link/subnet) communicate directly. The clients assume a FBI and the AP(s) try to give the view of a FBI. > Then also, why not defining a Multicast Interface? A multicast > interface is one that supports link-layer multicast. If you feel this term is needed, I will include this term. Just let me know. > > Border Router (BR) > > > > a router that participates in multiple routing regions, and often > > multiple routing protocols. A BR defines the border between its > > multiple routing regions. A BR is responsible for presenting a > > consistent picture of the nodes reachable through itself to each > > routing region. A BR determines the routing information to propagate > > between different routing regions. > > Due to similarity, maybe we should refer to OSPF's definition of an Area > Border Router and BGP's definition of an AS border router. > > > MANET Router (MAN) > > I think this may clash with Metropolitan Area Network. Why not just > saying MANET router or so. I had changed MR to MAN specifically to address collision with other terminology. I need a short version for diagrams. Do you think MAR is better? If you have another better suggestion - please provide it. > > MANET interfaces are defined as interfaces that demonstrate > > asymmetric reachability and/or neighbor addresses that are not known > > a priori. > > I can understand the first part of the phrase emplying the term > asymmetric reachability if it were expanded. It's easier to grasp if it > says that MANET interfaces can be unidirectional (if we agree sattelite > is part of MANET) and can have the hidden terminal problem. Or that a > MANET interface has asymmetric dl/ul (download/upload) link characteristics. > > I do not understand the last part of the phrase ("neighbor addresses > that are not known a priori"). Classic IP links/interfaces assume that all the devices within the same IP prefix/subnet are reachable in one IP hop. In a MANET, routers often cannot make assumptions about who will be on this link - as they are mobile and it will be changing. That is the concept I'm trying to capture. If you have a suggestion on how to get this point across please provide it. > > A MANET router may participate in routing on zero or more MANET > > interfaces. > > If a MANET router does no routing on a MANET interface (or participates > in routing on zero MANET interfaces) then it's no longer a MANET router, > right? A classic IP interfaces is a MANET interface. That is, all classic IP interfaces by definition are at least capable of MANET interface's characteristics. There is nothing stopping or hindering people from running MANET routing protocols over classic IP interfaces. This is the idea, I was trying to capture. If you have a clear way to present this point, please make a suggestion. > > MANET router may also have zero or more classic IP interfaces to > > which other nodes may connect; i.e. the router may be responsible for > > several IP prefixes. > > Sorry, it does not follow. That i.e. ("id est", lat.) makes me think > that only because the MANET router has some classic IP interfaces it is > in charge for some IP prefixes, and thus maybe if it has no classic IP > interfaces then it is _not_ in charge for any IP prefix; this is > obviously not true, because if MANET router has a MANET interface then > it necessarily has an IP prefix on it. A MANET router could function using only link local addresses and therefore not necessarily be in charge of any classic IP prefixes. > > <~~~~~~+~~~~~~> Routing-MANET > > | Interface(s) > > ''''''''''|''''''''''''''''' > > ' +-------|--------------+ ' > > ' | Router Functionality |................... > > ' +-------+-+------------+ ' Routing-Classic > > ' : : ' IP Interface(s) > > ' MANET : +-----------+ ' > > ' Router : | Internal | ' > > ' : |Addressable| ' > > ' : |Host Logic | ' > > ' : | (IAH) | ' > > ' : +-----------+ ' > > '''''''''':''''''''''''''''' > > : Nodes that live behind the router > > +......+.........+ ============ > > : : = : = > > +-+-+ +----+----+ =CLASSIC IP= > > | N | * * * | Node(s) | =INTERFACES= > > +---+ +---------+ ============ > > This figure is unclear, because there are classic IP interfaces both on > the right and on the bottom of the router. Not sure what the ":" means > either. Looks like an elipsis (1, 2...3) but then "***" seems to be used > for same meaning. I am trying to show that some classic IP interfaces are participating in routing, while others are "behind" the router. That is the router is responsible for participating in a routing protocol on these prefixes behalf. > > In MANETs there are several architectural scopes. We define the > > following scopes: > > > > MANET Neighbors a set of MANET routers that is reachable via one IP > > hop, reachable via link-local messaging. > > Is it the same as the link-local scope? The link-local scope is defined > for IPv6 in a certain RFC. I've added a citation to the IPv6 scoped address arch. > > MANET N-Neighborhood a set of MANET routers that is reachable via > > N-hops. These routers usually have a large number of common > > neighbors and may directly compete for the same shared wireless > > resources. > > This is very difficult to grasp. Neighbors (in terms of rfc2461) are > always on the same link. Here you're saying that MANET neighbors can be > on different links. I find this difficult to grasp conceptually, but it > may be only me. The term link is very overloaded and I've tried to avoid using it. The term neighborhood is trying to capture the idea that MANET routers often need to coordinate and know about MANET routers that are more than one hop away. > > 4.2.3. MANET Membership > > I think it is difficult to talk about 'membership' like that, referring > to a node belonging or not to a mobile area network. > > BEcause, 'membership' is widely used in multicast contexts, see MLD and > IGMP for example, and it can easily lead to clashes. At several places > in the draft I've been confused by this 'membership' dual meaning. Do you have a suggestion? > > A MANET router can be delegated zero or more prefixes. > > I have difficulties in understanding this phrase. I generally agree that > a MANET router is in charge of routing for one or more prefixes. > > If it is zero prefixes then it's not a router. If a router uses only it's link local addresses, it can still be a router and participate in routing. > If it is 'delegated' then DHCP-PD was used. > > I think the use of the words 'delegated' and 'zero' in that phrase is > problematic to my reading. > > > If a MANET router is delegated a prefix p::, this prefix can be > > assigned to its classic IP link(s), and nodes can be assigned > > addresses from within this prefix, and configured with this prefix as > > illustrated in figure 6. The figure does not get into the specific size of the prefix(es) assigned. > This text not only is in disagreement with the figure but also incorrect > in itself. I seem to be missing something here or not understanding. Perhaps you can send me a fix for the figure or text is it the use of :: that is wrong? > If prefix p::/48 is administratively assigned to a router then it can > not be (or is usually not) assigned as such on each of its interfaces. > Prefixes derived from that p::/48 are assigned to its interfaces (as the > figure correctly shows p:1:: p:2:: etc - it should be actually p:1::/64 > or so)). The router must assign the prefix(es) appropriately on classic IP interfaces. > Also, this case of a unique p::/48 administratively assigned to a router > is a particular case. The more general (and 'classic' in my > understanding) case is where different prefixes are assigned to each > link to which the router is attached, and these prefixes have nothing in > common, but only the first three bits maybe. E.g. MANET Router with > three MANET interfaces is administratively assigned the prefixes p::/48, > q::/48 and r::/48 and the interfaces are configured with addresses in > prefixes p:1::/64, q:1::/64 and r:1::/64. > > > o MANET interfaces, forming a multihop MANET area, may use a site > > prefix; > I've cut this bullet. Ian _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sat Jun 02 17:14: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 1HuavK-0004Vm-36; Sat, 02 Jun 2007 17:14:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HuavI-0004Vf-C8 for autoconf@ietf.org; Sat, 02 Jun 2007 17:14:08 -0400 Received: from hpsmtp-eml12.kpnxchange.com ([213.75.38.112]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HuavF-00056e-Os for autoconf@ietf.org; Sat, 02 Jun 2007 17:14:08 -0400 Received: from hpsmtp-eml07.kpnxchange.com ([213.75.38.107]) by hpsmtp-eml12.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 23:14:04 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml07.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 2 Jun 2007 23:14:03 +0200 From: "Teco Boot" To: "'Ian Chakeres'" Subject: RE: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Date: Sat, 2 Jun 2007 23:14:58 +0200 Message-ID: <005101c7a55b$141cfec0$05000100@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.3028 Thread-Index: AcelAm7AXlqKXsWRS26/zgAsiEPrTwAVKg7Q In-Reply-To: <374005f30706020340o5d894bf6o1b835fc5d130137@mail.gmail.com> X-OriginalArrivalTime: 02 Jun 2007 21:14:03.0881 (UTC) FILETIME=[F2948D90:01C7A55A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 Ian, comments inline. > > 8.1 > > > In MANET, nodes might assume a service is available locally (within > > > one IP hop) or within a particular scope (one or more IP hops - MANET, > > > site, global). > > As mentioned in 7, cross layer information could be available and such > > information could be far more important than hop-count. A 2-hop error- > free > > and lightly loaded 100Mbps path could be qualified as better related to > a > > single hop congested error-prone 2400bps link. > > I did not understand your suggestion. Can you please provide me with a > clearer textual "fix"? [Teco] Suggested text: In MANET, nodes might assume a service is available locally (within one IP hop) or within a particular scope (one or more IP hops - MANET, site, global) or with a certain path metric. > > I am still confused wat is meant in this section. There is the term > _Peer > > MANET Routers_. It is not _connected MANET routers_ / _connected nodes_ > (see > > text). I am not sure _MAN Neighbors_ is meant. May be a _MANET Peer_ is > a > > potential _MANET Neighbor_ and all _MANET Peers_ are configured for a > > _single routing region_. > > I've changed the title to "Number of MANET Routers in a MANET. Is that > clearer? [Teco] OK. In the current document, scaling options for MANET using hierarchy or other models are not described. A reason could be current IETF MANET protocols does not implement such (I could miss something here). > > This section gives people an idea of the current state of MANET > routing. We can safely say that MANETs can scale up to a few hundred > routers directly interconnected in one routing region (configured or > connected). For larger networks, hierarchy (not flat) still needs to > be used. > > > But reading 2.2. _MANET_, a _MANET_ is a _routing region_ and _MANETs_ > split > > and merge due to reachability, so _regions_ are based on connectivity > and > > not on configuration. > > A MANET's routing region is based on both connectivity and configuration. [Teco] Suggestion for 2.2: MANET a configured routing region consisting of a set of MANET routers that is reachable via one or more MANET router hops. If a MANET connects to other routing regions, its border is defined by Border Routers. I will check the current MANET protocols on this configuration option. It could be missing. I am aware that isolation could be implemented using L2 parameters or security configuration. Quite unacceptable mechanisms. What do you think? Regards, Teco _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Sat Jun 02 22:42:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hug2u-0005AF-2Q; Sat, 02 Jun 2007 22:42:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hug2s-0005AA-5T for autoconf@ietf.org; Sat, 02 Jun 2007 22:42:18 -0400 Received: from ug-out-1314.google.com ([66.249.92.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hug2r-0000Qx-Nl for autoconf@ietf.org; Sat, 02 Jun 2007 22:42:18 -0400 Received: by ug-out-1314.google.com with SMTP id j30so1413462ugc for ; Sat, 02 Jun 2007 19:42:17 -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=LuWem6MPN/MTOGVUFaost4pql9mn7BfZjEXcWK/nVojZy1T/B8C878k4CWVUiaTrRi1JD8whsIeL73SJrPhAoItiHfUehzxB9w6qC0WeJwYqXNgx+PmtftB5MCn221+GTbQdJf8OX51sTpEh0u/Ml69WjO58gu9G9l8vtmqe5xY= 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=c4TE78nwjp8k+GuCqEcgo9dFmtGLTVypgFbp5zsFk312AHvxugsg2EBbc5OYANQJ3URHL5nHKyjEjKNkxJKvOcQiq8zbHDI50eLXJrNUYyAY62OEhiXwVMwHy9E9jQo3y0Kl/J96VR/MEjzZq1BLsFa8ivy836rhgutUB9kKloQ= Received: by 10.78.175.8 with SMTP id x8mr1667077hue.1180838536763; Sat, 02 Jun 2007 19:42:16 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Sat, 2 Jun 2007 19:42:16 -0700 (PDT) Message-ID: <374005f30706021942q6a3a8260k96e79708f6bb01fa@mail.gmail.com> Date: Sun, 3 Jun 2007 08:12:16 +0530 From: "Ian Chakeres" To: "Teco Boot" Subject: Re: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt In-Reply-To: <005101c7a55b$141cfec0$05000100@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <374005f30706020340o5d894bf6o1b835fc5d130137@mail.gmail.com> <005101c7a55b$141cfec0$05000100@Teco> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 Comments inline. On 6/3/07, Teco Boot wrote: > Hi Ian, comments inline. > > > > 8.1 > > > > In MANET, nodes might assume a service is available locally (within > > > > one IP hop) or within a particular scope (one or more IP hops - MANET, > > > > site, global). > > > As mentioned in 7, cross layer information could be available and such > > > information could be far more important than hop-count. A 2-hop error- > > free > > > and lightly loaded 100Mbps path could be qualified as better related to > > a > > > single hop congested error-prone 2400bps link. > > > > I did not understand your suggestion. Can you please provide me with a > > clearer textual "fix"? > > [Teco] > Suggested text: > In MANET, nodes might assume a service is available locally (within one IP > hop) or within a particular scope (one or more IP hops - MANET, site, > global) or with a certain path metric. I understand what you're getting at now, but I think that the "certain path metric" case is covered by the above two cases. Or perhaps, the path metric case doesn't fit with the other cases. The concept I am trying to represent is that services might not be local - for example, nodes might not be able to assume that a DHCP server is run on every link, but they might need to use another protocol (e.g. protocols developed by Autoconf). I do like the idea that a message could be scoped by something other than hoplimit or administrative configuration, but I think that is a different concept. I also think the idea of a new scoping mechanism is not MANET specific. > > > I am still confused wat is meant in this section. There is the term > > _Peer > > > MANET Routers_. It is not _connected MANET routers_ / _connected nodes_ > > (see > > > text). I am not sure _MAN Neighbors_ is meant. May be a _MANET Peer_ is > > a > > > potential _MANET Neighbor_ and all _MANET Peers_ are configured for a > > > _single routing region_. > > > > I've changed the title to "Number of MANET Routers in a MANET. Is that > > clearer? > > [Teco] > OK. > In the current document, scaling options for MANET using hierarchy or other > models are not described. A reason could be current IETF MANET protocols > does not implement such (I could miss something here). The MANET WG protocols can use hierarchy, just like other routing protocols. > > This section gives people an idea of the current state of MANET > > routing. We can safely say that MANETs can scale up to a few hundred > > routers directly interconnected in one routing region (configured or > > connected). For larger networks, hierarchy (not flat) still needs to > > be used. > > > > > But reading 2.2. _MANET_, a _MANET_ is a _routing region_ and _MANETs_ > > split > > > and merge due to reachability, so _regions_ are based on connectivity > > and > > > not on configuration. > > > > A MANET's routing region is based on both connectivity and configuration. > > [Teco] > Suggestion for 2.2: > MANET > a configured routing region consisting of a set of MANET routers that > is reachable via one or more MANET router hops. If a MANET connects > to other routing regions, its border is defined by Border Routers. > > I will check the current MANET protocols on this configuration option. It > could be missing. I am aware that isolation could be implemented using L2 > parameters or security configuration. Quite unacceptable mechanisms. What do > you think? If the configured border occurs on the edge with a wire I don't think there is a problem. For example a border router connecting a MANET to the Internet. If the configured border occurs on a wireless MANET interface things are more complex. This type of configuration is not explicitly addressed at L3. There are many options to support this feature. One option I have discussed is for packets or messages (using PacketBB) to contain a MANET ID (TLV), thereby allowing devices to identify the particular routing region for the packet/message. I'm not sure whether the architecture document needs to talk about this particular concept. Do you think it should be flushed out in the MANET arch document? Ian _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Jun 04 09:31:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvCev-0007Cp-Jh; Mon, 04 Jun 2007 09:31:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvCep-0007CQ-31 for autoconf@ietf.org; Mon, 04 Jun 2007 09:31:39 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvCeo-0004Oz-FX for autoconf@ietf.org; Mon, 04 Jun 2007 09:31:39 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1180963897!15325173!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 9139 invoked from network); 4 Jun 2007 13:31:37 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-119.messagelabs.com with SMTP; 4 Jun 2007 13:31:37 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l54DVbUP007031; Mon, 4 Jun 2007 06:31:37 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id l54DVaQi029643; Mon, 4 Jun 2007 08:31:37 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id l54DVZBS029606; Mon, 4 Jun 2007 08:31:35 -0500 (CDT) Message-ID: <46641436.20805@gmail.com> Date: Mon, 04 Jun 2007 15:31:34 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt References: <465FE3E3.8080601@gmail.com> <374005f30706020432m6dd817e1q881da76fbf4d9222@mail.gmail.com> In-Reply-To: <374005f30706020432m6dd817e1q881da76fbf4d9222@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000746-2, 01/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 58b614506802734014829a093beb6879 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 Ian, thanks for your message. Ian Chakeres wrote: >>> Asymmetric Reachability >>> >>> A link where non-reflexive and/or non-transitive reachability is >>> part of normal operation. Non-reflexive reachability means that >>> packets from X reach Y but packets from Y don't reach X. >> >> I think this is the case only for sattelite wireless links. Is >> there another wireless link that has this property? All wireless >> links I can think of (2.4GHz WiFi, WLAN in general, IrDA, >> bluetooth) are "reflexive" rechability in this sense. Is there >> another? > > Most of these links are not necessarily reflexive. Though they are > generally used only when the reflexive property is fulfilled. > > Most of the wireless technologies you mention above exhibit > non-reflexive characteristics given certain conditions. For example, > asymmetric transmission power in IEEE 802.11 equipment. I think transmission power is not a parameter at IP level. I think the IP stack doesn't know the transmission power, which may indeed be asymmetric. If you thought asymmetric transmission power, as a characteristic of asymmetricity, I think this should be mentioned in the terminology definition of asymetricity. I personally think asymmetricity in terms of bandwidth and MTU. This has large impacts on IP stack, including TCP. >>> Non- transitive reachability means packets from X reach Y, and >>> packets from Y reach Z, but packets from X don't reach Z. Many >>> radio/ wireless interfaces exhibit these properties. >> >> Ok, but this doesn't sound as asymmetric, not to me. It is the >> well-known hidden terminal problem. I think we should state that >> this is the hidden terminal problem. > > I think the term "hidden terminal problem" is too specific, as it > excludes that this case could occur in non-wireless networks also. I'm almost sure the hidden terminal problem only shows in wireless links. > For example, poor performing ethernet cables between far devices. But common :-) Ethernet has precise specs saying how long the cables could be before repeaters :-) Not respecting these specs doesn't turn them into special links but into faulty links :-) > Furthermore, the term asymmetric reachability is "well" defined in > several RFCs already. Which ones? The ones talking TCP? I agree with those, should we reference them. >>> Neighbor >>> >>> If node X can directly exchange IP packets with node Y, then node >>> Y is node X's neighbor. Packet reception characteristics are >>> often used to assist devices in determining the quality of >>> neighbors' communication. >> >> I think here we should at least refer to RFC2461's definition of >> neighbors which is 'nodes attached to the same link'. > > The term link and subnet are extermely overloaded terms. Given the > characteristics of MANET, I think the existing definition captures > what we are trying to describe. I think this is the kind of perspective I completely disagree with, sorry and a smiley :-) I agree that link and subnet are so overloaded. But a new definition like above is going to overload it even more :-) Since 2461-ND runs ok over same wireless technologies over which MANET protocols have been run I think it makes a lot of sense to reuse ND terminology. I'm not suggesting to use the 'neighbor' definition that I only myself understand, but the definition that is already there in ND, that I haven't invented. >>> Note that an anycast address is syntactically indistinguishable >>> from a unicast address. Thus, nodes sending packets to anycast >>> addresses don't generally know that an anycast address is being >>> used. >> >> In a sense yes, anycast addresses are syntactically >> indistinguishable from unicast addresses, in that they're IPv6 >> 128bit addresses represented textually like any unicast address. >> However, at least some if not all anycast addresses have a >> IANA-reserved syntax. Thus the node sending a packet to a anycast >> address _does_ know that an anycast address is being used. > > I could not find anycast in the text, I think this is a copy/paste > error. Certainly a copy/paste error. Sorry about it. The comment is still valid but I think it pertains to rfc2461 instead (not to draft-ietf-autoconf-manetarch-02.txt). >>> Full-Broadcast Interface (FBI) >>> >>> A broadcast interface with reflexive and transitive reachability. >>> All nodes on the interface can send and receive IP packets >>> directly, all nodes are symmetric neighbors. An Ethernet segment >>> is an example of a FBI. >> >> I think you mean "a wired 802.3 Ethernet" is an example of FBI. >> Because WiFi 802.11 does not have this symmetric property: two MSs >> under a AP can't communicate directly. > > At the IP layer two clients on the same IP (link/subnet) communicate > directly. YEs. > The clients assume a FBI and the AP(s) try to give the view > of a FBI. YEs. In this sense, all interfaces are fully-broadcast, there's always an entity helping give that view. I mean there's no interface (other than UDLR) that is not fully-broadcast. Did you mean UDLR? >> Then also, why not defining a Multicast Interface? A multicast >> interface is one that supports link-layer multicast. > > If you feel this term is needed, I will include this term. Just let > me know. Yes, multicast-capable link layers and interfaces, like IEEE WLAN or under-development 802.16 multicast-capable links are and can be easily accommodated by IPv6. I think whenever talking IPv6 protocol (for MANET, AUTOCONF, and so on) we should talk multicast and less broadcast (broadcast being a particular and less mature case of multicast). >>> Border Router (BR) >>> >>> a router that participates in multiple routing regions, and often >>> multiple routing protocols. A BR defines the border between its >>> multiple routing regions. A BR is responsible for presenting a >>> consistent picture of the nodes reachable through itself to each >>> routing region. A BR determines the routing information to >>> propagate between different routing regions. >> >> Due to similarity, maybe we should refer to OSPF's definition of an >> Area Border Router and BGP's definition of an AS border router. >> >>> MANET Router (MAN) >> >> I think this may clash with Metropolitan Area Network. Why not >> just saying MANET router or so. > > I had changed MR to MAN specifically to address collision with other > terminology. I need a short version for diagrams. > > Do you think MAR is better? > > If you have another better suggestion - please provide it. MANET router. >>> MANET interfaces are defined as interfaces that demonstrate >>> asymmetric reachability and/or neighbor addresses that are not >>> known a priori. >> >> I can understand the first part of the phrase emplying the term >> asymmetric reachability if it were expanded. It's easier to grasp >> if it says that MANET interfaces can be unidirectional (if we agree >> sattelite is part of MANET) and can have the hidden terminal >> problem. Or that a MANET interface has asymmetric dl/ul >> (download/upload) link characteristics. >> >> I do not understand the last part of the phrase ("neighbor >> addresses that are not known a priori"). > > Classic IP links/interfaces assume that all the devices within the > same IP prefix/subnet are reachable in one IP hop. In a MANET, > routers often cannot make assumptions about who will be on this link > - as they are mobile and it will be changing. That is the concept I'm > trying to capture. If you have a suggestion on how to get this point > across please provide it. I think I'm more suggesting that MANET protocols have nothing to do with asymmetric links (as long as UDLR and sattelite is not used). Asymmetric links are important to TCP I believe, and to IPv6-over-foo protocols, but not much to MANET protocols... I'm generally opposing the idea that asymmetric links are for MANET. >>> A MANET router may participate in routing on zero or more MANET >>> interfaces. >> >> If a MANET router does no routing on a MANET interface (or >> participates in routing on zero MANET interfaces) then it's no >> longer a MANET router, right? > > A classic IP interfaces is a MANET interface. That is, all classic IP > interfaces by definition are at least capable of MANET interface's > characteristics. There is nothing stopping or hindering people from > running MANET routing protocols over classic IP interfaces. This is > the idea, I was trying to capture. If you have a clear way to present > this point, please make a suggestion. My understanding is that there is no special 'MANET interface'. Asymmetricity is for TCP and for MAC. I think also, as you, that MANET protocols can run over 'classical' IP interfaces. >>> MANET router may also have zero or more classic IP interfaces to >>> which other nodes may connect; i.e. the router may be responsible >>> for several IP prefixes. >> >> Sorry, it does not follow. That i.e. ("id est", lat.) makes me >> think that only because the MANET router has some classic IP >> interfaces it is in charge for some IP prefixes, and thus maybe if >> it has no classic IP interfaces then it is _not_ in charge for any >> IP prefix; this is obviously not true, because if MANET router has >> a MANET interface then it necessarily has an IP prefix on it. > > A MANET router could function using only link local addresses and > therefore not necessarily be in charge of any classic IP prefixes. Not sure what you mean... a classical router can indeed work if it only had link-local addresses on its interfaces but classical being it it has different prefixes on these interfaces such that it can route otherwise it's not classical and it doesn't route. >> This figure is unclear, because there are classic IP interfaces >> both on the right and on the bottom of the router. Not sure what >> the ":" means either. Looks like an elipsis (1, 2...3) but then >> "***" seems to be used for same meaning. > > I am trying to show that some classic IP interfaces are participating > in routing, while others are "behind" the router. That is the router > is responsible for participating in a routing protocol on these > prefixes behalf. Thanks for the explanation. >>> In MANETs there are several architectural scopes. We define the >>> following scopes: >>> >>> MANET Neighbors a set of MANET routers that is reachable via one >>> IP hop, reachable via link-local messaging. >> >> Is it the same as the link-local scope? The link-local scope is >> defined for IPv6 in a certain RFC. > > I've added a citation to the IPv6 scoped address arch. Thanks. >>> MANET N-Neighborhood a set of MANET routers that is reachable via >>> N-hops. These routers usually have a large number of common >>> neighbors and may directly compete for the same shared wireless >>> resources. >> >> This is very difficult to grasp. Neighbors (in terms of rfc2461) >> are always on the same link. Here you're saying that MANET >> neighbors can be on different links. I find this difficult to grasp >> conceptually, but it may be only me. > > The term link is very overloaded and I've tried to avoid using it. I think if you use the 'neighbor' term from ND then it's fine, to my reading, IMHO. I don't think we avoid overloading by overloading even more. I think (but not sure) that you may think, that 'neighbors' in OSPF terms is different than 'neighbors' in ND terms. I personally think Neighbor is same OSPF or ND. In this case there's no overloading. That's why if we referred to both OSPF and ND definitions of 'neighbor' then we're probably fine. But this is just a speculation on my side. > The term neighborhood is trying to capture the idea that MANET > routers often need to coordinate and know about MANET routers that > are more than one hop away. > >>> 4.2.3. MANET Membership >> >> I think it is difficult to talk about 'membership' like that, >> referring to a node belonging or not to a mobile area network. >> >> BEcause, 'membership' is widely used in multicast contexts, see MLD >> and IGMP for example, and it can easily lead to clashes. At several >> places in the draft I've been confused by this 'membership' dual >> meaning. > > Do you have a suggestion? First of all, if the problem is to find out who are the members of MANET then determining the MANET's membership - just use MLD. If on the other hand we want to say that when we need to find out who are the members of MANET then we should use MLD, then it's good too. However, the stance of the section seems to be to motivate the use of flooding. To which I can not disagree. So I'm in a position where I better abstain to suggest anything, sorry. >>> A MANET router can be delegated zero or more prefixes. >> >> I have difficulties in understanding this phrase. I generally agree >> that a MANET router is in charge of routing for one or more >> prefixes. >> >> If it is zero prefixes then it's not a router. > > If a router uses only it's link local addresses, it can still be a > router and participate in routing. Routing between what and what? >> This text not only is in disagreement with the figure but also >> incorrect in itself. > > I seem to be missing something here or not understanding. > Perhaps you can send me a fix for the figure or text > > is it the use of :: that is wrong? Maybe easier is to just picture an example MANET Router that you think most MANET people have run into? Instead of trying to generalize? A real example with real prefixes? And just state that as an example. >> If prefix p::/48 is administratively assigned to a router then it >> can not be (or is usually not) assigned as such on each of its >> interfaces. Prefixes derived from that p::/48 are assigned to its >> interfaces (as the figure correctly shows p:1:: p:2:: etc - it >> should be actually p:1::/64 or so)). > > The router must assign the prefix(es) appropriately on classic IP > interfaces. YEs, I agree with appropriately. Do you think your description can match a classical router with two interfaces and whose two prefixes are completely different? (the two prefixes having only 3 first common bits). I don't think your description can match such a router, because a P::/3 will never be assigned to a MANET router; however, two prefixes P::/64 can Q::/64 could very well be assigned to the interfaces to which this router connects. Not sure I made myself clear. If not then I'll just give it up. >> Also, this case of a unique p::/48 administratively assigned to a >> router is a particular case. The more general (and 'classic' in my >> understanding) case is where different prefixes are assigned to >> each link to which the router is attached, and these prefixes have >> nothing in common, but only the first three bits maybe. E.g. MANET >> Router with three MANET interfaces is administratively assigned the >> prefixes p::/48, q::/48 and r::/48 and the interfaces are >> configured with addresses in prefixes p:1::/64, q:1::/64 and >> r:1::/64. >> >>> o MANET interfaces, forming a multihop MANET area, may use a >>> site prefix; >> > > I've cut this bullet. Thanks, I agree. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Jun 04 10:24:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvDTs-0006VK-Jj; Mon, 04 Jun 2007 10:24:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvDTs-0006VF-1p for autoconf@ietf.org; Mon, 04 Jun 2007 10:24:24 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvDTr-0004Ji-Kk for autoconf@ietf.org; Mon, 04 Jun 2007 10:24:24 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l54EOEi7015271 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Jun 2007 09:24:19 -0500 (CDT) 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 l54EOEHX004740; Mon, 4 Jun 2007 09:24:14 -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 l54ENmES003748; Mon, 4 Jun 2007 09:24:13 -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, 4 Jun 2007 07:24:11 -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] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Date: Mon, 4 Jun 2007 07:24:10 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED82C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED826@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Thread-Index: Acej1kgFrOxL9Fl/RUW36hlYLGdDzgAQ/6sgABuSQ4AAAedEYAABDYAwAIdXPDA= References: <39C363776A4E8C4A94691D2BD9D1C9A1029ED821@XCH-NW-7V2.nw.nos.boeing.com><004301c7a493$981550b0$05000100@Teco> <39C363776A4E8C4A94691D2BD9D1C9A1029ED826@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Teco Boot" X-OriginalArrivalTime: 04 Jun 2007 14:24:11.0423 (UTC) FILETIME=[0528C2F0:01C7A6B4] X-Spam-Score: 0.0 (/) X-Scan-Signature: 22bbb45ef41b733eb2d03ee71ece8243 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 I would like to say just one more word about "subnetwork". With "classical" links in the IETF context, it is commonly considered that the layer immediately below IP is the link layer (or, L2). But, in some MANET contexts, there may be "sublayers" occurring between IP and the true link layer. Concensus seems to be steering toward calling these the "Sub-IP" layers, where Sub-IP is intended to mean anything immediately below IP down to and including the upper portion of L2. Again, in some MANET contexts, the Sub-IP layers are responsible for manifesting and maintaining subnetworks over which IP runs, but this happens above the true link layer. These subnetworks may comprise multiple links, such that there may be multiple (Sub-IP) hops required to span the subnetwork. But, as long as there is no attempt to apply a classical "IP subnet" abstraction, there is no issue for partitions/merges/etc. Scaling of subnetworks can be bounded several ways, including frequency multiplexing, spatial frequency reuse, power control etc. But, I believe the methods used are totally up to the subnetwork designer and so I don't see a need to add anything about this in the manetarch document. I might however suggest bringing "subnetwork" into the terminology. For instance, a MANET could consist of many "subnetworks"; each of which could be considered a MANET unto itself. Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Templin, Fred L=20 > Sent: Friday, June 01, 2007 2:44 PM > To: Teco Boot > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] I-D=20 > ACTION:draft-ietf-autoconf-manetarch-02.txt=20 >=20 > Teco, >=20 > Yes, RFC3819 is the IETF reference that I am aware of. > I have not done a thorough literature search such that > I could provide other references at this time, but I do > have plans to look into this. >=20 > Thanks - Fred > fred.l.templin@boeing.com >=20 > > -----Original Message----- > > From: Teco Boot [mailto:teco@inf-net.nl]=20 > > Sent: Friday, June 01, 2007 2:27 PM > > To: Templin, Fred L > > Cc: autoconf@ietf.org > > Subject: RE: [Autoconf] I-D=20 > > ACTION:draft-ietf-autoconf-manetarch-02.txt=20 > >=20 > > Hi Fred, > >=20 > > What about adding a description on scaling mechanisms in the ID? > > Can you provide references to IETF documents describing such=20 > > a technology? > > Is the difference between subnet and subnetwork somewhere=20 > > defined clearly? > >=20 > > I will check RFC3819, but this one discusses a subnetwork as=20 > > a L2 segment, > > although references to L3 areas are mentioned. > >=20 > > My concern is what to do if nodes get out of reach of others=20 > > in the same > > subnetwork, and nodes member of other subnetworks connects=20 > > them. It can > > occur with three nearby nodes and one obstacle. > >=20 > > Cheers, Teco > >=20 > > > -----Original Message----- > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > Sent: vrijdag 1 juni 2007 22:26 > > > To: Teco Boot; autoconf@ietf.org > > > Subject: RE: [Autoconf] I-D=20 > > ACTION:draft-ietf-autoconf-manetarch-02.txt > > >=20 > > > Hi Teco, > > >=20 > > > A term in common use in other context for areas within > > > a MANET is "subnetwork" which is meant in a way that is > > > distinct from the term "subnet", i.e., it makes no statement > > > about IP prefix/netmask assignments. Subnetworks within a > > > MANET can indeed be connected by inner MANET border routers, > > > since they are essetially just smaller MANETs within a larger > > > MANET. So, one way to bound scaling is to bound the sizes of > > > subnetworks within a MANET. > > >=20 > > > Fred > > > fred.l.templin@boeing.com > > >=20 > > > > 8.2 > > > > > ... complete number of nodes in a MANET ... > > > > > ... cohesive flat routing area ... > > > > > ... a single routing region ... > > > > Same comments as above, on term _multihop MANET area_.=20 > > Three terms for > > > > something not explained in this ID. > > > > I am still confused wat is meant in this section. There is > > > > the term _Peer > > > > MANET Routers_. It is not _connected MANET routers_ / > > > > _connected nodes_ (see > > > > text). I am not sure _MAN Neighbors_ is meant. May be a > > > > _MANET Peer_ is a > > > > potential _MANET Neighbor_ and all _MANET Peers_ are=20 > > configured for a > > > > _single routing region_. > > > > But reading 2.2. _MANET_, a _MANET_ is a _routing region_ and > > > > _MANETs_ split > > > > and merge due to reachability, so _regions_ are based on > > > > connectivity and > > > > not on configuration. > >=20 > >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Jun 04 11:39: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 1HvEev-0006HN-JK; Mon, 04 Jun 2007 11:39:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEeq-0006FP-FZ for autoconf@ietf.org; Mon, 04 Jun 2007 11:39:48 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvEep-0007od-Sl for autoconf@ietf.org; Mon, 04 Jun 2007 11:39:48 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-11.tower-119.messagelabs.com!1180971586!17946824!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 8520 invoked from network); 4 Jun 2007 15:39:46 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-11.tower-119.messagelabs.com with SMTP; 4 Jun 2007 15:39:46 -0000 Received: from az33exr03.mot.com (az33exr03.mot.com [10.64.251.233]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l54FdeKk005732; Mon, 4 Jun 2007 08:39:40 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l54Fddpu004564; Mon, 4 Jun 2007 10:39:39 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l54FdaXm004506; Mon, 4 Jun 2007 10:39:37 -0500 (CDT) Message-ID: <46643238.1090500@gmail.com> Date: Mon, 04 Jun 2007 17:39:36 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: sub-IP, AUTOCONF and MANEMO (was: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt) References: <39C363776A4E8C4A94691D2BD9D1C9A1029ED821@XCH-NW-7V2.nw.nos.boeing.com><004301c7a493$981550b0$05000100@Teco> <39C363776A4E8C4A94691D2BD9D1C9A1029ED826@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED82C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED82C@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000746-2, 01/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd 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, I've read your clarifications with interest. They picture sublayers between IP layer and link layer - sub-IP layers. Scaling subnetworks can indeed happen with link-layer, and I'd say more below, mechanisms: frequency multiplexing, reuse, power control; but I agree these are up to link-layer designer, maybe. Bringing the term 'subnetwork' to the terminology is what I agree with and I suggest to be added to the manetarch document; if other people agree with. Please allow me to explain why I remark to the MANET and AUTOCONF manetarch document. During the MANEMO effort we've been re-directed several times to AUTOCONF and MANET WGs to look for mechanisms that could accommodate MANEMO configurations. My comments are in light of these re-directions. For example, I believe that whereas MANET and AUTOCONF networks _may_ need sub-IP layer, there can exist MANEMO networks where the sub-IP routing or scaling is done by a MAC layer. For example two vehicles connecting directly with WiFi. In this sense, a MANEMO network does not need to be overwhelmed with the complexity of separation of layers, sub-IP layer whose role could be defined by both MANET and AUTOCONF, etc. A MANEMO network could simply re-use the MAC layer defined by Ethernet, that's all it needed. This is to say that I agree with what AUTOCONF and MANET WGs decide to have as architecture (sub-IP layers included or not). But I strongly suggest that the sub-IP layer and intermediary-layer routing as done (at least) by DYMO are not necessary in other contexts, for example for MANEMO vehicles connecting directly with WLAN. It is unnecessary complexification of scenes and configurations that are basically very simple and whose link-layer complexities (asymmetricity included) are hidden by a proper MAC layer. I would also like to invite AUTOCONF and MANET WG participants to read the MANEMO documents and participate in the MANEMO discussions. Alex Templin, Fred L wrote: > I would like to say just one more word about "subnetwork". With > "classical" links in the IETF context, it is commonly considered that > the layer immediately below IP is the link layer (or, L2). But, in > some MANET contexts, there may be "sublayers" occurring between IP > and the true link layer. Concensus seems to be steering toward > calling these the "Sub-IP" layers, where Sub-IP is intended to mean > anything immediately below IP down to and including the upper portion > of L2. > > Again, in some MANET contexts, the Sub-IP layers are responsible for > manifesting and maintaining subnetworks over which IP runs, but this > happens above the true link layer. These subnetworks may comprise > multiple links, such that there may be multiple (Sub-IP) hops > required to span the subnetwork. But, as long as there is no attempt > to apply a classical "IP subnet" abstraction, there is no issue for > partitions/merges/etc. > > Scaling of subnetworks can be bounded several ways, including > frequency multiplexing, spatial frequency reuse, power control etc. > But, I believe the methods used are totally up to the subnetwork > designer and so I don't see a need to add anything about this in the > manetarch document. > > I might however suggest bringing "subnetwork" into the terminology. > For instance, a MANET could consist of many "subnetworks"; each of > which could be considered a MANET unto itself. > > Fred fred.l.templin@boeing.com > >> -----Original Message----- From: Templin, Fred L Sent: Friday, June >> 01, 2007 2:44 PM To: Teco Boot Cc: autoconf@ietf.org Subject: RE: >> [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt >> >> Teco, >> >> Yes, RFC3819 is the IETF reference that I am aware of. I have not >> done a thorough literature search such that I could provide other >> references at this time, but I do have plans to look into this. >> >> Thanks - Fred fred.l.templin@boeing.com >> >>> -----Original Message----- From: Teco Boot >>> [mailto:teco@inf-net.nl] Sent: Friday, June 01, 2007 2:27 PM To: >>> Templin, Fred L Cc: autoconf@ietf.org Subject: RE: [Autoconf] I-D >>> ACTION:draft-ietf-autoconf-manetarch-02.txt >>> >>> Hi Fred, >>> >>> What about adding a description on scaling mechanisms in the ID? >>> Can you provide references to IETF documents describing such a >>> technology? Is the difference between subnet and subnetwork >>> somewhere defined clearly? >>> >>> I will check RFC3819, but this one discusses a subnetwork as a L2 >>> segment, although references to L3 areas are mentioned. >>> >>> My concern is what to do if nodes get out of reach of others in >>> the same subnetwork, and nodes member of other subnetworks >>> connects them. It can occur with three nearby nodes and one >>> obstacle. >>> >>> Cheers, Teco >>> >>>> -----Original Message----- From: Templin, Fred L >>>> [mailto:Fred.L.Templin@boeing.com] Sent: vrijdag 1 juni 2007 >>>> 22:26 To: Teco Boot; autoconf@ietf.org Subject: RE: [Autoconf] >>>> I-D >>> ACTION:draft-ietf-autoconf-manetarch-02.txt >>>> Hi Teco, >>>> >>>> A term in common use in other context for areas within a MANET >>>> is "subnetwork" which is meant in a way that is distinct from >>>> the term "subnet", i.e., it makes no statement about IP >>>> prefix/netmask assignments. Subnetworks within a MANET can >>>> indeed be connected by inner MANET border routers, since they >>>> are essetially just smaller MANETs within a larger MANET. So, >>>> one way to bound scaling is to bound the sizes of subnetworks >>>> within a MANET. >>>> >>>> Fred fred.l.templin@boeing.com >>>> >>>>> 8.2 >>>>>> ... complete number of nodes in a MANET ... ... cohesive >>>>>> flat routing area ... ... a single routing region ... >>>>> Same comments as above, on term _multihop MANET area_. >>> Three terms for >>>>> something not explained in this ID. I am still confused wat >>>>> is meant in this section. There is the term _Peer MANET >>>>> Routers_. It is not _connected MANET routers_ / _connected >>>>> nodes_ (see text). I am not sure _MAN Neighbors_ is meant. >>>>> May be a _MANET Peer_ is a potential _MANET Neighbor_ and all >>>>> _MANET Peers_ are >>> configured for a >>>>> _single routing region_. But reading 2.2. _MANET_, a _MANET_ >>>>> is a _routing region_ and _MANETs_ split and merge due to >>>>> reachability, so _regions_ are based on connectivity and not >>>>> on configuration. >>> >> _______________________________________________ Autoconf mailing >> list Autoconf@ietf.org >> https://www1.ietf.org/mailman/listinfo/autoconf >> > > _______________________________________________ Autoconf mailing list > Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Jun 04 11:49:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEoa-0001mN-3n; Mon, 04 Jun 2007 11:49:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEoY-0001mI-R0 for autoconf@ietf.org; Mon, 04 Jun 2007 11:49:50 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvEoW-0001e6-FH for autoconf@ietf.org; Mon, 04 Jun 2007 11:49:50 -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 l54FnljI029875 for ; Mon, 4 Jun 2007 16:49:47 +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 l54FnlY1019793 for ; Mon, 4 Jun 2007 16:49:47 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 04 Jun 2007 16:49:46 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 16:49:46 +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: sub-IP, AUTOCONF and MANEMO (was: [Autoconf] I-DACTION:draft-ietf-autoconf-manetarch-02.txt) Date: Mon, 4 Jun 2007 16:49:46 +0100 Message-ID: In-Reply-To: <46643238.1090500@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: sub-IP, AUTOCONF and MANEMO (was: [Autoconf] I-DACTION:draft-ietf-autoconf-manetarch-02.txt) Thread-Index: AcemvpyPNkcZI3xmRVmGRlaVNXcWEQAAHsQA From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" , "Templin, Fred L" X-OriginalArrivalTime: 04 Jun 2007 15:49:46.0791 (UTC) FILETIME=[FA13BB70:01C7A6BF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 > For example, I believe that whereas MANET and AUTOCONF networks _may_ > need sub-IP layer, there can exist MANEMO networks where the sub-IP > routing or scaling is done by a MAC layer. For example two vehicles > connecting directly with WiFi. I believe this is completely misunderstanding the MANET work, as indicated by recent comments on the MANET list about DYMO. DYMO (and other protocols being developed in the MANET WG) are not using sub-IP routing, they are network layer routing protocols. This is again therefore creating a false difference between MANET and whatever MANEMO may or may not be. > But I strongly > suggest that the sub-IP layer and intermediary-layer routing as done (at > least) by DYMO And this is making explicit that misunderstanding. ******************************************************************** 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 Mon Jun 04 11:51: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 1HvEqA-0003Sg-3f; Mon, 04 Jun 2007 11:51:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvEq8-0003Sb-P9 for autoconf@ietf.org; Mon, 04 Jun 2007 11:51:28 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvEq8-00027B-9U for autoconf@ietf.org; Mon, 04 Jun 2007 11:51:28 -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 l54FpQH2022677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Jun 2007 10:51:27 -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 l54FpP5Q013989; Mon, 4 Jun 2007 08:51:25 -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 l54FomFo012580; Mon, 4 Jun 2007 08:50:49 -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, 4 Jun 2007 08:50:44 -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: sub-IP, AUTOCONF and MANEMO (was: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt) Date: Mon, 4 Jun 2007 08:50:43 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED82E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <46643238.1090500@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: sub-IP, AUTOCONF and MANEMO (was: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt) Thread-Index: AcemvpYT3SqwE5pXS+GAUJ9iTzFfrgAAIVyA References: <39C363776A4E8C4A94691D2BD9D1C9A1029ED821@XCH-NW-7V2.nw.nos.boeing.com><004301c7a493$981550b0$05000100@Teco> <39C363776A4E8C4A94691D2BD9D1C9A1029ED826@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED82C@XCH-NW-7V2.nw.nos.boeing.com> <46643238.1090500@gmail.com> From: "Templin, Fred L" To: "Alexandru Petrescu" X-OriginalArrivalTime: 04 Jun 2007 15:50:44.0687 (UTC) FILETIME=[1C95F5F0:01C7A6C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 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 Alex, Thanks for the follow-up. Just for clarifications, I am not meaning to suggest that MANET *requires* Sub-IP=20 layers other than the true link layer; only that the subnetwork abstraction is manifested by the layer immediately below IP - be that a Sub-IP layer or the true link layer itself. I don't see a difference btw this and the other contexts you mentioned; the same principle applies also to classical interfaces such as wired LANs. I also believe the RFC3819 text applies equally for any subnetworks whether they are manifested by the true link layer or a Sub-IP layer below IP and above the true link layer. Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Monday, June 04, 2007 8:40 AM > To: Templin, Fred L > Cc: Teco Boot; autoconf@ietf.org > Subject: Re: sub-IP, AUTOCONF and MANEMO (was: [Autoconf] I-D=20 > ACTION:draft-ietf-autoconf-manetarch-02.txt) >=20 > Fred, I've read your clarifications with interest. >=20 > They picture sublayers between IP layer and link layer -=20 > sub-IP layers. > Scaling subnetworks can indeed happen with link-layer, and=20 > I'd say more > below, mechanisms: frequency multiplexing, reuse, power control; but I > agree these are up to link-layer designer, maybe. >=20 > Bringing the term 'subnetwork' to the terminology is what I agree with > and I suggest to be added to the manetarch document; if other people > agree with. >=20 > Please allow me to explain why I remark to the MANET and AUTOCONF > manetarch document. >=20 > During the MANEMO effort we've been re-directed several times to > AUTOCONF and MANET WGs to look for mechanisms that could accommodate > MANEMO configurations. My comments are in light of these=20 > re-directions. >=20 > For example, I believe that whereas MANET and AUTOCONF networks _may_ > need sub-IP layer, there can exist MANEMO networks where the sub-IP > routing or scaling is done by a MAC layer. For example two vehicles > connecting directly with WiFi. >=20 > In this sense, a MANEMO network does not need to be=20 > overwhelmed with the > complexity of separation of layers, sub-IP layer whose role could be > defined by both MANET and AUTOCONF, etc. A MANEMO network=20 > could simply > re-use the MAC layer defined by Ethernet, that's all it needed. >=20 > This is to say that I agree with what AUTOCONF and MANET WGs decide to > have as architecture (sub-IP layers included or not). But I strongly > suggest that the sub-IP layer and intermediary-layer routing=20 > as done (at > least) by DYMO are not necessary in other contexts, for example for > MANEMO vehicles connecting directly with WLAN. It is unnecessary > complexification of scenes and configurations that are basically very > simple and whose link-layer complexities (asymmetricity included) are > hidden by a proper MAC layer. >=20 > I would also like to invite AUTOCONF and MANET WG participants to read > the MANEMO documents and participate in the MANEMO discussions. >=20 > Alex >=20 >=20 > Templin, Fred L wrote: > > I would like to say just one more word about "subnetwork". With > > "classical" links in the IETF context, it is commonly=20 > considered that > > the layer immediately below IP is the link layer (or, L2). But, in > > some MANET contexts, there may be "sublayers" occurring between IP > > and the true link layer. Concensus seems to be steering toward > > calling these the "Sub-IP" layers, where Sub-IP is intended to mean > > anything immediately below IP down to and including the=20 > upper portion > > of L2. > >=20 > > Again, in some MANET contexts, the Sub-IP layers are responsible for > > manifesting and maintaining subnetworks over which IP runs, but this > > happens above the true link layer. These subnetworks may comprise > > multiple links, such that there may be multiple (Sub-IP) hops > > required to span the subnetwork. But, as long as there is no attempt > > to apply a classical "IP subnet" abstraction, there is no issue for=20 > > partitions/merges/etc. > >=20 > > Scaling of subnetworks can be bounded several ways, including > > frequency multiplexing, spatial frequency reuse, power control etc. > > But, I believe the methods used are totally up to the subnetwork > > designer and so I don't see a need to add anything about this in the > > manetarch document. > >=20 > > I might however suggest bringing "subnetwork" into the terminology. > > For instance, a MANET could consist of many "subnetworks"; each of > > which could be considered a MANET unto itself. > >=20 > > Fred fred.l.templin@boeing.com > >=20 > >> -----Original Message----- From: Templin, Fred L Sent: Friday, June > >> 01, 2007 2:44 PM To: Teco Boot Cc: autoconf@ietf.org Subject: RE: > >> [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt > >>=20 > >> Teco, > >>=20 > >> Yes, RFC3819 is the IETF reference that I am aware of. I have not > >> done a thorough literature search such that I could provide other > >> references at this time, but I do have plans to look into this. > >>=20 > >> Thanks - Fred fred.l.templin@boeing.com > >>=20 > >>> -----Original Message----- From: Teco Boot > >>> [mailto:teco@inf-net.nl] Sent: Friday, June 01, 2007 2:27 PM To: > >>> Templin, Fred L Cc: autoconf@ietf.org Subject: RE: [Autoconf] I-D > >>> ACTION:draft-ietf-autoconf-manetarch-02.txt > >>>=20 > >>> Hi Fred, > >>>=20 > >>> What about adding a description on scaling mechanisms in the ID?=20 > >>> Can you provide references to IETF documents describing such a > >>> technology? Is the difference between subnet and subnetwork > >>> somewhere defined clearly? > >>>=20 > >>> I will check RFC3819, but this one discusses a subnetwork as a L2 > >>> segment, although references to L3 areas are mentioned. > >>>=20 > >>> My concern is what to do if nodes get out of reach of others in > >>> the same subnetwork, and nodes member of other subnetworks > >>> connects them. It can occur with three nearby nodes and one > >>> obstacle. > >>>=20 > >>> Cheers, Teco > >>>=20 > >>>> -----Original Message----- From: Templin, Fred L > >>>> [mailto:Fred.L.Templin@boeing.com] Sent: vrijdag 1 juni 2007 > >>>> 22:26 To: Teco Boot; autoconf@ietf.org Subject: RE: [Autoconf] > >>>> I-D > >>> ACTION:draft-ietf-autoconf-manetarch-02.txt > >>>> Hi Teco, > >>>>=20 > >>>> A term in common use in other context for areas within a MANET > >>>> is "subnetwork" which is meant in a way that is distinct from > >>>> the term "subnet", i.e., it makes no statement about IP > >>>> prefix/netmask assignments. Subnetworks within a MANET can > >>>> indeed be connected by inner MANET border routers, since they > >>>> are essetially just smaller MANETs within a larger MANET. So, > >>>> one way to bound scaling is to bound the sizes of subnetworks > >>>> within a MANET. > >>>>=20 > >>>> Fred fred.l.templin@boeing.com > >>>>=20 > >>>>> 8.2 > >>>>>> ... complete number of nodes in a MANET ... ... cohesive > >>>>>> flat routing area ... ... a single routing region ... > >>>>> Same comments as above, on term _multihop MANET area_. > >>> Three terms for > >>>>> something not explained in this ID. I am still confused wat > >>>>> is meant in this section. There is the term _Peer MANET > >>>>> Routers_. It is not _connected MANET routers_ / _connected > >>>>> nodes_ (see text). I am not sure _MAN Neighbors_ is meant. > >>>>> May be a _MANET Peer_ is a potential _MANET Neighbor_ and all > >>>>> _MANET Peers_ are > >>> configured for a > >>>>> _single routing region_. But reading 2.2. _MANET_, a _MANET_ > >>>>> is a _routing region_ and _MANETs_ split and merge due to > >>>>> reachability, so _regions_ are based on connectivity and not > >>>>> on configuration. > >>>=20 > >> _______________________________________________ Autoconf mailing > >> list Autoconf@ietf.org=20 > >> https://www1.ietf.org/mailman/listinfo/autoconf > >>=20 > >=20 > > _______________________________________________ Autoconf=20 > mailing list > > Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf > >=20 >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Jun 04 12:23:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFLW-0000Ar-QY; Mon, 04 Jun 2007 12:23:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFLV-0000Am-Pw for autoconf@ietf.org; Mon, 04 Jun 2007 12:23:53 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvFLU-0007KK-Fe for autoconf@ietf.org; Mon, 04 Jun 2007 12:23:53 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-128.messagelabs.com!1180974195!6660085!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 2759 invoked from network); 4 Jun 2007 16:23:16 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-128.messagelabs.com with SMTP; 4 Jun 2007 16:23:15 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l54GNFPm007941; Mon, 4 Jun 2007 09:23:15 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l54GNF0D016710; Mon, 4 Jun 2007 11:23:15 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l54GNDle016703; Mon, 4 Jun 2007 11:23:14 -0500 (CDT) Message-ID: <46643C71.6050508@gmail.com> Date: Mon, 04 Jun 2007 18:23:13 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: sub-IP, AUTOCONF and MANEMO (was: [Autoconf] I-DACTION:draft-ietf-autoconf-manetarch-02.txt) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000746-2, 01/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Dearlove, Christopher (UK) wrote: >> For example, I believe that whereas MANET and AUTOCONF networks >> _may_ need sub-IP layer, there can exist MANEMO networks where the >> sub-IP routing or scaling is done by a MAC layer. For example two >> vehicles connecting directly with WiFi. > > I believe this is completely misunderstanding the MANET work, as > indicated by recent comments on the MANET list about DYMO. DYMO (and > other protocols being developed in the MANET WG) are not using > sub-IP routing, they are network layer routing protocols. This is > again therefore creating a false difference between MANET and > whatever MANEMO may or may not be. Christopher, thanks for pointing this. >> But I strongly suggest that the sub-IP layer and intermediary-layer >> routing as done (at least) by DYMO > > And this is making explicit that misunderstanding. I think there may indeed be some misunderstanding of DYMO on my part. Could we please share some oppinions about how you see DYMO/NHDP accommodate a MANEMO configuration and addressing scheme? For example do you think DYMO/NHDP are needed when the linnks are not asymmetric? Any other thoughts on MANEMO and DYMO/NHDP? Thanks, Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Jun 04 12:43:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFeJ-0006lq-1t; Mon, 04 Jun 2007 12:43:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFeH-0006ll-Fl for autoconf@ietf.org; Mon, 04 Jun 2007 12:43:17 -0400 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvFeG-0000S2-4A for autoconf@ietf.org; Mon, 04 Jun 2007 12:43:17 -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 l54GhEV7002187 for ; Mon, 4 Jun 2007 17:43:14 +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 l54GhE85025625 for ; Mon, 4 Jun 2007 17:43:14 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Mon, 04 Jun 2007 17:43:14 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Mon, 4 Jun 2007 17:43:14 +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: sub-IP, AUTOCONF and MANEMO (was: [Autoconf] I-DACTION:draft-ietf-autoconf-manetarch-02.txt) Date: Mon, 4 Jun 2007 17:43:13 +0100 Message-ID: In-Reply-To: <46643C71.6050508@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: sub-IP, AUTOCONF and MANEMO (was: [Autoconf] I-DACTION:draft-ietf-autoconf-manetarch-02.txt) Thread-Index: AcemxMJBeJOf6x9xQXyPaKk2Bs+bOAAAdpbw From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 04 Jun 2007 16:43:14.0325 (UTC) FILETIME=[71EA9450:01C7A6C7] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 =20 > Could we please share some oppinions about how you see DYMO/NHDP > accommodate a MANEMO configuration and addressing scheme? For example > do you think DYMO/NHDP are needed when the linnks are not asymmetric? > Any other thoughts on MANEMO and DYMO/NHDP? OLSRv2 is really my thing, rather than DYMO - what I've been commenting on has almost entirely been things that you could say "DYMO" or "OLSR" with otherwise no change in comments. Of course there are many other things that do differ, and now you are getting into those. Also right at the moment I don't really have time right now for the comments I have made, and definitely not for what you want. I would say that the preamble to NHDP discusses what the point of it is - but you don't need all of them to want NHDP. For example if you consider that NHDP handles lossy, possibly asymmetric, dynamic links where you want one and two hop neighbourhoods, you might still need NHDP if not all four of those conditions apply. ******************************************************************** 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 Mon Jun 04 13:01:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFvj-0000ou-VW; Mon, 04 Jun 2007 13:01:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvFvj-0000nK-BS for autoconf@ietf.org; Mon, 04 Jun 2007 13:01:19 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvFvh-00034L-1G for autoconf@ietf.org; Mon, 04 Jun 2007 13:01:19 -0400 Received: by ug-out-1314.google.com with SMTP id j30so15047ugc for ; Mon, 04 Jun 2007 10:01:14 -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=TzheFth+LW+2mS7bGTiEcaDlVehFIKuBz4hTxjjlQ3HHECOqhbtZkFov24+dIPtanOoMjyS2m1afc96Twi10YRrDRg7RSz/4uB3Y5JSSbR25fypZ283MV5klgv8btgQNOkUxISFMBjl3nud5CZb2kMtYRFqA6zor/L3J7PlualI= 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=VvsLU10k1KoJhyRJ5Wa3URqa4dcky3w7aHtCJJAA/FQMVT76yD4Tkmn8HV0Aobj6YKEuqbMeuWrE8XD/crun4GYo5Uo44RdL+ut9C3wPH5Au7SY/ZxCLZiJLclajMQf4vIcrBNteb6in406SB/sUMqzDbUVZdtYN22lm4myN5WM= Received: by 10.78.120.6 with SMTP id s6mr2115630huc.1180976474394; Mon, 04 Jun 2007 10:01:14 -0700 (PDT) Received: by 10.78.45.14 with HTTP; Mon, 4 Jun 2007 10:01:14 -0700 (PDT) Message-ID: <374005f30706041001y63ed7862oc7405d436782bc6b@mail.gmail.com> Date: Mon, 4 Jun 2007 22:31:14 +0530 From: "Ian Chakeres" To: "Alexandru Petrescu" Subject: Re: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt In-Reply-To: <46641436.20805@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <465FE3E3.8080601@gmail.com> <374005f30706020432m6dd817e1q881da76fbf4d9222@mail.gmail.com> <46641436.20805@gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 Comments inline with snips On 6/4/07, Alexandru Petrescu wrote: > Hi Ian, thanks for your message. > > Ian Chakeres wrote: > >>> Asymmetric Reachability I think a pointer to IPv6 Neighbor discovery RFC clears up where this term came from, and what it means. > >>> MANET router may also have zero or more classic IP interfaces to > >>> which other nodes may connect; i.e. the router may be responsible > >>> for several IP prefixes. > >> > >> Sorry, it does not follow. That i.e. ("id est", lat.) makes me > >> think that only because the MANET router has some classic IP > >> interfaces it is in charge for some IP prefixes, and thus maybe if > >> it has no classic IP interfaces then it is _not_ in charge for any > >> IP prefix; this is obviously not true, because if MANET router has > >> a MANET interface then it necessarily has an IP prefix on it. > > > > A MANET router could function using only link local addresses and > > therefore not necessarily be in charge of any classic IP prefixes. > > Not sure what you mean... a classical router can indeed work if it only > had link-local addresses on its interfaces but classical being it it has > different prefixes on these interfaces such that it can route otherwise > it's not classical and it doesn't route. Please see this presentation on unnumbered interfaces. It might explain how a router would participate in routing without having an address/prefix assigned to its various routable interfaces. www.apricot.net/apricot2006/slides/conf/thursday/Kireeti_Kompella_unnum.ppt _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Jun 04 14:54: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 1HvHha-00008j-VM; Mon, 04 Jun 2007 14:54:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvHhZ-00008Z-G9 for autoconf@ietf.org; Mon, 04 Jun 2007 14:54:49 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvHhX-0002hd-TO for autoconf@ietf.org; Mon, 04 Jun 2007 14:54:49 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-9.tower-119.messagelabs.com!1180983286!15346972!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 19228 invoked from network); 4 Jun 2007 18:54:46 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-119.messagelabs.com with SMTP; 4 Jun 2007 18:54:46 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l54Iskx2023615; Mon, 4 Jun 2007 11:54:46 -0700 (MST) Received: from il06vts01.mot.com (il06vts01.mot.com [129.188.137.141]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l54Isk89015885; Mon, 4 Jun 2007 13:54:46 -0500 (CDT) Received: from [127.0.0.1] (mvp-10-169-4-190.corp.mot.com [10.169.4.190]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l54IshT0015864; Mon, 4 Jun 2007 13:54:44 -0500 (CDT) Message-ID: <46645FF2.20502@gmail.com> Date: Mon, 04 Jun 2007 20:54:42 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: Ian Chakeres Subject: Re: asymmetric reachability (was: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt) References: <465FE3E3.8080601@gmail.com> <374005f30706020432m6dd817e1q881da76fbf4d9222@mail.gmail.com> <46641436.20805@gmail.com> <374005f30706041001y63ed7862oc7405d436782bc6b@mail.gmail.com> In-Reply-To: <374005f30706041001y63ed7862oc7405d436782bc6b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000747-0, 04/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 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 Ian Chakeres wrote: > Comments inline with snips > > On 6/4/07, Alexandru Petrescu wrote: >> Hi Ian, thanks for your message. >> >> Ian Chakeres wrote: >> >>> Asymmetric Reachability > > > > I think a pointer to IPv6 Neighbor discovery RFC clears up where this > term came from, and what it means. > > After our long discussions on asymmetric reachability. I think one should point to rfc2461bis draft, for being more updated. I think 2461bis defines asymmetric reachability in an uncomplete and bizarre way. I think 2461bis should talk about different ul/dl characteristics, udlr, tcp, mtu and bandwidth differences. I think 2461bis says at some point that ND _does_ work over asymmetric links (where it suggests NUD will discover the other end can't talk to it) and at the same time it says in appendix that asymmetric links are subject to future extensions. I think NHDP is not an ND extension. I think we can discuss to understand commonly what we understand by 'asymmetric' links. I think MANET does not deal with unidirectional links like satellite. So, what do _you_ understand by an asymmetric link: 1. Bandwidth/mtu variable uplink vs downlink ul/dl? 2. Links that may have the hidden terminal problem? 3. Unidirectional links like UDLR on satellite and DVB? Other? >> >>> MANET router may also have zero or more classic IP interfaces to >> >>> which other nodes may connect; i.e. the router may be responsible >> >>> for several IP prefixes. >> >> >> >> Sorry, it does not follow. That i.e. ("id est", lat.) makes me >> >> think that only because the MANET router has some classic IP >> >> interfaces it is in charge for some IP prefixes, and thus maybe if >> >> it has no classic IP interfaces then it is _not_ in charge for any >> >> IP prefix; this is obviously not true, because if MANET router has >> >> a MANET interface then it necessarily has an IP prefix on it. >> > >> > A MANET router could function using only link local addresses and >> > therefore not necessarily be in charge of any classic IP prefixes. >> >> Not sure what you mean... a classical router can indeed work if it only >> had link-local addresses on its interfaces but classical being it it has >> different prefixes on these interfaces such that it can route otherwise >> it's not classical and it doesn't route. > > Please see this presentation on unnumbered interfaces. It might > explain how a router would participate in routing without having an > address/prefix assigned to its various routable interfaces. > > www.apricot.net/apricot2006/slides/conf/thursday/Kireeti_Kompella_unnum.ppt Right... an IPv6 router can route without having global prefixes on interfaces. Remark the same presentation talks about ICMP... and thus a router without global addresses on its interfaces won't be able to send ICMP Redirect, or packet too big for PMTU, or ICMP... Alex > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Mon Jun 04 17:35: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 1HvKDT-0000x4-6u; Mon, 04 Jun 2007 17:35:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvKDS-0000wE-8D; Mon, 04 Jun 2007 17:35:54 -0400 Received: from [202.99.23.227] (helo=people.com.cn) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvKDQ-0003t7-D3; Mon, 04 Jun 2007 17:35:54 -0400 Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm124664c6e6; Tue, 05 Jun 2007 05:47:11 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jmec465f99e9; Fri, 01 Jun 2007 11:46:40 +0800 Received: from megatron.ietf.org([156.154.16.145]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Fri, 01 Jun 2007 11:46:40 +0800 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HttU1-0000US-1H; Thu, 31 May 2007 18:51:05 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HttTV-00084m-Ty; Thu, 31 May 2007 18:50:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HttTU-0007VN-HY; Thu, 31 May 2007 18:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 76380175F1; Thu, 31 May 2007 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1HttT0-0003Fe-4E; Thu, 31 May 2007 18:50:02 -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: Thu, 31 May 2007 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.5 Precedence: list X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: Internet-Drafts@ietf.org X-Auto-Forward: jaglee@people.com.cn jag@kw.com.cn X-Spam-Score: 2.2 (++) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Cc: autoconf@ietf.org Subject: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt X-BeenThere: autoconf@ietf.org Reply-To: internet-drafts@ietf.org 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-02.txt Pages : 20 Date : 2007-5-31 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-02.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-02.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-02.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-5-31161011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-autoconf-manetarch-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-autoconf-manetarch-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-5-31161011.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce --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 Mon Jun 04 19:22: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 1HvLsc-0004Wu-He; Mon, 04 Jun 2007 19:22:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvLsb-0004Wk-O2 for autoconf@ietf.org; Mon, 04 Jun 2007 19:22:29 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvLsb-0002H8-Dn for autoconf@ietf.org; Mon, 04 Jun 2007 19:22:29 -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 l54NMRm3019332 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 4 Jun 2007 16:22:27 -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 l54NMQF3011389; Mon, 4 Jun 2007 18:22:26 -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 l54NMKhA011211; Mon, 4 Jun 2007 18:22:26 -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, 4 Jun 2007 16:22:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Date: Mon, 4 Jun 2007 16:22:25 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED83C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <46641436.20805@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Thread-Index: AcemrLT0tBSa6W2oQp2S6x8V0Fsq3wAUYbqQ References: <465FE3E3.8080601@gmail.com><374005f30706020432m6dd817e1q881da76fbf4d9222@mail.gmail.com> <46641436.20805@gmail.com> From: "Templin, Fred L" To: "Alexandru Petrescu" , "Ian Chakeres" X-OriginalArrivalTime: 04 Jun 2007 23:22:26.0911 (UTC) FILETIME=[36C526F0:01C7A6FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 > > I had changed MR to MAN specifically to address collision=20 > with other=20 > > terminology. I need a short version for diagrams. > >=20 > > Do you think MAR is better? > >=20 > > If you have another better suggestion - please provide it. >=20 > MANET router. "MANET router" seems unnecessarily verbose. MAR is not defined in the IETF context so IMHO is eligible (just as "MAG" was declared eligible in the NETLMM realm even though it has entrenched connotations in other contexts). Another suggestion is "MNR" (for "MaNet Router"). IMHO, we are starting to put an inordinate amount of energy into this and should just pick something. Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jun 05 04:55:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvUpU-0005QZ-LK; Tue, 05 Jun 2007 04:55:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvUpS-0005OF-H4 for autoconf@ietf.org; Tue, 05 Jun 2007 04:55:50 -0400 Received: from smtp2.bae.co.uk ([20.133.0.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvUlv-00034T-Uv for autoconf@ietf.org; Tue, 05 Jun 2007 04:52:13 -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 l558qALO024178 for ; Tue, 5 Jun 2007 09:52:10 +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 l558q96l007145 for ; Tue, 5 Jun 2007 09:52:09 +0100 Received: from glkms1101.GREENLNK.NET ([10.15.184.109]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 05 Jun 2007 09:52:07 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1101.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 09:52:04 +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: asymmetric reachability (was: [Autoconf] Re: I-DACTION:draft-ietf-autoconf-manetarch-02.txt) Date: Tue, 5 Jun 2007 09:52:03 +0100 Message-ID: In-Reply-To: <46645FF2.20502@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: asymmetric reachability (was: [Autoconf] Re: I-DACTION:draft-ietf-autoconf-manetarch-02.txt) Thread-Index: Acem2diKBP/eCBtpT5iXs275UzwksgAdKQnQ From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" , "Ian Chakeres" X-OriginalArrivalTime: 05 Jun 2007 08:52:04.0271 (UTC) FILETIME=[CA106BF0:01C7A74E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 > I think NHDP is not an ND extension. You won't find anything, anywhere, by anyone who knows anything about NHDP, claiming that it's an ND extension. This is another red herring. ******************************************************************** 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 Tue Jun 05 05:48:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVe2-0004kz-9T; Tue, 05 Jun 2007 05:48:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVe0-0004kq-Ek for autoconf@ietf.org; Tue, 05 Jun 2007 05:48:04 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvVdz-00038e-7T for autoconf@ietf.org; Tue, 05 Jun 2007 05:48:04 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-13.tower-119.messagelabs.com!1181036882!29460296!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16336 invoked from network); 5 Jun 2007 09:48:02 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-13.tower-119.messagelabs.com with SMTP; 5 Jun 2007 09:48:02 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l559m2kh000617; Tue, 5 Jun 2007 02:48:02 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l559m1JX001540; Tue, 5 Jun 2007 04:48:01 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l559m0nD001519; Tue, 5 Jun 2007 04:48:00 -0500 (CDT) Message-ID: <4665314B.7020403@gmail.com> Date: Tue, 05 Jun 2007 11:47:55 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Dearlove, Christopher \(UK\)" Subject: Re: asymmetric reachability (was: [Autoconf] Re: I-DACTION:draft-ietf-autoconf-manetarch-02.txt) References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000747-0, 04/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Dearlove, Christopher (UK) wrote: >> I think NHDP is not an ND extension. > > You won't find anything, anywhere, by anyone who knows anything about > NHDP, claiming that it's an ND extension. This is another red > herring. I think I agree NHDP is not an ND extension. I wanted to say that even if ND partially left asymmetric links for future extensions (partially, because NUD does accomodate asymmetric links somehow) - NHDP is not an ND extension. There's little point in motivating NHDP by saying that ND left it for it. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jun 05 05:49: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 1HvVfj-00056q-69; Tue, 05 Jun 2007 05:49:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvVfh-00056j-U8 for autoconf@ietf.org; Tue, 05 Jun 2007 05:49:49 -0400 Received: from smtp1.bae.co.uk ([20.133.0.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvVfg-0003Vu-Hr for autoconf@ietf.org; Tue, 05 Jun 2007 05:49:49 -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 l559nkPY014493 for ; Tue, 5 Jun 2007 10:49:46 +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 l559nieU029283 for ; Tue, 5 Jun 2007 10:49:44 +0100 Received: from glkms1100.GREENLNK.NET ([10.15.184.108]) by glkas0002.GREENLNK.NET with InterScan Message Security Suite; Tue, 05 Jun 2007 10:49:43 +0100 Received: from GLKMS2100.GREENLNK.NET ([10.15.184.93]) by glkms1100.GREENLNK.NET with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 10:49:43 +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: asymmetric reachability (was: [Autoconf] Re: I-DACTION:draft-ietf-autoconf-manetarch-02.txt) Date: Tue, 5 Jun 2007 10:49:43 +0100 Message-ID: In-Reply-To: <4665314B.7020403@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: asymmetric reachability (was: [Autoconf] Re: I-DACTION:draft-ietf-autoconf-manetarch-02.txt) Thread-Index: AcenVp3qt9r363hQQN+DrJEs3OY+TQAABcrQ From: "Dearlove, Christopher \(UK\)" To: "Alexandru Petrescu" X-OriginalArrivalTime: 05 Jun 2007 09:49:43.0788 (UTC) FILETIME=[D818D2C0:01C7A756] 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 > I wanted to say that even if ND partially left asymmetric links for > future extensions (partially, because NUD does accomodate asymmetric > links somehow) - NHDP is not an ND extension. There's little point > in motivating NHDP by saying that ND left it for it. And, again, no one has said that. ******************************************************************** 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 Tue Jun 05 12:04:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbWG-0001V7-AG; Tue, 05 Jun 2007 12:04:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvbWE-0001Tl-OF for autoconf@ietf.org; Tue, 05 Jun 2007 12:04:26 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvbWD-0003Kq-Ff for autoconf@ietf.org; Tue, 05 Jun 2007 12:04:26 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l55G4MbX011552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 Jun 2007 09:04:23 -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 l55G4Lmu017228; Tue, 5 Jun 2007 09:04:21 -0700 (PDT) Received: from XCH-NWBH-10.nw.nos.boeing.com (xch-nwbh-10.nw.nos.boeing.com [130.247.55.83]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id l55G4DEH016863; Tue, 5 Jun 2007 09:04:16 -0700 (PDT) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-10.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 5 Jun 2007 09:04:13 -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] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Date: Tue, 5 Jun 2007 09:03:16 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED843@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED83C@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Thread-Index: AcemrLT0tBSa6W2oQp2S6x8V0Fsq3wAUYbqQACLutdA= References: <465FE3E3.8080601@gmail.com><374005f30706020432m6dd817e1q881da76fbf4d9222@mail.gmail.com><46641436.20805@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED83C@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "Alexandru Petrescu" , "Ian Chakeres" X-OriginalArrivalTime: 05 Jun 2007 16:04:13.0626 (UTC) FILETIME=[292A01A0:01C7A78B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 Actually, why not just call it as "MANET Mobile Router" abbreviated as either "MMR" or "MANET MR" which can be shortened to just "MR" within the scope of the MANET architecture document. Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jun 05 14:07:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvdRQ-0007hf-D4; Tue, 05 Jun 2007 14:07:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvdRO-0007hZ-Qm for autoconf@ietf.org; Tue, 05 Jun 2007 14:07:34 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvdRN-00008V-Ia for autoconf@ietf.org; Tue, 05 Jun 2007 14:07:34 -0400 Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net [82.239.213.32]) by smtp7-g19.free.fr (Postfix) with ESMTP id 686C918937; Tue, 5 Jun 2007 20:07:32 +0200 (CEST) Message-ID: <4665A663.9050000@gmail.com> Date: Tue, 05 Jun 2007 20:07:31 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt References: <465FE3E3.8080601@gmail.com><374005f30706020432m6dd817e1q881da76fbf4d9222@mail.gmail.com><46641436.20805@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED83C@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED843@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED843@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000747-1, 05/06/2007), Outbound message X-Antivirus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 Templin, Fred L wrote: > Actually, why not just call it as "MANET Mobile Router" > abbreviated as either "MMR" or "MANET MR" which can > be shortened to just "MR" within the scope of the MANET > architecture document. :-) makes some sense to me up to some point... Because if we say Mobile Router we understand a router that runs Mobile IPv6... MMR is a usable term to me. Alex _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jun 05 14:38:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvdut-0000bV-VW; Tue, 05 Jun 2007 14:38:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvdus-0000bN-Nl for autoconf@ietf.org; Tue, 05 Jun 2007 14:38:02 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvdup-0008D5-Dj for autoconf@ietf.org; Tue, 05 Jun 2007 14:38:02 -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 l55IbuMG003211 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 Jun 2007 11:37:56 -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 l55Ibup1016048; Tue, 5 Jun 2007 11:37:56 -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 l55IbNQn014488; Tue, 5 Jun 2007 11:37:26 -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); Tue, 5 Jun 2007 11:37:25 -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] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Date: Tue, 5 Jun 2007 11:37:03 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED846@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4665A663.9050000@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Thread-Index: AcennGZnAANqjAIoSuKhQvY4Yj9vDAAACi1w References: <465FE3E3.8080601@gmail.com><374005f30706020432m6dd817e1q881da76fbf4d9222@mail.gmail.com><46641436.20805@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED83C@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED843@XCH-NW-7V2.nw.nos.boeing.com> <4665A663.9050000@gmail.com> From: "Templin, Fred L" To: "Alexandru Petrescu" X-OriginalArrivalTime: 05 Jun 2007 18:37:25.0509 (UTC) FILETIME=[8FF40B50:01C7A7A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Alex, You would have to explain to me how Mobile Router necessarily implies Mobile IP, but it would not be appropriate to draw that distinction in terms of the MANET architecture document as I think you know. Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Tuesday, June 05, 2007 11:08 AM > To: Templin, Fred L > Cc: Ian Chakeres; autoconf@ietf.org > Subject: Re: [Autoconf] Re: I-D=20 > ACTION:draft-ietf-autoconf-manetarch-02.txt >=20 > Templin, Fred L wrote: > > Actually, why not just call it as "MANET Mobile Router" > > abbreviated as either "MMR" or "MANET MR" which can > > be shortened to just "MR" within the scope of the MANET > > architecture document. >=20 > :-) makes some sense to me up to some point... >=20 > Because if we say Mobile Router we understand a router that=20 > runs Mobile=20 > IPv6... >=20 > MMR is a usable term to me. >=20 > Alex >=20 >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jun 05 15:29: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 1Hvej0-00074Q-UQ; Tue, 05 Jun 2007 15:29:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hveiz-00074L-H5 for autoconf@ietf.org; Tue, 05 Jun 2007 15:29:49 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Hveiy-0004d8-1B for autoconf@ietf.org; Tue, 05 Jun 2007 15:29:49 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-10.tower-128.messagelabs.com!1181071786!5528133!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 24069 invoked from network); 5 Jun 2007 19:29:46 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-10.tower-128.messagelabs.com with SMTP; 5 Jun 2007 19:29:46 -0000 Received: from il06exr03.mot.com (il06exr03.mot.com [129.188.137.133]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l55JTkIY016627; Tue, 5 Jun 2007 12:29:46 -0700 (MST) Received: from il06vts03.mot.com (il06vts03.mot.com [129.188.137.143]) by il06exr03.mot.com (8.13.1/Vontu) with SMTP id l55JTk5Z028468; Tue, 5 Jun 2007 14:29:46 -0500 (CDT) Received: from [127.0.0.1] ([10.129.41.147]) by il06exr03.mot.com (8.13.1/8.13.0) with ESMTP id l55JTit6028439; Tue, 5 Jun 2007 14:29:44 -0500 (CDT) Message-ID: <4665B9A7.8000309@gmail.com> Date: Tue, 05 Jun 2007 21:29:43 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt References: <465FE3E3.8080601@gmail.com><374005f30706020432m6dd817e1q881da76fbf4d9222@mail.gmail.com><46641436.20805@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED83C@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED843@XCH-NW-7V2.nw.nos.boeing.com> <4665A663.9050000@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED846@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED846@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000747-1, 05/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 Templin, Fred L wrote: > Alex, > > You would have to explain to me how Mobile Router necessarily > implies Mobile IP, but it would not be appropriate to draw that > distinction in terms of the MANET architecture document as I > think you know. FRed, I think I agree Mobile Router would not mean to everybody that it runs the Mobile IP protocol. It does so to me. And, the mobility terminology RFC3753 defines Mobile Router as: > Mobile Router (MR) > > A router capable of changing its point of attachment to the > network, moving from one link to another link. The MR is capable > of forwarding packets between two or more interfaces, and possibly > running a dynamic routing protocol modifying the state by which it > does packet forwarding. > > 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 reads to me very much as running Mobile IP and potentially a routing protocol too. But that existing definition is different than the manetarch document definition of a MANET router at least because it talks about e/ingress interface whereas the latter talks about 'classical' and 'MANET' interfaces: > MANET Router (MAN) > a MANET router embodies router functionality and may also > incorporate an internally addressable host (IAH) logic, as > illustrated in Figure 1. A MANET router has one or more > interfaces. To simplify discussion we will classify the > interfaces into two categories: classic IP interfaces & MANET > interfaces. MANET interfaces are defined as interfaces that > demonstrate asymmetric reachability and/or neighbor addresses that > are not known a priori. A MANET router may participate in routing > on zero or more MANET interfaces. A MANET router may participate > in routing on zero or more classic IP interfaces. A MANET router > may also have zero or more classic IP interfaces to which other > nodes may connect; i.e. the router may be responsible for several > IP prefixes. These two definitions are different. Of course, AUTOCONF and MANET WGs are free to re-define Mobile Router as they best see fit, and ignore the existent definition of a Mobile Router (just as NEMO people ignored the pre-existing LFN term). I think more would be gained if we could find coherency between the two notions of Mobile Router, and it starts at terminology... Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jun 06 09:51:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvvv4-0000yO-0d; Wed, 06 Jun 2007 09:51:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvvv3-0000yJ-Ju for autoconf@ietf.org; Wed, 06 Jun 2007 09:51:25 -0400 Received: from stl-smtpout-01.boeing.com ([130.76.96.56]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvvv0-00007z-Tq for autoconf@ietf.org; Wed, 06 Jun 2007 09:51: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 l56DpJbR005640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Jun 2007 08:51:20 -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 l56DpJ81026212; Wed, 6 Jun 2007 06:51:19 -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 l56DpIPo026194; Wed, 6 Jun 2007 06:51:18 -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, 6 Jun 2007 06:51:16 -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] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Date: Wed, 6 Jun 2007 06:51:12 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED84C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4665B9A7.8000309@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Thread-Index: Acenp+GZiUWdnd0kTDG/vI4CZAv0iAAmFyWA References: <465FE3E3.8080601@gmail.com><374005f30706020432m6dd817e1q881da76fbf4d9222@mail.gmail.com><46641436.20805@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED83C@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED843@XCH-NW-7V2.nw.nos.boeing.com> <4665A663.9050000@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED846@XCH-NW-7V2.nw.nos.boeing.com> <4665B9A7.8000309@gmail.com> From: "Templin, Fred L" To: "Alexandru Petrescu" X-OriginalArrivalTime: 06 Jun 2007 13:51:16.0394 (UTC) FILETIME=[C0C6C0A0:01C7A841] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 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 Alex, Based on my read, the RFC3753 definition for Mobile Router makes no statement about Mobile IP or not. In terms of ingress/egress interfaces, IMHO a MANET interface is neither/nor, i.e., a MANET interface is not inherently in or out; up or down. In some respects it might be considered as "sideways". Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com]=20 > Sent: Tuesday, June 05, 2007 12:30 PM > To: Templin, Fred L > Cc: Ian Chakeres; autoconf@ietf.org > Subject: Re: [Autoconf] Re: I-D=20 > ACTION:draft-ietf-autoconf-manetarch-02.txt >=20 > Templin, Fred L wrote: > > Alex, > >=20 > > You would have to explain to me how Mobile Router necessarily > > implies Mobile IP, but it would not be appropriate to draw that > > distinction in terms of the MANET architecture document as I > > think you know. >=20 > FRed, I think I agree Mobile Router would not mean to=20 > everybody that it=20 > runs the Mobile IP protocol. It does so to me. >=20 > And, the mobility terminology RFC3753 defines Mobile Router as: > > Mobile Router (MR) > >=20 > > A router capable of changing its point of attachment to the > > network, moving from one link to another link. The=20 > MR is capable > > of forwarding packets between two or more interfaces,=20 > and possibly > > running a dynamic routing protocol modifying the=20 > state by which it > > does packet forwarding. > >=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=20 > ingress interface. >=20 > This reads to me very much as running Mobile IP and potentially a=20 > routing protocol too. >=20 > But that existing definition is different than the manetarch document=20 > definition of a MANET router at least because it talks about=20 > e/ingress=20 > interface whereas the latter talks about 'classical' and=20 > 'MANET' interfaces: >=20 > > MANET Router (MAN) > > a MANET router embodies router functionality and may also > > incorporate an internally addressable host (IAH) logic, as > > illustrated in Figure 1. A MANET router has one or more > > interfaces. To simplify discussion we will classify the > > interfaces into two categories: classic IP interfaces & MANET > > interfaces. MANET interfaces are defined as interfaces that > > demonstrate asymmetric reachability and/or neighbor=20 > addresses that > > are not known a priori. A MANET router may=20 > participate in routing > > on zero or more MANET interfaces. A MANET router may=20 > participate > > in routing on zero or more classic IP interfaces. A=20 > MANET router > > may also have zero or more classic IP interfaces to=20 > which other > > nodes may connect; i.e. the router may be responsible=20 > for several > > IP prefixes. >=20 > These two definitions are different. >=20 > Of course, AUTOCONF and MANET WGs are free to re-define=20 > Mobile Router as=20 > they best see fit, and ignore the existent definition of a=20 > Mobile Router=20 > (just as NEMO people ignored the pre-existing LFN term). >=20 > I think more would be gained if we could find coherency=20 > between the two=20 > notions of Mobile Router, and it starts at terminology... >=20 > Alex >=20 >=20 > ______________________________________________________________________ > This email has been scanned by the MessageLabs Email Security System. > For more information please visit http://www.messagelabs.com/email=20 > ______________________________________________________________________ >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jun 06 10:08: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 1HvwBC-0003oS-53; Wed, 06 Jun 2007 10:08:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvwBB-0003oK-DE for autoconf@ietf.org; Wed, 06 Jun 2007 10:08:05 -0400 Received: from hpsmtp-eml20.kpnxchange.com ([213.75.38.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvwBA-0003V7-Lm for autoconf@ietf.org; Wed, 06 Jun 2007 10:08:05 -0400 Received: from hpsmtp-eml06.kpnxchange.com ([213.75.38.106]) by hpsmtp-eml20.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 16:08:03 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml06.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 16:08:02 +0200 From: "Teco Boot" To: "'Templin, Fred L'" Subject: RE: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Date: Wed, 6 Jun 2007 16:08:56 +0200 Message-ID: <006a01c7a844$3c8f5f60$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.3028 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED84C@XCH-NW-7V2.nw.nos.boeing.com> Thread-Index: Acenp+GZiUWdnd0kTDG/vI4CZAv0iAAmFyWAAACjyaA= X-OriginalArrivalTime: 06 Jun 2007 14:08:02.0714 (UTC) FILETIME=[1896FFA0:01C7A844] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d 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, 3 seconds to find it in 3963(intro): Within the context of this document, the definition of a Mobile Router extends that of a Mobile IPv6 [1] Mobile Node, by adding routing capability routing between its point of attachment (Care-of Address) and a subnet that moves with the Mobile Router. I think it just has to do with the order of publishing. Let's not spend time on this discussion. And you could read this (3753;-) Note: this reference architecture is not well suited for people dealing with Mobile Ad-hoc Networks (MANET). Regards, Teco > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: woensdag 6 juni 2007 15:51 > To: Alexandru Petrescu > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch- > 02.txt > > Alex, > > Based on my read, the RFC3753 definition for Mobile > Router makes no statement about Mobile IP or not. > > In terms of ingress/egress interfaces, IMHO a MANET > interface is neither/nor, i.e., a MANET interface is > not inherently in or out; up or down. In some respects > it might be considered as "sideways". > > Fred > fred.l.templin@boeing.com > > > -----Original Message----- > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > Sent: Tuesday, June 05, 2007 12:30 PM > > To: Templin, Fred L > > Cc: Ian Chakeres; autoconf@ietf.org > > Subject: Re: [Autoconf] Re: I-D > > ACTION:draft-ietf-autoconf-manetarch-02.txt > > > > Templin, Fred L wrote: > > > Alex, > > > > > > You would have to explain to me how Mobile Router necessarily > > > implies Mobile IP, but it would not be appropriate to draw that > > > distinction in terms of the MANET architecture document as I > > > think you know. > > > > FRed, I think I agree Mobile Router would not mean to > > everybody that it > > runs the Mobile IP protocol. It does so to me. > > > > And, the mobility terminology RFC3753 defines Mobile Router as: > > > Mobile Router (MR) > > > > > > A router capable of changing its point of attachment to the > > > network, moving from one link to another link. The > > MR is capable > > > of forwarding packets between two or more interfaces, > > and possibly > > > running a dynamic routing protocol modifying the > > state by which it > > > does packet forwarding. > > > > > > 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 reads to me very much as running Mobile IP and potentially a > > routing protocol too. > > > > But that existing definition is different than the manetarch document > > definition of a MANET router at least because it talks about > > e/ingress > > interface whereas the latter talks about 'classical' and > > 'MANET' interfaces: > > > > > MANET Router (MAN) > > > a MANET router embodies router functionality and may also > > > incorporate an internally addressable host (IAH) logic, as > > > illustrated in Figure 1. A MANET router has one or more > > > interfaces. To simplify discussion we will classify the > > > interfaces into two categories: classic IP interfaces & MANET > > > interfaces. MANET interfaces are defined as interfaces that > > > demonstrate asymmetric reachability and/or neighbor > > addresses that > > > are not known a priori. A MANET router may > > participate in routing > > > on zero or more MANET interfaces. A MANET router may > > participate > > > in routing on zero or more classic IP interfaces. A > > MANET router > > > may also have zero or more classic IP interfaces to > > which other > > > nodes may connect; i.e. the router may be responsible > > for several > > > IP prefixes. > > > > These two definitions are different. > > > > Of course, AUTOCONF and MANET WGs are free to re-define > > Mobile Router as > > they best see fit, and ignore the existent definition of a > > Mobile Router > > (just as NEMO people ignored the pre-existing LFN term). > > > > I think more would be gained if we could find coherency > > between the two > > notions of Mobile Router, and it starts at terminology... > > > > Alex > > > > > > ______________________________________________________________________ > > This email has been scanned by the MessageLabs Email Security System. > > For more information please visit http://www.messagelabs.com/email > > ______________________________________________________________________ > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jun 06 10:21:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvwO6-0002Al-7X; Wed, 06 Jun 2007 10:21:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvwO4-0002AZ-To for autoconf@ietf.org; Wed, 06 Jun 2007 10:21:24 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvwO2-0005eq-Bc for autoconf@ietf.org; Wed, 06 Jun 2007 10:21:24 -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 l56EL6Li028401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Jun 2007 07:21:21 -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 l56EL6Gc018967; Wed, 6 Jun 2007 09:21:06 -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 l56EL2H6018797; Wed, 6 Jun 2007 09:21:05 -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); Wed, 6 Jun 2007 07:21:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Date: Wed, 6 Jun 2007 07:20:22 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED84E@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <006a01c7a844$3c8f5f60$0202a8c0@Teco> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Thread-Index: Acenp+GZiUWdnd0kTDG/vI4CZAv0iAAmFyWAAACjyaAAAGKDsA== References: <39C363776A4E8C4A94691D2BD9D1C9A1029ED84C@XCH-NW-7V2.nw.nos.boeing.com> <006a01c7a844$3c8f5f60$0202a8c0@Teco> From: "Templin, Fred L" To: "Teco Boot" X-OriginalArrivalTime: 06 Jun 2007 14:21:01.0220 (UTC) FILETIME=[E89D9640:01C7A845] 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 Thanks Teco, but I don't see the autoconf documents citing RFC3963 yet. As to RFC3753, the text you quoted says that the *reference architecture* is not well suited to MANETs; it makes no statement about whether/not the *terminology* is well suited. In fact, earlier it says: "First, there is a list of terms for general use and mobile access networks followed by terms related to handovers, and finally some terms used within the MANET and NEMO working groups." That said, I am neutral as to whether the MANET arch should try to incorporate anything about Mobile Router or any other RFC3753 terms. Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl]=20 > Sent: Wednesday, June 06, 2007 7:09 AM > To: Templin, Fred L > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] Re: I-D=20 > ACTION:draft-ietf-autoconf-manetarch-02.txt >=20 > Hi Fred, >=20 > 3 seconds to find it in 3963(intro): > Within the context of this document, the definition of a Mobile > Router extends that of a Mobile IPv6 [1] Mobile Node, by adding > routing capability routing between its point of attachment (Care-of > Address) and a subnet that moves with the Mobile Router. >=20 > I think it just has to do with the order of publishing. Let's=20 > not spend time > on this discussion. >=20 > And you could read this (3753;-) > Note: this reference architecture is not well suited for people > dealing with Mobile Ad-hoc Networks (MANET). >=20 > Regards, Teco >=20 > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: woensdag 6 juni 2007 15:51 > > To: Alexandru Petrescu > > Cc: autoconf@ietf.org > > Subject: RE: [Autoconf] Re: I-D=20 > ACTION:draft-ietf-autoconf-manetarch- > > 02.txt > >=20 > > Alex, > >=20 > > Based on my read, the RFC3753 definition for Mobile > > Router makes no statement about Mobile IP or not. > >=20 > > In terms of ingress/egress interfaces, IMHO a MANET > > interface is neither/nor, i.e., a MANET interface is > > not inherently in or out; up or down. In some respects > > it might be considered as "sideways". > >=20 > > Fred > > fred.l.templin@boeing.com > >=20 > > > -----Original Message----- > > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > > Sent: Tuesday, June 05, 2007 12:30 PM > > > To: Templin, Fred L > > > Cc: Ian Chakeres; autoconf@ietf.org > > > Subject: Re: [Autoconf] Re: I-D > > > ACTION:draft-ietf-autoconf-manetarch-02.txt > > > > > > Templin, Fred L wrote: > > > > Alex, > > > > > > > > You would have to explain to me how Mobile Router necessarily > > > > implies Mobile IP, but it would not be appropriate to draw that > > > > distinction in terms of the MANET architecture document as I > > > > think you know. > > > > > > FRed, I think I agree Mobile Router would not mean to > > > everybody that it > > > runs the Mobile IP protocol. It does so to me. > > > > > > And, the mobility terminology RFC3753 defines Mobile Router as: > > > > Mobile Router (MR) > > > > > > > > A router capable of changing its point of=20 > attachment to the > > > > network, moving from one link to another link. The > > > MR is capable > > > > of forwarding packets between two or more interfaces, > > > and possibly > > > > running a dynamic routing protocol modifying the > > > state by which it > > > > does packet forwarding. > > > > > > > > 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=20 > of the MR's > > > > egress interface; packets forwarded downstream to=20 > the mobile > > > > network are transmitted through one of the MR's > > > ingress interface. > > > > > > This reads to me very much as running Mobile IP and potentially a > > > routing protocol too. > > > > > > But that existing definition is different than the=20 > manetarch document > > > definition of a MANET router at least because it talks about > > > e/ingress > > > interface whereas the latter talks about 'classical' and > > > 'MANET' interfaces: > > > > > > > MANET Router (MAN) > > > > a MANET router embodies router functionality and may also > > > > incorporate an internally addressable host (IAH) logic, as > > > > illustrated in Figure 1. A MANET router has one or more > > > > interfaces. To simplify discussion we will classify the > > > > interfaces into two categories: classic IP=20 > interfaces & MANET > > > > interfaces. MANET interfaces are defined as=20 > interfaces that > > > > demonstrate asymmetric reachability and/or neighbor > > > addresses that > > > > are not known a priori. A MANET router may > > > participate in routing > > > > on zero or more MANET interfaces. A MANET router may > > > participate > > > > in routing on zero or more classic IP interfaces. A > > > MANET router > > > > may also have zero or more classic IP interfaces to > > > which other > > > > nodes may connect; i.e. the router may be responsible > > > for several > > > > IP prefixes. > > > > > > These two definitions are different. > > > > > > Of course, AUTOCONF and MANET WGs are free to re-define > > > Mobile Router as > > > they best see fit, and ignore the existent definition of a > > > Mobile Router > > > (just as NEMO people ignored the pre-existing LFN term). > > > > > > I think more would be gained if we could find coherency > > > between the two > > > notions of Mobile Router, and it starts at terminology... > > > > > > Alex > > > > > > > > >=20 > ______________________________________________________________________ > > > This email has been scanned by the MessageLabs Email=20 > Security System. > > > For more information please visit http://www.messagelabs.com/email > > >=20 > ______________________________________________________________________ > > > > >=20 > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www1.ietf.org/mailman/listinfo/autoconf >=20 >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jun 06 10:26:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvwSX-0006bq-3l; Wed, 06 Jun 2007 10:26:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvwSW-0006bl-Em for autoconf@ietf.org; Wed, 06 Jun 2007 10:26:00 -0400 Received: from mail128.messagelabs.com ([216.82.250.131]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HvwSW-00067G-0G for autoconf@ietf.org; Wed, 06 Jun 2007 10:26:00 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-15.tower-128.messagelabs.com!1181139958!12205813!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 16091 invoked from network); 6 Jun 2007 14:25:58 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-15.tower-128.messagelabs.com with SMTP; 6 Jun 2007 14:25:58 -0000 Received: from az33exr03.mot.com ([10.64.251.233]) by motgate8.mot.com (8.12.11/Motorola) with ESMTP id l56EPwnk016561; Wed, 6 Jun 2007 07:25:58 -0700 (MST) Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr03.mot.com (8.13.1/Vontu) with SMTP id l56EPvgR014932; Wed, 6 Jun 2007 09:25:57 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr03.mot.com (8.13.1/8.13.0) with ESMTP id l56EPtLt014838; Wed, 6 Jun 2007 09:25:56 -0500 (CDT) Message-ID: <4666C3ED.9080904@gmail.com> Date: Wed, 06 Jun 2007 16:25:49 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: MANET interface is MR's ingress interface (was: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt) References: <465FE3E3.8080601@gmail.com><374005f30706020432m6dd817e1q881da76fbf4d9222@mail.gmail.com><46641436.20805@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED83C@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED843@XCH-NW-7V2.nw.nos.boeing.com> <4665A663.9050000@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED846@XCH-NW-7V2.nw.nos.boeing.com> <4665B9A7.8000309@gmail.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED84C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED84C@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000747-1, 05/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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 Templin, Fred L wrote: > Alex, > > Based on my read, the RFC3753 definition for Mobile Router makes no > statement about Mobile IP or not. It doesn't, but it's obvious to my reading, deduced from the fact that it says the MR attaches to different points of attachment to the Internet. To do that, the MR must run Mobile IP. The only alternatives I can think of are HIP and MOBIKE, but not MANET. > In terms of ingress/egress interfaces, IMHO a MANET interface is > neither/nor, i.e., a MANET interface is not inherently in or out; up > or down. In some respects it might be considered as "sideways". I think I agree with the sideways aspect and that it looks more equipotential interface, no directivity. That is related to the fact that MANET doesn't discuss the existence or absence of a default route, and little about the reachability to Internet. If it did then it would have been more directed interfaces. For MANEMO, a case of Mobile Router that was widely discussed is where the router has an egress interfaces on which NEMOv6 is run and an ingress interface on which a MANET protocol is run; thus the MR's ingress interface is a MMR's MANET interface... or so. I think I will suggest that to MANEMO. Alex > > Fred fred.l.templin@boeing.com > >> -----Original Message----- From: Alexandru Petrescu >> [mailto:alexandru.petrescu@gmail.com] Sent: Tuesday, June 05, 2007 >> 12:30 PM To: Templin, Fred L Cc: Ian Chakeres; autoconf@ietf.org >> Subject: Re: [Autoconf] Re: I-D >> ACTION:draft-ietf-autoconf-manetarch-02.txt >> >> Templin, Fred L wrote: >>> Alex, >>> >>> You would have to explain to me how Mobile Router necessarily >>> implies Mobile IP, but it would not be appropriate to draw that >>> distinction in terms of the MANET architecture document as I >>> think you know. >> FRed, I think I agree Mobile Router would not mean to everybody >> that it runs the Mobile IP protocol. It does so to me. >> >> And, the mobility terminology RFC3753 defines Mobile Router as: >>> Mobile Router (MR) >>> >>> A router capable of changing its point of attachment to the >>> network, moving from one link to another link. The >> MR is capable >>> of forwarding packets between two or more interfaces, >> and possibly >>> running a dynamic routing protocol modifying the >> state by which it >>> does packet forwarding. >>> >>> 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 reads to me very much as running Mobile IP and potentially a >> routing protocol too. >> >> But that existing definition is different than the manetarch >> document definition of a MANET router at least because it talks >> about e/ingress interface whereas the latter talks about >> 'classical' and 'MANET' interfaces: >> >>> MANET Router (MAN) a MANET router embodies router functionality >>> and may also incorporate an internally addressable host (IAH) >>> logic, as illustrated in Figure 1. A MANET router has one or >>> more interfaces. To simplify discussion we will classify the >>> interfaces into two categories: classic IP interfaces & MANET >>> interfaces. MANET interfaces are defined as interfaces that >>> demonstrate asymmetric reachability and/or neighbor >> addresses that >>> are not known a priori. A MANET router may >> participate in routing >>> on zero or more MANET interfaces. A MANET router may >> participate >>> in routing on zero or more classic IP interfaces. A >> MANET router >>> may also have zero or more classic IP interfaces to >> which other >>> nodes may connect; i.e. the router may be responsible >> for several >>> IP prefixes. >> These two definitions are different. >> >> Of course, AUTOCONF and MANET WGs are free to re-define Mobile >> Router as they best see fit, and ignore the existent definition of >> a Mobile Router (just as NEMO people ignored the pre-existing LFN >> term). >> >> I think more would be gained if we could find coherency between the >> two notions of Mobile Router, and it starts at terminology... >> >> Alex >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security >> System. For more information please visit >> http://www.messagelabs.com/email >> ______________________________________________________________________ >> >> > ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jun 06 10:57: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 1Hvwwb-0000Gc-9C; Wed, 06 Jun 2007 10:57:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvwwZ-0000GX-J7 for autoconf@ietf.org; Wed, 06 Jun 2007 10:57:03 -0400 Received: from hpsmtp-eml14.kpnxchange.com ([213.75.38.114]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvwwY-0002Ac-QP for autoconf@ietf.org; Wed, 06 Jun 2007 10:57:03 -0400 Received: from hpsmtp-eml08.kpnxchange.com ([213.75.38.108]) by hpsmtp-eml14.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 16:57:01 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 16:57:00 +0200 From: "Teco Boot" To: "'Templin, Fred L'" Subject: RE: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Date: Wed, 6 Jun 2007 16:57:58 +0200 Message-ID: <006b01c7a84b$138c8be0$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.3028 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED84E@XCH-NW-7V2.nw.nos.boeing.com> Thread-Index: Acenp+GZiUWdnd0kTDG/vI4CZAv0iAAmFyWAAACjyaAAAGKDsAABNh5Q X-OriginalArrivalTime: 06 Jun 2007 14:57:00.0329 (UTC) FILETIME=[EF8B7990:01C7A84A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 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 started the overlapping MR acronym. This as a reaction on the discussion on LFN. I think MR and MR (for a MANET Router and a Mobile Router) could be more confusing than LFN and LFN (Long Fat Network and Local Fixed Network). I expect routers are or will be MR and MR, some are only MR, others are the opposite and just MR and some are not MR at all. I use the abbreviation just to show there could be some confusion; in other context I will use full names. For new documents, we can discuss the acronym used. It would be helpful to come up with something useful and stop the discussion as soon as possible. And also, new documents should try to obey RFC3753 and draft-ietf-nemo-terminology, which is to be published as RFC soon. Regards, Teco > -----Original Message----- > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > Sent: woensdag 6 juni 2007 16:20 > To: Teco Boot > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch- > 02.txt > > Thanks Teco, but I don't see the autoconf documents citing > RFC3963 yet. As to RFC3753, the text you quoted says that > the *reference architecture* is not well suited to MANETs; > it makes no statement about whether/not the *terminology* > is well suited. In fact, earlier it says: > > "First, there is a list of terms for general use and mobile access > networks followed by terms related to handovers, and finally some > terms used within the MANET and NEMO working groups." > > That said, I am neutral as to whether the MANET arch should > try to incorporate anything about Mobile Router or any other > RFC3753 terms. > > Fred > fred.l.templin@boeing.com > > > -----Original Message----- > > From: Teco Boot [mailto:teco@inf-net.nl] > > Sent: Wednesday, June 06, 2007 7:09 AM > > To: Templin, Fred L > > Cc: autoconf@ietf.org > > Subject: RE: [Autoconf] Re: I-D > > ACTION:draft-ietf-autoconf-manetarch-02.txt > > > > Hi Fred, > > > > 3 seconds to find it in 3963(intro): > > Within the context of this document, the definition of a Mobile > > Router extends that of a Mobile IPv6 [1] Mobile Node, by adding > > routing capability routing between its point of attachment (Care-of > > Address) and a subnet that moves with the Mobile Router. > > > > I think it just has to do with the order of publishing. Let's > > not spend time > > on this discussion. > > > > And you could read this (3753;-) > > Note: this reference architecture is not well suited for people > > dealing with Mobile Ad-hoc Networks (MANET). > > > > Regards, Teco > > > > > -----Original Message----- > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > Sent: woensdag 6 juni 2007 15:51 > > > To: Alexandru Petrescu > > > Cc: autoconf@ietf.org > > > Subject: RE: [Autoconf] Re: I-D > > ACTION:draft-ietf-autoconf-manetarch- > > > 02.txt > > > > > > Alex, > > > > > > Based on my read, the RFC3753 definition for Mobile > > > Router makes no statement about Mobile IP or not. > > > > > > In terms of ingress/egress interfaces, IMHO a MANET > > > interface is neither/nor, i.e., a MANET interface is > > > not inherently in or out; up or down. In some respects > > > it might be considered as "sideways". > > > > > > Fred > > > fred.l.templin@boeing.com > > > > > > > -----Original Message----- > > > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > > > Sent: Tuesday, June 05, 2007 12:30 PM > > > > To: Templin, Fred L > > > > Cc: Ian Chakeres; autoconf@ietf.org > > > > Subject: Re: [Autoconf] Re: I-D > > > > ACTION:draft-ietf-autoconf-manetarch-02.txt > > > > > > > > Templin, Fred L wrote: > > > > > Alex, > > > > > > > > > > You would have to explain to me how Mobile Router necessarily > > > > > implies Mobile IP, but it would not be appropriate to draw that > > > > > distinction in terms of the MANET architecture document as I > > > > > think you know. > > > > > > > > FRed, I think I agree Mobile Router would not mean to > > > > everybody that it > > > > runs the Mobile IP protocol. It does so to me. > > > > > > > > And, the mobility terminology RFC3753 defines Mobile Router as: > > > > > Mobile Router (MR) > > > > > > > > > > A router capable of changing its point of > > attachment to the > > > > > network, moving from one link to another link. The > > > > MR is capable > > > > > of forwarding packets between two or more interfaces, > > > > and possibly > > > > > running a dynamic routing protocol modifying the > > > > state by which it > > > > > does packet forwarding. > > > > > > > > > > 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 reads to me very much as running Mobile IP and potentially a > > > > routing protocol too. > > > > > > > > But that existing definition is different than the > > manetarch document > > > > definition of a MANET router at least because it talks about > > > > e/ingress > > > > interface whereas the latter talks about 'classical' and > > > > 'MANET' interfaces: > > > > > > > > > MANET Router (MAN) > > > > > a MANET router embodies router functionality and may also > > > > > incorporate an internally addressable host (IAH) logic, as > > > > > illustrated in Figure 1. A MANET router has one or more > > > > > interfaces. To simplify discussion we will classify the > > > > > interfaces into two categories: classic IP > > interfaces & MANET > > > > > interfaces. MANET interfaces are defined as > > interfaces that > > > > > demonstrate asymmetric reachability and/or neighbor > > > > addresses that > > > > > are not known a priori. A MANET router may > > > > participate in routing > > > > > on zero or more MANET interfaces. A MANET router may > > > > participate > > > > > in routing on zero or more classic IP interfaces. A > > > > MANET router > > > > > may also have zero or more classic IP interfaces to > > > > which other > > > > > nodes may connect; i.e. the router may be responsible > > > > for several > > > > > IP prefixes. > > > > > > > > These two definitions are different. > > > > > > > > Of course, AUTOCONF and MANET WGs are free to re-define > > > > Mobile Router as > > > > they best see fit, and ignore the existent definition of a > > > > Mobile Router > > > > (just as NEMO people ignored the pre-existing LFN term). > > > > > > > > I think more would be gained if we could find coherency > > > > between the two > > > > notions of Mobile Router, and it starts at terminology... > > > > > > > > Alex > > > > > > > > > > > > > > ______________________________________________________________________ > > > > This email has been scanned by the MessageLabs Email > > Security System. > > > > For more information please visit http://www.messagelabs.com/email > > > > > > ______________________________________________________________________ > > > > > > > > > > _______________________________________________ > > > Autoconf mailing list > > > Autoconf@ietf.org > > > https://www1.ietf.org/mailman/listinfo/autoconf > > > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jun 06 11:09:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvx94-0004XS-6a; Wed, 06 Jun 2007 11:09:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hvx92-0004XI-Tj for autoconf@ietf.org; Wed, 06 Jun 2007 11:09:56 -0400 Received: from errol.lancs.ac.uk ([148.88.0.66]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hvx92-0004Oh-3Z for autoconf@ietf.org; Wed, 06 Jun 2007 11:09:56 -0400 Received: from mail02.lancs.ac.uk ([148.88.1.54]) by errol.lancs.ac.uk with esmtp (Exim 4.60) (envelope-from ) id 1Hvx91-0001yZ-Jp; Wed, 06 Jun 2007 16:09:55 +0100 Received: from issw-f833.vpn.local ([10.56.248.51] helo=MCLAPTOP) by mail02.lancs.ac.uk with esmtp (Exim 4.66) (envelope-from ) id 1Hvx91-0007Wb-0v; Wed, 06 Jun 2007 16:09:55 +0100 From: "Ben McCarthy" To: "'Teco Boot'" , "'Templin, Fred L'" Subject: RE: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Date: Wed, 6 Jun 2007 16:09:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 In-Reply-To: <006b01c7a84b$138c8be0$0202a8c0@Teco> thread-index: Acenp+GZiUWdnd0kTDG/vI4CZAv0iAAmFyWAAACjyaAAAGKDsAABNh5QAACWywA= X-Spam-Score: 0.0 (/) X-Scan-Signature: f2728948111f2edaaf8980b5b9de55af 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 Message-Id: Hi Teco, > -----Original Message----- > From: Teco Boot [mailto:teco@inf-net.nl] > Sent: 06 June 2007 15:58 > To: 'Templin, Fred L' > Cc: autoconf@ietf.org > Subject: RE: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch- > 02.txt > > Hi Fred, > > I started the overlapping MR acronym. This as a reaction on the discussion > on LFN. I think MR and MR (for a MANET Router and a Mobile Router) could > be > more confusing than LFN and LFN (Long Fat Network and Local Fixed > Network). > > I expect routers are or will be MR and MR, some are only MR, others are > the > opposite and just MR and some are not MR at all. I use the abbreviation > just > to show there could be some confusion; in other context I will use full > names. > I think Fred's original proposal on this was that in situations where the two terms could coincide you could use MMR for "MANET MR" and then in purely MANET situations you could just use MR. Is my thinking correct here Fred? Cheers, Ben > For new documents, we can discuss the acronym used. It would be helpful to > come up with something useful and stop the discussion as soon as possible. > > And also, new documents should try to obey RFC3753 and > draft-ietf-nemo-terminology, which is to be published as RFC soon. > > Regards, Teco > > > -----Original Message----- > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > Sent: woensdag 6 juni 2007 16:20 > > To: Teco Boot > > Cc: autoconf@ietf.org > > Subject: RE: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch- > > 02.txt > > > > Thanks Teco, but I don't see the autoconf documents citing > > RFC3963 yet. As to RFC3753, the text you quoted says that > > the *reference architecture* is not well suited to MANETs; > > it makes no statement about whether/not the *terminology* > > is well suited. In fact, earlier it says: > > > > "First, there is a list of terms for general use and mobile access > > networks followed by terms related to handovers, and finally some > > terms used within the MANET and NEMO working groups." > > > > That said, I am neutral as to whether the MANET arch should > > try to incorporate anything about Mobile Router or any other > > RFC3753 terms. > > > > Fred > > fred.l.templin@boeing.com > > > > > -----Original Message----- > > > From: Teco Boot [mailto:teco@inf-net.nl] > > > Sent: Wednesday, June 06, 2007 7:09 AM > > > To: Templin, Fred L > > > Cc: autoconf@ietf.org > > > Subject: RE: [Autoconf] Re: I-D > > > ACTION:draft-ietf-autoconf-manetarch-02.txt > > > > > > Hi Fred, > > > > > > 3 seconds to find it in 3963(intro): > > > Within the context of this document, the definition of a Mobile > > > Router extends that of a Mobile IPv6 [1] Mobile Node, by adding > > > routing capability routing between its point of attachment (Care-of > > > Address) and a subnet that moves with the Mobile Router. > > > > > > I think it just has to do with the order of publishing. Let's > > > not spend time > > > on this discussion. > > > > > > And you could read this (3753;-) > > > Note: this reference architecture is not well suited for people > > > dealing with Mobile Ad-hoc Networks (MANET). > > > > > > Regards, Teco > > > > > > > -----Original Message----- > > > > From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com] > > > > Sent: woensdag 6 juni 2007 15:51 > > > > To: Alexandru Petrescu > > > > Cc: autoconf@ietf.org > > > > Subject: RE: [Autoconf] Re: I-D > > > ACTION:draft-ietf-autoconf-manetarch- > > > > 02.txt > > > > > > > > Alex, > > > > > > > > Based on my read, the RFC3753 definition for Mobile > > > > Router makes no statement about Mobile IP or not. > > > > > > > > In terms of ingress/egress interfaces, IMHO a MANET > > > > interface is neither/nor, i.e., a MANET interface is > > > > not inherently in or out; up or down. In some respects > > > > it might be considered as "sideways". > > > > > > > > Fred > > > > fred.l.templin@boeing.com > > > > > > > > > -----Original Message----- > > > > > From: Alexandru Petrescu [mailto:alexandru.petrescu@gmail.com] > > > > > Sent: Tuesday, June 05, 2007 12:30 PM > > > > > To: Templin, Fred L > > > > > Cc: Ian Chakeres; autoconf@ietf.org > > > > > Subject: Re: [Autoconf] Re: I-D > > > > > ACTION:draft-ietf-autoconf-manetarch-02.txt > > > > > > > > > > Templin, Fred L wrote: > > > > > > Alex, > > > > > > > > > > > > You would have to explain to me how Mobile Router necessarily > > > > > > implies Mobile IP, but it would not be appropriate to draw that > > > > > > distinction in terms of the MANET architecture document as I > > > > > > think you know. > > > > > > > > > > FRed, I think I agree Mobile Router would not mean to > > > > > everybody that it > > > > > runs the Mobile IP protocol. It does so to me. > > > > > > > > > > And, the mobility terminology RFC3753 defines Mobile Router as: > > > > > > Mobile Router (MR) > > > > > > > > > > > > A router capable of changing its point of > > > attachment to the > > > > > > network, moving from one link to another link. The > > > > > MR is capable > > > > > > of forwarding packets between two or more interfaces, > > > > > and possibly > > > > > > running a dynamic routing protocol modifying the > > > > > state by which it > > > > > > does packet forwarding. > > > > > > > > > > > > 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 reads to me very much as running Mobile IP and potentially a > > > > > routing protocol too. > > > > > > > > > > But that existing definition is different than the > > > manetarch document > > > > > definition of a MANET router at least because it talks about > > > > > e/ingress > > > > > interface whereas the latter talks about 'classical' and > > > > > 'MANET' interfaces: > > > > > > > > > > > MANET Router (MAN) > > > > > > a MANET router embodies router functionality and may also > > > > > > incorporate an internally addressable host (IAH) logic, as > > > > > > illustrated in Figure 1. A MANET router has one or more > > > > > > interfaces. To simplify discussion we will classify the > > > > > > interfaces into two categories: classic IP > > > interfaces & MANET > > > > > > interfaces. MANET interfaces are defined as > > > interfaces that > > > > > > demonstrate asymmetric reachability and/or neighbor > > > > > addresses that > > > > > > are not known a priori. A MANET router may > > > > > participate in routing > > > > > > on zero or more MANET interfaces. A MANET router may > > > > > participate > > > > > > in routing on zero or more classic IP interfaces. A > > > > > MANET router > > > > > > may also have zero or more classic IP interfaces to > > > > > which other > > > > > > nodes may connect; i.e. the router may be responsible > > > > > for several > > > > > > IP prefixes. > > > > > > > > > > These two definitions are different. > > > > > > > > > > Of course, AUTOCONF and MANET WGs are free to re-define > > > > > Mobile Router as > > > > > they best see fit, and ignore the existent definition of a > > > > > Mobile Router > > > > > (just as NEMO people ignored the pre-existing LFN term). > > > > > > > > > > I think more would be gained if we could find coherency > > > > > between the two > > > > > notions of Mobile Router, and it starts at terminology... > > > > > > > > > > Alex > > > > > > > > > > > > > > > > > > ______________________________________________________________________ > > > > > This email has been scanned by the MessageLabs Email > > > Security System. > > > > > For more information please visit http://www.messagelabs.com/email > > > > > > > > ______________________________________________________________________ > > > > > > > > > > > > > _______________________________________________ > > > > Autoconf mailing list > > > > Autoconf@ietf.org > > > > https://www1.ietf.org/mailman/listinfo/autoconf > > > > > > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jun 06 11:17:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvxGG-00019O-5q; Wed, 06 Jun 2007 11:17:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvxGF-00019J-Gb for autoconf@ietf.org; Wed, 06 Jun 2007 11:17:23 -0400 Received: from blv-smtpout-01.boeing.com ([130.76.32.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvxGD-00062p-7O for autoconf@ietf.org; Wed, 06 Jun 2007 11:17:23 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id l56FH9GP010770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Jun 2007 08:17:15 -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 l56FH9fF022772; Wed, 6 Jun 2007 08:17:09 -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 l56FH7RY022694; Wed, 6 Jun 2007 08:17:09 -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, 6 Jun 2007 08:16:35 -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] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Date: Wed, 6 Jun 2007 08:16:17 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED851@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <200706061509.l56F9uq3002037@slb-smtpin-01.ns.cs.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-02.txt Thread-Index: Acenp+GZiUWdnd0kTDG/vI4CZAv0iAAmFyWAAACjyaAAAGKDsAABNh5QAACWywAAAFFLMA== References: <006b01c7a84b$138c8be0$0202a8c0@Teco> <200706061509.l56F9uq3002037@slb-smtpin-01.ns.cs.boeing.com> From: "Templin, Fred L" To: "Ben McCarthy" , "Teco Boot" X-OriginalArrivalTime: 06 Jun 2007 15:16:35.0821 (UTC) FILETIME=[AC3151D0:01C7A84D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 > I think Fred's original proposal on this was that in=20 > situations where the > two terms could coincide you could use MMR for "MANET MR" and=20 > then in purely > MANET situations you could just use MR. I think Teco has said why he doesn't like "MR" for "MANET Router" in any situation. I am neutral on "MMR" for "MANET MR"; I have a slight preference towards "MNR" for "MaNet Router". Fred fred.l.templin@boeing.com _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Wed Jun 06 11:25:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvxOE-0004TZ-8w; Wed, 06 Jun 2007 11:25:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HvxOD-0004TU-9l for autoconf@ietf.org; Wed, 06 Jun 2007 11:25:37 -0400 Received: from hpsmtp-eml14.kpnxchange.com ([213.75.38.114]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HvxOC-00080E-HT for autoconf@ietf.org; Wed, 06 Jun 2007 11:25:37 -0400 Received: from hpsmtp-eml09.kpnxchange.com ([213.75.38.109]) by hpsmtp-eml14.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 17:25:35 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml09.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 6 Jun 2007 17:25:35 +0200 From: "Teco Boot" To: "'Templin, Fred L'" , "'Ben McCarthy'" Subject: FW: [Autoconf] MR terminology Date: Wed, 6 Jun 2007 17:26:28 +0200 Message-ID: <007401c7a84f$11bb2a70$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.3028 Thread-Index: AceHBMiwQuH8MkHCSZGCWVjnD1m1pQAAXXLQCFHel5A= X-OriginalArrivalTime: 06 Jun 2007 15:25:35.0289 (UTC) FILETIME=[EDBD9A90:01C7A84E] X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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, Ben, Here an old copy with exactly the same "original" MMR suggestion. NMR could be used where a NEMO Mobile Router is meant. In a new document, for example the MANET.arch, we could define the new acronyms. We could kick out MANET Router and define MR as Mobile Router. Is the document about MANET only, it is OK, the MR runs a MANET protocol. If the document is about NEMO only, also OK, the MR runs NEMO. In MANEMO documents, where a mixed setup is discussed, with nodes and routers running MIP, MANET and NEMO things can be confusing and the full acronyms MMR, NMR, MMN, MN etc. shall be used (Mobile Node and Manet Node has same problems). Some would prefer using the term MANET Router. Regards, Teco -----Original Message----- From: Teco Boot [mailto:teco@inf-net.nl] Sent: woensdag 25 april 2007 9:28 To: 'Ian Chakeres' Subject: RE: [Autoconf] MR terminology Hi Ian, Jari forced us (MANEMO folks) to work on a clear problem statement and after some consensus find solutions ;-). I think MR for Mobile Router is commonly used, also in STD Tracks RFCs (e.g. RFC3963 NEMO Basic). MANET Experimental RFCs doesn't use MR. So changing the MANET Router abbreviation seems more logical. Similar problem: MIP Home Agent and Home Address uses HA and HoA. I don't like such a solution, e.g. MaR for MANER Router. Some use MAR for Mobile Access Router (Cisco does, the Cisco MAR runs NEMO and not MANET!!!). MANETarch use RT for Router. MRT could be used fro MANET RT. Another approach would be using a prefix, e.g. NMR for NEMO Mobile Router and MMR for MANET MANET Router. The MM in MMR is double, to be solved in the next option. The two could also converge, and an architecture for the Mobile Domain could include MANET and MIP/NEMO. Then MR is Mobile Router, running both a MANET protocol and a Mobile IP stack. This is my personal favorite. But it is not providing a clear solution for our short term problem. This option could be used with the previous: MR is a Mobile Router in the Mobile domain, either running MANET or NEMO. NMR is more specific, it runs NEMO only. MMR is a MANET-only Mobile Router. By the way, MN has the same problem; it stands for MANET Node (MANETarch) and for Mobile Node (RFC3753). Also the usage of the term Node should be verified. Within IETF, the term is used for a Host or a Router. Things are mixed up in MANETarch, there a Node is a Router and a set of hosts (set is 0 or more). Also one of the hosts in the MN could be a router, like a LFR in RFC3963 / LFN in NEMOterms. I think we should discuss this with the NEMO WG chairs. A new I-D could be written for an informational RFC updating 3753 for both NEMO and MANET. I think it would be better to replace RFC3753. A single RFC defining all terminology for the mobile domain without duplicates is helpful. Regards, Teco > -----Original Message----- > From: Ian Chakeres [mailto:ian.chakeres@gmail.com] > Sent: woensdag 25 april 2007 8:42 > To: Teco Boot > Subject: Re: [Autoconf] MR terminology > > Do you have a suggestion on another term for either the Mobile Router > or MANET Router? > > Ian > > On 4/25/07, Teco Boot wrote: > > Hi all, > > > > I think the abbreviation MR is confusing. In a NEMO context it stands > for > > Mobile Router, where in MANET context is stands for MANET Router. Those > two > > are very different. > > > > > > RFC 3753 Mobility Related Terminology & draft-ietf-nemo-terminology-06: > > > > Mobile Router (MR) > > > > A router capable of changing its point of attachment to the > > network, moving from one link to another link. The MR is capable > > of forwarding packets between two or more interfaces, and possibly > > running a dynamic routing protocol modifying the state by which it > > does packet forwarding. > > > > 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. > > > > > > draft-ietf-autoconf-manetarch-01: > > > > MANET Router (MR) > > an entity that has one or more MANET interfaces and that engages > > in a MANET routing protocol. A MANET router may also have zero or > > more classic IP interfaces to which hosts may connect. > > > > > > So a router could be no MR, a MR, a MR or a MR and MR. > > > > Also publish on MANET ML? > > > > Regards, Teco > > > > > > _______________________________________________ > > Autoconf mailing list > > Autoconf@ietf.org > > https://www1.ietf.org/mailman/listinfo/autoconf > > _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Tue Jun 19 15:51:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jjd-0004J4-Fh; Tue, 19 Jun 2007 15:51:29 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I0jil-0002Un-Ou for autoconf-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 15:50:35 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jii-0002L0-O2; Tue, 19 Jun 2007 15:50:33 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0jii-0002Hj-CF; Tue, 19 Jun 2007 15:50:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 4E6972ACB7; Tue, 19 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I0jiE-0004lB-1c; Tue, 19 Jun 2007 15:50:02 -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: Tue, 19 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: autoconf@ietf.org Subject: [Autoconf] I-D ACTION: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 --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 : Address Autoconfiguration for MANET: Terminology and Problem Statement Author(s) : E. Baccelli, et al. Filename : draft-ietf-autoconf-statement-00.txt Pages : 16 Date : 2007-6-19 Traditional dynamic IPv6 address assignment solutions are not adapted to mobile ad hoc networks. This document elaborates on this problem, states the need for new solutions, and requirements to these solutions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-autoconf-statement-00.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-statement-00.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-statement-00.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-6-19115108.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-autoconf-statement-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-autoconf-statement-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-19115108.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 Tue Jun 19 16: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 1I0k72-0001Pq-FI; Tue, 19 Jun 2007 16:15:40 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I0k70-0001Op-Qg for autoconf-confirm+ok@megatron.ietf.org; Tue, 19 Jun 2007 16:15:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0jik-0002NJ-6D; Tue, 19 Jun 2007 15:50:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I0jij-0002IR-MG; Tue, 19 Jun 2007 15:50:33 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id DE481175F8; Tue, 19 Jun 2007 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1I0jiE-0004mU-LX; Tue, 19 Jun 2007 15:50:02 -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: Tue, 19 Jun 2007 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: autoconf@ietf.org Subject: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-03.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-03.txt Pages : 21 Date : 2007-6-19 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-03.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-03.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-03.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-6-19141257.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-autoconf-manetarch-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-autoconf-manetarch-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2007-6-19141257.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 Jun 20 03:28: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 1I0uc9-0007X6-6X; Wed, 20 Jun 2007 03:28:29 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I0uc7-0007NZ-HF for autoconf-confirm+ok@megatron.ietf.org; Wed, 20 Jun 2007 03:28:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I0uc3-0007MM-SN for autoconf@ietf.org; Wed, 20 Jun 2007 03:28:23 -0400 Received: from hpsmtp-eml14.kpnxchange.com ([213.75.38.114]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I0uc2-0006r4-9s for autoconf@ietf.org; Wed, 20 Jun 2007 03:28:23 -0400 Received: from hpsmtp-eml08.kpnxchange.com ([213.75.38.108]) by hpsmtp-eml14.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 09:28:18 +0200 Received: from Teco ([86.83.9.22]) by hpsmtp-eml08.kpnxchange.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 20 Jun 2007 09:28:18 +0200 From: "Teco Boot" To: Date: Wed, 20 Jun 2007 09:29:14 +0200 Message-ID: <002501c7b30c$b46d7440$0202a8c0@Teco> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 Thread-Index: AceyrrHGKGavyygvRQmseGcdOwCrrgAVeLAg X-OriginalArrivalTime: 20 Jun 2007 07:28:18.0380 (UTC) FILETIME=[929890C0:01C7B30C] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Autoconf] autoconf-manetarch: IPv6 ND and asymmetric reachability 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 MANET-arch 4.1: Many protocols (e.g. IPv6 neighbor discovery [RFC2461]) do not operate in wireless networks with asymmetric reachability. After the update to -03; the statement is more precise. But I wonder if the problem is described somewhere. ND is the IPv6 replacement for ARP and performs much better than IPv4 ARP (RFC2461 3.1). I am aware it offers additional functions and those doesn't always work with SBI. But on the other hand, it provides NUD which is exactly what is needed with SBI. IMHO support for mobility is a valid reason switching to IPv6. Having ND is one argument. I would prefer a recommendation to use IPv6 as carrier for packetBB, also for IPv4 routed traffic. This would eliminate a need for ARP. I also prefer piggy bagging as much as possible. A way of doing this is sending ND and MANET routing protocol data in a single frame (L2) or packet (L3). Using ICMP ND as carrier is one idea. RFC2461 is made for it: APPENDIX B: FUTURE EXTENSIONS Adding additional procedures for links where asymmetric and non- transitive reachability is part of normal operations. Such procedures might allow hosts and routers to find usable paths on, e.g., radio links. Without some form of piggy bagging, we send packetBB and ND in separate packets. This is a waste of resources. Teco. _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Jun 28 23:41:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I47Mq-00064y-RY; Thu, 28 Jun 2007 23:41:56 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I47Mp-00064p-J0 for autoconf-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 23:41:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I47Mo-00064h-V6 for autoconf@ietf.org; Thu, 28 Jun 2007 23:41:54 -0400 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I47Mh-0004WU-Jv for autoconf@ietf.org; Thu, 28 Jun 2007 23:41:54 -0400 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 9BEAD3429F for ; Thu, 28 Jun 2007 23:41:53 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 23:40:56 -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 Subject: RE: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-03.txt Date: Thu, 28 Jun 2007 23:40:56 -0400 Message-ID: <816DD9299957E547B5D758D7F977D6DC021023D1@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-03.txt thread-index: Aceyrp28gs22VUj0QGCOQNEyaQeB3wHTGZAg References: From: "Bound, Jim" To: X-OriginalArrivalTime: 29 Jun 2007 03:40:56.0274 (UTC) FILETIME=[4CFC2320:01C7B9FF] X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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 Folks, my congrats to the authors and working group this is simply wonderful progress and well written and clear. Not clear we should add more and keep this as simple as it is now. I was very glad the IEEE 802.11s case was covered too. Best, /jim > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Tuesday, June 19, 2007 3:50 PM > To: i-d-announce@ietf.org > Cc: autoconf@ietf.org > Subject: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-03.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Ad-Hoc Network=20 > Autoconfiguration Working Group of the IETF. >=20 > Title : Mobile Ad hoc Network Architecture > Author(s) : I. Chakeres, et al. > Filename : draft-ietf-autoconf-manetarch-03.txt > Pages : 21 > Date : 2007-6-19 > =09 > This document discusses Mobile Ad hoc NETworks (MANETs). It > introduces basic MANET terms, characteristics, and=20 > challenges. This > document also defines several MANET entities and architectural > concepts. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-autoconf-maneta rch-03.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-autoconf-manetarch-03.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-autoconf-manetarch-03.txt". > =09 > 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=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Thu Jun 28 23:58:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I47ce-0007dg-Pm; Thu, 28 Jun 2007 23:58:16 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I47cd-0007Yy-Gw for autoconf-confirm+ok@megatron.ietf.org; Thu, 28 Jun 2007 23:58:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I47cd-0007XL-6i for autoconf@ietf.org; Thu, 28 Jun 2007 23:58:15 -0400 Received: from ccerelbas04.cce.hp.com ([161.114.21.107]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I47cN-00079T-Qe for autoconf@ietf.org; Thu, 28 Jun 2007 23:58:15 -0400 Received: from cceexg13.americas.cpqcorp.net (cceexg13.americas.cpqcorp.net [16.81.1.58]) by ccerelbas04.cce.hp.com (Postfix) with ESMTP id 649A9346FD for ; Thu, 28 Jun 2007 22:57:59 -0500 (CDT) Received: from cceexb11.americas.cpqcorp.net ([16.81.1.6]) by cceexg13.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 22:56:00 -0500 Received: from tayexb11.americas.cpqcorp.net ([16.103.130.93]) by cceexb11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 22:56:00 -0500 Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexb11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 28 Jun 2007 23:55:59 -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 Subject: RE: [Autoconf] I-D ACTION:draft-ietf-autoconf-statement-00.txt Date: Thu, 28 Jun 2007 23:55:58 -0400 Message-ID: <816DD9299957E547B5D758D7F977D6DC021023D4@tayexc14.americas.cpqcorp.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Autoconf] I-D ACTION:draft-ietf-autoconf-statement-00.txt thread-index: Aceyqz7EZHlwuwsxRZas5nKQl3edvQHVR1ZQ References: From: "Bound, Jim" To: X-OriginalArrivalTime: 29 Jun 2007 03:55:59.0269 (UTC) FILETIME=[67363D50:01C7BA01] X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 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 Authors, I am analyzing this draft now and it adds much value to autoconfiguration issues/discussion for classic IP network relations. =20 But before I go further can I ask do you support the direction of the current autoconfig manet arch document just sent out? =20 Is the objective of this work to only identify the technical issues? =20 Or will this eventually propose a solution per the guidelines in autoconfig manet arch for IP autoconfig? =20 What are your views on L3/L2 MESH via 802.11s or the work on MESH for 802.16, and is not the IETF work 6lowpan and 16ng relevant to this analysis as input, I think these need to be in your analysis?=20 Knowing this will skew my next read of this spec for input to the work? It is written well as a note, nice job. Thanks /jim > -----Original Message----- > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 > Sent: Tuesday, June 19, 2007 3:50 PM > To: i-d-announce@ietf.org > Cc: autoconf@ietf.org > Subject: [Autoconf] I-D ACTION:draft-ietf-autoconf-statement-00.txt=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Ad-Hoc Network=20 > Autoconfiguration Working Group of the IETF. >=20 > Title : Address Autoconfiguration for MANET:=20 > Terminology and Problem Statement > Author(s) : E. Baccelli, et al. > Filename : draft-ietf-autoconf-statement-00.txt > Pages : 16 > Date : 2007-6-19 > =09 > Traditional dynamic IPv6 address assignment solutions are=20 > not adapted > to mobile ad hoc networks. This document elaborates on=20 > this problem, > states the need for new solutions, and requirements to these > solutions. >=20 >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-autoconf-statem > ent-00.txt >=20 > To remove yourself from the I-D Announcement list, send a=20 > message to i-d-announce-request@ietf.org with the word=20 > unsubscribe in the body of the message.=20 > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. >=20 > Internet-Drafts are also available by anonymous FTP. Login=20 > with the username "anonymous" and a password of your e-mail=20 > address. After logging in, type "cd internet-drafts" and then=20 > "get draft-ietf-autoconf-statement-00.txt". >=20 > A list of Internet-Drafts directories can be found in=20 > http://www.ietf.org/shadow.html or=20 > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > Internet-Drafts can also be obtained by e-mail. >=20 > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-ietf-autoconf-statement-00.txt". > =09 > 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=20 > 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. >=20 > Below is the data which will enable a MIME compliant mail=20 > reader implementation to automatically retrieve the ASCII=20 > version of the Internet-Draft. >=20 _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jun 29 05:43: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 1I4D0o-00030b-3T; Fri, 29 Jun 2007 05:43:34 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I4D0m-00030V-NS for autoconf-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 05:43:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4D0m-00030N-BQ for autoconf@ietf.org; Fri, 29 Jun 2007 05:43:32 -0400 Received: from mail119.messagelabs.com ([216.82.241.179]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I4D0i-0001fN-2z for autoconf@ietf.org; Fri, 29 Jun 2007 05:43:32 -0400 X-VirusChecked: Checked X-Env-Sender: alexandru.petrescu@gmail.com X-Msg-Ref: server-4.tower-119.messagelabs.com!1183110207!22339424!1 X-StarScan-Version: 5.5.12.11; banners=.,-,- X-Originating-IP: [144.189.100.102] Received: (qmail 15250 invoked from network); 29 Jun 2007 09:43:27 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-4.tower-119.messagelabs.com with SMTP; 29 Jun 2007 09:43:27 -0000 Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id l5T9hQP6021692 for ; Fri, 29 Jun 2007 02:43:26 -0700 (MST) Received: from az10vts01 (az10vts01.mot.com [10.64.251.242]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id l5T9hPAG000980 for ; Fri, 29 Jun 2007 04:43:26 -0500 (CDT) Received: from [127.0.0.1] (zfr01-2117.crm.mot.com [10.161.201.117]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id l5T9hOuE000901 for ; Fri, 29 Jun 2007 04:43:24 -0500 (CDT) Message-ID: <4684D436.5050405@gmail.com> Date: Fri, 29 Jun 2007 11:43:18 +0200 From: Alexandru Petrescu User-Agent: Thunderbird 2.0.0.0 (Windows/20070326) MIME-Version: 1.0 To: autoconf@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000752-3, 28/06/2007), Outbound message X-Antivirus-Status: Clean X-Vontu: Pass X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Autoconf] Two 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 Hi authors, I have two quick comments on this problem statement. > For instance, in Fig. 1, even if MR1 would be able to delegate > prefixes to MR3 with DHCP [4], it cannot be assumed that MR1 and MR3 > will not move and become unable to communicate directly. It should also be said that if MNR1 and MNR2 move but keep their addresses stable, and if DYMO/OLSR/NHDP update the routes between their new positions, then DHCP Prefix Delegation can still be used as defined. > The distributed nature of MANETs brings the need for address > generation algorithms that are not always based on traditional > "client-server" schemes and hierarchies to provide MANET routers with > addresses and prefixes. I think it should also say that Internet has also a very distributed nature yet client-server schemes are sometimes needed. Alex ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________ _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf From autoconf-bounces@ietf.org Fri Jun 29 09:14: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 1I4GIv-0006fl-Do; Fri, 29 Jun 2007 09:14:29 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I4GIu-0006fc-0q for autoconf-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 09:14:28 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4GIt-0006fU-L8 for autoconf@ietf.org; Fri, 29 Jun 2007 09:14:27 -0400 Received: from mailout2.samsung.com ([203.254.224.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1I4GIs-0001JL-Og for autoconf@ietf.org; Fri, 29 Jun 2007 09:14:27 -0400 Received: from epmmp2 (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0JKE0096QFCRHO@mailout2.samsung.com> for autoconf@ietf.org; Fri, 29 Jun 2007 22:12:27 +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 <0JKE00DFSFCOTW@mmp2.samsung.com> for autoconf@ietf.org; Fri, 29 Jun 2007 22:12:27 +0900 (KST) Date: Fri, 29 Jun 2007 18:48:45 +0530 From: Shubhranshu To: "Bound, Jim" Message-id: <01d601c7ba50$072abd60$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.1 (/) X-Scan-Signature: 1e467ff145ef391eb7b594ef62b8301f Cc: autoconf@ietf.org Subject: [Autoconf] Re:I-D ACTION: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: , Content-Type: multipart/mixed; boundary="===============2031689601==" Errors-To: autoconf-bounces@ietf.org This is a multi-part message in MIME format. --===============2031689601== Content-type: multipart/alternative; boundary="Boundary_(ID_4LwTkoE9+96bl4h3gZ2MIQ)" This is a multi-part message in MIME format. --Boundary_(ID_4LwTkoE9+96bl4h3gZ2MIQ) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Please see inline comments. > ----- Original Message ----- > From: "Bound, Jim" > To: > Sent: Friday, June 29, 2007 9:25 AM > Subject: RE: [Autoconf] I-D ACTION:draft-ietf-autoconf-statement-00.txt > > Authors, I am analyzing this draft now and it adds much value to > autoconfiguration issues/discussion for classic IP network relations. > > But before I go further can I ask do you support the direction of the > current autoconfig manet arch document just sent out? > Yes > Is the objective of this work to only identify the technical issues? > > Or will this eventually propose a solution per the guidelines in > autoconfig manet arch for IP autoconfig? > The Problem statement document is focused on discussing the technical issues, and provide Autoconf related terminologies. > What are your views on L3/L2 MESH via 802.11s or the work on MESH for > 802.16, and is not the IETF work 6lowpan and 16ng relevant to this > analysis as input, I think these need to be in your analysis? > I think it would help to first know which aspect of these groups/work you are referring to and that you think is needed in the analysis. > Knowing this will skew my next read of this spec for input to the work? > > It is written well as a note, nice job. > :-) - Shubhranshu > Thanks > /jim > > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Tuesday, June 19, 2007 3:50 PM > > To: i-d-announce@ietf.org > > Cc: autoconf@ietf.org > > Subject: [Autoconf] I-D ACTION:draft-ietf-autoconf-statement-00.txt > > > > 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 : Address Autoconfiguration for MANET: > > Terminology and Problem Statement > > Author(s) : E. Baccelli, et al. > > Filename : draft-ietf-autoconf-statement-00.txt > > Pages : 16 > > Date : 2007-6-19 > > > > Traditional dynamic IPv6 address assignment solutions are > > not adapted > > to mobile ad hoc networks. This document elaborates on > > this problem, > > states the need for new solutions, and requirements to these > > solutions. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-autoconf-statem > > ent-00.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-statement-00.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-statement-00.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. > > > > > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf > > > --Boundary_(ID_4LwTkoE9+96bl4h3gZ2MIQ) Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: 7BIT
Please see inline comments.
 
> ----- Original Message -----
> From: "Bound, Jim" <Jim.Bound@hp.com>
> To: <autoconf@ietf.org>
> Sent: Friday, June 29, 2007 9:25 AM
> Subject: RE: [Autoconf] I-D ACTION:draft-ietf-autoconf-statement-00.txt
>
> Authors, I am analyzing this draft now and it adds much value to
> autoconfiguration issues/discussion for classic IP network relations.
>
> But before I go further can I ask do you support the direction of the
> current autoconfig manet arch document just sent out?
>
 
Yes
 
> Is the objective of this work to only identify the technical issues?
>
> Or will this eventually propose a solution per the guidelines in
> autoconfig manet arch for IP autoconfig?
>
 
The Problem statement document is focused on discussing the
technical issues, and provide Autoconf related terminologies.

> What are your views on L3/L2 MESH via 802.11s or the work on MESH for
> 802.16, and is not the IETF work 6lowpan and 16ng relevant to this
> analysis as input, I think these need to be in your analysis?
>
 
I think it would help to first know which aspect of these groups/work you are
referring to and that you think is needed in the analysis.

> Knowing this will skew my next read of this spec for input to the work?
>
> It is written well as a note, nice job.
>
 
:-)  
 
 
- Shubhranshu
 

> Thanks
> /jim
>
> > -----Original Message-----
> > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]
> > Sent: Tuesday, June 19, 2007 3:50 PM
> > To: i-d-announce@ietf.org
> > Cc: autoconf@ietf.org
> > Subject: [Autoconf] I-D ACTION:draft-ietf-autoconf-statement-00.txt
> >
> > 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 : Address Autoconfiguration for MANET:
> > Terminology and Problem Statement
> > Author(s) : E. Baccelli, et al.
> > Filename : draft-ietf-autoconf-statement-00.txt
> > Pages : 16
> > Date : 2007-6-19
> >
> >    Traditional dynamic IPv6 address assignment solutions are
> > not adapted
> >    to mobile ad hoc networks.  This document elaborates on
> > this problem,
> >    states the need for new solutions, and requirements to these
> >    solutions.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-autoconf-statem
> > ent-00.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-statement-00.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-statement-00.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.
> >
>
>
> _______________________________________________
> Autoconf mailing list
> Autoconf@ietf.org
> https://www1.ietf.org/mailman/listinfo/autoconf
>
>
>
--Boundary_(ID_4LwTkoE9+96bl4h3gZ2MIQ)-- --===============2031689601== 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 --===============2031689601==-- From autoconf-bounces@ietf.org Fri Jun 29 13:05:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ju9-0005rp-8l; Fri, 29 Jun 2007 13:05:09 -0400 Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1I4Ju6-0005lB-DV for autoconf-confirm+ok@megatron.ietf.org; Fri, 29 Jun 2007 13:05:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I4Ju5-0005Sb-Af for autoconf@ietf.org; Fri, 29 Jun 2007 13:05:05 -0400 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I4JsM-0004Xy-EW for autoconf@ietf.org; Fri, 29 Jun 2007 13:03:31 -0400 Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.186]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id D0E6F34190; Fri, 29 Jun 2007 13:03:46 -0400 (EDT) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jun 2007 13:03:15 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 29 Jun 2007 13:03:14 -0400 Message-ID: <816DD9299957E547B5D758D7F977D6DC02102688@tayexc14.americas.cpqcorp.net> In-Reply-To: <01d601c7ba50$072abd60$7c046c6b@sisodomain.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D ACTION:draft-ietf-autoconf-statement-00.txt thread-index: Ace6Tyk5RV3YMzb6RHCY7ZK9cFd/ewAIC0gA References: <01d601c7ba50$072abd60$7c046c6b@sisodomain.com> From: "Bound, Jim" To: "Shubhranshu" X-OriginalArrivalTime: 29 Jun 2007 17:03:15.0818 (UTC) FILETIME=[62639CA0:01C7BA6F] X-Spam-Score: 0.1 (/) X-Scan-Signature: d49da3f50144c227c0d2fac65d3953e6 Cc: autoconf@ietf.org Subject: [Autoconf] RE: I-D ACTION: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: , Content-Type: multipart/mixed; boundary="===============0790974247==" Errors-To: autoconf-bounces@ietf.org This is a multi-part message in MIME format. --===============0790974247== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7BA6F.61E4224A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C7BA6F.61E4224A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks will get back to you on the groups and their work that might be relative. =20 /jim ________________________________ From: Shubhranshu [mailto:shubhranshu@samsung.com]=20 Sent: Friday, June 29, 2007 9:19 AM To: Bound, Jim Cc: autoconf@ietf.org Subject: Re:I-D ACTION:draft-ietf-autoconf-statement-00.txt =09 =09 Please see inline comments. =09 > ----- Original Message ----- > From: "Bound, Jim" > To: > Sent: Friday, June 29, 2007 9:25 AM > Subject: RE: [Autoconf] I-D ACTION:draft-ietf-autoconf-statement-00.txt >=20 > Authors, I am analyzing this draft now and it adds much value to > autoconfiguration issues/discussion for classic IP network relations. >=20 > But before I go further can I ask do you support the direction of the > current autoconfig manet arch document just sent out? >=20 =20 Yes =20 > Is the objective of this work to only identify the technical issues? >=20 > Or will this eventually propose a solution per the guidelines in > autoconfig manet arch for IP autoconfig? >=20 =20 The Problem statement document is focused on discussing the technical issues, and provide Autoconf related terminologies.=20 > What are your views on L3/L2 MESH via 802.11s or the work on MESH for > 802.16, and is not the IETF work 6lowpan and 16ng relevant to this > analysis as input, I think these need to be in your analysis? >=20 =20 I think it would help to first know which aspect of these groups/work you are=20 referring to and that you think is needed in the analysis.=20 > Knowing this will skew my next read of this spec for input to the work? >=20 > It is written well as a note, nice job. >=20 =20 :-) =20 =20 =20 - Shubhranshu =20 > Thanks > /jim >=20 > > -----Original Message----- > > From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] > > Sent: Tuesday, June 19, 2007 3:50 PM > > To: i-d-announce@ietf.org > > Cc: autoconf@ietf.org > > Subject: [Autoconf] I-D ACTION:draft-ietf-autoconf-statement-00.txt > > > > 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 : Address Autoconfiguration for MANET: > > Terminology and Problem Statement > > Author(s) : E. Baccelli, et al. > > Filename : draft-ietf-autoconf-statement-00.txt > > Pages : 16 > > Date : 2007-6-19 > > > > Traditional dynamic IPv6 address assignment solutions are > > not adapted > > to mobile ad hoc networks. This document elaborates on > > this problem, > > states the need for new solutions, and requirements to these > > solutions. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-autoconf-statem > > ent-00.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-statement-00.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-statement-00.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. > > >=20 >=20 > _______________________________________________ > Autoconf mailing list > Autoconf@ietf.org > https://www1.ietf.org/mailman/listinfo/autoconf >=20 >=20 >=20 =09 ------_=_NextPart_001_01C7BA6F.61E4224A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Thanks will get back to you on the groups and = their work=20 that might be relative.
 
/jim

From: Shubhranshu=20 [mailto:shubhranshu@samsung.com]
Sent: Friday, June 29, = 2007 9:19=20 AM
To: Bound, Jim
Cc: = autoconf@ietf.org
Subject:=20 Re:I-D = ACTION:draft-ietf-autoconf-statement-00.txt

Please see inline = comments.

> ----- Original Message = -----
>=20 From: "Bound, Jim" <Jim.Bound@hp.com>
> To: = <autoconf@ietf.org>
> = Sent:=20 Friday, June 29, 2007 9:25 AM
> Subject: RE: [Autoconf] I-D=20 ACTION:draft-ietf-autoconf-statement-00.txt
>
> Authors, = I am=20 analyzing this draft now and it adds much value to
> = autoconfiguration=20 issues/discussion for classic IP network relations.
>
> = But=20 before I go further can I ask do you support the direction of = the
>=20 current autoconfig manet arch document just sent out?
> =
 
Yes
 
> Is the objective of this work to only identify the technical = issues?
>
> Or will this eventually propose a solution = per the=20 guidelines in
> autoconfig manet arch for IP autoconfig?
> =
 
The Problem statement document is focused on discussing = the
technical issues, and provide Autoconf related = terminologies.

> What are your views on L3/L2 MESH via 802.11s or the = work on=20 MESH for
> 802.16, and is not the IETF work 6lowpan and 16ng = relevant to=20 this
> analysis as input, I think these need to be in your=20 analysis?
>
 
I think it would help to first know which aspect of these = groups/work you=20 are
referring to and that you think is needed in the analysis. =

> Knowing this will skew my next read of this spec for = input to=20 the work?
>
> It is written well as a note, nice = job.
>=20
 
:-)  
 
 
- Shubhranshu
 

> Thanks
> /jim
>
> > -----Original=20 Message-----
> > From: Internet-Drafts@ietf.org=20 [mailto:Internet-Drafts@ietf.org]
> > Sent: Tuesday, June 19, = 2007=20 3:50 PM
> > To: i-d-announce@ietf.org
> = > Cc:=20 autoconf@ietf.org
> = > Subject:=20 [Autoconf] I-D ACTION:draft-ietf-autoconf-statement-00.txt
>=20 >
> > A New Internet-Draft is available from the = on-line
>=20 > Internet-Drafts directories.
> > This draft is a work = item of=20 the Ad-Hoc Network
> > Autoconfiguration Working Group of the = IETF.
> >
> > Title : Address Autoconfiguration for=20 MANET:
> > Terminology and Problem Statement
> > = Author(s) :=20 E. Baccelli, et al.
> > Filename :=20 draft-ietf-autoconf-statement-00.txt
> > Pages : 16
> = > Date=20 : 2007-6-19
> >
> >    Traditional = dynamic=20 IPv6 address assignment solutions are
> > not adapted
> = >    to mobile ad hoc networks.  This document=20 elaborates on
> > this problem,
> = >    states=20 the need for new solutions, and requirements to these
>=20 >    solutions.
> >
> >
> = > A URL=20 for this Internet-Draft is:
> > h= ttp://www.ietf.org/internet-drafts/draft-ietf-autoconf-statem
>= =20 > ent-00.txt
> >
> > To remove yourself from the = I-D=20 Announcement list, send a
> > message to i-d-announce-request@ietf.o= rg=20 with the word
> > unsubscribe in the body of the = message.
>=20 > You can also visit https://www1= .ietf.org/mailman/listinfo/I-D-announce
>=20 > to change your subscription settings.
> >
> >=20 Internet-Drafts are also available by anonymous FTP. Login
> = > with=20 the username "anonymous" and a password of your e-mail
> > = address.=20 After logging in, type "cd internet-drafts" and then
> > "get = draft-ietf-autoconf-statement-00.txt".
> >
> > A = list of=20 Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html<= /A>=20 or
> > ftp://ftp.ietf.org/iet= f/1shadow-sites.txt
>=20 >
> > Internet-Drafts can also be obtained by = e-mail.
>=20 >
> > Send a message to:
> > mailserv@ietf.org.
> > = In the=20 body type:
> > "FILE=20 /internet-drafts/draft-ietf-autoconf-statement-00.txt".
> = >
>=20 > NOTE: The mail server at ietf.org can return the document = in
> >=20 MIME-encoded form by using the "mpack" utility.  To use = this
> >=20 feature, insert the command "ENCODING mime" before the "FILE"
> = >=20 command.  To decode the response(s), you will need "munpack" = or
>=20 > a MIME-compliant mail reader.  Different = MIME-compliant
> >=20 mail readers
> > exhibit different behavior, especially when = dealing=20 with
> > "multipart" MIME messages (i.e. documents which have = been=20 split
> > up into multiple messages), so check your local=20 documentation on
> > how to manipulate these = messages.
>=20 >
> > Below is the data which will enable a MIME compliant = mail
> > reader implementation to automatically retrieve the=20 ASCII
> > version of the Internet-Draft.
> >
> =
>
> = _______________________________________________
>=20 Autoconf mailing list
> Autoconf@ietf.org
> https://www1.iet= f.org/mailman/listinfo/autoconf
>=20
>
>
------_=_NextPart_001_01C7BA6F.61E4224A-- --===============0790974247== 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 --===============0790974247==--