Subject: [Autoconf] review of draft-chakeres-manet-arch-00.txt

From: Jari Arkko <[email-masked]>
Date: Mon, 02 Oct 2006 14:39:26 +0300

Ian et al,

I have read this document. Overall, its well
written and its easy to agree with everything
that it says. I liked the terminology that the
document used.

Unfortunately, it also doesn't go very far in terms
of defining an architecture. In fact, there's very
little in the document that goes beyond terminology
and design challenges/requirements. In particular,
I expected to find a description of what subnet
model will be used, whether one can attach
regular non-MANET interfaces to MRs, what
security model will be applied, etc.

For most of these questions the answer is
probably very short and simple, but it is
important that you have an answer. (Please
remember that we are attempting to create
standards in this space, and, as a part of that
effort, it is natural that we have to choose
a particular way of doing things as opposed to
allowing or enumerating all possible ways
that it could be done.)
>    MANET Router (MR)
>       a router that engages in a MANET routing protocol.  In certain
>       scenarios a MR may forward packets only for itself (and its
>       attached nodes).
>   
This may need clarification. I think you mean that a MR may forward
packets only to itself or to nodes attached to it in a non-MANET manner
(e.g., a device that offers a WLAN interface to regular hosts). But I
wonder how typical it is for an MR to not forward in the MANET,
and whether it is something that you want to highlight the
definition.
> 5.  Architectural Issues
There's very little architecture here, and the
current text should probably should be placed
in the previous section "Challenges".

See also my high-level comments.
> 7.  Security Considerations
>
>    TBD
Like for the architecture, we need to make decisions so
that work can progress. For instance, if you disallow
prior arrangements to authorize nodes to act in a MANET,
this probably has an effect to the kind of solutions that
we can consider.
> 6.4.  Example Deployments
If this section were completed it would be interesting, but
I'm not sure it would be useful for the task at hand, i.e.,
defining the architecture of the MANETs. Focus on the
architecture, not secondary issues.

--Jari

_______________________________________________
Autoconf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/autoconf

---

From: "Ian Chakeres" <[email-masked]>
Date: Mon, 2 Oct 2006 06:51:35 -0700

Thank you very much for your comments Jari.

We have been working hard to create a new revision based on people's
feedback, and I have already made several of the changes you've
suggested. I hope to submit the new rev in the next few days, so it
can be discussed in San Diego.

Thanks.
Ian Chakeres

---

From: Jari Arkko <[email-masked]>
Date: Mon, 02 Oct 2006 17:07:18 +0300

Ian Chakeres wrote:
> suggested. 
Good!
> I hope to submit the new rev in the next few days, so it
Any pointers on what you intend to say? There's no penalty
for discussing things before the IETF meeting.

--Jari

---

From: "Ian Chakeres" <[email-masked]>
Date: Mon, 2 Oct 2006 10:54:05 -0700

The number of changes in the ID is large, so I will withhold
enumeration for a few more days while I work toward completion.

In response to the subnet model of MANET, can you please elaborate on
what you mean by subnet model? This is an often confused term and I'd
like to understand your definition and question clearly.

Ian Chakeres

---

From: Thomas Clausen <[email-masked]>
Date: Wed, 4 Oct 2006 01:16:55 +0200

Jari,

Thanks for your thoughtful comments. I'll give a few comments below.

On Oct 2, 2006, at 1:39 PM, Jari Arkko wrote:

> model will be used,

This, I think, is a topic that we need to discuss - I sense from our  
off-line discussions that we share an understanding of this, but we  
clearly do not do a good enough job at putting it into words in the I-D.

> whether one can attach
> regular non-MANET interfaces to MRs,

Short answer: Yes. Longer answer: a MR in this respect is no  
different from any other R, which may have interfaces over which a  
routing protocol runs, and interfaces over which they do not. Or  
interfaces over which routing protocol X runs and interfaces over  
which routing protocol Y runs - and so on and so forth.

> what

Good point, and I agree. It's, therefore, very important also that we  
solicit and, if you wish, try to enumerate the options, such that we  
pick the right one. I hope that more people will give feedback on  
this I-D, that we may go forward with and informed choice.

> and whether it is something that you want to highlight the

Actually, it is a permitted and, in some scenarios, useful mechanism.  
We have explicitly in, e.g., OLSR and OLSRv2 (and, I think DYMO too,  
but Ian can confirm) allowed for this. Think of such non-forwarding  
MRs as "routers which know they'll for a bit be roaming about a lot  
and therefore not be suitable network-forming-devices", yet still may  
have an external interface (WLAN) to which it would like to forward.

--thomas

-- 
Thomas Clausen
[email-masked]
http://www.lix.polytechnique.fr/Labo/Thomas.Clausen/
http://www.lix.polytechnique.fr/hipercom/

---

From: Thomas Narten <[email-masked]>
Date: Wed, 04 Oct 2006 11:49:38 -0400

> clearly do not do a good enough job at putting it into words in the

Let me be frank (and this comment is really directed at the WG and the
document authors). I've read the document and agree with Jari's
assessment. But he's being very diplomatic. My own comments based on
my review of two of the key documents is:

manet-arch has no meat. As you may recall during the original
chartering discussions, I've been really keen on understanding the
basic subnet model. This document doesn't say anything about it! I
think we are talking about a single page of (succinct) text. But we
seem to keep dancing around the key questions that need to be
answered! This documment has a lot of generic text about manets. We
need to focus on the issues specific to an IP environment and what the
basic subnet model is. If the answer is "there are no subnets, its
flat host routing within an ASN", you need to come out and just say
so. (and this can't actually be the answer, because you probably have
to have a "link" between a node and its neighboring router, even if
only to handle the case of being able to reach your neighbor.)

(And the defn of an ASN is not good, IMO, because ASN already has a
clear meaning in BGP/OSPF, but means something different in manets.)

Autoconf-statement seems to basically say "we need to assign unique
addresses", which is obvious. But how hard that is or why this is
complicated (IMO) has little meaning until some basic assumptions are
nailed down on the subnet model, and how it differs from what we are
familiar with in other LANs (e.g., ethernets) I.e., why doesn't
stateless addrconf work? Or DHC? Just asserting they don't isn't an
answer. You have to explain why. (And I suspect that in order to
explain why, you have to make assumptions about the subnet/link
model...)

Now, what I would suggest is that these topics be discussed _here_ (on
the mailing list) and _now_. I.e., not "in the next rev of the
document. How about proposing some text (that could maybe go into the
document), but post it here so we can get some discussion about
whether the text is what is needed. Please do this on the mailing
list, so we don't have deal with the (very long) cycle of publish a
draft, get comments, revise draft, etc.

Thomas

---

From: Ralph Droms <[email-masked]>
Date: Wed, 04 Oct 2006 12:12:35 -0400

Thomas - I agree that some additional detail in fundamental assumptions is
needed.  But, I think we need a better term than "subnet model".  I think
you mean "basic assumptions about L2 delivery that affect IP".  For example,
IPoEthernet assumes every transmission reaches every node, every node has a
unique L2 address, there is an MTU, there is a broadcast mechanism, there is
a multicast mechanism, etc.

At the risk of over-generalization, those assumptions are reflected in the
design of IP.  An L2 technology that deviates from those assumptions will
have an effect on how IP operates.

I see two ways to deal with an L2 technology that has fundamental
characteristics that differ from those assumed by IP: add function to L2 to
meet those assumptions; modify IP to work with the L2 characteristics.
Either way, we have to know the characteristics first.

I started off by suggesting we need a better term than "subnet model".  How
about "L2 model"?

- Ralph

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 04 Oct 2006 09:30:57 -0700

Hello Thomas,

ext Thomas Narten wrote:
>                        As you may recall during the original
> basic subnet model. This document doesn't say anything about it!
I think that is probably a good thing.  We need to make an autoconfiguration
protocol that works even in the absence of well-defined subnets.
> We need to focus on the issues specific to an IP environment
O.K.
>  and what the
> basic subnet model is.
You didn't explain why.  The fact is, that many people have built workable
systems using various autoconfiguration techniques, without going into
paroxysms and paralysis trying to solve this non-essential problem.
> If the answer is "there are no subnets, its
> so.
Well, I reckon that subnets can be "allowed" -- without being a stumbling
block when the collection of nodes that are internetworking do not conform
naturally to any subnet model.
>  (and this can't actually be the answer, because you probably have
You do not need to be on a common subnet to have IP connectivity.
You need to have a common link.  And I do not think it is reasonable
to assume that every link has a subnet prefix (i.e., not every link is
a subnet).

Regards,
Charlie P.

-- 
Please address return e-mail to [email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Wed, 04 Oct 2006 12:44:00 -0400

Charlie - perhaps we're running into the terminology problem I mentioned in
my previous e-mail; "subnet model" might be misleading.  Do you agree that
there has to be some explicit description of the characteristics of the L2
connectivity to give a basis for discussion of manet autoconf mechanisms?
What shall we call that description?

- Ralph

---

From: "Charles E. Perkins" <[email-masked]>
Date: Wed, 04 Oct 2006 10:02:41 -0700

Hello Ralph,

I am not sure such an explicit description is needed.  If a node
transmits a packet over a link and another node receives the
packet as sent, then what more is needed?

For more general delivery mechanisms such as multicast
and broadcast transmission of IP packets, some information
about L2 connectivity is important to know.  But I don't
think that is what you are looking for, is it?

Regarding the subnet model and its applicability, I have always
thought that any node announcing reachability to a subnet has
to be responsible for verifying that reachability.  But for a large
class of manets we do not need that.

Regards,
Charlie P.

---

From: "Joe Macker" <[email-masked]>
Date: Wed, 4 Oct 2006 13:14:07 -0400

>-----Original Message-----
>From: Charles E. Perkins [mailto:[email-masked]] 
>Sent: Wednesday, October 04, 2006 12:31 PM
>To: ext Thomas Narten
>Cc: [email-masked]; Thomas Clausen
>Subject: Re: [Autoconf] review of draft-chakeres-manet-arch-00.txt
>
>
>Hello Thomas,
>
>ext Thomas Narten wrote:
>I think that is probably a good thing.  We need to make an 
>autoconfiguration protocol that works even in the absence of 
>well-defined subnets.
>You didn't explain why.  The fact is, that many people have 
>built workable systems using various autoconfiguration 
>techniques, without going into paroxysms and paralysis trying 
>to solve this non-essential problem.
>> If the answer is "there are no subnets, its flat host routing within 
>> an ASN", you need to come out and just say so.
>Well, I reckon that subnets can be "allowed" -- without being 
>a stumbling block when the collection of nodes that are 
>internetworking do not conform naturally to any subnet model.
>>  (and this can't actually be the answer, because you 
>probably have to 
>> have a "link" between a node and its neighboring router, 
>even if only 
>> to handle the case of being able to reach your neighbor.)
>>   
>You need to have a common link.  And I do not think it is 
>reasonable to assume that every link has a subnet prefix 
>(i.e., not every link is a subnet).

True since we define MRs as routers. We certainly have implemented routers
that use link local addresses and unnumbered interfaces to support attached
prefixes. Flat host routing yuck why would we say that.

One thing missing is interconnectivity scenarios which we had in a different
draft.  This can lead to multiple valid autconf solution spaces.

---

From: Thomas Narten <[email-masked]>
Date: Wed, 04 Oct 2006 13:56:29 -0400

Hi Ralph.

> a multicast mechanism, etc.

Actually, after thinking a bit about this, I think I do mean "subnet
model". This is all about defining the abstraction that IP sees. From
IP's perspective, what does a manet network look like?

But, let's dig deeper. Some questions:

1) What is the scope of an IP "link" or "subnet"? That is, if one has
   a manet (which consists of many routers and hosts), which hosts are
   considered (from IP's perspective) to be on the same "link", and
   thus can communicate directly with each other (without having to
   forward traffic through a router)? Note that here, I'm using the term "link", and one could
   assume link-local addressing is in use.

2) Are there "subnets" in a manet? That is, is there a prefix that
   covers multiple nodes? that is, where all the nodes on that subnet
   can reach each other (directly, without going through a router)? Or
   stated differently, are there subnets where all the nodes on that
   subnet can be assigned addresses out of the same prefix (and that
   can reach each other directly)?

3) What type of link does a "host" connect to? Is it essentially just
   a p2p link between itself and a router? Is a manet nothing more
   than a set of links, each of which is p2p?

Consider Figure 1 in chakeres-manet-arch. It only shows routers. I'd
like a corresponding figure that also shows hosts, and gives example
IP address assignments, and shows where the IP subnets are.

Thomas

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 4 Oct 2006 11:18:02 -0700

Joe,

> We certainly have implemented routers that use link
> local addresses and unnumbered interfaces to support
> attached prefixes.

Yes; this approach was outlined in Dave Thaler's
"Multi-subnet MANET" draft.

Fred
[email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 4 Oct 2006 11:27:26 -0700

(Did this not make it to the list?)

Ralph,

> What shall we call that description?

'draft-templin-manet-autoconf-link' gives: "Observations on
"Link" in MANET/Autoconf and Other Contexts". I don't know
whether/not this would help these discussions.

Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 4 Oct 2006 10:42:21 -0700

Ralph,

Fred