[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