Re: AUTOCONF address architecture (was: [Autoconf] Review of draft-ietf-autoconf-manetarch-07)

[Alexandru Petrescu <[e-mail]>]

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.

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

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.

> --  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?

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 
______________________________________________________________________


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