Re: [PATCH] IPv6: Improvement of Source Address Selection

2 messages, 2 authors, 2002-09-29 · open the first message on its own page

Re: [PATCH] IPv6: Improvement of Source Address Selection

From: <hidden>
Date: 2002-09-28 05:32:47

Hello!
Or would you have an already-sorted list of possible candidate addresses 
for each route in the order of preference?
I am not mad yet. :-)

What preference? You must select _one_ address, you do not need lost
candidates.

And recalculate always when address changes?
What address? Interface address? Routing tables used to be synchronized
to this.

This is IMO a wrong approach from user's perspective.  Perhaps not if the 
algorithm was run and e.g. additional, temporary "address selection" 
routes were created by kernel.
 
quoted
quoted
(stuff that's network prefix -independent
I am sorry, I feel I do not understand what you mean.
Hmm.. this depends on the interpretation of the concept above.  If the
list is refreshed always when addresses change or change state, this could
perhaps work..
I am afraid I do not understand what "address", "state", "temporary" routes
etc you mean. It remained in your brains. :-)

Pekka, are you not going to sleep? (I am.) I bet when you reread this tomorrow,
you will not blame that my brains eventually falled to "parse error" loop. :-)

Alexey

Re: [PATCH] IPv6: Improvement of Source Address Selection

From: Pekka Savola <hidden>
Date: 2002-09-29 08:36:22

On Sat, 28 Sep 2002 kuznet@ms2.inr.ac.ru wrote:
quoted
Or would you have an already-sorted list of possible candidate addresses 
for each route in the order of preference?
I am not mad yet. :-)

What preference? You must select _one_ address, you do not need lost
candidates.
In the case the first entry goes away, having a list could help being able 
to the next one to use very easily.  But this probably just an 
implementation detail.
quoted
And recalculate always when address changes?
What address? Interface address? Routing tables used to be synchronized
to this.
Any address.

One notable case is that the outgoing interface has only link/site-local 
addresses and the destination is global.  There are other cases too.
quoted
This is IMO a wrong approach from user's perspective.  Perhaps not if the 
algorithm was run and e.g. additional, temporary "address selection" 
routes were created by kernel.
 
quoted
quoted
(stuff that's network prefix -independent
I am sorry, I feel I do not understand what you mean.
Hmm.. this depends on the interpretation of the concept above.  If the
list is refreshed always when addresses change or change state, this could
perhaps work..
I am afraid I do not understand what "address", "state", "temporary" routes
etc you mean. It remained in your brains. :-)

Pekka, are you not going to sleep? (I am.) I bet when you reread this tomorrow,
you will not blame that my brains eventually falled to "parse error" loop. :-)
I had already woken up :-).

At least BSD and I think Linux create ad-hoc, "cloned" routes e.g. in Path
MTU discovery process to hold some different values.  I don't remember the 
details.  I was wondering if this would be done the same or not.

change state = move to deprecated, move to non-deprecated.

Hope this clarifies.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help