Subject: Re: [Autoconf] BDRP vs. world hunger

From: [email-masked]
Date: Thu, 24 Sep 2009 23:19:04 +0200 (CEST)

Hi Charlie,

|> Did you check 5.3.  Support for Autonomous MANETs ?
|> It is a bit out of context for BRDP. As I see it, assigning globals is
|the
|> tough part.
|>
|
|You have to admit, that section 5.3 does not indicate the solution to
|the four-node problem.

I don't see the four-node problem as a problem.
If your boxes has a problem because they cannot generate
an (almost) unique address, you may define a solution.
Such a mechanism could work for all address types of interest.

> I assume unique Interface-IDs.
  <skip>
|However, the point of the discussion has been that we should
|enable solutions where this assumption isn't automatically
|valid.

Do we agree on having unique Interface-IDs, by nature (EUI-64),
pseudo-random (good enough) or inferieur with duplicate detection (try &
error)?

I really want to know why this DAD discussion is related to link-locals
and not to other address types.

Regards, Teco

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 24 Sep 2009 14:39:32 -0700

Hello Teco,

> Such a mechanism could work for all address types of interest.

Then in your universe all nodes have unique interface
identifications,  So much the better!  All you need from
autoconfiguration is to learn the routing prefix.  Then
you are done.

If the four nodes do not have the unique interface IDs,
then you do not provide a solution for them.  But
solutions have been devised for that case.  They do
not need link-locals.  In point of fact, you don't need
link-locals, even when you do have unique interface IDs,
except insofar as they have been mandated by IPv6
specification.

I think the main point is that we want to avoid making
the universal mandate, not at all that we would try to
make the universal prohibition.  I hope by now you
agree with this.

> Do we agree on having unique Interface-IDs,
Not always.
>  by nature (EUI-64),
Not always.
> pseudo-random (good enough)
Not always.
>  or inferieur

Inferior by what metric?  What if there are
cost goals that must be met?  What if they
just don't happen to be IEEE interfaces?

> with duplicate detection (try &
> error)?
>   

These are not necessarily tied together.

> and not to other address types.

What DAD discussion?

Can we distinguish between (i) some discussion about
duplicate addresses and (ii) DAD?

I think we ought, generally speaking, to try to avoid (ii) at this point
in the discussion.

Regards,
Charlie P.

---

From: "Teco Boot" <[email-masked]>
Date: Wed, 30 Sep 2009 14:49:48 +0200

Hi Charlie,

|-----Oorspronkelijk bericht-----
|Van: Charles E. Perkins [mailto:[email-masked]]
|Verzonden: donderdag 24 september 2009 23:40
|Aan: [email-masked]
|CC: [email-masked]
|Onderwerp: Re: BDRP vs. world hunger
|
|
|Hello Teco,
|
[email-masked] wrote:
|> |You have to admit, that section 5.3 does not indicate the solution to
|> |the four-node problem.
|>
|> I don't see the four-node problem as a problem.
|> If your boxes has a problem because they cannot generate
|> an (almost) unique address, you may define a solution.
|> Such a mechanism could work for all address types of interest.
|>
|
|Then in your universe all nodes have unique interface
|identifications,  So much the better!  All you need from
|autoconfiguration is to learn the routing prefix.  Then
|you are done.
|
|If the four nodes do not have the unique interface IDs,
|then you do not provide a solution for them.  But
|solutions have been devised for that case.  They do
|not need link-locals.  In point of fact, you don't need
|link-locals, even when you do have unique interface IDs,
|except insofar as they have been mandated by IPv6
|specification.
|
|I think the main point is that we want to avoid making
|the universal mandate, not at all that we would try to
|make the universal prohibition.  I hope by now you
|agree with this.

Agreed. Let us focus on [Autoconf] chartered items.

This includes global addresses. You stated correctly, 
one way dealing with it is unique interface identifications
and learn the routing prefix.
There is more, such as address selection and routing packets 
to the correct border router. But first things first.

Can you be specific on "provided solutions"? Then I can check
these for unique interface IDs and / or providing globals.
I said many times I stop pushing BRDP if an equivalent is 
out there.

|>
|>
|>> I assume unique Interface-IDs.
|>>
|>   <skip>
|> |However, the point of the discussion has been that we should
|> |enable solutions where this assumption isn't automatically
|> |valid.
|>
|> Do we agree on having unique Interface-IDs,
|Not always.
|>  by nature (EUI-64),
|>
|Not always.
|> pseudo-random (good enough)
|Not always.
|>  or inferieur
|
|Inferior by what metric?  What if there are
|cost goals that must be met?  What if they
|just don't happen to be IEEE interfaces?

(sorry for using Dutch word)
"inferior" was for uniqueness. I thought the context was quite clear.

On cost goals: this is extremely important for me. For me, the costs
of unneeded overhead is unacceptable expensive. A good seed for pseudo
random is in my case for free or very low cost.

Also, in my case there are IEEE interfaces in the box.
The global unique identifiers can be used for all interfaces for that box.

I asked couple of times for clarifications on mechanisms for 
avoiding duplicates. No answers yet. We could say we postpone, 
as it is solution space.
But we have to include something in the MANET addressing model. 
It is about using unique Interface IDs or not.

Regards, Teco.

|
|
|> with duplicate detection (try &
|> error)?
|>
|
|These are not necessarily tied together.
|
|>
|> I really want to know why this DAD discussion is related to link-
|locals
|> and not to other address types.
|>
|
|What DAD discussion?
|
|Can we distinguish between (i) some discussion about
|duplicate addresses and (ii) DAD?
|
|I think we ought, generally speaking, to try to avoid (ii) at this point
|in the discussion.
|
|Regards,
|Charlie P.