Subject: RE: [Int-area] Re: AUTOCONF charter

From: "Bound, Jim" <[email-masked]>
Date: Mon, 10 Oct 2005 12:23:31 -0400

> > Regarding using Ad Hoc networks as transit networks is very 
> important
> > discussion, and the views in industry are mixed.  I 
> personally believe
> > this must be supported for emergency preparedness reasons and I can
> come
> > up with many others, and that the IETF community needs to develop Ad
> Hoc
> > network specs, ops views, etc that include viewing Ad Hoc nets as
> > transit providers.  This will have much debate is my guess.
> 
> I would separate this into two cases, one being an AHN that 
> is a transit
> to another AHN, which I would be interested in (or more generally,
> AHNs which collectively are a stub, but individually may be transit
> networks), the other being an AHN with multiple connections to the
> fixed Internet (or any other network with significantly greater
> stability, reliability and/or - usually and - bandwidth) the 
> AHN acting
> as a transit for the other network. The latter I'd be happy 
> to exclude.

I still believe stub is poor explanation and I emphatically do not want
to exclude AHN as transit to reach another fixed Internet.

Earthquake takes out a town.  AHNs form.  Metro Fixed Internet is
enabled (dark fiber to Wimax towers, or Satcom) consisting of
distributed Internet (virtualized and I am not implying VPN tunnels).
The primary fixed Metro Internet IX goes down and is re-established at
different physical, mobile, or routing topology location. But, the AHN
is aware of all nets from multiple interfaces.  The AHN can be used to
assist to announce all new converged routes to all nets to the new Metro
Fixed Network, as a transit network. 

This needs to be dicussed in far greater depth is my point and why I am
against exclusion at this point, it should be on the design center table
of the IETF discussion.

> I'd postpone considering the former too if it helped the process along
> (or include it if that helped the proces along, but that seems less
> likely).

I don't agree.  We have waited this long to standardize this entire
space and it affects lives in several deployment models.  What is out
there today for Defense or 911 is not acceptable, and is not
interoperable, and as you know does not meet the John Garstka principles
of net centricity.  It is high time the IETF now is discussing all these
topics and are more than qualified with the technical wealth within our
community to work on this objectively.  When spec ops, policeman,
fireman, or doctors have to pick up a cell phone to communicate because
the AHN is broken is not good, and that is the case today, and the IETF
can do a great service for networking by taking this on besides what the
MANET WG has done at this juncture.

> 
> [Incidentally I take your point about there being a logical difference
> between MANETs and AHNs and have used the latter above. However in
> practice the distinction blurs, I've presented results from a real
> network which had non-mobile nodes, but was a non-static network
> - and that was before allowing nodes to fail. I think what you really
> want are protocols that can be adapted - or better yet adapt 
> themeselves
> - to the range of conditions, and I hope at least some of this will
> come out in Standards Track routing protocols. But that's off 
> the point
> here I think, hence the brackets.]

As you, I glean from your mail? I am working real live scenarios with
real live direct participant input that what is there now is not working
at all, and they are picking up cell phones.  Clearly we cannot wait
entirely for standards to complete. but the IETF moving in this
direction and work is at least a hope for tomorrows interoperability.
If we just follow the principles of net centricity then we have half the
battle won, and the gaps for that to be deployed require some
standardization for protocols, ops views, and updated lexicon from specs
like 2501.

We know more today about the Internet today for AHNs and Mobility than
we did 10 years go when pioneers like Charlie Perkins and Dave Johnson
began this form of work in the IETF.

NB: Tenets of Net Centricity are as follows:  end-to-end communications
that supports connectivity, interoperability, security, and discovery.
For IETF purposes across the Internet.  For First Responders or 911
support within a Metropolitan network with access to some form of
command control center, and for Defense these principles should work and
apply across their Global Information Grid (not Grid per GGF or the SOA
from Father of that Grid Dr. Ian Foster, but rather a network Grid).

/jim

_______________________________________________
Int-area mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/int-area

---

From: Thomas Narten <[email-masked]>
Date: Tue, 11 Oct 2005 09:29:41 -0400

> to exclude AHN as transit to reach another fixed Internet.

While I suspect that most AHN's will be stub, I'd offer the following
observations/questions:

 - how does restricting AHNs to stub networks simplify any aspect of
   the problem? (if it doesn't, why add the restriction or make such
   an assmption?)

 - how can one enforce such a restiction? (one probably can't --
   people will use them for transit), so better go ahead and plan for
   it so that things don't break in horrible ways when it happens in
   practice...

Thomas

---

From: Greg Daley <[email-masked]>
Date: Thu, 13 Oct 2005 17:02:54 +1000

Hi Thomas,

>    it so that things don't break in horrible ways when it happens in

I think the stub argument is really irrelevant for
autoconf.  It's a routing issue, rather than a
configuration issue.  It doesn't matter a gnat
whether the routers at the edge of the adhoc domain
wish to learn each other's routes, or forward to
each other.

We should concentrate on the issue of applying addressing
to the chosen subnet model, when that's clearly explained.

Greg