Subject: RE: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt

From: "Teco Boot" <[email-masked]>
Date: Fri, 1 Jun 2007 10:27:49 +0200

Hi Ian, Joe and Thomas, 
Thanks for the updated ID. Here some comments.

4.1.
> Many protocols (e.g. neighbor discovery) do not operate in
> wireless networks with asymmetric reachability.
Is IPv6 ND mentioned? I prefer an exact reference.

4.2.3.
> To assist in coordinating among a loosely connected set of MANET
> routers, a procedure called flooding is used.  MANET flooding consist
> of disseminating a packet to all connected MANET routers.
Here start a MANET pitfall. By introducing a mechanism allowing flooding to
_all connected MANET routers_, scaling of the MANET is bounded. 
Adding an option for flooding to parts of the MANET provide a remedy. Sample
mechanisms are _logical areas_ and _inner MANET border routers_ or limit
flooding based on hopcount or path metric. I know such mechanisms could
introduce other problems, like multihop Asymmetric Reachability when path
metric bounds are used.

5.
> MANET interfaces, forming a multihop MANET area, may use a site
> prefix;
The term _multihop MANET area_ is not defined in the ID. The term _logical
areas_ I used above could be meant.

8.1
> In MANET, nodes might assume a service is available locally (within 
> one IP hop) or within a particular scope (one or more IP hops - MANET, 
> site, global).
As mentioned in 7, cross layer information could be available and such
information could be far more important than hop-count. A 2-hop error-free
and lightly loaded 100Mbps path could be qualified as better related to a
single hop congested error-prone 2400bps link.

8.2
> ... complete number of nodes in a MANET ...
> ... cohesive flat routing area ...
> ... a single routing region ...
Same comments as above, on term _multihop MANET area_. Three terms for
something not explained in this ID.
I am still confused wat is meant in this section. There is the term _Peer
MANET Routers_. It is not _connected MANET routers_ / _connected nodes_ (see
text). I am not sure _MAN Neighbors_ is meant. May be a _MANET Peer_ is a
potential _MANET Neighbor_ and all _MANET Peers_ are configured for a
_single routing region_.
But reading 2.2. _MANET_, a _MANET_ is a _routing region_ and _MANETs_ split
and merge due to reachability, so _regions_ are based on connectivity and
not on configuration.

Regards, Teco

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 01 Jun 2007 11:16:19 +0200

Hi, I have read large parts of the draft 
draft-ietf-autoconf-manetarch-02.txt

I generally agree with the draft intention, and especially with the 
parts that say that IP addressing model is the same as classical IP 
addressing model.

> These routers may communicate over wireless links with asymmetric 
> reachability ...

I think you mean asymmetric path characteristics?  Like 10mb/1024mtu
downlink and 2mb/512mtu uplink?  Because asymmetric _reachability_
sounds to me like yes-no like sattelite uni-directional links.  I don't
think udlr sattelite links are considered in MANET.

Are sattelite links considered by MANET?

Are there other wireless unidirectional links considered by MANET? 
(DVB-H terestrial, RFID, other?)

> Asymmetric Reachability
> 
> A link where non-reflexive and/or non-transitive reachability is part
>  of normal operation. Non-reflexive reachability means that packets 
> from X reach Y but packets from Y don't reach X.

I think this is the case only for sattelite wireless links.  Is there
another wireless link that has this property?  All wireless links I can
think of (2.4GHz WiFi, WLAN in general, IrDA, bluetooth) are "reflexive"
rechability in this sense.  Is there another?

> Non- transitive reachability means packets from X reach Y, and 
> packets from Y reach Z, but packets from X don't reach Z. Many radio/
>  wireless interfaces exhibit these properties.

Ok, but this doesn't sound as asymmetric, not to me.  It is the
well-known hidden terminal problem.  I think we should state that this
is the hidden terminal problem.

> Neighbor
> 
> If node X can directly exchange IP packets with node Y, then node Y 
> is node X's neighbor.  Packet reception characteristics are often 
> used to assist devices in determining the quality of neighbors' 
> communication.

I think here we should at least refer to RFC2461's definition of
neighbors which is 'nodes attached to the same link'.

> Note that an anycast address is syntactically indistinguishable from
>  a unicast address.  Thus, nodes sending packets to anycast addresses
>  don't generally know that an anycast address is being used.

In a sense yes, anycast addresses are syntactically indistinguishable
from unicast addresses, in that they're IPv6 128bit addresses
represented textually like any unicast address.  However, at least some
if not all anycast addresses have a IANA-reserved syntax.  Thus the
node sending a packet to a anycast address _does_ know that an anycast
address is being used.

> Full-Broadcast Interface (FBI)
> 
> A broadcast interface with reflexive and transitive reachability. All
>  nodes on the interface can send and receive IP packets directly, all
>  nodes are symmetric neighbors.  An Ethernet segment is an example of
>  a FBI.

I think you mean "a wired 802.3 Ethernet" is an example of FBI.  Because
  WiFi 802.11 does not have this symmetric property: two MSs under a AP
can't communicate directly.

Then also, why not defining a Multicast Interface?  A multicast
interface is one that supports link-layer multicast.

> Border Router (BR)
> 
> a router that participates in multiple routing regions, and often 
> multiple routing protocols.  A BR defines the border between its 
> multiple routing regions.  A BR is responsible for presenting a 
> consistent picture of the nodes reachable through itself to each 
> routing region.  A BR determines the routing information to propagate
>  between different routing regions.

Due to similarity, maybe we should refer to OSPF's definition of an Area
Border Router and BGP's definition of an AS border router.

> MANET Router (MAN)

I think this may clash with Metropolitan Area Network.  Why not just
saying MANET router or so.

> MANET interfaces are defined as interfaces that demonstrate 
> asymmetric reachability and/or neighbor addresses that are not known 
> a priori.

I can understand the first part of the phrase emplying the term
asymmetric reachability if it were expanded.  It's easier to grasp if it
says that MANET interfaces can be unidirectional (if we agree sattelite
is part of MANET) and can have the hidden terminal problem.  Or that a
MANET interface has asymmetric dl/ul (download/upload) link characteristics.

I do not understand the last part of the phrase ("neighbor addresses
that are not known a priori").

> A MANET router may participate in routing on zero or more MANET 
> interfaces.

If a MANET router does no routing on a MANET interface (or participates
in routing on zero MANET interfaces) then it's no longer a MANET router,
right?

> MANET router may also have zero or more classic IP interfaces to
> which other nodes may connect; i.e. the router may be responsible for
> several IP prefixes.

Sorry, it does not follow.  That i.e. ("id est", lat.) makes me think
that only because the MANET router has some classic IP interfaces it is 
in charge for some IP prefixes, and thus maybe if it has no classic IP 
interfaces then it is _not_ in charge for any IP prefix; this is 
obviously not true, because if MANET router has a MANET interface then 
it necessarily has an IP prefix on it.

>          <~~~~~~+~~~~~~>            Routing-MANET
>                 |                   Interface(s)
>       ''''''''''|'''''''''''''''''
>       ' +-------|--------------+ '
>       ' | Router Functionality |...................
>       ' +-------+-+------------+ '  Routing-Classic
>       '         :  :             '  IP Interface(s)
>       ' MANET   :  +-----------+ '
>       ' Router  :  | Internal  | '
>       '         :  |Addressable| '
>       '         :  |Host Logic | '
>       '         :  |   (IAH)   | '
>       '         :  +-----------+ '
>       '''''''''':'''''''''''''''''
>                 : Nodes that live behind the router
>          +......+.........+           ============
>          :                :           =    :     =
>        +-+-+         +----+----+      =CLASSIC IP=
>        | N |  * * *  | Node(s) |      =INTERFACES=
>        +---+         +---------+      ============

This figure is unclear, because there are classic IP interfaces both on
the right and on the bottom of the router. Not sure what the ":" means
either. Looks like an elipsis (1, 2...3) but then "***" seems to be used
for same meaning.

> In MANETs there are several architectural scopes.  We define the 
> following scopes:
> 
> MANET Neighbors a set of MANET routers that is reachable via one IP
> hop, reachable via link-local messaging.

Is it the same as the link-local scope? The link-local scope is defined
for IPv6 in a certain RFC.

> MANET N-Neighborhood a set of MANET routers that is reachable via
> N-hops.  These routers usually have a large number of common
> neighbors and may directly compete for the same shared wireless
> resources.

This is very difficult to grasp. Neighbors (in terms of rfc2461) are
always on the same link. Here you're saying that MANET neighbors can be
on different links. I find this difficult to grasp conceptually, but it
may be only me.

> 4.2.3.  MANET Membership

I think it is difficult to talk about 'membership' like that, referring
to a node belonging or not to a mobile area network.

BEcause, 'membership' is widely used in multicast contexts, see MLD and
IGMP for example, and it can easily lead to clashes. At several places
in the draft I've been confused by this 'membership' dual meaning.

> A MANET router can be delegated zero or more prefixes.

I have difficulties in understanding this phrase. I generally agree that
a MANET router is in charge of routing for one or more prefixes.

If it is zero prefixes then it's not a router.

If it is 'delegated' then DHCP-PD was used.

I think the use of the words 'delegated' and 'zero' in that phrase is
problematic to my reading.

> If a MANET router is delegated a prefix p::, this prefix can be
> assigned to its classic IP link(s), and nodes can be assigned
> addresses from within this prefix, and configured with this prefix as
> illustrated in figure 6.

This text not only is in disagreement with the figure but also incorrect
in itself.

If prefix p::/48 is administratively assigned to a router then it can
not be (or is usually not) assigned as such on each of its interfaces.
Prefixes derived from that p::/48 are assigned to its interfaces (as the
figure correctly shows p:1:: p:2:: etc - it should be actually p:1::/64
or so)).

Also, this case of a unique p::/48 administratively assigned to a router
is a particular case. The more general (and 'classic' in my
understanding) case is where different prefixes are assigned to each
link to which the router is attached, and these prefixes have nothing in
common, but only the first three bits maybe. E.g. MANET Router with
three MANET interfaces is administratively assigned the prefixes p::/48,
q::/48 and r::/48 and the interfaces are configured with addresses in
prefixes p:1::/64, q:1::/64 and r:1::/64.

> o  MANET interfaces, forming a multihop MANET area, may use a site 
> prefix;

Not sure about this phrase, what site prefix?

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 1 Jun 2007 08:47:15 -0700

> saying MANET router or so.

How about either MAR or MARTR (for Mobile Ad-hoc Router)?

There was also still the point about acronym collision
for LFN in the NEMO terminology. LFN has been used for
"Long Fat Network" in the IETF terminology for a long
time, and a satellite link is one example of an LFN.
Was the acronym overlap intentional?

Fred
[email-masked]

---

From: "Ben McCarthy" <[email-masked]>
Date: Fri, 1 Jun 2007 17:08:18 +0100

Hi Fred,

> -----Original Message-----
> From: Templin, Fred L [mailto:[email-masked]]
> Sent: 01 June 2007 16:47
> To: Alexandru Petrescu; [email-masked]
> Subject: RE: [Autoconf] Re: I-D ACTION:draft-ietf-autoconf-manetarch-
> 02.txt
> 
> > > MANET Router (MAN)
> >

I haven't got any suggestion of my own, but I just thought I'd point out
that MAR is already a pretty heavily loaded acronym for Mobile Access
Router:

http://www.cisilion.com/cisco-3200-series.htm

http://research.microsoft.com/~pablo/MAR.htm

Hope this is of some help.

Cheers,

Ben

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Fri, 01 Jun 2007 19:20:40 +0200

Hi,

	I agree that MAR is already heavily loaded. I'd suggest using any other
acronym (such as MARO) or just using "MANET Router".

	Regards,

	Carlos

-- 
¡ASÓCIATE! Gratis para estudiantes  http://www.telematica.ws
 Carlos Jesús Bernardos Cano     http://www.netcoms.net
 GPG FP: BFF1 7C7A 6AA7 BCE3 885A  4DF1 ED0C 5952 BF89 B974

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 1 Jun 2007 13:25:45 -0700

Hi Teco,

A term in common use in other context for areas within
a MANET is "subnetwork" which is meant in a way that is
distinct from the term "subnet", i.e., it makes no statement
about IP prefix/netmask assignments. Subnetworks within a
MANET can indeed be connected by inner MANET border routers,
since they are essetially just smaller MANETs within a larger
MANET. So, one way to bound scaling is to bound the sizes of
subnetworks within a MANET.

Fred

> From: Teco Boot [mailto:[email-masked]] 
> Sent: Friday, June 01, 2007 1:28 AM
> To: [email-masked]
> Subject: RE: [Autoconf] I-D 
> ACTION:draft-ietf-autoconf-manetarch-02.txt 
> 
> Hi Ian, Joe and Thomas,

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 1 Jun 2007 23:27:00 +0200

Hi Fred,

What about adding a description on scaling mechanisms in the ID?
Can you provide references to IETF documents describing such a technology?
Is the difference between subnet and subnetwork somewhere defined clearly?

I will check RFC3819, but this one discusses a subnetwork as a L2 segment,
although references to L3 areas are mentioned.

My concern is what to do if nodes get out of reach of others in the same
subnetwork, and nodes member of other subnetworks connects them. It can
occur with three nearby nodes and one obstacle.

Cheers, Teco

> Sent: vrijdag 1 juni 2007 22:26
> To: Teco Boot; [email-masked]
> Subject: RE: [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt
> 
> Hi Teco,
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 1 Jun 2007 14:44:09 -0700

Teco,

Yes, RFC3819 is the IETF reference that I am aware of.
I have not done a thorough literature search such that
I could provide other references at this time, but I do
have plans to look into this.

Thanks - Fred

> Sent: Friday, June 01, 2007 2:27 PM
> To: Templin, Fred L
> Cc: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 01 Jun 2007 23:45:31 +0200

Templin, Fred L wrote:
>>> MANET Router (MAN)
>> I think this may clash with Metropolitan Area Network.  Why not 
>> just saying MANET router or so.
> 

I think MAR may clash with a Cisco Mobile Access Router (I may be wrong,
it's just vague rememberings).  MARTR sounds good but maybe too close to
begging for an unfortunate y... Maybe something else yet.

> There was also still the point about acronym collision for LFN in the
>  NEMO terminology. LFN has been used for "Long Fat Network" in the 
> IETF terminology for a long time, and a satellite link is one example
>  of an LFN. Was the acronym overlap intentional?

Generally speaking, I personally agree the acronym collision for LFN
should be solved, and that the easiest way to solve it is to change
current usage of NEMO LFN.  But, authors of that NEMO terminology draft
and a shepherding person pushing this through IESG seem to prefer to
just leave it as it is - something that I can understand somehow too
when the number of documents is so high planning them is stricter.

And no, the LFN acronym overlap was not at all intentional, it just came
during a discussion around a table without any worry of long-fat 
networks.  And I'm happy the overlap was revealed, at least we're aware 
of it.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 1 Jun 2007 14:59:38 -0700

Alex, 

I am fine with just raising awareness for the short term,
and revisiting in the longer term whether a change is needed.
For instance, it could be quite common in the future that a
NEMO/MANET router would have a connection to a Long Fat
Network (LFN) via a satellite link.

Thanks - Fred

---

From: "Ian Chakeres" <[email-masked]>
Date: Sat, 2 Jun 2007 16:10:25 +0530

Comments inline.

> Is IPv6 ND mentioned? I prefer an exact reference.

Done.

> introduce other problems, like multihop Asymmetric Reachability when path

I've changed the text to say
"""
MANET flooding consist of disseminating a piece of information to a
connected set of MANET routers.
"""
I believe that no MANET WG protocols require complete MANET wide flooding.

I think that the new text also captures your intent.

> areas_ I used above could be meant.

I've removed the bullet all together.

> single hop congested error-prone 2400bps link.

I did not understand your suggestion. Can you please provide me with a
clearer textual "fix"?

> something not explained in this ID.

I believe I've cut all the offending text.

> potential _MANET Neighbor_ and all _MANET Peers_ are configured for a

I've changed the title to "Number of MANET Routers in a MANET. Is that clearer?

This section gives people an idea of the current state of MANET
routing. We can safely say that MANETs can scale up to a few hundred
routers directly interconnected in one routing region (configured or
connected). For larger networks, hierarchy (not flat) still needs to
be used.

> and merge due to reachability, so _regions_ are based on connectivity and

A MANET's routing region is based on both connectivity and configuration.

Thanks for the comments.

Ian

---

From: "Ian Chakeres" <[email-masked]>
Date: Sat, 2 Jun 2007 17:02:29 +0530

Comments inline.

> > These routers may communicate over wireless links with asymmetric

We mean asymmetric reachability, as defined in the terminology
section. More below with your other comments.

> rechability in this sense.  Is there another?

Most of these links are not necessarily reflexive. Though they are
generally used only when the reflexive property is fulfilled.

Most of the wireless technologies you mention above exhibit
non-reflexive characteristics given certain conditions. For example,
asymmetric transmission power in IEEE 802.11 equipment.

> is the hidden terminal problem.

I think the term "hidden terminal problem" is too specific, as it
excludes that this case could occur in non-wireless networks also. For
example, poor performing ethernet cables between far devices.
Furthermore, the term asymmetric reachability is "well" defined in
several RFCs already.

> neighbors which is 'nodes attached to the same link'.

The term link and subnet are extermely overloaded terms. Given the
characteristics of MANET, I think the existing definition captures
what we are trying to describe.

> node sending a packet to a anycast address _does_ know that an anycast

I could not find anycast in the text, I think this is a copy/paste error.

> can't communicate directly.

At the IP layer two clients on the same IP (link/subnet) communicate
directly. The clients assume a FBI and the AP(s) try to give the view
of a FBI.

> interface is one that supports link-layer multicast.

If you feel this term is needed, I will include this term. Just let me know.

> saying MANET router or so.

I had changed MR to MAN specifically to address collision with other
terminology. I need a short version for diagrams.

Do you think MAR is better?

If you have another better suggestion - please provide it.

> that are not known a priori").

Classic IP links/interfaces assume that all the devices within the
same IP prefix/subnet are reachable in one IP hop. In a MANET, routers
often cannot make assumptions about who will be on this link - as they
are mobile and it will be changing. That is the concept I'm trying to
capture. If you have a suggestion on how to get this point across
please provide it.

> in routing on zero MANET interfaces) then it's no longer a MANET router,

A classic IP interfaces is a MANET interface. That is, all classic IP
interfaces by definition are at least capable of MANET interface's
characteristics. There is nothing stopping or hindering people from
running MANET routing protocols over classic IP interfaces. This is
the idea, I was trying to capture. If you have a clear way to present
this point, please make a suggestion.

> it necessarily has an IP prefix on it.

A MANET router could function using only link local addresses and
therefore not necessarily be in charge of any classic IP prefixes.

> either. Looks like an elipsis (1, 2...3) but then "***" seems to be used

I am trying to show that some classic IP interfaces are participating
in routing, while others are "behind" the router. That is the router
is responsible for participating in a routing protocol on these
prefixes behalf.

> for IPv6 in a certain RFC.

I've added a citation to the IPv6 scoped address arch.

> on different links. I find this difficult to grasp conceptually, but it

The term link is very overloaded and I've tried to avoid using it.

The term neighborhood is trying to capture the idea that MANET routers
often need to coordinate and know about MANET routers that are more
than one hop away.

> in the draft I've been confused by this 'membership' dual meaning.

Do you have a suggestion?

> If it is zero prefixes then it's not a router.

If a router uses only it's link local addresses, it can still be a
router and participate in routing.

> > addresses from within this prefix, and configured with this prefix as

The figure does not get into the specific size of the prefix(es) assigned.

> This text not only is in disagreement with the figure but also incorrect

<note> I seem to be missing something here or not understanding.
Perhaps you can send me a fix for the figure or text </note>

<maybe> is it the use of :: that is wrong?

> figure correctly shows p:1:: p:2:: etc - it should be actually p:1::/64

The router must assign the prefix(es) appropriately on classic IP interfaces.

> > o  MANET interfaces, forming a multihop MANET area, may use a site

I've cut this bullet.

Ian

---

From: "Teco Boot" <[email-masked]>
Date: Sat, 2 Jun 2007 23:14:58 +0200

Hi Ian, comments inline.

> I did not understand your suggestion. Can you please provide me with a

[Teco] 
Suggested text:
In MANET, nodes might assume a service is available locally (within one IP
hop) or within a particular scope (one or more IP hops - MANET, site,
global) or with a certain path metric.

> I've changed the title to "Number of MANET Routers in a MANET. Is that

[Teco] 
OK.
In the current document, scaling options for MANET using hierarchy or other
models are not described. A reason could be current IETF MANET protocols
does not implement such (I could miss something here). 

> A MANET's routing region is based on both connectivity and configuration.

[Teco] 
Suggestion for 2.2:
   MANET
      a configured routing region consisting of a set of MANET routers that 
      is reachable via one or more MANET router hops.  If a MANET connects
      to other routing regions, its border is defined by Border Routers.

I will check the current MANET protocols on this configuration option. It
could be missing. I am aware that isolation could be implemented using L2
parameters or security configuration. Quite unacceptable mechanisms. What do
you think?

Regards, Teco

---

From: "Ian Chakeres" <[email-masked]>
Date: Sun, 3 Jun 2007 08:12:16 +0530

Comments inline.

> global) or with a certain path metric.

I understand what you're getting at now, but I think that the "certain
path metric" case is covered by the above two cases. Or perhaps, the
path metric case doesn't fit with the other cases.

The concept I am trying to represent is that services might not be
local - for example, nodes might not be able to assume that a DHCP
server is run on every link, but they might need to use another
protocol (e.g. protocols developed by Autoconf).

I do like the idea that a message could be scoped by something other
than hoplimit or administrative configuration, but I think that is a
different concept. I also think the idea of a new scoping mechanism is
not MANET specific.

> does not implement such (I could miss something here).

The MANET WG protocols can use hierarchy, just like other routing protocols.

> parameters or security configuration. Quite unacceptable mechanisms. What do

If the configured border occurs on the edge with a wire I don't think
there is a problem. For example a border router connecting a MANET to
the Internet.

If the configured border occurs on a wireless MANET interface things
are more complex. This type of configuration is not explicitly
addressed at L3. There are many options to support this feature. One
option I have discussed is for packets or messages (using PacketBB) to
contain a MANET ID (TLV), thereby allowing devices to identify the
particular routing region for the packet/message.

I'm not sure whether the architecture document needs to talk about
this particular concept.  Do you think it should be flushed out in the
MANET arch document?

Ian

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Jun 2007 15:31:34 +0200

Hi Ian, thanks for your message.

Ian Chakeres wrote:
>>> Asymmetric Reachability
>>> 
>>> A link where non-reflexive and/or non-transitive reachability is
>>> part of normal operation. Non-reflexive reachability means that
>>> packets from X reach Y but packets from Y don't reach X.
>> 
>> I think this is the case only for sattelite wireless links.  Is
>> there another wireless link that has this property?  All wireless
>> links I can think of (2.4GHz WiFi, WLAN in general, IrDA,
>> bluetooth) are "reflexive" rechability in this sense.  Is there
>> another?
> 

I think transmission power is not a parameter at IP level.  I think the
IP stack doesn't know the transmission power, which may indeed be
asymmetric.

If you thought asymmetric transmission power, as a characteristic of
asymmetricity, I think this should be mentioned in the terminology
definition of asymetricity.

I personally think asymmetricity in terms of bandwidth and MTU.  This
has large impacts on IP stack, including TCP.

>>> packets from Y reach Z, but packets from X don't reach Z. Many
>>> radio/ wireless interfaces exhibit these properties.
>> 
>> well-known hidden terminal problem.  I think we should state that
>> this is the hidden terminal problem.
> 
> excludes that this case could occur in non-wireless networks also.

I'm almost sure the hidden terminal problem only shows in wireless links.

> For example, poor performing ethernet cables between far devices.

But common :-) Ethernet has precise specs saying how long the cables 
could be before repeaters :-)  Not respecting these specs doesn't turn 
them into special links but into faulty links :-)

> Furthermore, the term asymmetric reachability is "well" defined in 

Which ones?  The ones talking TCP?  I agree with those, should we 
reference them.

>>> Neighbor
>>> 
>>> If node X can directly exchange IP packets with node Y, then node
>>> Y is node X's neighbor.  Packet reception characteristics are
>>> often used to assist devices in determining the quality of
>>> neighbors' communication.
>> 

I think this is the kind of perspective I completely disagree with, 
sorry and a smiley :-)

I agree that link and subnet are so overloaded.  But a new definition 
like above is going to overload it even more :-)

Since 2461-ND runs ok over same wireless technologies over which MANET 
protocols have been run I think it makes a lot of sense to reuse ND 
terminology.

I'm not suggesting to use the 'neighbor' definition that I only myself 
understand, but the definition that is already there in ND, that I 
haven't invented.

>>> Note that an anycast address is syntactically indistinguishable
>>> from a unicast address.  Thus, nodes sending packets to anycast
>>> addresses don't generally know that an anycast address is being
>>> used.
>> 
>> In a sense yes, anycast addresses are syntactically
>> indistinguishable from unicast addresses, in that they're IPv6
>> 128bit addresses represented textually like any unicast address.
>> However, at least some if not all anycast addresses have a
>> IANA-reserved syntax.  Thus the node sending a packet to a anycast
>> address _does_ know that an anycast address is being used.
> 

Certainly a copy/paste error.  Sorry about it.  The comment is still 
valid but I think it pertains to rfc2461 instead (not to 
draft-ietf-autoconf-manetarch-02.txt).

>>> A broadcast interface with reflexive and transitive reachability.
>>> All nodes on the interface can send and receive IP packets
>>> directly, all nodes are symmetric neighbors.  An Ethernet segment
>>> is an example of a FBI.
>> 
>> I think you mean "a wired 802.3 Ethernet" is an example of FBI.
>> Because WiFi 802.11 does not have this symmetric property: two MSs
>> under a AP can't communicate directly.
> 
> directly.

YEs.

> The clients assume a FBI and the AP(s) try to give the view
>  of a FBI.

YEs.

In this sense, all interfaces are fully-broadcast, there's always an 
entity helping give that view.  I mean there's no interface (other than 
UDLR) that is not fully-broadcast.  Did you mean UDLR?

> If you feel this term is needed, I will include this term. Just let

Yes, multicast-capable link layers and interfaces, like IEEE WLAN or 
under-development 802.16 multicast-capable links are and can be easily 
accommodated by IPv6.

I think whenever talking IPv6 protocol (for MANET, AUTOCONF, and so on) 
we should talk multicast and less broadcast (broadcast being a 
particular and less mature case of multicast).

>>> routing region.  A BR determines the routing information to
>>> propagate between different routing regions.
>> 
>> Due to similarity, maybe we should refer to OSPF's definition of an
>> Area Border Router and BGP's definition of an AS border router.
>> 
>>> MANET Router (MAN)
>> 

MANET router.

>>> asymmetric reachability and/or neighbor addresses that are not
>>> known a priori.
>> 
>> asymmetric reachability if it were expanded.  It's easier to grasp
>> if it says that MANET interfaces can be unidirectional (if we agree
>> sattelite is part of MANET) and can have the hidden terminal
>> problem.  Or that a MANET interface has asymmetric dl/ul
>> (download/upload) link characteristics.
>> 
>> I do not understand the last part of the phrase ("neighbor
>> addresses that are not known a priori").
> 
> same IP prefix/subnet are reachable in one IP hop. In a MANET,
> routers often cannot make assumptions about who will be on this link
> - as they are mobile and it will be changing. That is the concept I'm
> trying to capture. If you have a suggestion on how to get this point
> across please provide it.

I think I'm more suggesting that MANET protocols have nothing to do with 
asymmetric links (as long as UDLR and sattelite is not used). 
Asymmetric links are important to TCP I believe, and to IPv6-over-foo 
protocols, but not much to MANET protocols...

I'm generally opposing the idea that asymmetric links are for MANET.

>> If a MANET router does no routing on a MANET interface (or
>> participates in routing on zero MANET interfaces) then it's no
>> longer a MANET router, right?
> 

My understanding is that there is no special 'MANET interface'. 
Asymmetricity is for TCP and for MAC.

I think also, as you, that MANET protocols can run over 'classical' IP 
interfaces.

>>> which other nodes may connect; i.e. the router may be responsible
>>> for several IP prefixes.
>> 
>> Sorry, it does not follow.  That i.e. ("id est", lat.) makes me
>> think that only because the MANET router has some classic IP
>> interfaces it is in charge for some IP prefixes, and thus maybe if
>> it has no classic IP interfaces then it is _not_ in charge for any
>> IP prefix; this is obviously not true, because if MANET router has
>> a MANET interface then it necessarily has an IP prefix on it.
> 

Not sure what you mean... a classical router can indeed work if it only 
had link-local addresses on its interfaces but classical being it it has 
different prefixes on these interfaces such that it can route otherwise 
it's not classical and it doesn't route.

>> This figure is unclear, because there are classic IP interfaces
>> both on the right and on the bottom of the router. Not sure what
>> the ":" means either. Looks like an elipsis (1, 2...3) but then
>> "***" seems to be used for same meaning.
> 

Thanks for the explanation.

>>> MANET Neighbors a set of MANET routers that is reachable via one
>>> IP hop, reachable via link-local messaging.
>> 
>> Is it the same as the link-local scope? The link-local scope is
>> defined for IPv6 in a certain RFC.
> 

Thanks.

>> This is very difficult to grasp. Neighbors (in terms of rfc2461)
>> are always on the same link. Here you're saying that MANET
>> neighbors can be on different links. I find this difficult to grasp
>> conceptually, but it may be only me.
> 

I think if you use the 'neighbor' term from ND then it's fine, to my 
reading, IMHO.

I don't think we avoid overloading by overloading even more.

I think (but not sure) that you may think, that 'neighbors' in OSPF 
terms is different than 'neighbors' in ND terms.  I personally think 
Neighbor is same OSPF or ND.  In this case there's no overloading.

That's why if we referred to both OSPF and ND definitions of 'neighbor' 
then we're probably fine.

But this is just a speculation on my side.

> The term neighborhood is trying to capture the idea that MANET
> routers often need to coordinate and know about MANET routers that
> are more than one hop away.
> 
>>> 4.2.3.  MANET Membership
>> 
>> I think it is difficult to talk about 'membership' like that,
>> referring to a node belonging or not to a mobile area network.
>> 
>> BEcause, 'membership' is widely used in multicast contexts, see MLD
>> and IGMP for example, and it can easily lead to clashes. At several
>> places in the draft I've been confused by this 'membership' dual
>> meaning.
> 

First of all, if the problem is to find out who are the members of MANET 
then determining the MANET's membership - just use MLD.

If on the other hand we want to say that when we need to find out who 
are the members of MANET then we should use MLD, then it's good too.

However, the stance of the section seems to be to motivate the use of 
flooding.  To which I can not disagree.  So I'm in a position where I 
better abstain to suggest anything, sorry.

>> I have difficulties in understanding this phrase. I generally agree
>> that a MANET router is in charge of routing for one or more
>> prefixes.
>> 

Routing between what and what?

>> This text not only is in disagreement with the figure but also
>> incorrect in itself.
> 

Maybe easier is to just picture an example MANET Router that you think 
most MANET people have run into?  Instead of trying to generalize?

A real example with real prefixes?  And just state that as an example.

>> If prefix p::/48 is administratively assigned to a router then it
>> can not be (or is usually not) assigned as such on each of its
>> interfaces. Prefixes derived from that p::/48 are assigned to its
>> interfaces (as the figure correctly shows p:1:: p:2:: etc - it
>> should be actually p:1::/64 or so)).
> 

YEs, I agree with appropriately.

Do you think your description can match a classical router with two 
interfaces and whose two prefixes are completely different?  (the two 
prefixes having only 3 first common bits).

I don't think your description can match such a router, because a P::/3 
will never be assigned to a MANET router; however, two prefixes P::/64 
can Q::/64 could very well be assigned to the interfaces to which this 
router connects.

Not sure I made myself clear.  If not then I'll just give it up.

>> Also, this case of a unique p::/48 administratively assigned to a
>> router is a particular case. The more general (and 'classic' in my 
>> understanding) case is where different prefixes are assigned to
>> each link to which the router is attached, and these prefixes have
>> nothing in common, but only the first three bits maybe. E.g. MANET
>> Router with three MANET interfaces is administratively assigned the
>> prefixes p::/48, q::/48 and r::/48 and the interfaces are
>> configured with addresses in prefixes p:1::/64, q:1::/64 and
>> r:1::/64.
>> 
>>> o  MANET interfaces, forming a multihop MANET area, may use a
>>> site prefix;
>> 
> 
> I've cut this bullet.

Thanks, I agree.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 Jun 2007 07:24:10 -0700

I would like to say just one more word about "subnetwork".
With "classical" links in the IETF context, it is commonly
considered that the layer immediately below IP is the link
layer (or, L2). But, in some MANET contexts, there may be
"sublayers" occurring between IP and the true link layer.
Concensus seems to be steering toward calling these the
"Sub-IP" layers, where Sub-IP is intended to mean anything
immediately below IP down to and including the upper portion
of L2.

Again, in some MANET contexts, the Sub-IP layers are
responsible for manifesting and maintaining subnetworks
over which IP runs, but this happens above the true link
layer. These subnetworks may comprise multiple links, such
that there may be multiple (Sub-IP) hops required to span
the subnetwork. But, as long as there is no attempt to apply
a classical "IP subnet" abstraction, there is no issue for
partitions/merges/etc.

Scaling of subnetworks can be bounded several ways,
including frequency multiplexing, spatial frequency reuse,
power control etc. But, I believe the methods used are
totally up to the subnetwork designer and so I don't see
a need to add anything about this in the manetarch document.

I might however suggest bringing "subnetwork" into the
terminology. For instance, a MANET could consist of many
"subnetworks"; each of which could be considered a MANET
unto itself.

Fred

> From: Templin, Fred L 
> Sent: Friday, June 01, 2007 2:44 PM
> To: Teco Boot
> Cc: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Jun 2007 17:39:36 +0200

Fred, I've read your clarifications with interest.

They picture sublayers between IP layer and link layer - sub-IP layers.
  Scaling subnetworks can indeed happen with link-layer, and I'd say more
below, mechanisms: frequency multiplexing, reuse, power control; but I
agree these are up to link-layer designer, maybe.

Bringing the term 'subnetwork' to the terminology is what I agree with
and I suggest to be added to the manetarch document; if other people
agree with.

Please allow me to explain why I remark to the MANET and AUTOCONF
manetarch document.

During the MANEMO effort we've been re-directed several times to
AUTOCONF and MANET WGs to look for mechanisms that could accommodate
MANEMO configurations.  My comments are in light of these re-directions.

For example, I believe that whereas MANET and AUTOCONF networks _may_
need sub-IP layer, there can exist MANEMO networks where the sub-IP
routing or scaling is done by a MAC layer.  For example two vehicles
connecting directly with WiFi.

In this sense, a MANEMO network does not need to be overwhelmed with the
complexity of separation of layers, sub-IP layer whose role could be
defined by both MANET and AUTOCONF, etc.  A MANEMO network could simply
re-use the MAC layer defined by Ethernet, that's all it needed.

This is to say that I agree with what AUTOCONF and MANET WGs decide to
have as architecture (sub-IP layers included or not).  But I strongly
suggest that the sub-IP layer and intermediary-layer routing as done (at
least) by DYMO are not necessary in other contexts, for example for
MANEMO vehicles connecting directly with WLAN.  It is unnecessary
complexification of scenes and configurations that are basically very
simple and whose link-layer complexities (asymmetricity included) are
hidden by a proper MAC layer.

I would also like to invite AUTOCONF and MANET WG participants to read
the MANEMO documents and participate in the MANEMO discussions.

Alex

Templin, Fred L wrote:
> I would like to say just one more word about "subnetwork". With
> "classical" links in the IETF context, it is commonly considered that
> the layer immediately below IP is the link layer (or, L2). But, in
> some MANET contexts, there may be "sublayers" occurring between IP
> and the true link layer. Concensus seems to be steering toward
> calling these the "Sub-IP" layers, where Sub-IP is intended to mean
> anything immediately below IP down to and including the upper portion
>  of L2.
> 
> Again, in some MANET contexts, the Sub-IP layers are responsible for
> manifesting and maintaining subnetworks over which IP runs, but this
> happens above the true link layer. These subnetworks may comprise
> multiple links, such that there may be multiple (Sub-IP) hops
> required to span the subnetwork. But, as long as there is no attempt
> to apply a classical "IP subnet" abstraction, there is no issue for 
> partitions/merges/etc.
> 
> Scaling of subnetworks can be bounded several ways, including
> frequency multiplexing, spatial frequency reuse, power control etc.
> But, I believe the methods used are totally up to the subnetwork
> designer and so I don't see a need to add anything about this in the
> manetarch document.
> 
> I might however suggest bringing "subnetwork" into the terminology.
> For instance, a MANET could consist of many "subnetworks"; each of
> which could be considered a MANET unto itself.
> 
> Fred [email-masked]
> 
>> -----Original Message----- From: Templin, Fred L Sent: Friday, June
>> 01, 2007 2:44 PM To: Teco Boot Cc: [email-masked] Subject: RE:
>> [Autoconf] I-D ACTION:draft-ietf-autoconf-manetarch-02.txt
>> 
>> Teco,
>> 
>> Yes, RFC3819 is the IETF reference that I am aware of. I have not
>> done a thorough literature search such that I could provide other
>> references at this time, but I do have plans to look into this.
>> 
>> Thanks - Fred [email-masked]
>> 
>>> -----Original Message----- From: Teco Boot
>>> [mailto:[email-masked]] Sent: Friday, June 01, 2007 2:27 PM To:
>>> Templin, Fred L Cc: [email-masked] Subject: RE: [Autoconf] I-D
>>> Can you provide references to IETF documents describing such a
>>> technology? Is the difference between subnet and subnetwork
>>> somewhere defined clearly?
>>> 
>>> I will check RFC3819, but this one discusses a subnetwork as a L2
>>> segment, although references to L3 areas are mentioned.
>>> 
>>> My concern is what to do if nodes get out of reach of others in
>>> the same subnetwork, and nodes member of other subnetworks
>>> connects them. It can occur with three nearby nodes and one
>>> obstacle.
>>> 
>>> Cheers, Teco
>>> 
>>>> -----Original Message----- From: Templin, Fred L
>>>> [mailto:[email-masked]] Sent: vrijdag 1 juni 2007
>>>> 22:26 To: Teco Boot; [email-masked] Subject: RE: [Autoconf]
>>>> I-D
>>>> A term in common use in other context for areas within a MANET
>>>> is "subnetwork" which is meant in a way that is distinct from
>>>> the term "subnet", i.e., it makes no statement about IP
>>>> prefix/netmask assignments. Subnetworks within a MANET can
>>>> indeed be connected by inner MANET border routers, since they
>>>> are essetially just smaller MANETs within a larger MANET. So,
>>>> one way to bound scaling is to bound the sizes of subnetworks
>>>> within a MANET.
>>>> 
>>>> Fred [email-masked]
>>>> 
>>>>> 8.2
>>>>>> ... complete number of nodes in a MANET ... ... cohesive
>>>>>> flat routing area ... ... a single routing region ...
>>>>> something not explained in this ID. I am still confused wat
>>>>> is meant in this section. There is the term _Peer MANET
>>>>> Routers_. It is not _connected MANET routers_ / _connected
>>>>> nodes_ (see text). I am not sure _MAN Neighbors_ is meant.
>>>>> May be a _MANET Peer_ is a potential _MANET Neighbor_ and all
>>>>> _MANET Peers_ are
>>> configured for a
>>>>> _single routing region_. But reading 2.2. _MANET_, a _MANET_
>>>>> is a _routing region_ and _MANETs_ split and merge due to
>>>>> reachability, so _regions_ are based on connectivity and not
>>>>> on configuration.
>>> 
>> _______________________________________________ Autoconf mailing
>> list [email-masked] 
> _______________________________________________ Autoconf mailing list
>  [email-masked] https://www1.ietf.org/mailman/listinfo/autoconf
>

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Mon, 4 Jun 2007 16:49:46 +0100

> connecting directly with WiFi.

I believe this is completely misunderstanding the MANET work,
as indicated by recent comments on the MANET list about DYMO.
DYMO (and other protocols being developed in the MANET WG)
are not using sub-IP routing, they are network layer routing
protocols. This is again therefore creating a false difference
between MANET and whatever MANEMO may or may not be.

> But I strongly
> least) by DYMO

And this is making explicit that misunderstanding.

********************************************************************
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.
********************************************************************

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 Jun 2007 08:50:43 -0700

Alex,

Thanks for the follow-up. Just for clarifications, I
am not meaning to suggest that MANET *requires* Sub-IP 
layers other than the true link layer; only that the
subnetwork abstraction is manifested by the layer
immediately below IP - be that a Sub-IP layer or the
true link layer itself.

I don't see a difference btw this and the other contexts
you mentioned; the same principle applies also to classical
interfaces such as wired LANs. I also believe the RFC3819
text applies equally for any subnetworks whether they are
manifested by the true link layer or a Sub-IP layer below
IP and above the true link layer.

Fred

> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Monday, June 04, 2007 8:40 AM
> To: Templin, Fred L
> Cc: Teco Boot; [email-masked]
> Subject: Re: sub-IP, AUTOCONF and MANEMO (was: [Autoconf] I-D 
> ACTION:draft-ietf-autoconf-manetarch-02.txt)
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Jun 2007 18:23:13 +0200

Dearlove, Christopher (UK) wrote:
>> For example, I believe that whereas MANET and AUTOCONF networks 
>> _may_ need sub-IP layer, there can exist MANEMO networks where the
>>  sub-IP routing or scaling is done by a MAC layer.  For example two
>>  vehicles connecting directly with WiFi.
> 
> I believe this is completely misunderstanding the MANET work, as 
> indicated by recent comments on the MANET list about DYMO. DYMO (and
>  other protocols being developed in the MANET WG) are not using
> sub-IP routing, they are network layer routing protocols. This is
> again therefore creating a false difference between MANET and
> whatever MANEMO may or may not be.

Christopher, thanks for pointing this.

>> But I strongly suggest that the sub-IP layer and intermediary-layer
>>  routing as done (at least) by DYMO
> 

I think there may indeed be some misunderstanding of DYMO on my part.

Could we please share some oppinions about how you see DYMO/NHDP
accommodate a MANEMO configuration and addressing scheme?  For example
do you think DYMO/NHDP are needed when the linnks are not asymmetric?
Any other thoughts on MANEMO and DYMO/NHDP?

Thanks,

Alex

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Mon, 4 Jun 2007 17:43:13 +0100

> Any other thoughts on MANEMO and DYMO/NHDP?

OLSRv2 is really my thing, rather than DYMO - what I've been commenting
on has almost entirely been things that you could say "DYMO" or "OLSR"
with otherwise no change in comments. Of course there are many other
things that do differ, and now you are getting into those. Also right
at the moment I don't really have time right now for the comments I have
made, and definitely not for what you want. I would say that the
preamble
to NHDP discusses what the point of it is - but you don't need all of
them
to want NHDP. For example if you consider that NHDP handles lossy,
possibly
asymmetric, dynamic links where you want one and two hop neighbourhoods,
you might still need NHDP if not all four of those conditions apply.

---

From: "Ian Chakeres" <[email-masked]>
Date: Mon, 4 Jun 2007 22:31:14 +0530

Comments inline with snips

> Hi Ian, thanks for your message.

<snip>

I think a pointer to IPv6 Neighbor discovery RFC clears up where this
term came from, and what it means.

<snip>

> it's not classical and it doesn't route.

Please see this presentation on unnumbered interfaces. It might
explain how a router would participate in routing without having an
address/prefix assigned to its various routable interfaces.

www.apricot.net/apricot2006/slides/conf/thursday/Kireeti_Kompella_unnum.ppt

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 04 Jun 2007 20:54:42 +0200

> term came from, and what it means.

After our long discussions on asymmetric reachability.

I think one should point to rfc2461bis draft, for being more updated.

I think 2461bis defines asymmetric reachability in an uncomplete and 
bizarre way.  I think 2461bis should talk about different ul/dl 
characteristics, udlr, tcp, mtu and bandwidth differences.

I think 2461bis says at some point that ND _does_ work over asymmetric 
links (where it suggests NUD will discover the other end can't talk to 
it) and at the same time it says in appendix that asymmetric links are 
subject to future extensions.

I think NHDP is not an ND extension.

I think we can discuss to understand commonly what we understand by 
'asymmetric' links.

I think MANET does not deal with unidirectional links like satellite.

So, what do _you_ understand by an asymmetric link:

1. Bandwidth/mtu variable uplink vs downlink ul/dl?

2. Links that may have the hidden terminal problem?

3. Unidirectional links like UDLR on satellite and DVB?

Other?

> www.apricot.net/apricot2006/slides/conf/thursday/Kireeti_Kompella_unnum.ppt

Right... an IPv6 router can route without having global prefixes on 
interfaces.

Remark the same presentation talks about ICMP... and thus a router 
without global addresses on its interfaces won't be able to send ICMP 
Redirect, or packet too big for PMTU, or ICMP...

Alex

---

From: [email-masked]
Date: Thu, 31 May 2007 18:50:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Ad-Hoc Network Autoconfiguration Working Group of the IETF.

	Title		: Mobile Ad hoc Network Architecture
	Author(s)	: I. Chakeres, et al.
	Filename	: draft-ietf-autoconf-manetarch-02.txt
	Pages		: 20
	Date		: 2007-5-31
	
This document discusses Mobile Ad hoc NETworks (MANETs).  It
   introduces basic MANET terms, characteristics, and challenges.  This
   document also defines several MANET entities and architectural
   concepts.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-autoconf-manetarch-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-ietf-autoconf-manetarch-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-autoconf-manetarch-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce
_______________________________________________
Autoconf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/autoconf

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 4 Jun 2007 16:22:25 -0700

> > If you have another better suggestion - please provide it.

"MANET router" seems unnecessarily verbose. MAR is not
defined in the IETF context so IMHO is eligible (just as
"MAG" was declared eligible in the NETLMM realm even though
it has entrenched connotations in other contexts). Another
suggestion is "MNR" (for "MaNet Router").

IMHO, we are starting to put an inordinate amount of energy
into this and should just pick something.

Fred

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 5 Jun 2007 09:52:03 +0100

> I think NHDP is not an ND extension.

You won't find anything, anywhere, by anyone who knows anything
about NHDP, claiming that it's an ND extension. This is another
red herring.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 05 Jun 2007 11:47:55 +0200

Dearlove, Christopher (UK) wrote:
> You won't find anything, anywhere, by anyone who knows anything about
>  NHDP, claiming that it's an ND extension. This is another red 
> herring.

I think I agree NHDP is not an ND extension.

I wanted to say that even if ND partially left asymmetric links for
future extensions (partially, because NUD does accomodate asymmetric
links somehow) - NHDP is not an ND extension.  There's little point
in motivating NHDP by saying that ND left it for it.

Alex

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Tue, 5 Jun 2007 10:49:43 +0100

> in motivating NHDP by saying that ND left it for it.

And, again, no one has said that.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Jun 2007 09:03:16 -0700

Actually, why not just call it as "MANET Mobile Router"
abbreviated as either "MMR" or "MANET MR" which can
be shortened to just "MR" within the scope of the MANET
architecture document.

Fred

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 05 Jun 2007 20:07:31 +0200

> be shortened to just "MR" within the scope of the MANET

:-) makes some sense to me up to some point...

Because if we say Mobile Router we understand a router that runs Mobile 
IPv6...

MMR is a usable term to me.

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 5 Jun 2007 11:37:03 -0700

Alex,

You would have to explain to me how Mobile Router necessarily
implies Mobile IP, but it would not be appropriate to draw that
distinction in terms of the MANET architecture document as I
think you know.

Fred

> Sent: Tuesday, June 05, 2007 11:08 AM
> To: Templin, Fred L
> Cc: Ian Chakeres; [email-masked]
> Subject: Re: [Autoconf] Re: I-D

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 05 Jun 2007 21:29:43 +0200

> distinction in terms of the MANET architecture document as I

FRed, I think I agree Mobile Router would not mean to everybody that it 
runs the Mobile IP protocol.  It does so to me.

And, the mobility terminology RFC3753 defines Mobile Router as:
>    Mobile Router (MR)
> 
>       A router capable of changing its point of attachment to the
>       network, moving from one link to another link.  The MR is capable
>       of forwarding packets between two or more interfaces, and possibly
>       running a dynamic routing protocol modifying the state by which it
>       does packet forwarding.
> 
>       A MR acting as a gateway between an entire mobile network and the
>       rest of the Internet has one or more egress interface(s)  and one
>       or more ingress interface(s).  Packets forwarded upstream to the
>       rest of the Internet are transmitted through one of the MR's
>       egress interface; packets forwarded downstream to the mobile
>       network are transmitted through one of the MR's ingress interface.

This reads to me very much as running Mobile IP and potentially a 
routing protocol too.

But that existing definition is different than the manetarch document 
definition of a MANET router at least because it talks about e/ingress 
interface whereas the latter talks about 'classical' and 'MANET' interfaces:

>    MANET Router (MAN)
>       a MANET router embodies router functionality and may also
>       incorporate an internally addressable host (IAH) logic, as
>       illustrated in Figure 1.  A MANET router has one or more
>       interfaces.  To simplify discussion we will classify the
>       interfaces into two categories: classic IP interfaces & MANET
>       interfaces.  MANET interfaces are defined as interfaces that
>       demonstrate asymmetric reachability and/or neighbor addresses that
>       are not known a priori.  A MANET router may participate in routing
>       on zero or more MANET interfaces.  A MANET router may participate
>       in routing on zero or more classic IP interfaces.  A MANET router
>       may also have zero or more classic IP interfaces to which other
>       nodes may connect; i.e. the router may be responsible for several
>       IP prefixes.

These two definitions are different.

Of course, AUTOCONF and MANET WGs are free to re-define Mobile Router as 
they best see fit, and ignore the existent definition of a Mobile Router 
(just as NEMO people ignored the pre-existing LFN term).

I think more would be gained if we could find coherency between the two 
notions of Mobile Router, and it starts at terminology...

Alex

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jun 2007 06:51:12 -0700

Alex,

Based on my read, the RFC3753 definition for Mobile
Router makes no statement about Mobile IP or not.

In terms of ingress/egress interfaces, IMHO a MANET
interface is neither/nor, i.e., a MANET interface is
not inherently in or out; up or down. In some respects
it might be considered as "sideways".

Fred

> Sent: Tuesday, June 05, 2007 12:30 PM
> To: Templin, Fred L

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 6 Jun 2007 16:08:56 +0200

Hi Fred,

3 seconds to find it in 3963(intro):
   Within the context of this document, the definition of a Mobile
   Router extends that of a Mobile IPv6 [1] Mobile Node, by adding
   routing capability routing between its point of attachment (Care-of
   Address) and a subnet that moves with the Mobile Router.

I think it just has to do with the order of publishing. Let's not spend time
on this discussion.

And you could read this (3753;-)
   Note: this reference architecture is not well suited for people
   dealing with Mobile Ad-hoc Networks (MANET).

Regards, Teco

> Sent: woensdag 6 juni 2007 15:51
> To: Alexandru Petrescu
> Cc: [email-masked]

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jun 2007 07:20:22 -0700

Thanks Teco, but I don't see the autoconf documents citing
RFC3963 yet. As to RFC3753, the text you quoted says that
the *reference architecture* is not well suited to MANETs;
it makes no statement about whether/not the *terminology*
is well suited. In fact, earlier it says:

   "First, there is a list of terms for general use and mobile access
   networks followed by terms related to handovers, and finally some
   terms used within the MANET and NEMO working groups."

That said, I am neutral as to whether the MANET arch should
try to incorporate anything about Mobile Router or any other
RFC3753 terms.

Fred

> Sent: Wednesday, June 06, 2007 7:09 AM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: RE: [Autoconf] Re: I-D

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 06 Jun 2007 16:25:49 +0200

Templin, Fred L wrote:
> Alex,
> 
> Based on my read, the RFC3753 definition for Mobile Router makes no
> statement about Mobile IP or not.

It doesn't, but it's obvious to my reading, deduced from the fact that 
it says the MR attaches to different points of attachment to the 
Internet.  To do that, the MR must run Mobile IP.  The only alternatives 
I can think of are HIP and MOBIKE, but not MANET.

> In terms of ingress/egress interfaces, IMHO a MANET interface is
> neither/nor, i.e., a MANET interface is not inherently in or out; up
> or down. In some respects it might be considered as "sideways".

I think I agree with the sideways aspect and that it looks more 
equipotential interface, no directivity.  That is related to the fact 
that MANET doesn't discuss the existence or absence of a default route, 
and little about the reachability to Internet.  If it did then it would 
have been more directed interfaces.

For MANEMO, a case of Mobile Router that was widely discussed is where 
the router has an egress interfaces on which NEMOv6 is run and an 
ingress interface on which a MANET protocol is run; thus the MR's 
ingress interface is a MMR's MANET interface... or so.

I think I will suggest that to MANEMO.

Alex

>> -----Original Message----- From: Alexandru Petrescu
>> [mailto:[email-masked]] Sent: Tuesday, June 05, 2007
>> 12:30 PM To: Templin, Fred L Cc: Ian Chakeres; [email-masked] 
>> FRed, I think I agree Mobile Router would not mean to everybody
>> that it runs the Mobile IP protocol.  It does so to me.
>> 
>> But that existing definition is different than the manetarch
>> document definition of a MANET router at least because it talks
>> about e/ingress interface whereas the latter talks about
>> 'classical' and 'MANET' interfaces:
>> 
>>> MANET Router (MAN) a MANET router embodies router functionality
>>> and may also incorporate an internally addressable host (IAH)
>>> logic, as illustrated in Figure 1.  A MANET router has one or
>>> more interfaces.  To simplify discussion we will classify the 
>> Of course, AUTOCONF and MANET WGs are free to re-define Mobile
>> Router as they best see fit, and ignore the existent definition of
>> a Mobile Router (just as NEMO people ignored the pre-existing LFN
>> term).
>> 
>> I think more would be gained if we could find coherency between the
>> two notions of Mobile Router, and it starts at terminology...
>> 
>> Alex
>> 
>> 
>>  This email has been scanned by the MessageLabs Email Security
>> System. For more information please visit
>> http://www.messagelabs.com/email

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 6 Jun 2007 16:57:58 +0200

Hi Fred, 

I started the overlapping MR acronym. This as a reaction on the discussion
on LFN. I think MR and MR (for a MANET Router and a Mobile Router) could be
more confusing than LFN and LFN (Long Fat Network and Local Fixed Network).

I expect routers are or will be MR and MR, some are only MR, others are the
opposite and just MR and some are not MR at all. I use the abbreviation just
to show there could be some confusion; in other context I will use full
names.

For new documents, we can discuss the acronym used. It would be helpful to
come up with something useful and stop the discussion as soon as possible.

And also, new documents should try to obey RFC3753 and
draft-ietf-nemo-terminology, which is to be published as RFC soon.

Regards, Teco

> Sent: woensdag 6 juni 2007 16:20
> To: Teco Boot
> Cc: [email-masked]

---

From: "Ben McCarthy" <[email-masked]>
Date: Wed, 6 Jun 2007 16:09:51 +0100

Hi Teco,

> Sent: 06 June 2007 15:58
> To: 'Templin, Fred L'

I think Fred's original proposal on this was that in situations where the
two terms could coincide you could use MMR for "MANET MR" and then in purely
MANET situations you could just use MR.

Is my thinking correct here Fred?

Cheers,

Ben

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 6 Jun 2007 08:16:17 -0700

> MANET situations you could just use MR.

I think Teco has said why he doesn't like "MR" for
"MANET Router" in any situation. I am neutral on "MMR"
for "MANET MR"; I have a slight preference towards "MNR"
for "MaNet Router".

Fred