RE: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt

"Bound, Jim" <Jim.Bound@hp.com> Tue, 04 December 2007 22:10 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 1Izfyl-0002Et-PA; Tue, 04 Dec 2007 17:10:59 -0500
Received: from autoconf by megatron.ietf.org with local (Exim 4.43) id 1Izfyk-0002Eg-Qw for autoconf-confirm+ok@megatron.ietf.org; Tue, 04 Dec 2007 17:10:58 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Izfyk-0002EX-FA for autoconf@ietf.org; Tue, 04 Dec 2007 17:10:58 -0500
Received: from ccerelbas03.cce.hp.com ([161.114.21.106]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Izfyj-0003Ta-Jh for autoconf@ietf.org; Tue, 04 Dec 2007 17:10:58 -0500
Received: from G3W0631.americas.hpqcorp.net (g3w0631.americas.hpqcorp.net [16.233.59.15]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ccerelbas03.cce.hp.com (Postfix) with ESMTP id CB15434668; Tue, 4 Dec 2007 16:10:56 -0600 (CST)
Received: from G5W0326.americas.hpqcorp.net (16.228.8.70) by G3W0631.americas.hpqcorp.net (16.233.59.15) with Microsoft SMTP Server (TLS) id 8.0.700.0; Tue, 4 Dec 2007 22:08:52 +0000
Received: from G5W0274.americas.hpqcorp.net ([16.228.8.60]) by G5W0326.americas.hpqcorp.net ([16.228.8.70]) with mapi; Tue, 4 Dec 2007 22:08:51 +0000
From: "Bound, Jim" <Jim.Bound@hp.com>
To: Teco Boot <teco@inf-net.nl>, 'Thomas Narten' <narten@us.ibm.com>, "autoconf@ietf.org" <autoconf@ietf.org>
Date: Tue, 04 Dec 2007 22:08:50 +0000
Subject: RE: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt
Thread-Topic: [Autoconf] comments on draft-ietf-autoconf-manetarch-07.txt
Thread-Index: Acg2e/nOtIBRwU+xQ6uuLQWg5th/fwACoTZAAA6lHWA=
Message-ID: <1AB21F94DA6EEF459F107706554433392210FA4211@G5W0274.americas.hpqcorp.net>
References: <200712041343.lB4Dhwq5006349@cichlid.raleigh.ibm.com> <009501c83696$7e9753a0$7bc5fae0$@nl>
In-Reply-To: <009501c83696$7e9753a0$7bc5fae0$@nl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2e8fc473f5174be667965460bd5288ba
Cc:
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

Teco,

MANET is not a "link-type" as Thomas N relays it is an interface but the choice of calling it that could be optimized, though it works for me as input to the WG.  For example MANET interface will have different L2 drivers to those link types for 802.11g, 802.11s, Military Classified L2's, GSM, CDMA, and ones not invented yet.  I think the bug is in the orginal 2461 ND spec using the term NBMA and back to ATM networks.  NBMA is not a link type but an architecture approach to operate IP over links.  MANET is like NBMA in the abstract but completely different.  MANET is really to me a reference architecture for an implementation of a network architecture and that is new to us in the IETF except in the MANET WG arena.  The next order derivative to MANET the interface is how it approaches routing, advertisements, solicitations, etc.  That is what must be written in a manner that it is comfortable and clear to the IETF IP community.  To me the spec is fine but as you I live in the MANET world almost daily as architect and one who is concerned with products and time to market for MANET.  We probably need to make it more IP community friendly and that will help the market too to adopt this spec.

/jim

> -----Original Message-----
> From: Teco Boot [mailto:teco@inf-net.nl]
> Sent: Tuesday, December 04, 2007 11:55 AM
> To: 'Thomas Narten'; autoconf@ietf.org
> Subject: RE: [Autoconf] comments on
> draft-ietf-autoconf-manetarch-07.txt
>
> Some comments inline.
>
> > -----Oorspronkelijk bericht-----
> > Van: Thomas Narten [mailto:narten@us.ibm.com]
> > Verzonden: dinsdag 4 december 2007 14:44
> > Aan: autoconf@ietf.org
> > Onderwerp: [Autoconf] comments on
> draft-ietf-autoconf-manetarch-07.txt
> >
> > 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.
>
> Maybe better definition could help.
> I think it is easy to understand that a MANET Interface is an
> interface that may suffer from certain link characteristics.
> We have similar kind of interface types, like NBMA and P2MP.
> Now we want to define another.
> Term MANET Interface is well known, e.g. it is used in MANET
> Routing Protocol documents, including the OSPF ones.
>
> Maybe term Semi-Broadcast Interface (SBI) should be removed,
> this is about the link characteristics. Hint for editer:
> Change SBI into MANET and some textual cleanup will do.
>
>
> <snip>
>
> >    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.
> >
>
> If this is true, we do not have to do anything special.
>
>
> > 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.
>
> I think there are two MANET implementation models.
> One is hiding MANET form IP, e.g. a sub-IP MANET model. This
> is more or less out-of-scope for IETF.
> The other model is described in this document. Now we have to
> face the reachability issues. I think the MANET Router shall
> hide this for IP hosts and non-MANET routers. If this is
> arranged by using a single IP subnet or using another
> addressing model is solution space.
>
> There might be a discussion on supporting connectivity to
> (mobile) hosts via the MANET Interface. I will post on this
> separately.
>
> 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