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

From: [email-masked]
Date: Mon, 09 Jul 2007 13:15:05 -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-04.txt
	Pages		: 21
	Date		: 2007-7-9
	
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-04.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-04.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-04.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.
_______________________________________________
Autoconf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/autoconf

---

From: "Dearlove, Christopher \(UK\)" <[email-masked]>
Date: Wed, 11 Jul 2007 15:56:42 +0100

I see that my comments on reflexive and transitive have turned
into:

> Note: the definitions of non-reflexive and non-transitive
> above differ from mathematical terminology.

I strongly disagree with this treatment. Actually transitive
isn't non-standard, but the inclusion of transitivity makes
this not a property of a link, but of a network. Reflexive
is wrong, and you don't fix a problem by adding a note that
this is wrong, you change it.

I think these changes should be made (especially the first
two)
- That this is not just a property of a link.
- Changing reflexive to the proper term, symmetric (which
  is a reason for the next point, to avoid overloading the
  term symmetric).
- Asymmetric reachability to something else (what you are
  really saying is that it's not an equivalence relation,
  but that may be more detail than is needed).

I haven't checked how my other comments have been handled.

********************************************************************
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: Wed, 11 Jul 2007 10:35:38 -0700

Overall, the document is in reasonably good shape. The most
substantial  objection is that it consistently uses the term
"interface" where the term "link" should be used instead. Also,
the MANET router definition seems to assume only a singular
"internal addressable host logic" whereas a node may embody
an arbitrarily-complex internal network of virtual hosts (e.g.,
a network of virutal machines running inside a linux box).

The following are specific comments and change suggestions
for the -04 draft:

Fred
[email-masked] 

1) (comment) Section 2.1, the definition for the term "Link"
is acceptable, but would be better served by adopting the
full text of the definitions for "link" found in RFCs
2460/2461/3753.

2) (semi-editorial) Section 2.1, the definition for the term
"Asymmetric Reachability" - rename as "Asymmetric Reachability
Link".

3) (comment) Section 2.1, the definition for the term "interface"
is correct as-written, but compare against the way the term is
being (mis)used elsewhere throughout the document (see below).

4) (substantial) Section 2.1, remove the definitions for
{Broadcast, Full-Broadcast, Semi-Broadcast} Interface. These
are describing properties of *links*; not *interfaces*. And,
since "Asymmetric Reachability Link" is already defined and
covers the same definition space that these are intending to
cover, their presence is redundant.

(If there is a desire to retain the phrase: "semi-broadcast",
this can be added as a new sentence under the "Asymmetric
Reachability Link" defininition, i.e., "semi-broadcast" is
one property of such links.)

5) (comment) Section 2.2, 'draft-templin-autoconf-dhcp-08.txt'
defines several terms that also appear here (e.g., MANET, MANET
Router, MANET interface, etc.) and should be consulted for
consistency with this document (see below). 

6) (substantial) Section 2.2, the definition for the term "MANET
Router" and accompanying figure seem to assume a singular "internal
addressable host logic" whereas a MANET router may contain an
arbitrarily-complex internal network of virtual links connecting
internal hosts. Also, the term "classical IP interface" is not
defined and is insufficient to cover the types of interfaces a
MANET router may have - namely, MANET interfaces, ingress
interfaces, and egress interfaces (where ingress/egress are the
same as defined in RFC3753). See the definition and figure for
"MANET Router" in draft-templin-autoconf-dhcp-08.txt.

7) (substantial) Section 2.2, add a definition for "MANET interface"
as follows:

   "MANET Interface
       a MANET Router's attachment to an asymmetric reachability
       link. A MANET interface is a "lateral" interface, i.e., it
       is inherently neither an ingress nor egress interface although
       it can sometimes exhibit characteristics of both."

8) (editorial) Section 2.2, s/may partitioned/may be partitioned/

9) (editorial) Section 2.2, s/MANETs' BR/MANET's BRs/

10) (semi-substantial) Section 3, second paragraph, second sentence,
change: "single SBI" to: "single MANET interface".

11) (semi-editorial) Section 3, second paragraph, next-to-last
sentence, change: "R1 on its interface" to: "R1 on its MANET
interface".

12) (semi-substantial) Section 3, second paragraph, last sentence,
remove the leading phrase: "This example also illustrates how SBIs
differ from FBIs:".

13) (semi-substantial) Section 3, Figure 2, change: "SBI" to:
"MANET Interface".

14) (semi-editorial) Section 3, paragraph immediately following
Figure 2, change: "nodes' asymmetric reachability" to: "asymmetric
reachability links".

15) (semi-substantial) Section 3, same paragraph as 14), change:
"dynamic wireless interface" to: "dynamic wireless link".

16) (semi-substantial) Section 3, next to last paragraph, change:
"node and interface" to: "node and link".

17) (semi-substantial) Section 3, last paragraph, change:
"heterogeneous interfaces" to: "heterogeneous links".

18) (semi-substantial) Section 4.1, change: "interface" to: "link"
in 4 places.

19) (editorial) Section 4.1, third paragraph, s/exacerbates/exacerbate/

20) (editorial) Section 4.2, s/MANETs/MANET/

21) (substantial) Section 4.2.1, change title to: "Asymmetric
Reachability Links".

22) (semi-substantial) Section 4.2.1, first paragraph, change:
"a wireless SBI with asymmetric reachability" to: "an asymmetric
reachability link".

23) (semi-substantial) Section 4.2.1, Figure 3, change: "Single SBI"
to: "Single MANET Interface" and change figure caption to:
"Asymetric Reachability Link and Neighboring Routers".

24) (semi-substantial) Section 4.2.1, paragraph after Figure 3,
change: "wireless interface" to "MANET interface".

25) (semi-substantial) Section 4.2.2, first paragraph, change:
"interface characteristics" to: "link charachteristics".

26) (substantial) Section 5.1, second sentence, change to:
"The attached nodes may be "external" (i.e., attached to the
router via interfaces to external networks) or "internal"
(i.e., attached to the router via internal virtual interfaces)."

(Note that the trailing phrase beginning: "- however the
important" should be removed since it is redundant with the
following sentence.)
  
27) (substantial) Section 5.1, Figure 5, same comment as for
6) above; a MNR need not have only a singular IAH. See also
Figure 1 in draft-templin-autoconf-dhcp-08.txt.

28) (substantial) Section 5.1, paragraph following figure 5,
change: "interfaces towards classic IP link(s)" to: "ingress
interfaces". Reason being is that delegated prefixes can
only be assigned to "downstream" (aka ingress) interfaces;
they cannot be assigned to "upstream" (aka egress) interfaces.
(They also cannot be assigned to MANET interfaces, which are
neither up- nor downstream, but "lateral".)

29) (substantial) Section 5.1, paragraph beginning:
"Interface(s) with asymmetric...", change first sentence
to: "MANET interfaces and egress interfaces are specifically
*NOT* configured with delegated prefixes."

30) (substantial) Section 5.1, paragraph immediately before
Figure 6, this paragraph needs to be rewritten in light of
the earlier change suggestions. No specific change suggestions
at this time.

31) (substantial) Section 5.1, Figure 6, same comment as for
6) and 27) above.

32) (semi-substantial) Section 5.2, first paragraph, first
sentence, strike the phrase "semi-broadcast interfaces".

33) (comment) Section 5.2, this paragraph may benefit from
adopting the definition for "MANET Local Address (MLA)"
found in draft-templin-autoconf-dhcp-08.txt as well as
descriptive text in that document that speaks to MLAs.

34) (substantial) Section 6, this entire section seems to
say that there is IP-layer (L3) MANET routing and L2 MANET
routing (aka bridging) and nothing else in-between. I am
aware of use-cases in which MANET routing is applied as
neither a pure IP-layer mechanism nor a pure L2 mechanism
but rather "something in-between" that could be considered
as a grey-area in-between routing and briding. Suggest this
entire section be re-written using the term "IP Layer"
instead of L3 and "Sub-IP Layer" instead of L2. Also, drop
the (wrong) assumption that: "If it isn't IP Layer, then it
must be bridging".

35) (semi-substantial) Section 8, change: "inexpensive
wireless interfaces" to: "inexpensive wireless link types".

36) (semi-editorial) Section 8.3, under the list of example
deployments, add: "aircraft networks, ship-to-ship networks,
and many others".

(end of comments)

---

From: "Teco_Boot" <[email-masked]>
Date: Thu, 12 Jul 2007 11:14:44 +0200

Comments inline.
Teco.

>        it can sometimes exhibit characteristics of both."
[Teco] 
Please avoid terms ingress and egress interface here. In NEMO context, it is
extremely confusing. And Autoconf and NEMO are related.
RFC3753 definitions:
Ingress interface
      The interface of a MR attached to a link inside the mobile
      network.
Egress interface
      The interface of a MR attached to the home link if the MR is at
      home, or attached to a foreign link if the MR is in a foreign
      network.

> neither up- nor downstream, but "lateral".)
[Teco] 
Same story

> *NOT* configured with delegated prefixes."
[Teco] 
Same story

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 12 Jul 2007 08:38:40 -0700

Teco - see below:

> -----Original Message-----
> From: Teco_Boot [mailto:[email-masked]] 
> Sent: Thursday, July 12, 2007 2:15 AM
> To: Templin, Fred L; [email-masked]
> Cc: 'Thomas Heide Clausen (home)'
> Subject: RE: [Autoconf] Comments on 
> draft-ietf-autoconf-manetarch-04.txt
> 
> Comments inline.
> Teco.
> 

Please look at the paragraph immediately preceding those two
definitions in RFC3753, where it says:

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

By this paragraph, an egress interface is used for forwarding
packets "upstream" to the rest of the Internet and an ingress
interface is used for forwarding packets "downstream" to a
mobile network. This is exactly the sense in which I am
intending egress/ingress in my change suggestions. I could
have said "upstream/downstream", but that would seem less
precise?

Fred

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 13 Jul 2007 09:26:31 +0200

Fred,

Your definition is about a MANET Router (MNR).
RFC3753 is about a Mobile Router (MR).
Although MR and MNR have many characteristics in common, they are different.
MR, Mobile Network, Ingress Interface and Egress Interface are further
described in draft-ietf-nemo-terminology-06 (in RFC queue).

Combining MR and MNR is work in progress (MANEMO). Maybe we have the same
opinion what to do with interface types MANET, Ingress and Egress.
We will have a discussion on this in Chicago.

Regards, Teco

> From: Templin, Fred L [mailto:[email-masked]]
> Sent: donderdag 12 juli 2007 17:39
> To: Teco_Boot; [email-masked]
> Cc: Thomas Heide Clausen (home)
> Subject: RE: [Autoconf] Comments on draft-ietf-autoconf-manetarch-04.txt
> 
> Teco - see below:
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 13 Jul 2007 08:07:37 -0700

Teco,

> From: Teco Boot [mailto:[email-masked]] 
> Sent: Friday, July 13, 2007 12:27 AM
> To: Templin, Fred L
> Cc: [email-masked]

Using the RFC3753 definition, IMHO a MNR is essentially a
MR that that has MANET interfaces and may participate in
routing over them.

> Combining MR and MNR is work in progress (MANEMO).

Perhaps we are making this into something more than it really
is (see below).

> Maybe we have the same

Maybe we do have the same opinion, and IMHO its pretty simple;
egress interfaces forward packets upstream (toward the Internet),
ingress interfaces forward packets downstream (toward mobile
networks) and MANET interfaces forward packets laterally
(toward other MANET interfaces).

Please see Figure 1 in 'draft-templin-autoconf-dhcp-08.txt' for
a graphical depiction of this.

Thanks - Fred

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 13 Jul 2007 18:06:36 +0200

Hi Fred,

I checked draft-templin-autoconf-dhcp-08.txt.
It uses egress in a different context as RFC3753.
In 3753, the egress is connected to the home link or to the foreign link, in
templin-autoconf-dhcp it is used to forward packets to the Internet.
IMHO this is very different. For example, the RFC3753-Ingress-interface can
provide connectivity to Internet via another router (MR, MNR or LFR).

In templin-autoconf-dhcp, there is little difference in the ingress and
egress interfaces. Both have arrows pointing away from the router entity. I
think both interface types are bi-directional (incoming and outgoing
packets). I think peering to other routers is possible on both interface
types. 
A difference I can think of is that via the egress interface, a link to a
next hop neighbor for a default route exists. Or the ingress interface is a
stub network, it does not peer to other routers on it.

Why not using MANET Architecture figure 1?
There, the term Classic IP Interface is used. What is the difference with
your ingress and egress interface?

Regards, Teco

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 13 Jul 2007 10:09:18 -0700

http://www.ietf.org/internet-drafts/draft-templin-autoconf-dhcp-08.txt

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 16 Jul 2007 09:31:48 -0700

Teco, 

> Sent: Friday, July 13, 2007 9:07 AM
> To: Templin, Fred L
> Cc: [email-masked]

Thanks for checking, and see below.

> It uses egress in a different context as RFC3753.

I don't see it as different; in particular, see the paragraph
in RFC3753 immediately preceding the definition for "Ingress
interface" where it says:

This sets the directionality for ingress/egress interfaces
in a way that matches what is said in 'draft-templin'. It is
essentially the applicability statement for ingress/egress
interfaces, and no other use for ingress/egress interfaces
is implied in their respective definitions.

> IMHO this is very different.

As above, 'draft-templin' is compatible with the second
paragraph of the definition for Mobile Router and hence
also compatible with the definition for Egress interface.

That said, 'draft-templin' defines MANET Router as: "a
node that...". Will fix this in the next version to say:
"a Mobile Router that ...".

> For example, the 
> RFC3753-Ingress-interface can

By RFC3753, Ingress interfaces are a MR's interfaces that
connect Mobile networks to the Internet and by the RFC3753
definition for Mobile network, a Mobile network is "An
entire network, moving as a unit, which dynamically changes
its point of attachment to the Internet...".

It is true that a mobile network can connect to the global
Internet via one or more MNRs, but what you are saying above
implies that the Mobile network can be used as a transit
network for the MNR's default route and that does not seem
to follow from RFC3753. 
 
> egress interfaces.

Not true; egress interfaces are "upstream" and ingress
interfaces are "downstream", so there is a directionality.

> Both have arrows pointing away from the router entity.

True.

> I think both interface types are bi-directional (incoming
> and outgoing packets).

True.

> I think peering to other routers is possible on 
> both interface types.

True.

> A difference I can think of is that via the egress interface, 
> a link to a next hop neighbor for a default route exists.

This seems well-worded and probably also true depending
on the sense in which you mean "next hop neighbor". If
you mean "next hop neighbor" as a persistent neighbor on
the same physical link then I agree. If you mean next hop
neighbor as the next IP hop, then I don't necessarily agree,
because the next IP hop may be many physical hops away. But,
that would make it a MANET interface as opposed to an egress
interface.

> Or the ingress interface is a stub network, it does not peer
> to other routers on it.

Not true, mobile networks attached on a MNR's ingress
interfaces can be not-so-stubby and have many attached
routers (or maybe I misunderstood).
 
> Why not using MANET Architecture figure 1?

IMHO, the figure in 'draft-templin' is better.

> your ingress and egress interface?

The difference is in the directionaliy; "Classical IP
interface" in the MANET Architecture draft does not
capture a directionality.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 18 Jul 2007 11:01:54 -0700

A brief set of comments on this draft follows:
 
Fred

1) (semi-substantial) Section 1, first sentence of final
paragraph (and elsewhere throughout the document), the
document should remain agnostic to the particular IP
version. Suggest changing first portion of sentence to:

  "Standard automatic address/prefix assignment solutions
   (e.g., [5], [3], [4], etc.) ..."

2) (suggestion) Section 2, the definition for "Local address",
suggest renaming this to "MANET Local Address (MLA)" (the term
"MLA" is used in other autconf-related documents).

3) (substantial) Section 2, the definition for "Local address",
strike the second sentence. In the first case, this document
is a problem statement and should not be using MUST/SHOULD/MAY,
and in the second case at least one anticipated type of MLAs
(namely, RFC4193 ULAs) are permitted to be routed between
sites - see ([RFC4193], Section 1). Also, strike the RFC2119
language at the beginning of this section.

4) (editorial) Section 3.1, end of second paragraph, the
phrase "either either" appears.

5) (semi-editorial) Section 3.2, first paragraph, the term
"MBR" is now being called simply: "BR" in [2] (but, I prefer
"MNBR").

6) (editorial) Section 3.3, "scenarii" - spelling?

7) (substantial) Section 4.1, first paragraph is too IPv6-
centric and its use of the terms "host interface" and
"loopback interface" seem overly precise and potentially too
restrictive for this document's scope. Suggested reword for
paragraph:

  "A MANET router needs to configure addresses and/or prefixes on its
   non-MANET interfaces. Besides, it needs to configure an MLA and/or
   a link local address on its MANET interface.  A MANET router may also
   configure a prefix shorter than /128 (IPv6) or /32 (IPv4) on its
MANET
   interface provided prefix uniqueness is guaranteed [2]."

8) (editorial) Section 4.2.4, spelling on "partitionning" in 2 places. 

(end of comments)

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 20 Jul 2007 17:47:34 +0200

>    interface provided prefix uniqueness is guaranteed [2]."
[Teco] 
I think Autoconf is chartered for IPv6 only. So what is wrong with an
IPv6-centric approach?

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 20 Jul 2007 09:06:37 -0700

Teco,

By my read, the Autoconf wg charter calls for the development
of IPv6 address autoconfiguration mechanisms and I support that.
But at the same time, the charter does not disallow the use of
IPv4 in MANETs and so a problem statement should not introduce
such a restriction. Therefore, I agree that my use of the
phrase "too IPv6-centric" may not have been quite right, but
IMHO the change suggestion is appropriate.

Fred

> Sent: Friday, July 20, 2007 8:48 AM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: RE: [Autoconf] comments on 
> draft-ietf-autoconf-statement-00.txt
>

---

From: Shubhranshu <[email-masked]>
Date: Sat, 21 Jul 2007 00:49:13 +0530

Please see inline comments:

>   (e.g., [5], [3], [4], etc.) ..."

I am OK with the suggested changes however we need to scope the
Problem statement ID with discussions specific to IPv6 and save our
effort in analyzing any IPv4 specific issues, at least when the WG is
not charterd to work on IPv4 aspect at this point of time.

> "MLA" is used in other autconf-related documents).

Agree.

> language at the beginning of this section.

OK

> "MBR" is now being called simply: "BR" in [2] (but, I prefer

I'd also prefer to use MNBR.

> 6) (editorial) Section 3.3, "scenarii" - spelling?

Yes, needs to be fixed.

>   interface provided prefix uniqueness is guaranteed [2]."

Ok with this. However, please note that MANET interface is allowed to
configure global IP address on its interface (and not only
MLA/Link-local address).

> 8) (editorial) Section 4.2.4, spelling on "partitionning" in 2 places.

thanks, Fred

- Shubhranshu

---

From: "Teco_Boot" <[email-masked]>
Date: Sun, 22 Jul 2007 22:27:02 +0200

Hi Fred,
Comments inline.
Teco.

> Sent: maandag 16 juli 2007 18:32
> To: Teco Boot
> Cc: [email-masked]
[Teco] 
Please explain the templin-autoconf-dhcp egress-interface connected to the
home link and to foreign links. Is routing disabled when connected to a
foreign link? If not, please explain why not.
=== (RFC3963)
   The Mobile Router should be configured
   not to send any routing protocol messages on its egress interface
   when it is away from the home link and connected to a visited link.
===

> "a Mobile Router that ...".
[Teco] 
Mobile Router or MANET router?
I think a Mobile Router provides macro mobility services to MNNs and a MANET
router provides micro mobility for its internal host functionality and
connected hosts (Nodes that live behind the router).

> network for the MNR's default route and that does not seem
[Teco] 
Why not? Please check section 8 in RFC3963.
Mobile networks can also be multi-homed (RFC4885 section 5.3) and I do not
see any reason they cannot provide connectivity to Internet to each other.

> interfaces are "downstream", so there is a directionality.
[Teco] 
I do not understand what you mean by this. I thought both interface types
were bi-directionally. Maybe the difference is that the ingress interface
connects a stub network and on the egress interface, a route to the Internet
could exist. I reject this classification, as I explained above.

> routers (or maybe I misunderstood).
[Teco] 
OK, but when peering to other routers is supported, the ingress interface
can be used for reaching the Internet and thus transforms into an "egress". 

> capture a directionality.
[Teco] 
That is why I prefer the MANET-architecture figure. 
After this comment on comment I still do not see a reason using ingress and
egress interface for what I would call "Classical IP interfaces".

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 23 Jul 2007 10:21:12 -0700

Teco,

I am just seeing your message now, but I would only add by way
of follow up for now that IMHO: 1) an egress interface is one
over which a MR can configure a default route and 2) an ingress
interface is one over which a MR can advertise itself as a
default router. Some interfaces might not qualify on either
point, and IMHO a MANET interface fits that desciption. Other
interfaces might qualify on both points, but I would have to
think about that more...

Fred

> Sent: Sunday, July 22, 2007 1:27 PM
> To: Templin, Fred L
> Cc: [email-masked]