Re: [Autoconf] WC consensus call for RFC5889 modifications (Fwd:Forgotone [Was: RFC 5889)

[Thomas Heide Clausen <[e-mail]>]

Charlie,

You suggest a face-to-face meeting. As you know I will be in your neck of the woods next week, so let's discuss, then ...

Wg-chair-hat-on: 

If we do that, we do owe it to the wg to report both the arguments and the outcome of the discussions here on the list, as I believe that both are valuable for the wg. Although (still wearing that hat) I would very much like for as much of the discussions to be in public (ie on the list)....

Wg-chair-hat-off:

I'll respond in more details later, but I have suitcases to pack ...

-- 
Thomas Clausen
http://www.thomasclausen.org/

On 6 août 2010, at 18:56, "Charles E. Perkins" <[e-mail]> wrote:

> Hello Thomas,
> 
> I said:
> 
>>> Do you _really_ want to exclude hosts from your network?
>>> Where will the applications reside?
> 
> You said:
> 
>> User applications (regular user applications) reside on hosts. Hosts are
>> accessing the network by way of being connected to (i.e. one IP hop away
>> from) a router.
> 
> Of course I do not have a problem with running applications
> on MANET routers.  I have proposed this for many years --
> and in fact I do not in any way require that the applications
> reside on hosts that are one hop away from a router.
> 
> My question was partly in jest -- but I do fully
> expect that non-routing hosts will be found in many
> or perhaps even most ad hoc networks.  For instance,
> we will have sensor fields and transmit-only data
> aggregators (both of which do not need to be routers,
> but are likely to need addresses).  I keep thinking
> this is totally obvious!
> 
> 
>> The connectivity between a host and a router is a "classic IP link",
>> and there are already excellent protocols in existence for managing
>> also autoconfiguration of addresses for hosts on classic IP links.
> 
> My objection has been to disqualify non-routing hosts from receiving
> addresses by way of an [autoconf] protocol.  There are of course known
> protocols (excellent or not, does not matter here) for configuring
> "classic hosts" on "classic IP links".  I reckon we mean the same
> thing by those terms.
> 
> My point is that there are almost certainly going to be non-routing
> hosts in <networks whose connectivity is established by MANET routers.>
> I would have just said "MANETs", but now we have so little agreement
> that we don't even know what a MANET is any more.
> 
> 
>> The connectivity between routers is.....who knows? Maybe a MANET,
>> maybe an OSPF network, maybe an ISIS network, and maybe links between
>> routers have "undetermined connectivity properties" -- or not, they
>> may be of NBMA or P2P or telepathic nature. However, that's a matter
>> for routers to figure out and manage; hosts are exposed to a classic
>> IP link and are isolated by an IP hop from any specific connectivity
>> properties of the connectivity/links between routers.
> 
> Here I have to disagree.  A host may have an 802.11 link to a router,
> and be subject to every single last problem of indeterminate range,
> interference, link-local ambiguity, and the other concepts which have
> proved so difficult for [autoconf] to resolve (regardless of so much
> reputable research available).
> 
> And, moreover, it's not up to the "routers".  It's up to "us",
> because we're designing the routers (at least in [manet] wg,
> not in [autoconf]).  Moreover, if a MANET router can work better
> by transacting new protocol with a host, then (a) the host may
> then considered to be something besides a "classic host", and
> (b) why not?  Let's figure it out.  But this does NOT mean that
> a network of the abovementioned variety has to REQUIRE changes
> to classic hosts; as an example, NEMO has made a lot of changes
> but still allows "classic" hosts to reside on mobile networks.
> Our situation is a bit different, insofar as mobile wireless hosts
> still must pay due respect to the realities of wireless.
> 
> 
>> Of course, there *may* be applications (for example, the routing demon)
>> running on routers and exposed to the specific connectivity properties
>> of the connectivity/links between routers. These, and only these
>> (non-user) applications should be sufficiently aware of these properties
>> to operate correctly. User-applications reside on hosts, separated by
>> an IP hop from any "strangeness" between routers, and exposed to
>> well-defined properties of a classic IP link.
> 
> 
> I also disagree with this.  Numerous studies have shown that
> applications can benefit from knowledge of bit-error rate,
> link capacity, jitter, and so on.  Of course we'd prefer that
> applications not have to pay attention to CDMA vs. 802.11,
> etc.  Nevertheless, I am sure that in a face-to-face meeting
> on this subject we would quickly find that we are in substantially
> complete agreement.
> 
> 
>>>> >> This architectural consideration thus separated the issue of
>>>> >> "configuring routers" from the issue of "configuring hosts" in this
>>>> >> context, and the rough consensus was that we would first focus on
>>>> >> configuring routers. Which lead us to where we are now.
> 
> ...
> 
>> This particular point was discussed - at length - at IETF'67 in 2006 in
>> San Diego, where it received (in my recollection) wide consensus; in part
>> because of its analogy with the "regular Internet".
> 
> Surely, "configuring" routers and hosts should be
> done differently.  This does NOT imply:
> (a) hosts should be barred from using the address
>    allocation protocol established for MANET routers, or
> (b) hosts should run useless router code in order to
>    make use of said address allocation protocol, or
> (c) the [autoconf] address allocation protocol design
>    should proceed on the assumption that non-routing
>    hosts are out of scope.
> 
> 
> Regards,
> Charlie P.
> 
> _______________________________________________
> Autoconf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/autoconf