Subject: Re: [manet] Defining subnet models used by our protocols

From: Abdussalam Baryun <[email-masked]>
Date: Mon, 4 Jun 2012 09:17:50 +0200

Hi Don, and All,

I would like to know your opinion about why we don't define subnets for MANET?

On 6/3/12, Don Sturek <[email-masked]> wrote:
> +1
>
> On 6/2/12 11:21 PM, "Charles E. Perkins" <[email-masked]> wrote:

Could we discuss why we don't define subnets models? I don't
understand adding (+1). I hope the chair does not ask me to close this
thread too :)

The ad hoc autoconfig was proposed in 2005 and proposed-ended in 2011
so living for about 6 years only. What was the reason for the proposed
close of it? please read the DA Jari's reasons below.

IMO it because it had low/no useful discussions and only produced one
RFC which is RFC5889, why only one? what happend within 6 years?  IMO
any WG should have more discussions, discussions are mandatory
activity for WG. Not discussing issues is like ignoring the value
input to group progress. Healthy discussions are more important than
producing more documents produced, because discussions are really the
source of correct documents (don't mean it has to be perfect, but
should not be misleading). WGs should be compared in terms of the
amount of discussions not in amount of documents forwarded/submitted.

According to Chakeres and Maker (2006) [1] quoated below:

[The autoconf WG is chartered to initially develop
two documents. The first document is a document
defining the MANET architecture and how MANET
relates to IP networks and the Internet. The second
document is to define the terminology, problem statement
and goals for autoconf. These autoconf documents
will be discussed on the autoconf mailing list.]

That WG did not produce the definition of MANET architecture. Which I
think is related to the subnet-model definition importance for MANET.
So i understand the authors see the importance of defining something
for MANET in 2006. Now, Do we have a network architecture definition
of MANET in one RFC?

> On 6/2/12 11:21 PM, "Charles E. Perkins" <[email-masked]> wrote:
>>Hello folks,
>>
>>I would be opposed to requiring the subnet model as a mandatory
>>component of any current [manet] working group charter item.
>>
>>We have had at least ten years of experience showing that requiring
>>subnets can derail practically any wireless network discussion within
>>the sphere of applicability of manet protocols.  The reasons are many
>>and varied -- and, I must admit, really very interesting.
>>
>>It was the death of another working group which really should have
>>been allowed to go forward except for disagreements about certain
>>subnet-related constructs.  Let's not consign ourselves to the same
>>fate.

In future the death of the WG will be because they don't discuss
things on the list, or don't have what to discuss, please read the
reasons mentioned by Jari Arkko below. IMO for the future, some day
any WGs possibly will close and other days new WGs comes.

>>Regards,
>>Charlie P.

References:
[1] Chakers, I., and Maker, J., 'Mobile Ad Hoc Networking and the
IETF', Mobile Computing and communication review, volume 1, Number 2,
2006.

Best regards

Abdussalam Baryun
University of Glamorgan, UK
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
To: "autoconf at ietf.org" <autoconf at ietf.org>
Subject: [Autoconf] closing the working group?
From: Jari Arkko <jari.arkko at piuha.net>
Date: Tue, 29 Mar 2011 08:48:47 +0200

--------------------------------------------------------------------------------
I have looked at the discussions on the list (or lack thereof). I also
cannot see too many internet drafts on the topics belonging to the
group's charter. I am very happy with the RFC that has been produced
by the working group, but we also seem to have some actual protocol
work happening elsewhere (e.g., in the context of the ROLL WG).

I discussed this matter with the chairs and my co-AD, and we are
wondering if it would be time to close the working group. I do know
that there is at least one implementation team that is still in the
process of describing their DHCP-based solution, maybe there are
similar efforts on the distributed solution space. My proposal is that
we close the working group and I'be VERY happy to AD sponsor all such
solutions to Experimental RFCs as soon as we have those proposals in
some reasonable shape.
Thoughts?

Jari
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
To: IETF-Announce at ietf.org
Subject: WG Review: Ad Hoc Network configuration (autoconf)
From: The IESG <iesg-secretary at ietf.org>
Date: Wed, 27 Jul 2005 14:28:49 -0400
Cc: manetautoconf at ml.free.fr
List-help: <mailto:[email-masked]?subject=help>
List-id: ietf-announce.ietf.org
List-post: <mailto:[email-masked]>
List-subscribe:
<https://www1.ietf.org/mailman/listinfo/ietf-announce>,
<mailto:[email-masked]?subject=subscribe>
List-unsubscribe:
<https://www1.ietf.org/mailman/listinfo/ietf-announce>,
<mailto:[email-masked]?subject=unsubscribe>
Reply-to: iesg at ietf.org
Sender: ietf-announce-bounces at ietf.org

--------------------------------------------------------------------------------
A new IETF working group has been proposed in the Internet Area. The
IESG has not
made any determination as yet. The following draft charter was
submitted, and is
provided for informational purposes only. Please send your comments to the IESG
mailing list (iesg at ietf.org) by August 3rd.

+++++++++++++

Ad Hoc Network configuration (autoconf)
========================================

Current Status: Proposed Working Group

Chairs:
TBD

Internet Area Director(s):
Mark Townsley <townsley at cisco.com>
Margaret Wasserman <margaret at thingmagic.com>

Internet Area Advisor:
Margaret Wasserman <margaret at thingmagic.com>

Mailing Lists:
General Discussion: manetautoconf at ml.free.fr
To Subscribe: manetautoconf-request at ml.free.fr

Description of the WG:

In order to communicate among themselves, ad hoc nodes (refer to RFC
2501) may need to configure their network interface(s) with local
addresses that are valid within an ad hoc network. Ad hoc nodes may
also need to configure globally routable addresses, in order to
communicate with devices on the Internet.

Ad hoc networks present several new challenges. Unlike in traditional
IP networks, each ad hoc node, besides being a traffic end-point,
should be capable of forwarding traffic destined for other hosts.
Additionally, nodes constituting an ad-hoc network do not share access
to a single multicast-capable link for signaling. Many protocol
specifications used in traditional IP networks e.g. RFCs 2462, 2463
etc. do, however, assume that subnet-local signals (e.g. link-local
multicast signal) are received by each of the hosts on the particular
subnet without being forwarded by the routers defining the subnet
boundary.

The main purpose of the AUTOCONF WG is to standardize mechanisms to be
used by ad hoc nodes for configuring unique local and/or globally
routable IPv6 addresses. The ad hoc nodes under consideration are
expected to support multi-hop communication by running a MANET routing
protocol, e.g. those developed by the IETF MANET WG. However, this may
or may not mean that an AUTOCONF mechanism will be dependent on any
specific MANET routing protocol. With this in mind, the goals of
AUTOCONF WG are to:

- Produce a "terminology and problem statement" document, defining the
problem statement and goals for AUTOCONF.

- Develop an IPv6 stateless autoconfiguration mechanism to be used by
ad hoc nodes for configuring unique local addresses as well as, in
cases where Internet connectivity exists, globally routable unique
addresses.

- Develop a stateful address autoconfiguration mechanism to be used by
ad hoc nodes for configuring globally routable unique addresses, if an
address providing entity such as DHCPv6 server is available.

- Develop a mechanism to promote configured address uniqueness in the
situation where different ad hoc networks merge.

Issues and requirements related to prefix and/or address providing
entities, such as an Internet gateway, will be addressed within the
group to the extent that they are directly related to the AUTOCONF
mechanisms. Security concerns related to AUTOCONF mechanisms will also
be discussed within the group.

The working group will reuse existing specifications whenever
reasonable and possible.

Goals and Milestones:

Oct 05 : Submit "terminology and problem statement" document for WG
review
Oct 05: Submit initial I-D(s) of candidate proposed AUTOCONF mechanisms
and design frameworks
Feb 06: Submit "terminology and problem statement" document to IESG for
publication as an informational RFC
Apr 06: Submit initial I-D of "stateless autoconfiguration mechanism"
for WG review
Apr 06: Submit initial I-D of "stateful autoconfiguration mechanism"
for WG review
Apr 06: Submit initial -ID of "configured address uniqueness
maintenance" for WG review
Aug 06: Revise WG documents and review
Dec 06 Revise documents based upon implementation experience
Apr 07: Submit "stateless autoconfiguration mechanism" specification
and supporting documentation to IESG for publications as Proposed
Standard
Apr 07: Submit "stateful autoconfiguration mechanism" specification and
supporting documentation to IESG for publications as Proposed Standard
Apr 07: Submit "configured address uniqueness maintenance"
specification and supporting documentation to IESG for publications as
Proposed Standard
Oct 07: Close or recharter the WG

_______________________________________________
IETF-Announce mailing list
IETF-Announce at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce

=====================================================
>>
>>
>>
>>On 6/2/2012 1:12 AM, Abdussalam Baryun wrote:
>>> Hi All
>>>
>>> I want to discuss this subnet definition issue that was raised in the
>>> 82 meeting, could we discuss about it please. Will we need to put it
>>> in a draft or include it in our active draft working in progress,
>>> please advise,
>>>
>>> Abdussalam Baryun,
>>> University of Glamorgan, UK
>>> ++++++++++++++++++++++++++++++
>>>
>>> In WG 82 meeting it was mentioned (Bob Cole and Teco discussions):
>>> BC>  that subnet-models are not defined But in DLEP it looks at two
>>> subnet-models (different models; e.g. radio subnet-models,
>>> sat-subnet-models). We are defining IP over a subnet, but the subnet
>>> is not defined. Then we don¹t know how to define control protocols,
>>> data-packet-formats, and managements-models without having a subnet
>>> model in mind.
>>> TB>  In sat-comms the up-link and down-link can be very different. So
>>> for different nodes on same carrier can be different data rates, SNR,
>>> etc. so it is important that DLEP include the link metrics, even if it
>>> is a full connected subnet.
>>> BC>  the subnet depends on the link of the subnet-underlying model,
>>> The semantics of link up and down are determined by the underlying.
>>> ++++++++++++++++++++++++++++++++++++++++++++++++++
>>>
>>> ********************************************************************
>>> This email and any attachments are confidential to the intended
>>> recipient and may also be privileged. If you are not the intended
>>> recipient please delete it from your system and notify the sender.
>>> You should not copy it or use it for any purpose nor disclose or
>>> distribute its contents to any other person.
>>> ********************************************************************
>>> _______________________________________________
>>> manet mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/manet
>>>
>>>
>>
>>
>>--
>>Regards,
>>Charlie P.
>>
>>_______________________________________________
>>manet mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/manet
>
>
>

---

From: Don Sturek <[email-masked]>
Date: Mon, 04 Jun 2012 06:35:11 -0700

Hi Abdullalam,

I think basing a routing protocol (like those in MANET and also ROLL) on
some standard definition of subnets is:
1)  not needed in my experience with virtually every deployment scenario I
have seen
2)  conflates the network topology with the pratical issue of providing
peer to peer route discovery and establishment

Don