[Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt
Thomas Narten <narten@us.ibm.com> Tue, 04 December 2007 13:44 UTC
Return-path: <autoconf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzY4D-0004Lp-Jq; Tue, 04 Dec 2007 08:44:05 -0500
Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1IzY4B-0004Dw-Ta for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 08:44:03 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzY4B-0004B7-E5 for autoconf@ietf.org; Tue, 04 Dec 2007 08:44:03 -0500
Received: from e1.ny.us.ibm.com ([32.97.182.141]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzY4A-0003eN-Dh for autoconf@ietf.org; Tue, 04 Dec 2007 08:44:03 -0500
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e1.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id lB4Di1ts002982 for <autoconf@ietf.org>; Tue, 4 Dec 2007 08:44:01 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id lB4Di1S0484942 for <autoconf@ietf.org>; Tue, 4 Dec 2007 08:44:01 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lB4Di1Wf021984 for <autoconf@ietf.org>; Tue, 4 Dec 2007 08:44:01 -0500
Received: from cichlid.raleigh.ibm.com (wecm-9-67-194-205.wecm.ibm.com [9.67.194.205]) by d01av04.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id lB4Di0oY021850 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <autoconf@ietf.org>; Tue, 4 Dec 2007 08:44:00 -0500
Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.1/8.12.5) with ESMTP id lB4Dhwq5006349 for <autoconf@ietf.org>; Tue, 4 Dec 2007 08:43:58 -0500
Message-Id: <200712041343.lB4Dhwq5006349@cichlid.raleigh.ibm.com>
To: autoconf@ietf.org
Date: Tue, 04 Dec 2007 08:43:58 -0500
From: Thomas Narten <narten@us.ibm.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b
Subject: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt
X-BeenThere: autoconf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Ad-Hoc Network Autoconfiguration WG discussion list <autoconf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/autoconf>
List-Post: <mailto:autoconf@ietf.org>
List-Help: <mailto:autoconf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/autoconf>, <mailto:autoconf-request@ietf.org?subject=subscribe>
Errors-To: autoconf-bounces@ietf.org
2007-11-30 review of -7 Overall. I still do not think this document is ready for publication. It is still to vague/muddy on the key architectural points that it is supposed to explain. My major concern is that you still do not lay out an understandable "architecture" that allows one to understand what an IP subnet would look like in MANETs. Interface terminology is non-standard and confusing. Should use "link type". Really. If you want the rest of the community to be able to understand this stuff, you cannot redefine terminology that is already widely in use and understood to mean something different than who it is used in this document. Neighbor In the context of routing, two routers are neighbors if one can send/receive routing protocol IP packets to the other without passing through any intermediaries at the same layer. Why "router"? Definition of neighbor from from 2460 should be used instead: neighbors - nodes attached to the same link. Why (or why isn't) the RFC2460 definition sufficient? Interface A node's point of attachment to a communication link. This is mostly fine as written, but... Semi-Broadcast Interface (SBI) A broadcast capable interface that may exhibit asymmetric reachability. Multiple access wireless radio interfaces are often SBI. Note that since a SBI *may* exhibit asymmetric reachability, it also may not. Call it a "link" not an "interface". Manets provide IP with a conceptual link, that has certain properties. What I thought the MANET architecture would provide is a description of the properties of that link type. MANET Interface A MANET interface is distinguished by its potentially significant time-varying asymmetric reachability (e.g., SBI) amongst potential neighboring routers. A more detailed discussion of MANET interface characteristics is presented in Section 4.2. The addressing constraints for a MANET interface are discussed in Section 5.2. No. A MANET _link_ has these characteristics. Not the interface. Etc. MANET Router (MNR) A MANET router is distinguished by having one or more MANET interfaces. A MANET router may also have zero or more non-MANET interfaces. A MANET router is responsible for hiding MANETs' challenging characteristics from nodes that are not MANET-aware. A MANET router with a single MANET interface is illustrated in Figure 1. No. the "interface/link" hides the challenging characteristics from IP. Not the BR itself. This is a critical point (architecturally) to get right. You really (I think) need to define an abstraction that defines an link type of "manet" that handles all the "interesting" characteristics of MANETs (like non-transitive connectivity) but that also presents itself to IP as a single IP subnet that has the normal properties. MANET Neighborhood a set of neighboring routers that can communicate via MANET interfaces without passing through any other routers (intermediaries at the same layer). If A can reach B, B can reach C, but A cannot reach C, are A&C in the same neighborhood? from the wording, I think the answer is no, per the definition of "neighbor". Do I understand that correctly? MANET a routing domain containing MANET routers. A example MANET is illustrated in Figure 3. This is too vague (i.e, it's a meangless definition). If I have two manet routers connected to each other, plus 100 ethernet links connected by routers, is the entire set considered to be part the "MANET"? receive the packet from PR1 on its interface and determine that it must retransmit the packet over the same interface as the one where the packet was received, in order for the packet to reach PR3. From s/retransmit/forward/ Wireless interfaces often exhibit more challenging characteristics when compared to wired interfaces. Many protocols (e.g., IPv6 neighbor discovery [RFC4861]) were not designed to operate in wireless networks with asymmetric reachability. Wireless interfaces may also exhibit very dynamic time varying performance (e.g., packet loss, data rate), and the factors have a significant impact on local communication. Be more precise. ND assumes a standard IP subnet model that all nodes on the same subnet are neighbors. Also, it is wrong to say "wireless vs. wired". What you really mean is that the link characteristics of things like typical ethernet differ from the link characteristics of other technologies. The challenge for MANETs is to figure out how to work around that assumption. Ad hoc networking further compounds problems by allowing nodes to join and leave the network, or even form new networks, at will. Do you mean "links"? or "subnets"? Saying "network" is vague. 4.2. Challenges MANET characteristics result in many challenges. These challenges reveal themselves in many forms, and MANET specific protocols must often be developed. I don't like this wording. what is unclear here is _what_ protocols will need to do this, and to what degree these are MANET-specific (hidden under an abstraction of an interface looking like a normal IP subnet, with emulation underneath to deal with the manet challenges) or something else. In MANETs' with SBI, MANET routers within the same small geographic region are often densely connected with other nearby MANET routers. These routers form a set of extended neighbor relationships. This set is referred to as a MANET neighborhood. A MANET neighborhood is typically composed of several MANET routers, with each MANET router being densely connected to other MANET routers. Shouldn't this be in the defintion section? logical. For example, in an Ethernet network nodes are often told that a particular range of addresses are "on-link". In MANETs' a MANET router often cannot make assumptions that a particular set of MANET routers is always (directly) reachable. Instead, MANET routers must detect and determine neighboring MANET routers, and handle changes to this set over time. Again, I find the term "MR" vague here. The issues here have to do with MANET-specific things, and refer only to the MANET links. Yet, the MR definition is broader, and simply says "a router with at least one interface to a MANET". I would expect section 5.2 to clarify what the basic MANET subnet model is. But it does not. Unique Prefixes MANET interfaces that are known to exhibit the above mentioned properties must be configured with unique prefixes. The reason for this requirements is so that no two MANET interfaces are configured to appear within the same IP prefix. One way to achieve this is /128 (IPv6) or /32 (IPv4) prefixes. It is worth noting that prefix lengths shorter than /128 (IPv6) or /32 (IPv4) are possible on the MANET interfaces, as long as the prefixes are unique to a single MANET interface. Note that the above statements are not an exception, but simply a clarification that MANET are no different from other networks in this respect. Don't understand this. More specifically: MANET interfaces that are known to exhibit the above mentioned properties must be configured with unique prefixes. The reason for this requirements is so that no two MANET interfaces are configured to appear within the same IP prefix. Why? Is this a requirement specific to MANETs, or is this a more general requirement? One way to achieve this is /128 (IPv6) or /32 (IPv4) prefixes. It is worth noting that prefix lengths shorter than /128 (IPv6) or /32 (IPv4) Sorry, but a /128 or /32 is an address, not a prefix (practically speaking). If you really mean "an address", why don't you say so. are possible on the MANET interfaces, as long as the prefixes are unique to a single MANET interface. Note that the above statements are not an exception, but simply a clarification that MANET are no different from other networks in this respect. If this is really a standard requirement of IP, I still don't get what issue you are trying to raise or why you are point this out. Link-local Multicast/Broadcast Scope On a MANET interface, a packet sent to a link-local multicast or all-ones broadcast address reaches the MANET interfaces of neighboring MANET routers, regardless of their configured addresses. Link-local multicast/broadcast packets are never forwarded and since a MANET may span several hops, nodes cannot assume that a packet sent to a link-local multicast/broadcast address will reach all routers within a MANET. Sorry, this is bogus. "link-local multicast" is defined by IP and means that a packet sent to that address is delivered to all nodes on the "link". This latter part, that says "never forwarded" does not make sense. They are never forwarded beyond the link, but they may be forwarded by MRs (your terminology) if required by the "link model". You cannot just say that multicast doesn't work in MANETS, and then imply protocols at the IP layer need to take that into account. That would be changing the basic IP model. Thomas _______________________________________________ Autoconf mailing list Autoconf@ietf.org https://www1.ietf.org/mailman/listinfo/autoconf
- [Autoconf] comments on draft-ietf-autoconf-maneta… Thomas Narten
- RE: [Autoconf] comments on draft-ietf-autoconf-ma… Teco Boot
- RE: [Autoconf] comments on draft-ietf-autoconf-ma… Templin, Fred L
- Re: [Autoconf] comments on draft-ietf-autoconf-ma… Thomas Narten
- Re: [Autoconf] comments on draft-ietf-autoconf-ma… Alexandru Petrescu
- RE: [Autoconf] comments on draft-ietf-autoconf-ma… Templin, Fred L
- RE: [Autoconf] comments on draft-ietf-autoconf-ma… Bound, Jim
- RE: [Autoconf] comments on draft-ietf-autoconf-ma… Teco Boot
- RE: [Autoconf] comments on draft-ietf-autoconf-ma… Templin, Fred L
- RE: [Autoconf] comments on draft-ietf-autoconf-ma… Bound, Jim