Subject: Re: New multi6 draft: WIMP

From: Iljitsch van Beijnum <[email-masked]>
Date: Sat, 14 Feb 2004 23:54:14 +0100

On 28-jan-04, at 16:57, Jukka Ylitalo wrote:

> We have submitted a new multi6 draft to I-D directory. The draft 
> defines a Weak Identifier Multihoming Protocol (WIMP), and we wrote it 
> in order to see how opportunistic/weak authentication methods could be 
> used to sove the multi6 problem.

Ok. This is basically a secure negotiation mechanism. All other aspects 
of multihoming are only addressed fleetingly, if at all.

When a host wants to negotiate new addresses, some info is split into n 
pieces and sent to n addresses. What happens if less than the full set 
of n addresses is reachable?

I believe there is a problem with the gradual release of secret 
information (such as hash chains) when a man in the middle can trick 
both sides to become desynchronized such that side A has two messages 
in transit, messages M+1 and M+2, with an ealier message being M. M, 
M+1 and M+2 are protected using hashes X, X+1 and X+2, respectively. 
Side B can check whether message M+1 is authentic by taking X+1, 
performing a function over it and determining whether the result is 
equal to X. However, a man in the middle that already has X+2 could 
create X+1 and then use this value to create an authentic-looking 
message M+1. Or am I missing something?

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 15 Feb 2004 22:50:19 -0800 (PST)

> message M+1. Or am I missing something?

I don't see why this is a problem when 
1) the signalling protocol (which advances the hash element to use/reveal)
   has at most one outstanding operation
2) the signalling protocol never gives up on an operation - keeps on 
   retransmitting until the host-pair context is abandoned
3) when a new host-pair context is created the initiator picks a new
   ephemeral ID

I that case, the MiTM that appears after the initial exchange can't force 
either end to reveal an "extra" hash element as you suggest.

  Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 16 Feb 2004 09:40:10 +0100

>    has at most one outstanding operation

I think this is harder than it would at first glance seem. For 
instance, if a MitM can trigger both ends to start an exchange at 
approximately the same time.

This is why I chose to exchange a key in cleartext in my ODT draft in 
the absense of strong authentication.

---

From: Jukka Ylitalo <[email-masked]>
Date: Mon, 16 Feb 2004 13:05:04 +0200

Iljitsch van Beijnum wrote:

>
> Ok. This is basically a secure negotiation mechanism. All other 
> aspects of multihoming are only addressed fleetingly, if at all.

Hi Iljitsch,

The same phrase applies to several multi-homing I-Ds conversely. "Ok. 
This is a
multi-homing mechanism. All aspects of security are only addresses 
fleetingly,
if at all" :-)

The main purpose of the WIMP is to present a way to protect hosts from 
re-direction
attacks. I don't believe that using IKE nor IPSec are the best ways to 
solve the
re-direction problem. WIMP offers a weak, but sufficient security model 
for multi-homing.

We are willing to combine the presented WIMP exchange with other multi6
ideas. Multi-homing architecture is a puzzle. Our purpose is to bring a 
couple
of new pieces to the puzzle that might complete the final solution. I 
believe
that the final solution contains features of several proposals.    

>
> When a host wants to negotiate new addresses, some info is split into 
> n pieces and sent to n addresses. What happens if less than the full 
> set of n addresses is reachable?
>
WIMP works fine also in that case.

Let's say that the responder receives a set of new IP addresses, IP1, 
IP2, and IP3.
It sends a challenge to each of them. However, IP2 is not reachable. The 
initiator
reveices only messages with IP1 and IP3. It constructs a combined key 
using the
received key pieces in the challenge messages and sends a response to 
the responder.
The responder finds out which of the challenge messages the initiator 
received,
using the key mask. The responder is able to verify the answer to the 
challenge
using the combined key.

That part of the draft requires clarification. Thanks!

-- Jukka

---

From: Jukka Ylitalo <[email-masked]>
Date: Mon, 16 Feb 2004 13:17:27 +0200

Hi Iljitsch,

The ephemeral IDs of the initiators protect the hosts in the case they 
start
the exchange at the same time. In other words, it is not possible that two
initiator's have identical hash chains and common context in both 
end-points.

If I didn't give an answer to the problem, could you elaborate the scenario.
(I am currently reading your ODT draft.)

Thanks, Jukka

---

From: Dave Crocker <[email-masked]>
Date: Tue, 17 Feb 2004 13:15:11 -0800

Folks,

JY> We are willing to combine the presented WIMP exchange with other multi6
JY> ideas. Multi-homing architecture is a puzzle. Our purpose is to bring a 
JY> couple

Some proposals differ from each other at the level of "paradigm".  They
quite simply approach the solution in a fundamentally different way.
However others are variations on the same paradigmatic theme.  It seems
entirely reasonable to look for the commonality and select from among
the proposals.

Although the paradigmatic differences probably affect one's list of
issues or "modules", my own view is:

  - Association establishment
  - Endpoint-pair context identification
  - Authentication of the control exchange
  - Updates to the pool of locators for the context
  - Rendezvous (for mobile targets)
  - Control exchange transport

For those of a like mind, trying to first agree on a common set of such
functions would be helpful.  It would then let us look for pieces of
solution that we can share. (I think this sort of exercise at least
will help refine our understanding of the differences.)

By way of example, MAST has a very large hand-wave with respect to the
details of control exchange authentication. It takes the approach that
something of the weak authentication/purpose-built keys approach is
sufficient, but leaves the details unstated.

It would be great to have a solution that we could simply plug in to
that part of the specification. The choice is essential for viable use,
of course, but it does not affect the MAST paradigm.

d/
--
 Dave Crocker <dcrocker-at-brandenburg-dot-com>
 Brandenburg InternetWorking <www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>

---

From: Pekka Nikander <[email-masked]>
Date: Wed, 18 Feb 2004 09:24:24 +0200

Dave,

> issues or "modules", my own view is:

As we apparently share the same paradigm, your list looks

>   - Association establishment

An interesting aspect here is the idea of a "staged"
association establishment.  That is, maybe you could initially
just exchange a couple of identifiers and/or hash anchors and
check the reachability of the primary address as a side effect.
All further checks, i.e. reachability of other addresses,
establishing strong identity via public key crypto, etc,
could be "delayed" and performed only if needed.

>   - Endpoint-pair context identification

To me, it looks like that we have to look at this on two or
perhaps three levels.  One is how to identify the context
initially, before the end-points have exchanged any messages.
The second one is the way the context is identified in the
control protocol, and the third one how the context is
identified in the actual payload packets.  Apparently, some
of these may overlap, depending on the details.

>   - Authentication of the control exchange

Here the minimal requirements seem to be covered by
Erik's draft (I know that some WG members disagree, but
that is at least party due to different paradigm, IMHO.)
However, especially if the "staged" association establishment
idea is used, it may be possible to introduce more secure
("strong" or "semi-strong" instead of "weak") authentication
on demand.

>   - Rendezvous (for mobile targets)

I think that we have to make a distinction between initial
rendezvous, or finding a mobile target before there is any
association, and rendezvous while there is an active
association.

And then we have the "third party rendezvous", which I
would like to call referral.  That is, handing over an
identifier (IP address or other) to a third host, so that
it can create an association with the identified end-point.

> details of control exchange authentication. ...

HIP, on the other hand, has very well defined control exchange
authentication, but many people consider it too heavy.  The
"staged" idea might be able to help there.  It looks like that
HIP is weakest in its handling of the address pool and in some
aspects of rendezvous.

--Pekka

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 18 Feb 2004 11:53:36 +0100

Hi Dave,

[trim the destination list]

> entirely reasonable to look for the commonality and select from among

Well, i would also say that different views also are dealing with different
problems related with multihoming and the basically focus on different
issues.

For instance, most of the modules that you describe below are basically
focused in preserving established communication through outages in
multihomed environments.

This is only *one* issue about multihoming. While most of proposals focus on
this point (i would say because it is the mist challenging one) this is not
the complete multihoming problem. There are many other issues that have to
be addressed in order to provide a multihoming solution and which solution
it is probably simpler and easier to deploy. Moreover, solving the other
simpler issues is likely to be what most of users really need right now. I
mean, I would say that there is a significant amount of potential IPv6
multihoming users that don't really have many critical established
communications that have to survive a outage that occurred in one of their
non directly connected link. (moreover, probably currently IPv4 multihoming
solution fails to provide this for many apps in some scenarios where BGP
reconvergence takes a while)

Please, note that i am not saying that the preservation of established
communications is not important, i am just saying that there are other
multihoming issues that are also important and that are easier to deploy and
that would provide many of the multihoming benefits.

Now, returning to the preservation of established communications, i think
that there is another module that i would include: locator selection
mechanisms.

This has at least three issues related:

Locator selection for initial contact: you have to discover which locator is
available

Locator selection during the communication: you have to decide when a
locator has become unreachable (at least)

Policing: locator selection mechanisms have to provide the means to
implement policing

Regards, marcelo

---

From: senthil ayyasamy <[email-masked]>
Date: Wed, 18 Feb 2004 06:46:49 -0600

>focused in preserving established communication through outages in
...
>I mean, I would say that there is a significant amount of potential IPv6

For now, connection preservation (fail over etc) should be the only goal.
LB/multi paths is a difficult problem (both at transport and routing.) It
has to be done after multi6 standardization. If we support MA, concurrent
multi transfer has to be standardized within tsv. If we support routing
based solutions(locator rewriting or BGP related,) load balancing needs
an algorithm approach (which should be done within routing area.) OTOH,
host centric solutions can depend on DNS for LB etc (which is not a
multi6 issue.)

or you meant something else?

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 18 Feb 2004 14:58:01 +0100

> -----Mensaje original-----
> De: senthil ayyasamy [mailto:[email-masked]]
> Enviado el: miercoles, 18 de febrero de 2004 13:47
> Para: [email-masked]; Dave Crocker
> CC: [email-masked]
> Asunto: Re: modules of a mh solution (was RE: New multi6 draft: WIMP)
>
>

Yes, definitely i meant something else, sorry for being so unclear.

Actually i was pointing that there are some simpler problems that can be
solved locally at the multihomed site that are also part of the multihoming
solution and that would provide important benefits without too much cost.

The first issue that has to be addressed is ingress filtering compatibility.
If you are using multiple addresses per host and the ISP are implementing
ingress filtering, problems appear when a single homed host becomes
multihomed. This problems occur even when there is no outage, and may affect
communications even when both links are working fine.
This implies that a single homed site that becomes multihomed will obtain a
degraded performance because of multihoming.
so the first step IMHO is that when a site becomes multihomed, it should
obtain at least the same benefits as when it was single homed.

Then, some mechanisms can provide some benefits of multihoming. For
instance, when a outage occurs, hosts within the multihomed site should not
use the source address associated with the path that has suffered the
outage. Note that this is not related with the preservation of the
communication, it is just that when an ISP is down, new communication
shouldn't use the associated address. In this case, a certain level of fault
tolerance is provided, even if the established communications are not
preserved

Additionally, selecting the source and destination properly some levels of
policing can be provided.

IMHO all this is much more simpler than mechanisms to preserve established
communications but they provide important benefits.

I say that these mechanisms are simpler because they require only
modification within the multihomed site and they don't require modification
of external hosts.

Moreover, some of these mechanisms work fine with non upgraded hosts within
the multihomed site.

I hope i explain myself more properly this time, sorry for the confusion.

Regards, marcelo

---

From: Dave Crocker <[email-masked]>
Date: Wed, 18 Feb 2004 06:57:23 -0800

Pekka,

>>   - Association establishment
PN> An interesting aspect here is the idea of a "staged"
PN> association establishment.  ...

I like this idea quite a lot.  It reduces the initial cost of creating
and using multiaddressing, while planning for evolution to better
capabilities.

>>   - Endpoint-pair context identification
PN> To me, it looks like that we have to look at this on two or
PN> perhaps three levels.  ...

Right.

(The MAST "fill-in values" for your list of 3 is: 1) Initial - no change
to existing procedures, 2) Control ID -
none/hash/purpose-built-key/etc., 3) Per-packet - no per-packet
identifier.)

>>   - Authentication of the control exchange
PN> Here the minimal requirements seem to be covered by
PN> Erik's draft (I know that some WG members disagree, but ...

This, again, highlights the need for us to be very careful about the
difference between "all relevant issues" versus "issues to be resolve
for an initial service".

>>   - Rendezvous (for mobile targets)
PN> I think that we have to make a distinction between initial
PN> rendezvous, or finding a mobile target before there is any
PN> association, and rendezvous while there is an active
PN> association.

Yes!

PN> And then we have the "third party rendezvous", which I
PN> would like to call referral.

I think the term is fine, and I like to refer the issue to an
independent effort. (Ie, not deal with it for this work...)

>> details of control exchange authentication. ...

PN> HIP, on the other hand, has very well defined control exchange
PN> authentication, but many people consider it too heavy.

yup...

d/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 18 Feb 2004 09:24:58 -0800

marcelo,

mb>  There are many other issues that have to
mb> be addressed in order to provide a multihoming solution and which solution
mb> it is probably simpler and easier to deploy.

First, I certainly agree that we need to be clear what problem(s) a
proposal solves and equally clear about what (related and interesting)
problems it does not.  And we need to be clear about relative
priorities.  So it's good you are raising this point it and will be even
better if folks discuss it.

mb> Moreover, solving the other
mb> simpler issues is likely to be what most of users really need right now.

There is certainly some feeling that this is true, but I am not so
certain. I think that the current reason for multihoming is reliability,
rather than performance.  As you note, connection preservation is only
one aspect of reliability.

I think there is an orthogonal issue to connection preservation. A host
needs to discover the set of addresses available to it. And it needs to
have a basis for choosing one. It would be nice for host to have a
discovery mechanism that did not involve manual configuration or running
a routing protocol listener.

What other, near-term uses for multihoming are you suggesting that are
a) important, and b) easier than any of the current proposals?

I'll comment that I think the discussion of multihoming gets distorted
by treated mobility as an entirely separate topic.  Portions of each are
entirely separate from the other.  However some portions do overlap. By
pursuing them independently, we do not take advantage of the overlap.

(Now, quite a few multi6 participants are also attending to mobility, in
their proposals.  However the conceptual discussions on the list are
nearly always and only about multihoming.)

A final demure: merging two areas of interest can serve to dissipate the
effort to solve either.  However I think this is not one of those cases.

mb> Now, returning to the preservation of established communications, i think
mb> that there is another module that i would include: locator selection
mb> mechanisms.

yes.

d/

---

From: "marcelo bagnulo" <[email-masked]>
Date: Wed, 18 Feb 2004 19:14:37 +0100

> I think there is an orthogonal issue to connection preservation.

Locator discovery for *initial* contact is orthogonal IMHO

Determinig which locator to use during the lifetime of a communication has
additional timing constraints that will probably require different
mechanisms than just the ones using for the initial contact, i guess

> A host

fully agree.
do you have in mind something different than just plain trial and error?
becuase i wouldn't want to modify external hosts, right?

> a) important, and b) easier than any of the current proposals?

ingress filtering?

(supposing that by current proposals you mean proposals for preserving
established communications...)

> pursuing them independently, we do not take advantage of the overlap.

Well, i guess that some mh solutions can be used to provide mobility support
but not all of them. For instance, i don't think that a solution like NOID
would address the mobility problem, since the dynamic of the locator set
changes is very slow because it is conditionated by the DNS timing

I mean, in multihoming the locator set is pretty fixed and changes rather
slowly, and probably a solution that doesn't not support changes in the
address set once that the asosciation has been established would be
acceptable, i guess.
this type of solution wouldn't be suitable to provide mobility support.

Regards, marcelo

---

From: Dave Crocker <[email-masked]>
Date: Thu, 19 Feb 2004 08:10:45 -0800

marcelo,

>> I think there is an orthogonal issue to connection preservation.
mb> Locator discovery for *initial* contact is orthogonal IMHO

ok.

>> a routing protocol listener.
mb> fully agree.
mb> do you have in mind something different than just plain trial and error?
mb> becuase i wouldn't want to modify external hosts, right?

I have a suspicion that you do not mean "trial and error for discovering
one's own list of addresses" but rather mean "trial and error as a basis
for choosing one"...

I think there need to be mechanisms for both learning of one's own
addresses and for helping decide which one to use.  The former is
essential in the near-term, I believe.  Without it, we cannot scale any
approach that makes the hosts aware of their multiple addresses.

Something akin to routing table information, to help a host choose among
the list of its own addresses, is important, but can be deferred.

>> pursuing them independently, we do not take advantage of the overlap.
mb> Well, i guess that some mh solutions can be used to provide mobility support
mb> but not all of them.

That is my point.

If we have two proposal that are roughly equal in their complexity,
utility, and the like, then the fact that one can also be used to
satisfy some mobility requirements ought to bias us in its favor.

At the least, this wider range of utility ought to be a significant part
of our evaluation among the proposals.

d/

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 19 Feb 2004 17:20:47 +0100

> one's own list of addresses" but rather mean "trial and error as a basis

Yes.

> approach that makes the hosts aware of their multiple addresses.

I agree that the mechanism to learn one's own addresses is fundamental, but
i thought that the mechanism to do that would be stateless (or statefull)
address autoconfiguration...

Do you think that we may need something else?

> the list of its own addresses, is important, but can be deferred.

I would say that you will need a mechanism to selects the destination
address the moment you want to be able to obtain fault tolerance by using
the available path. If not you may end up using a path that is not
available, i guess.

Regards, marcelo

---

From: Dave Crocker <[email-masked]>
Date: Thu, 19 Feb 2004 08:34:19 -0800

marcelo,

mb> I agree that the mechanism to learn one's own addresses is fundamental, but
mb> i thought that the mechanism to do that would be stateless (or statefull)
mb> address autoconfiguration...

mb> Do you think that we may need something else?

I don't have any particular thoughts about the solution for this.  As
long as it scales at least as well as DHCP it is fine with me.

The one thing that makes this more challenging than DHCP is the problem
of timing and initiative.  DHCP is triggered by the client with an
obvious example being system boot.

For multiaddressing, the easy question is how to supply information
about multiple addresses at system boot.

The harder question is how to get information about the availability of
new addresses to the client system? Offhand, I think this requires a
"push" mechanism from the network, rather than a pull mechanism from the
client, in order to make sure the client learns of the changes in a
timely fashion.

d/

---

From: "marcelo bagnulo" <[email-masked]>
Date: Thu, 19 Feb 2004 18:02:03 +0100

> obvious example being system boot.

DHCP for IPv6 supports server initiated configuration i.e. a push from the
server AFAIK (the reconfigure message from the server)

So what we need now is a mechanism to inform the server on real time about
which prefixes are to be configured in the clients.

Using stateless autoconfiguration, you can use the Router Advertisement in
the same way, so you can inform the hosts which prefixes they have to use at
every moment.

The problem again is how does the router knows about which prefixes to use.

In this case there is an additional problem related to the fact that Router
Advertisement are link scoped, so you need to inform the routers through
other means. A possible option for this would be Router Renumbering
protocol. The problem with this is that AFAIK the router renumbering
protocol is not very supported in available equipment, so i am not sure that
this would be a real option.

the other option for this would be to use DHCP prefix delegation, so you can
delegate a prefix to every router, so that they can announce it through dhcp
to the hosts.

In both cases , stateless and statefull autoconfiguration, the resulting
situation is that you have a central server that manages the prefixes. The
point now is how does this server knows which prefixes are to be announced.

IMHO, the only case that a prefix has to be removed is when the direct link
between the multihomed site and the isp that delegated the prefix is down.

In other failures modes, a prefix should be used to reach a set of
destinations and not to reach others.

For instance a multihomed site with ISPA and ISPB

The link between ISPA and the internet fails.

One may think that PrefixA should be removed and not used anymore.

However, if you do that, you will not be able to reach the other customers
of ISPA

So in this case both prefixes has to be preserved in the site, only that
PrefA should be included in the source address when communicating with other
ISPA customers and PrefB should be used when communicating with all the rest
of the Internet.

That is why IMHO it is so important a mechanism to discover the proper
source address to be used in order to reach a certain destination address.

So according to this, the problem of discovering one's own prefixes would be
simple, you just have to remove the prefix when the direct link with the
provider that delegated the prefix is down. This could be as simple as a
ping or bdf (draft-katz-ward-bfd-01.txt)

The problem is then moved to the source address selection :-)

Regards, marcelo

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 22 Feb 2004 16:49:54 +0100

Dave,

A host
> the list of its own addresses, is important, but can be deferred.

are you arguing that as part of any solution, we should either include 
a address selection / pairing algorithm or we should make that an 
"external" requirement to be solved by a separate protocol or by 
someone else?

> of our evaluation among the proposals.

It should. And this IMHO is covered by "2.1.2 Uniqueness" and "2.1.2.1 
Does your solution address mobility" in Eliot's draft.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 22 Feb 2004 16:41:44 +0100

> this type of solution wouldn't be suitable to provide mobility support.

We also had this discussed sometime during the autumn and from what I 
remember, most seemed to think that mobility and mutli6 required 
solutions with different paramters - to the point where the solutions 
would be different solutions.

Best regards,

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Sun, 22 Feb 2004 16:54:29 +0100

> client, in order to make sure the client learns of the changes in a

Following my question in the other mail, do you also see that this 
mechanism in some way needs to help with the actual address selection? 
So, my concern  is that we actually have a problem split in (at least) 
two pieces - making the end system aware of what addresses with what 
properties are available to it; and from the set of addresses/locators 
make the selection of which one to use.

You can further complicate the above if we think that selecting a 
address for initial communication is one thing, selecting a address for 
established communication is something else.

- - kurtis -

---

From: "marcelo bagnulo" <[email-masked]>
Date: Mon, 23 Feb 2004 11:24:06 +0100

Hi Kurtis,

I know you were asking Dave, but i include my opinion also...

> mechanism in some way needs to help with the actual address selection?

IMHO yes, I think we will need to modify the address selection mechanism,
but I think we can limit the changes to the hosts within the multihomed
site.

> make the selection of which one to use.

Yes

> established communication is something else.

Yes

Regards, marcelo

>
> - - kurtis -
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 8.0.3
>
> iQA/AwUBQDjQuKarNKXTPFCVEQILXgCgyicjJWpe9jRTA4t9C9bp7It1QxQAmwfY
> m1zkKKjHoeTmuVrYG9StwXIZ
> =AtMi
> -----END PGP SIGNATURE-----
>
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 23 Feb 2004 11:35:43 +0100

> would be different solutions.

The differences are that mobility needs to be able to change addresses 
on short notice, unlike multihoming. With multihoming, there is the 
whole selection/failover issue, which is a no-brainer in mobility.

What they could/should share is a way to make transport sessions 
survive address changes, and preferably also the security mechanisms.

The problem is that current MIPv6 doesn't do much that is usable for 
multihoming, especially not if we rule out the extra "this is the real 
address" header because it adds too much overhead.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 24 Feb 2004 09:10:06 +0800

Kurt,

KEL> We also had this discussed sometime during the autumn and from what I
KEL> remember, most seemed to think that mobility and mutli6 required 
KEL> solutions with different paramters - to the point where the solutions
KEL> would be different solutions.

 This sufficiently at odds with my own sense of the solution space
 that I really would appreciate any elaboration of the details folks
 can conjure up.

 So far, my sense is that there is a very large amount of overlap
 between the two problem spaces.  No, not 100%, but more than enough
 to justify seeking a single solution for the common set of
 requirements.

 Multihoming is about multiple addresses.  Mobility is about multiple
 addresses.  The structure, predictability and timing of address
 management for the two differ.  This might mean they need entirely
 different mechanisms, but so far it looks like they can do fine with
 just one.

KEL> are you arguing that as part of any solution, we should either include
KEL> a address selection / pairing algorithm or we should make that an
KEL> "external" requirement to be solved by a separate protocol or by 
KEL> someone else?

Any initial specification needs to provide a complete capability.  So
I am arguing that we distinguish between near-term "simplistic"
choices that provide initial utility, versus longer-term, extended
choices that can be pursued outside of the initial critical path.
 
d/

---

From: Dave Crocker <[email-masked]>
Date: Tue, 24 Feb 2004 09:41:05 +0800

Kurt,

(meant to tack this on to my reply of a few minutes ago.)

>> client, in order to make sure the client learns of the changes in a
KEL> Following my question in the other mail, do you also see that this
KEL> mechanism in some way needs to help with the actual address selection?

To the extent that the mechanism for notifying of changes in
availability also supplies QOS-related parametric information, yes, it
is helping selection.

But the actual selection is a separate mechanism, and I think we can
get quite a bit of benefit out of a qos entry that is nothing more
than exists/doesn't-exist. At any rate, the _use_ of the qos-related
information is quite different from creating the database of the info.

KEL> So, my concern  is that we actually have a problem split in (at least)
KEL> two pieces - making the end system aware of what addresses with what
KEL> properties are available to it; and from the set of addresses/locators
KEL> make the selection of which one to use.

yes.  however this separation is natural.  The activities occur
at different times (or, I think, they should) and the hard work
probably is done by different entities (the supplier of the qos
information, versus the user of it).

KEL> You can further complicate the above if we think that selecting a
KEL> address for initial communication is one thing, selecting a address for
KEL> established communication is something else.

Yup.

In fact there is one approach to this domain that says the initial
mechanism is whatever we already have today and that the mechanism for
selections with an existing communication is all that we should pursue
in the near-term, because it provides a strategic, incremental
enhancement.

d/

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 24 Feb 2004 21:13:49 +0100

> information is quite different from creating the database of the info.

First I don't think you want to call it QOS. Also, I am not so sure 
about this. This would require some form of extra state throughout the 
edge of the provider network, per customer or in worst case, per node. 
Right?

> information, versus the user of it).

Yes, but it does make some of the implications below.

> in the near-term, because it provides a strategic, incremental

I think that todays state is a must as fall-back. But I don't have a 
problem of "multi6 capable host" triggering on new features being 
announce to it and first trying to use that for connection 
establishing.

- - kurtis -

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Tue, 24 Feb 2004 21:06:37 +0100

>  different mechanisms, but so far it looks like they can do fine with

 From what I remember of the discussions here on the list, most people 
seem to see several similarities between the two. However the "failure 
modes" seemed different as well as the timing for the events. Also, I 
guess the way the address "learning" is/could be/should be handled in 
different ways for the two scenarios. I am not convinced that the two 
are similar enough to be able to use the same mechanisms, even with 
different parameters. But I would be happy to be proved wrong. :-)

However, again I think that this is something we also should provide as 
input for the architectural analysis. Just as impact on ULPs might 
vary.

> choices that can be pursued outside of the initial critical path.

Hmm, this has also been discussed before and the standard counter 
argument is that we should concentrate resources on one solution as we 
otherwise risk not having anyone at all. I am not arguing one way or 
the other, but an interesting question is what do you use to categorize 
any solution in an architectural evaluation in to the categories you 
describe?

- - kurtis -