Subject: [Autoconf] Review of draft-ietf-autoconf-manetarch-07

From: "Ulrich Herberg" <[email-masked]>
Date: Mon, 26 Nov 2007 16:16:21 +0100

Hi,

some minor comments on the MANET architecture draft:
----------------------
typos:
----------------------

  -- page 10 (section 4.2.2), paragraph 4: "In MANETs` with SBI...";
remove the genitive apostrophe
  -- page 12 (section 5.1), paragraph 3: "...may be assigned to the
MANET routers' non-MANET interfaces(s)" ; remove first s of interfaces
  -- same paragraph: the prefix p should be either upper-case or
lower-case but not mixed
  -- page 13 (section 5.2), paragraph "unique prefixes": "this
requirements" -- wrong plural; should be "these requirements" or "this
requirement"
  -- same paragraph, "One way to achieve this is /128 ..."; I would
rather say "One way to achieve this is _using_ /128 [...] prefixes"...
as I am not a native English speaker, I am not sure about that :-)
  -- same paragraph, last line: MANETs instead of MANET
  -- page 15 (section 7), paragraph 2: "or two network can share...";
network should be in plural
  -- page 16 (section 8.2), paragraph 2: "to discuss the number of
MANET router to.."; router should be in plural

------------------
other issues
------------------
  -- maybe I would combine section 6 and 7. They seem to belong
together in a certain way
  -- figure 5: maybe I just didn't see it, but I cannot find a
reference to this figure
  -- figure 6: I would definitely add some more explanations to this
figure (which itself is very good) in the paragraph above of it: it
could be explained why a /62 prefix is used in the delegated prefix,
otherwise one could think it's a typo. Also the loopback interface is
not explained in the text. One could maybe also add in the text that
the address of the MANET interface of is not part of a subnet, or
formulated in another way: the MANET is not a subnet. In the second
paragraph of section 5.1, one could relate these nodes with the figure
(to help the reader understand which nodes in the figure are exposed
to the MANET characteristics and which not)
  -- section 8.1. "one or more IP hops - MANET, _site_,...". Is the
site scope defined? Hasn't it been declared deprecated in RFC3879?
  --  same section, last sentence. I do not understand this sentence;
why do you suddenly talk about AS, when you did never before or after
this sentence?

Regards,
Ulrich

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

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 26 Nov 2007 19:19:44 +0100

Hi Ulrich, please allow me make some comments without troubling too much 
the waters on this topic.  This document manetarch is already largely 
discussed and hard-agreed, and deep in the reviewing state.

Ulrich Herberg wrote:
[...]
>        MANET        <~~~~~~+~~~~~~>
>      Interface             |              Delegated
>                            |              Prefix
>                  '''''''''''''''''''''    ==========
>                  '       MANET       ' <=== P::/62 =
>                  '       Router      '    ==========
>                  ''''''''' :         '    Assigned
>                       :  ' :         '    Prefix
>                       :  '++--------+'    ============
>                       :  '|Loopback |' <=== P:1::/64 =
>     ============      :  '|P:1::L/64|'    ============
>     =    :     =      :  '+---------+'    
>     =  Other   =      :  '''''''''''''    Assigned
>     =Interfaces=      :                   Prefix
>     ============      :                   ============
>                   +...+...........+    <=== P:2::/64 =
>                   :               :       ============
>            +------+--+         +--+------+
>            |P:2::1/64|  * * *  |P:2::K/64|
>            +---------+         +---------+

[...]

The first thing I'd note is that people have already worked very hard to
get agreement between several very different opinions on that figure.
It's been long debated at least at public meetings and it's been very
difficult for many people to finally agree on it - I respect the work
and I don't oppose it.

That said.

> otherwise one could think it's a typo.

To me, that /62 is clear. It means that a MANET Router is allocated that
prefix. That prefix is further divided by that Router's logic into some
/64 prefixes which are then assigned on interfaces (presumably for
Ethernet EID SLAAC stateless autoconf to work ok to the hosts attached).
My personal understanding is that this is hierarchically aggregated
prefixes, and it is good and an obvious common denominator - I agree
with it.

What's not clear to me is the "P" - what does it mean. Is it a 32bit
string? Less? It's not common IPv6 notation, but it is conceptually
understandable. I wrote to authors and there seems to be suggestion to
substitute "2001:db8::/32" (RFC3849 "IPv6 Address Prefix Reserved for
Documentation") for "P", for a more precise IPv6 notation.

Further, what _could_ be clearer, is _probably_ an IPv6 Addressing
Architecture for AUTOCONF, that would show both that hierarchically
aggregated prefixes _and_ some completely non-aggregated prefixes for a
completely non-hierarchical topology. That's difficult to draw for at 
least two reasons: (1) how could a MANET Router be at such top routing 
level such to have two prefixes differing on the first (!) bit on two of 
its interfaces - these are typically huge Router farms not small MANET 
Routers and (2) there's only one prefix reserved for documentation 
(2001:db8::/32) so whatever two prefixes one will derive from it they'll 
always be shown somehow aggregated. I think it's tough to illustrate a 
suggestive non-hierarchical non-aggregated example.

I am not sure whether this non-hierarchical non-aggregated AUTOCONF IPv6
Addressing Architecture is relevant for MANET, or just one of its
particular cases. It's just that people mention very often that MANETs
are non-hierarchical, so I think a figure would be more support for it.

> Also the loopback interface is not explained in the text.

I'm also surprised it's indeed not explained in the manetarch text.

But for this also there seems to be already agreement that MANET uses
the loopback interface in a special way. It could be very difficult to
get it modified in that document. I think it's very hard to modify
existing consensus - I wouldn't try.

At some point I could live without knowing what the manetarch document
use intends to make out of the loopback interface as long as AUTOCONF
mechanism would work without any special loopback treatment too in some 
cases.

My two cents worth.

> One could maybe also add in the text that the address of the MANET
> interface of is not part of a subnet, or formulated in another way:
> the MANET is not a subnet.

sorry, I'm confused by the "of is not" text above?

> In the second paragraph of section 5.1, one could relate these nodes
> with the figure (to help the reader understand which nodes in the
> figure are exposed to the MANET characteristics and which not) --
> section 8.1. "one or more IP hops - MANET, _site_,...". Is the site
> scope defined? Hasn't it been declared deprecated in RFC3879?

I agree.

I think you mean this manetarch draft sentence:
> Different frameworks for autoconfiguration, network management, and 
> routing within an Autonomous System (AS) can be developed based upon 
> the expected constraints and operating conditions.

I think it meant eg AUTOCONF could develop a new autoconfiguration
mechanism (like SLAAC/DHCP), and maybe a new SNMP extension or even a
BGP extension; and that three should be different. I read it highly
conceptual, I can live ok with it.

Of course, that's my humble interpretation.

Thanks,

Alex

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

---

From: "Ian Chakeres" <[email-masked]>
Date: Tue, 27 Nov 2007 00:25:07 +0530

Thank you very much for the detailed review. I will work to integrate
your comments in my local revision.

I plan to submit an update based on the feedback recently received
when I-D submission opens again.

Thanks.
Ian Chakeres