Subject: Re: [Autoconf] I-D Action:draft-ietf-autoconf-statement-02.txt

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 21 Nov 2007 14:23:30 +0100

Alexandru Petrescu a écrit :
 > Emmanuel Baccelli wrote:
 >>
 >>
 >> Alexandru Petrescu a écrit :
 >>> Alexandru Petrescu wrote:
 >>>> Emmanuel Baccelli wrote:
 >>>>
 >>>>> Alexandru Petrescu a écrit :
 >>>>>>>
 >>>>>>> What would you suggest we use to replace the generic terms 
"prefix delegation". I didn't know it was such DHCP tainted. I though it 
was just a generic term, at the base of Internet addressing schemes.
 >>>>>>
 >>>>>> I was thinking maybe something like 'admninistratively assigned 
by a human network planner' or maybe 'statically and manually 
configured' depending on context.  Other people may use different?
 >>>>>>
 >>>>> Well, it may be done automatically too right? So I'm afraid what you
 >>>>>  propose is not approriate...
 >>>>
 >>>> I don't think there's no means to automatically administratively 
assign
 >>> ---------------------   ^strike 'no', I meant 'any'.
 >>>> prefixes to a machine remotely (other than DHCPv6-PD and some use of
 >>>> Router Renumbering).
 >>>>
 >>>> If you think there's a method for automatically administratively
 >>>> assigning of prefixes please say so, thanks, I don't know what is 
intended.
 >>>
 >>> Do you think there's any means to automatically administratively 
assign prefixes?
 >>>
 >>> Alex
 >>
 >> I also think that DHCP is a candidate to solve part of the problem, 
and it is clearly said in the draft. OK. But what I don't understand is 
that it seems you have the impression the draft forbids DHCP as part of 
a solution. What is said in the draft about not being able to use DHCP 
as part of a solution? Please tell me.
 >
 > I've replied publicly to this.  It's about the draft saying that DHCP 
can not accommodate the dynamic networks:
 >
 >>  > For example, in Fig.
 >>    1, the MANET router MR3 cannot communicate directly with a DHCP
 >>    server [4] that would be available through a MANET border router,
 >>    since the server and the MANET router are not located on the same
 >>    logical link.  While DHCP can to some extent overcome this issue in a
 >>    static network, it is not the case in a dynamic topology, as
 >>    explained below.
 >

I'm sorry but if DHCP worked "as-is" on MANETs then it would have been 
used off the shelf since long ago by people who need automatic address 
configuration on MANETs. This is not the case. So there must be a reason 
why, don't you think?

Emmanuel

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

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 21 Nov 2007 15:03:23 +0100

All,

after the feedback received from Alex, Teco, Carlos, Ronald, Thomas 
(thanks to all of you), a tentative -03 is available on a server 
reachable at 
http://djincoda.free.fr/autoconf-PS/draft-ietf-autoconf-problem-statement-03.txt

Highlights about the updates include:

- the definition of the term ICP is more precise
- even more explicit mention that DHCP etc. may be part of a solution
- typos corrected here and there
- global address terminology updated
- more precision regarding issues developped in 4.1.x

Alex, you were suggesting to write up a paragraph about even more 
details on DHCP shortcomings. Can you propose some text and a place to 
put it in -03 ?

Otherwise, please take -03 as the base for further discussions as of now.

Cheers
Emmanuel

Alexandru Petrescu a écrit :
> Emmanuel Baccelli wrote:
> [...]
>>  > I've replied publicly to this.  It's about the draft saying that 
>> DHCP can not accommodate the dynamic networks:
>>  >
>>  >>  > For example, in Fig.
>> configuration on MANETs. This is not the case. So there must be a 
>> reason why, don't you think?
> 
> There may be a reason.  Can we see it?  Can one enumerate the issues 
> with DHCP not working in MANETs?
> 
> As I said earlier, I can see palpable issues with DHCP Prefix Delegation 
> not updating its routing table when delegating a prefix through a Relay. 
>  Or maybe an issue with decisions about who _is_ the DHCP Server in a 
> set of entities that could all be.  But nobody describes these.
> 
> Alex
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Nov 2007 15:14:04 +0100

> details on DHCP shortcomings. Can you propose some text and a place to 

YEs, I can.  Remark though I will no longer post on this list.  I will 
send you privately the DHCP shortcomings text.

> Otherwise, please take -03 as the base for further discussions as of now.

Thanks,

Alex

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

---

From: "Simone Ruffino" <[email-masked]>
Date: Wed, 21 Nov 2007 16:01:11 +0100

Alexandru Petrescu wrote:
>> details on DHCP shortcomings. Can you propose some text and a place 
>> to put it in -03 ?
>

Alex, my suggestion is to post them here, instead. Because they can be 
part of the problems we're going to describe.

>> Otherwise, please take -03 as the base for further discussions as of 
--------------------------------------------------------------------

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 21 Nov 2007 16:06:50 +0100

This is what I've just sent to Emmanuel about noticed shortcomings of 
DHCP in some MANET-like deployemnts.

Alex

> For the following text:
> 
>    For example, in Fig. 1, the MANET router MR3 cannot communicate
>    directly with a DHCP server [4] that would be available through a
>    border router, since the border router and MR3 are not located on
>    the same logical link.  While DHCP can to some extent overcome this
>    issue in a static network, it is not the case in a dynamic
>    topology, as explained below.  On the other hand IPv6 Stateless
>    Address Autoconfiguration [5] and Neighbor Discovery for IPv6 [3]
>    do not account for potential address duplication beyond a single
>    multicast-capable link.
> 
> 
>                                                        ----- MR1...MR3
>                                                       /      .
>               +-------------+         +------------+ /       .
>               |             |   p2p   |            |/        .  (MANET)
>               |  ISP Edge   |   Link  |  Border    |         .
>               |   Router    +---------+  Router    |\        .
>               |             |         |            | \       .
>               +-------------+         +------------+  \----- MR2
> 
>                        Fig. 1. Connected MANET router topology.
> 
> With the following:
> 
>    For example, in Figure 1, we assume that the "p2p Link"
>    (point-to-point link) and the links BR-MR1, MR1-MR2 and MR2-MR3 all
>    have distinctive IP subnets assigned.  The MR3 needs to be assigned
>    an IPv6 prefix.  The MANET router MR3 does not yet know the IP
>    address of the DHCPv6 Server, so it needs to discover it by using
>    link-layer multicast mechanisms and IP-layer multicast.  It is
>    possible for MR2 to run DHCP Relay software.  In this case the MR3
>    would send a DHCP Solicit message (IP dst address is a IP multicast
>    address), message preceded by a header containing a link-layer
>    multicast address as destination.  The Solicit message would be
>    further sent by MR2 (DHCP Relay) to the the ISP Edge Router (DHCP
>    Server).  After this initial step the next DHCPv6 exchanges would
>    be performed such that the MR3 obtains a prefix.
> 
> 
>                                                        ----- MR1-MR2-MR3
>                                                       /      .
>               +-------------+         +------------+ /       .
>               |             |   p2p   |            |/        .  (MANET)
>               |  ISP Edge   |   Link  |  Border    |         .
>               |   Router    +---------+  Router    |\        .
>               |             |         |            | \       .
>               +-------------+         +------------+  \----- MRn
> 
>                        Fig. 1. Connected MANET router topology.
> 
>    This is a DHCP behaviour that would work in this MANET topology.
>    However, there may be at least the following two issues:
> 
>    -in the group of MANET Routers described above there should be a
>     dynamic decision of roles about who is a Relay and at what moment.
>     If MR2 disappears from its place and another MR takes its place
>     then that router should receive the DHCPv6 Solicit sent by MR3 and
>     relay it to the DHCPv6 Server.
> 
>    -some implementations of DHCPv6 Prefix Delegation will not update
>     routes on the DHCP Server with respect to the allocated prefix.
>     Or, when assigning prefixes that don't respect a hierarchical
>     structure it is necessary when using a Relay to add a new routing
>     table entry at the DHCP Server whenever a new prefix is assigned
>     to a new MANET Router.  This route should point to the Relay
>     address.
> 
>    These are two issues that appear in the topology pictured in Figure
>    1.  In this figure the DHCP Server, Border Router, MR1 and MR3 are
>    assumed to be stable non-moving (only MR2 moves).  If we consider
>    that any entities will also move then there may be more DHCP issues
>    that could be identified.

Simone Ruffino wrote:
> This message and its attachments are addressed solely to the persons 
> above and may contain confidential information. If you have received the 
> message in error, be informed that any use of the content hereof is 
> prohibited. Please return it immediately to the sender and delete the 
> message. Should you have any questions, please contact us by replying to 
> [email-masked].
> 
>        Thank you
> 
>                                        www.telecomitalia.it
>

---

From: Emmanuel Baccelli <[email-masked]>
Date: Wed, 21 Nov 2007 17:09:05 +0100

Hi Alex,
thanks for your contribution. Could you revise the text you propose so  
that it focuses more on issues, and so that it also elaborates on the  
additional problems there are when everything is potentially mobile?  
It is a case that is envisionned too ;)
Emmanuel

Alexandru Petrescu <[email-masked]> a ?it :

>>>> after the feedback received from Alex, Teco, Carlos, Ronald,   
>>>> Thomas (thanks to all of you), a tentative -03 is available on a   
>>>> server reachable at   
>>>> http://djincoda.free.fr/autoconf-PS/draft-ietf-autoconf-problem-statement-03.txt Highlights about the updates   
>>>> include:
>>>>
>>>>  details on DHCP shortcomings. Can you propose some text and a   
>>>> place to put it in -03 ?
>>>
>>> YEs, I can.  Remark though I will no longer post on this list.  I   
>>> will send you privately the DHCP shortcomings text.
>>>
>>
>> Alex, my suggestion is to post them here, instead. Because they can  
>>  be part of the problems we're going to describe.
>>
>> This message and its attachments are addressed solely to the   
>> persons above and may contain confidential information. If you have  
>>  received the message in error, be informed that any use of the   
>> content hereof is prohibited. Please return it immediately to the   
>> sender and delete the message. Should you have any questions,   
>> please contact us by replying to [email-masked].
>>
>>       Thank you
>>
>>                                       www.telecomitalia.it
>>

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

---

From: "Velt, R. (Ronald) in 't" <[email-masked]>
Date: Thu, 22 Nov 2007 19:15:15 +0100

Emmanuel, all,  

> -----Original Message-----
> From: Emmanuel Baccelli [mailto:[email-masked]] 
> Sent: woensdag 21 november 2007 15:03
> To: [email-masked]
> Subject: [Autoconf] tentative 
> draft-ietf-autoconf-problem-statement-03.txt
> 
> All,
> 
> Thomas (thanks to all of you), a tentative -03 is available 
> on a server reachable at 
> Alex, you were suggesting to write up a paragraph about even 
> more details on DHCP shortcomings. Can you propose some text 
> and a place to put it in -03 ?
> 

For what it's worth after the, er, thorough review by Dave Thaler, I too
have some comments. (Reminds me of that old joke about the mouse and the
elephant walking side by side over a wooden bridge, with the mouse
saying: "Aren't we making a lot of noise?"). Mine are against the
tentative -03 and are mainly terminology related. I need to look more
into the perceived (by some) disparity between this draft and the WG
charter. Perhaps the more logical order would be to raise fundamental
issues first and deal with terminoloy / editorials later. However, I
chose to do easy stuff first, hard stuff later to give you some early
feedback.

Here goes:

1. Introduction, 2nd para. typo: "assymetric" --> asymmetric

2. Terminology

(Section copied verbatim, with comments inserted)

This document uses the terminology defined in [2], as well as the
   following terms :

   MANET Local Prefix (MLP)  - An IP prefix delegated to a MANET router,
      consisting in chunks of IP addresses valid for communications
      inside the MANET.

RitV: "chunks"??? Does 1 "chunk" correspond to 1 prefix? Note that the
definition of "Prefix provision" later in the section talks about a set
of contiguous addresses. And even that is not completely accurate, as
pointed out by Dave T.

   MANET Local Address (MLA)  - An IP address configured on a MANET
      interface, and valid for communications inside the MANET.

   Internet Configuration Provider (ICP)  - An entity that can provide
      routers requesting configuration with routable addresses or
      prefixes.  A typical example of ICP is a DHCP server.

RitV: Alternative terms have been suggested, such as Internet Address
and Prefix Provider. Conceptually, we could even distinguish between
Internet Address Provider and Internet Address Prefix Provider, which
may or may not be co-located.  

   Global prefix  - An IP prefix managed by a router, consisting in
      chunks of IP addresses valid for communications reaching outside
      the MANET (as well as communications within the MANET).

   Global address  - An IP address configured on an interface, and valid
      for communications inside the MANET as well as for communications
      with corresponding hosts on the Internet, via a border router.  A
      global address may be associated with a particular ICP in order to
      be routable.

RitV: Works for me. Teco seems to be saying that not all global
addresses are suitable for the purpose intended here and proposes MGA.
(Not sure if I've understood him correctly). To me, the adjective put in
front of "address" is an indication of scope. Thus, "MANET Local" makes
sense to me, but "MANET Global" does not. Teco further stated that these
addresses should be unique and globally routable. To me, that is implied
by "valid for communications ..." in the definition above.

   Connected MANET  - A mobile ad hoc network, which has reachability to
      at least one ICP.

RitV: I have a problem with "connected". Using the definition of a
Mobile Ad Hoc Network that you give in the first sentence of the
Introduction, "Connected MANET" expands into "Connected loosely
connected set of MANET routers" What, then, is a Disconnected MANET? I'm
trying to think of something better, without success so far. Attached
MANET? Internet-attached MANET? Suggestions, anyone? (Note that in the
MANEMO / Tree Discovery vernacular, terms "grounded" and "floating" are
used for concepts not entirely unlike "connected" and "stand alone". But
I would not want to propose those here).

   Standalone MANET  - A mobile ad hoc network, which does not have
      reachability to any ICP.

   Network merger  - The process by which two or more previously
      disjoint ad hoc networks get connected.

RitV: See? "Connected" gets you in trouble here already. I don't think
you mean "connected" in the sense of "connected MANET".

   Network partitioning  - The process by which an ad hoc network splits
      into two or more disconnected ad hoc networks.

RitV: Same thing: Disconnected MANETs?

   Address generation  - The process of selecting a tentative address
      with the purpose of configuring an interface.

   Address assignment  - The process of configuring an interface with a
      given address.

   Prefix provision  - The process of providing a router with a set of
      contiguous addresses it may manage for the purpose of configuring
      interfaces or other routers.

RitV: "Prefix provision" --> Prefix provisioning?

   Pre-service address uniqueness  - The property of an address which is
      assigned at most once within a given scope, and which is unique,
      before it is being used.

   In-service address uniqueness  - The property of an address which was
      assigned at most once within a given scope, and which remains
      unique over time, after the address has started being used.

(end of copy)

3. Deployment Sceanarios

3.2 Standalone MANET

1st sentence, typo: "does" --> do

"Due to potential network partitions and mergers, standalone MANETs may
be composed of routers of either types." --> Isn't this also true for
"Connected MANETs"?

3.3 Deployment Scenarios Selection

last sentence, typo: "an other" --> another

4. Problem Statement

4.1.  MANET Autoconfiguration Goals

"A MANET router needs to configure IP addresses and prefixes as usual,
on its non-MANET interfaces as well as its attached hosts and routers,
if any."
--> suggest to change this to:
 "A MANET router needs to configure IP addresses and prefixes as usual
on its non-MANET interfaces as well as facilitate IP address and prefix
configuration for its attached hosts and routers, if any." 

4.1.1.  Multi-hop Support

"Existing protocols assume that a broadcast directly reaches every
router or host on the subnetwork, whereas this generally is not the case
in MANETs (see [2])."

--> As pointed out in my mail of last Tuesday: Section 5.2 of the
manetarch I-D says that "MANET interfaces (...) must be configured with
unique prefixes." If I am interpreting this correctly, it means that a
MANET interface is always the only interface in the subnetwork formed
from its prefix and therefore it is still true that a broadcast reaches
"every router or host on the subnetwork". Can we safely replace
"subnetwork" by "link" here to make the point that was intended? (Note:
I think Carlos was saying that in some cases all MANET interfaces from a
MANET could be configured from a single prefix. Haven't found time yet
to read his I-Ds. Would that still be in line with the manetarch
draft?). 

"Due to the nature of the links over which a MANET is formed, ad hoc
nodes within a MANET do not share access to a single multicast-capable
link for signaling."

--> Sometimes they do, sometimes they don't. That's dependent on the
time-varying topology of the MANET.

4.1.2.  Dynamic Topology Support

1st para. "On the other hand, frequent reconfiguration may cause IPv6
Stateless Address Autoconfiguration [5] to be much less efficient than
expected, due to large amounts of control signalling." 

--> What is meant here: sending Router Advertisements at a higher rate? 

2nd para. This implication is the specificity of MANETs that brings the
requirement for new levels of service distribution, since the "everyone
is a server" approach is essentially not functional.

--> This claim needs to be substantiated.

4.1.4.  Network Partitioning Support

typo: provisionning --> provisioning

4.2.  MANET Autoconfiguration Issues

4.2.2.  Prefix and Address Uniqueness Requirements

"Pre-service Issues -- Address or prefix uniqueness problems in this
category are called pre-service issues." --> Which category is meant?

5.  Solutions Considerations

1st sentence, typo: "scarse" --> scarce (already found by Dave Thaler).

That's all for now,

Regards,
Ronald

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/disclaimer/email.html

---

From: mase <[email-masked]>
Date: Fri, 23 Nov 2007 11:18:24 +0900

Dear Ronald, all,

Thank you for your comments. I agree "Connected MANET" may be 
confusing. Among your suggestions. I like Internet-attached MANET (or 
Infrastructure-attached MANET).

Regards,
Kenichi

---

From: "Teco Boot" <[email-masked]>
Date: Fri, 23 Nov 2007 08:50:55 +0100

Clarifications on usage if Global Address

> by "valid for communications ..." in the definition above.
 
IMHO Global Addresses may have very different contexts, especially outside
Autoconf and also related to Autoconf.
GA can be "valid", but not by definition "valid for communication" in a
MANET environment. This is an important aspect and I think this is the main
reason having an Autoconf WG.

I don't care which name we pick, as long as we all know what we mean when we
use the name.
Using MGA, it is clear that the GA is inside the MANET, and that is exactly
what it is. MGA shall not be used outside the MANET, ingress filtering shall
block such a usage (multiple of BCP on this!!).

MLA are also inside the MANET, but cannot be used for Internet connectivity.

MGA can and shall be used for this, with respecting the topologically
correctness requirement. Sometimes MIP/NEMO can be used, sometimes this is
not needed, e.g. when there is only one BR. There could be other methods
enforcing routing via the associated BR. I am interested in all options
ensuring topologically correctness.

Teco.

---

From: mase <[email-masked]>
Date: Fri, 23 Nov 2007 17:41:07 +0900

Dear all,

See in line.

At 16:50 07/11/23, Teco Boot wrote:
> > sense to me, but "MANET Global" does not.

I strongly agree.

>Teco further stated that
> > these

One of the goals of Autoconf WG is to establish a method to provide 
"global addresses" to MANET routers for communication with the Internet.
Not to provide MGA to MANET routers. The same global address may be 
given some time to MANET routers and some time to non-MANET mobile 
routers or hosts. After, a MANET router obtains the global address, 
it may lose Internet connectivity and its global address may become 
useless for communication with the Internet, but it is still one of 
the global address. IMHO I don't think the definition of the global 
address is necessary in the PS document, because I think this 
terminology should and can be used in the same meaning outside Autoconf.
I agree Teco in the sense that the current special definition of teh 
global address in PS document is confusing and should be deleted.

Regards,
Kenichi