Subject: [Monami6] about draft-montavont-mobileip-multihoming-pb-statement-05current

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 20 Jul 2005 16:12:16 +0200

Hi,

I have been reading this draft and i have some comments about it.
Essentially, most of my comments are my understanding of stuff that 
have been discussed in the multi6/shim working group, which experience 
imho would be useful for this work

In section 2.  Terminology it is stated that

    In [3], a node is said to be multihomed when it has multiple IPv6
    addresses,

defining a node as multihomed when it has multiple address would imply 
that most (if not all ipv6) nodes are multihomed, since most IPv6 nodes 
has at least one global address and one link local address, which is 
not the intention here. An option would to define a multihomed node whe 
it has multiple *global* addresses, however, this would result in a 
funny situation, where all MIP nodes are multihomed when they are away 
from home, since they have, at least, one CoA and one HoA i.e. two 
global addresses.
This would imply that all mip nodes are multihomed, so we would be 
failing to define and limit the problem accurately.
I would suggest to avoid trying to provide a general definition of 
multihomed node, and limit ourselves to define what a MIP multihomed 
node is, which i would define as:

  A MIP multihomed node is a MIP node that simultaneously has
  more than one HoA and/or more than one CoA.

later on the sentence continues with...

    either because multiple prefixes are advertised on the
    link(s) the node is attached to,

i would substitute advertised with available, i mean, what if the 
prefixes are not announced through RADV and the addresses of the node 
are manually configured or configured through DHCP?

this comment applies to all the document. i would suggest to 
substituting all the places where it is stated that a prefix is 
advertised by that a prefix is available, in order to consider as 
multihomed those nodes that have multiple global addresses configured 
by dhcp or manually.

Then it is stated that:

    o  Simultaneously using multiple addresses

       This indicates a scenario where the MN has the ability to use any
       of the said multiple addresses at the same time.  This implies
       that the MN is able to receive packets with destination address
       field equals to any of the said multiple addresses, and the MN is
       able to choose any of the said multiple addresses as the source
       address of the packets it is sending.

i am not sure what do you have in mind here... in a mip mn, i clearly 
see that a node with multiple valid CoAs qualifies here, but a mip mn 
located in a foreign link, with a single coa and multipel hoas, would 
also qualify as simultaneously using multiple addresses?

in other words, the multiple addresses that the node is using, must 
they be valid? if so, i would suggest to explicitly state it in the 
paragraph above (since a mn can receive and send packets from/to his 
hoa while he is in a foreign link, but the hoa is not a valid address 
AFAIU)

Later on in section 3.  Requirements it is stated that

    Basically, Internet connectivity is guaranteed for a MN as long as at
    least one path is maintained between the MN and the fixed Internet.

I think it is important to look a bit more in depth to this point:
when you mention the fixed internet, are you considering that the MN 
has access to the HA or that it has access to the rest of the internet 
(outside its home network)
I bring this point because imho it is an important distinction that 
needs to be considered (not really implying that a modification in the 
actual text is needed, but just thinking out loud). IMHO, the host 
multihoming problem has two differentiated parts: on one hand, we have 
a mn that has multiple paths to the HA (for instance multiple CoAs and 
perhaps multiple tunnels to the HA). On the other hand, we have the 
possibility of a multihomed host that has multiple paths from its home 
network to the internet (for instance the case where the home network 
is multihomed to multiple providers). Of course you got the general 
case, where the host has multiple tunnels and multiple links from the 
home network to the internet.

I mean, imho these are different problems and imho are likely to have 
different mechanisms to support them. Phrasing it as multiple paths to 
the fixed internet seems to hide this two imho different problems, if 
you see what i mean.

later on in the same section it is stated that

    In order to meet some of the goals (particularly load balancing and
    load sharing), multiple paths must be maintained simultaneously
    between the mobile node and the home network(s).

This seems that only the case of multiple paths between the MN and the 
HA is being considered, while as i mention above, the other part of the 
problem where there are multiple paths from the home network to the 
rest of the internet is not being considered.

I mean, imho the host multihoming problem is how to deal with the part 
of the multiple paths available between the MN and the CN that can be 
managed by the MN itself (in particular through interface and/or 
address selection)

later on it is stated that

    o  The MN must have either multiple interfaces with at least a single
       valid IP address on each interface, or a single interface with
       more than one valid address.

Let me see if i get this right...
a MN with multiple HoAs but a single interface is a multihomed host, 
right?
If so, when this node is away from home, it only has a single CoA, 
since it only has a single interface, right?
So, it only has one topologically correct address, right?
So, it doesn't fulfill the above requirement, right?
But, this node with multiple HoAs can provide some degree of fault 
tolerance and load sharing imho...
So, i am not sure i agree with this requirement..
(in other words, not only the case of multiple CoAs is relevant imho, 
but the case of multiple HoAs is also)

later on...

    o  The MN must be able to use multiple HAs simultaneously for a given
       home address.

    o  The MN must be able to use a distinct HA for each home address
       simultaneously.

I would do as in the previous points and start the requirement with "If 
the MN has multiple HA available, then ..."

Later on it is stated that

    One has to consider whether these goals can be achieved with
    transparency or without transparency.  Transparency is achieved when
    switching between interfaces does not cause the disruption of on-
    going sessions.  To be achieved with transparency, a necessary (may
    or may not be sufficient) condition is for the end-point addresses to
    remain unchanged.  This is in-view of the large amount of Internet
    traffic today are carried by TCP, which unlike SCTP, cannot handle
    multiple end-point address pairs.

As i see it, this is not a problem of transperency, but a problem of 
whether the fault tolerance requirement is fulfilled or not. I mean, 
the fault tolerance requirement has basically three subproblems 
(J.N.Chiappa's distinction actually) i.e. :  initiating new outgoing 
communications after an outage, initiating new incoming communications 
after an outage and preserving established through an outage. Failing 
to preserve established communications is failing to fulfill the fault 
tolerance requirement.

then in section 4.  Taxonomy it is stated that

    In order to aid the discussion of the benefits of multihoming as
    listed in [3] from the perspective of a mobile node, we will use in
    the present document the taxonomy (x,y,z) where:

    o  x = number of active interfaces

    o  y = number of Home Addresses (HoAs)

    o  z = number of Care-of Addresses (CoAs)

I fail to see the relevance of the x parameter... i mean why is 
relevant the difference between a MN that has multiple CoAs because 
multiple prefixes are available in the visited link and the case that 
it has multiple physical interfaces...

I mean, adding an additional parameter severely increases the 
complexity of the problem space (as we have seen with the nemo 
taxonomy), so i would suggest to analyze in depth if all the three 
parameters are critical for understanding the problems. FWIW, imho the 
number of Coas and the number of HoAs are relevant.

Then in section 5.  Scenarios

it is stated that

5.2  (1,n,1): 1 iface, n HoAs, 1 CoA

    The MN is multihomed, since it has several HoAs.  This case may
    happen when a node is getting access to the Internet through
    different HAs (possibly distinct operators) and each offers a Mobile
    IPv6 service to the node.  That way, the node will have a HoA per HA.
    Alternatively, though less commonly practiced, a single operator may
    have a multiple prefixed home link assigned to the mobile node, thus
    the mobile node would have multiple HoAs for a single home link.
    Either case, the node would need to configure a single CoA on the
    visited IPv6 subnet, and bind that single CoA to all the HoAs it
    owns.

I think that a very common scenario for this case is when the home 
network itself is multihomed and becuase of that, there are multiple 
prefixes available in the home network, one from each of the ISPs 
serving the home network. imho it would be worth mentioning it

later

    o  Fault Recovery

       If there is a failure in one of the home network of the MN (e.g.,

s/network/networks

       one HA of the MN is disconnected from the network) MIPv6 does not
       provide any mechanism to hand-over the communication to another
       HoA.  If a HoA, which is used at the transport layer by an
       application, needs to be changed, the application must be
       restarted.  MIPv6 does not allow changing of the HoA transparently
       for a given transport session.  Currently, fault recovery can
       therefore only be performed without transparency.  See the
       corresponding discussion in Section 7.3

I would state it otherwise, fault tolerance is not achieved in this 
case, since established communications cannot be preserved.

    o  Preference Settings and Load Sharing

       As an entry in the binding cache is identified by a HoA, the MN
       can register the same CoA with all HoAs, on any distant node.  A
       mechanism would then be needed for the MN to select which HoA
       should be used when a new communication flow is initiated.  A
       similar mechanism is needed on the CN side if it knows that
       multiple HoAs are assigned to the same MN.  With such mechanisms,
       it would be possible to use multiple HoAs at the same time, and
       load sharing could be performed.  See in Section 6.1.1 where such
       path selection issues are discussed.

I would mention that in this scenario, the load sharing and preference 
setting affects the path between the CN and the HA, and not the path 
between the HA and the MN, since there is only one CoA. In addition, 
this only applies in BT mode, since in RO mode the traffic flows 
directly between the CN and the CoA, independently of the HoA used.

Then it is stated that:

5.3  (1,1,n): 1 iface, 1 HoA, n CoAs

    The MN is multihomed since it has several CoAs.  This case may occur
    when the interface of the node is connected to a link where multiple
    IPv6 prefixes are advertised.

I would add:
One possible reason for this is that the visited network is multihomed 
and because of that, multiple prefixes are available in it, one per 
provider.

then it is stated that:

    o  Fault Recovery

       Fault recovery will be limited to the case where a prefix in the
       visited network is not advertised anymore, i.e. when the MN looses
       a CoA.  This is possible with MIPv6 as it can associate an
       alternate CoA to replace the failed CoA.  However, efficient
       mechanisms are needed to determine that a CoA has failed (see
       Section 6.1.3) and to determine which CoA should be used instead
       (see below).

Well, imho this configuration may have a much more broader application. 
If you consider the case that i mentioned above, where the visited 
network is multihomed, then different CoAs will have different 
prefixes, which may have different reachability. I mean, each CoA will 
be associated to a different ISP available in the visited network, and 
if the path through an ISP is down, the correspodent CoA will be 
unreachable. Having multiple CoAs allows important fault tolerance 
features, since one of the ISPs of the visited networks, fails, the 
other CoAs will be still reachable, allowing to preserve the 
establsihed communications. (please note that a path through a given 
ISP to a given CN is unavailable, doesn't mean that the whole ISP is 
down and that the prefix/CoA is deprecated)

then

    o  Preference Setting, Load Sharing and Bicasting

       In order to achieve load sharing under this scenario, the MN would
       need to register several CoAs with its unique HoA.  However, the
       present specification of MIPv6 only allows the MN to register a
       single CoA per HoA.  This is discussed in Section 6.2.1.  When a
       single HoA is bounded with several CoAs at the same time, the MN
       or HA/CN would need to select which CoA should be used.  This
       selection could be done based on user/application preferences (see
       Section 6.1.1).

I would add that this configuration allows to share the load and set 
preferences among different paths between the HA and the MN, when BT 
mode is used and between the CN and the MN when RO mode is used.

later on

5.5  (n,1,1): n ifaces, 1 HoA, 1 CoA

    This is a very special case of a node with multiple interfaces
    connected to different IPv6 subnets.  The MN is multihomed if one of
    the interface is attached to a foreign link, the other one is
    attached to the home link.  Thus, the MN only configures one CoA on
    the foreign subnet, and one HoA on the home link.

I think this is really a corner case, that it is not worth mentioning.

later on it is stated that

    o  Fault Recovery and Ubiquitous Access

       These goals are achievable, but in a limited manner.  The MN can
       build a temporary IPv6 address on its other interface but it
       cannot register the temporary address with its HA because the node
       is using its HoA.

what is a temporary address? RFC3041 address?
Anyway, in this case there is by definition 1 hoa and 1 coa. Creating 
another address would result in more than one HoA or Coa, which would 
result in a different scenario, so, i think this does not apply here

Actually, the case where there are multiple interfaces and one HoA and 
one Coa, the faul tolerance features seem to me that are limited to 
change the physical interface actually being used. So i would say that 
this is transparent for IP and MIP, so would fall out of the scope of 
this analysis.

later on

    o  Preference Settings, Load Sharing and Load Balancing

       The MN is able to use both interfaces at the same time, according
       to some preference settings on its side to decide which one to use
       for which application.

How? i mean, the node has only one CoA and one HoA.

In order to have both of them working, the node must be at home, and 
also at a visited network. In this case, if he is at home, it does not 
have any CoA registered in the HA. So all incoming connections are 
going to be addressed to the HoA. So no load balancing here. I guess 
that the only option would for the MN to initiate some communication 
using the CoA and other using the HoA. But i could argue that this is 
always possible, and that a MN in a visited network can always use the 
CoA or the HoA for initating communications and this would result in 
some form of load sharing preference setting

later on...

5.6  (n,1,n): n ifaces, 1 HoA, n CoAs

    The MN is multihomed: the node has several addresses to choose from.
    This case regroups two different scenarios: either the MN is
    connected to its home link via one interface, or the MN is only
    connected to visited subnets via all its interfaces.

i fail to see why this distinction is relevant, could you expand on 
this?

later on...

    o  Fault Recovery

       Fault recovery is possible with MIPv6 whenever the MN looses one
       interface (and the CoA configured on this interface) as it can
       associate the CoA of an alternate interface to replace the failed
       one.  However, efficient mechanisms are needed to determine that
       an interface has failed (see Section 6.1.3) and to determine which
       interface should be used instead (see Section 6.1.1)

I seems to me that all this is below IP and it is transparent to IP and 
to MIP, so i would argue that is out of the scope of this analysis how 
a node changes the physical interface associated to a given address
Actually, the problem that is on the IP layer is the case when the MN 
decides to use another CoA when it has multiple ones, and this, is 
independent of the number of physical interfaces available in the MN

    o  Preference Settings, Load Sharing and Bicasting

       In order to achieve these goals under this scenario, the MN would
       need to register several CoAs with its unique HoA.  However, the
       present specification of MIPv6 only allows the MN to register a
       single CoA per HoA.  This is discussed in Section 6.2.1.  Having
       multiple interfaces and their associated CoAs available
       simultaneously, efficient mechanisms are needed to select the
       appropriate path (see Section 6.1.1).

this is exactly the same that occurs in the (1,1,n) scenario AFAICT, so 
having multiple interfaces doesn't really changes anything

later on...

    o  Flow redirection (Fault Recovery, Load Sharing, preference
       settings)

This flow redirection has not been defined and has not been considered 
before, why is that? could you define exactly what is the point here?

is it specific to this particular scenario?

later on...

5.7  (n,n,1): n ifaces, n HoAs, 1 CoA

    The MN is multihomed.  This case extends the case (n,1,1) when the
    node has several HoAs, for example from multiple operators.  The CoA
    can be associated with each HoA.

again, i don't see anything substantial in this section the differs 
from the considerations that need to be considered in (1,n,1)
same for (n,n,n) and (1,n,n)

then in section 6.  Issues

IMHO there are some fundamental issues that are not included in this 
section that must be provided in order to support host multihoming. 
Among those, i can spot:

- Failure detection: If we want to obtain fault tolerance features, we 
must be able to identify failures in currently used paths in order to 
rehome the communication to an alternative path

- Path exploration: once that we have detected an outage, we need to be 
able to explore alternative paths to identify which of them is 
available

- Path selection: once we identified alternative paths, we need to 
select which one to use to rehome the communication. this is not done 
only with RFC3484

- Rehoming: after we decided we will use an alternative path, we need 
to actually move the communication to an alternative path, which may 
require some signaling

- Address selection for initiating communication after outages: When an 
outage has occurred, some of the available addresses are no longer 
working, so in order to initiate new communications it is likely that 
several addresses need to be retried, in particular source addresses. 
Such behaviour is not currently supported by RFC3484 and additional 
mechanisms are needed

Note that these issues and some other issues included in this section 
(like ingress filtering) are also being considered in the shim design, 
so probably the mechanisms designed there will be useful here, with 
minor modifications (i hope)

Regards, marcelo

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

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 21 Jul 2005 12:09:22 -0400

Dear Marcelo,

Thank you very much for you in-deep review of our draft. It is very good 
to have someone like you reviewing it. Please find my comments inline.

marcelo bagnulo braun wrote:

> that most (if not all ipv6) nodes are multihomed, since most IPv6 
> nodes has at least one global address and one link local address, 
> which is not the intention here. An option would to define a 
> multihomed node whe it has multiple *global* addresses, however, this 
> would result in a funny situation, where all MIP nodes are multihomed 
> when they are away from home, since they have, at least, one CoA and 
> one HoA i.e. two global addresses.

You are perfectly right. This is why we tried to extend the definition 
we gave in draft-ernst-goals-and-benefits in the MIP specific draft.

> multihomed node, 

You think it's also useless to propose a general definition of 
multihoming in draft-ernst-goals-and benefits?

> and limit ourselves to define what a MIP multihomed node is, which i 
> would define as:
>

That was our intend, we first remind the definition given in 
draft-ernst-goals-and-benefits, and then propose this sentence. Maybe we 
can keep just this part, and don't remind the general definition.

> multihomed those nodes that have multiple global addresses configured 

I agree with that, I'll do it.

> hoa while he is in a foreign link, but the hoa is not a valid address 

Yes you are right, and more generally as you point out later, we should 
consider more the path from a CN to the MN's HAs. What we meant here is 
that at the application layer, any of the addresses currently in use 
(HoAs and valid CoAs) could be used. What about this new text:

      This indicates a scenario where the MN has the ability to use any
      of the said multiple addresses at the same time.  This implies that
      a packet with the destination field set to one of the said multiple
      addresses will reach the MN, either directly from a CN to the MN
      or through a tunnel with one of the MN's HAs. This also implies
      that any of the said multiple addresses can be used as source
      address above the MIPv6 layer.

> the fixed internet seems to hide this two imho different problems, if 

Yes I think I see what you mean here, and I am not sure that we capture 
the case "mutliple paths from the Internet to the home network" well in 
the draft. In the particular sentence you mentioned, we meant that at 
least one path between a CN and the MN is maintained, either through a 
home network or not.

But isn't the Multiple path between the Internet to the home network 
capture by having multiple HoAs?

> HA is being considered, while as i mention above, the other part of 
> the problem where there are multiple paths from the home network to 
> the rest of the internet is not being considered.

Yes, what about this new text:

   In order to meet some of the goals (particularly load balancing and
   load sharing), multiple paths must be maintained simultaneously
   between the mobile node and its CN.

> but the case of multiple HoAs is also)

what about adding another condition:

    [...] or a single interface with one valid address and multiple HoAs.

> I would do as in the previous points and start the requirement with 
> "If the MN has multiple HA available, then ..."

Make sense.

> to preserve established communications is failing to fulfill the fault 

What we wanted to say here was not only about fault tolerence, but more 
generaly if a flow can be transparently redirected for whatever the 
reason. Imagine that the policies that dictate wich interface to use on 
the MN change, and now tell the MN to redirect one flow from one 
interface to another one. Transparent redirection is an issue in that 
case too.

> it has multiple physical interfaces...

The intend was that there is a difference between having a single 
interface, and several of them: when you have a single interface, you 
cannot perform load balancing, and fault recovery and ubiquitous access 
benefits are reduced: if you loose the interface, then there is not much 
you can do.

> number of Coas and the number of HoAs are relevant.

I see what you mean. Maybe the number of interfaces can be distinguished 
only when it is relevant.

> serving the home network. imho it would be worth mentioning it

Ok.

> case, since established communications cannot be preserved.

Ok.

> directly between the CN and the CoA, independently of the HoA used.

Ok.

> and because of that, multiple prefixes are available in it, one per 

Ok.

> Well, imho this configuration may have a much more broader 
> application. If you consider the case that i mentioned above, where 
> the visited network is multihomed, then different CoAs will have 
> different prefixes, which may have different reachability. I mean, 
> each CoA will be associated to a different ISP available in the 
> visited network, and if the path through an ISP is down, the 
> correspodent CoA will be unreachable. Having multiple CoAs allows 
> important fault tolerance features, since one of the ISPs of the 
> visited networks, fails, the other CoAs will be still reachable, 
> allowing to preserve the establsihed communications. (please note that 
> a path through a given ISP to a given CN is unavailable, doesn't mean 
> that the whole ISP is down and that the prefix/CoA is deprecated)

Your descrition and ours are similar, aren't they ? Actually, this is 
what we had in mind, so if this is not clear, I have to rewrite it.

> mode is used and between the CN and the MN when RO mode is used.

Ok.

> I think this is really a corner case, that it is not worth mentioning.

i think you are right, but we wanted to list all cases. If we get a 
consensus that some scenarios are useless, we can remove some of them.

> result in a different scenario, so, i think this does not apply here

What we wanted to say here, is that you can configure an address on the 
interface connected to the foreign link, but it is not really a CoA 
(because we can not register it with a HoA, as we are using it). I think 
the text is misleading.

> this is transparent for IP and MIP, so would fall out of the scope of 

I am not sure I get this one. Let me re-word what we wanted to say: If 
you are using your HoA, and you shutdown the corresponding interface 
(the one connected to the home network), you need MIPv6 to register your 
CoA configured on your other interface (so it is not transparent to IP 
without using MIPv6)

But when you have both interfaces available and you initiate some flow 
directly through the "CoA", if you loose this interface, then you can 
not rely on MIPv6 to redirect the flow.

> some form of load sharing preference setting

Yes this is exactly what we meant, and what is possible in this 
particular case. For example, a CoA could be directly used (without the 
MIpv6 mechanisms) for a certain type of application to avoid all the 
encapsulation mechanisms required by MIPv6. The advantage will be a 
faster initiation and less overhead, and the disadvantage the fact that 
if you change prefix, you will have to re-start the application. But for 
a webbrowsing, I think it makes sense.

> i fail to see why this distinction is relevant, could you expand on this?

If the MN is connected to its home link, then it can not register any of 
its "CoA". Therefore, it is hard to have alternative paths.

> I seems to me that all this is below IP and it is transparent to IP 
> and to MIP, so i would argue that is out of the scope of this analysis 
> how a node changes the physical interface associated to a given address

No, I think you misunderstood our point (maybe because our text is not 
clear enough): if you loose a CoA (because you loose the corresponding 
interface for example), you have to redirect the flow using this old CoA 
to another CoA. There you need MIPv6. We are not talking about how to 
allocate one address from one interface to another.

> independent of the number of physical interfaces available in the MN

Yes, but in this particular scenario, we wanted to point out that this 
is a movement detection that has to be taken into account, to react 
quickly against the failure of an interface/CoA.

> this is exactly the same that occurs in the (1,1,n) scenario AFAICT, 
> so having multiple interfaces doesn't really changes anything

Yes, some scenarios are overlapping, but again, we wanted to list all of 
them, to be sure we do not miss some.

> before, why is that? could you define exactly what is the point here?

We had a big discussion on this, and I think we failed to be consistent. 
Either we use this term each time it applies, or we don't use it at all. 
IMHO, it applies very well in this area, since when you are dealing with 
multihomed node, you can have different policies to distribute your flow 
on interfaces / addresses, and then you might want to consider 
redirection of flows across your interfaces / addresses.

If you look at section 7.3, we are specifically talking about flow 
redirection.

> is it specific to this particular scenario?

No I think it applies all the time: when you have to change CoA, you can 
use the term "flow redirection" to indicate that the flows that were 
using the old CoA will now use the new CoA.

> rehome the communication to an alternative path

this is what we wanted to capture is 6.1.3 Media detection. Maybe we 
should extend this issue to point out failure detection more generaly 
than just a media detection.

>
> - Path exploration: once that we have detected an outage, we need to 
> be able to explore alternative paths to identify which of them is 
> available

Let me check if I understand your point: you mean path selection after 
an outage?

> select which one to use to rehome the communication. this is not done 

Isn't this section 6.1.1?

> to actually move the communication to an alternative path, which may 

Isn't this 7.3 flow redirection?

>
> - Address selection for initiating communication after outages: When 
> an outage has occurred, some of the available addresses are no longer 

Again, isn't this captured by 6.1.1 path selection and 6.1.3 media 
detection?

> minor modifications (i hope)

This is something we can investigate in the future if monami6 is successful.

Again thank you for your review, it is very valuable.

Nicolas

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 21 Jul 2005 12:09:22 -0400

Dear Marcelo,

Make sense.

Ok.

Ok.

Ok.

Ok.

Ok.

Nicolas

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Jul 2005 19:41:15 +0200

Hi Nicolas,

El 21/07/2005, a las 18:09, Nicolas Montavont escribió:
>> have been discussed in the multi6/shim working group, which 
>> experience imho would be useful for this work
>>
>> defining a node as multihomed when it has multiple address would 
>> imply that most (if not all ipv6) nodes are multihomed, since most 
>> IPv6 nodes has at least one global address and one link local 
>> address, which is not the intention here. An option would to define a 

but it is stated somehow funny, since it states that

    In [3], a node is said to be multihomed when it has multiple IPv6
    addresses, either because multiple prefixes are advertised on the
    link(s) the node is attached to, or because the node has multiple
    interfaces (see the entire definition).  For a mobile node operating
    MIPv6, this may translate into the MN having multiple HoAs and/or
    multiple CoAs:

But, this is not so, because if you apply directly the definition, you 
end up with the aforementioned conclusion, that any MN away from home 
fulfills the requirements for being multihomed, right?

So actually, the above definition would actually translate in the MIP 
scenario in:

     Any MN away from home is multihomed, becuase it has a CoA and a HoA

agree?

> multihoming in draft-ernst-goals-and benefits?

I don't know about draft-ernst-goals-and benefits (haven't actually 
reviewed it yet) But i am certain, is that the proposed general 
definition does not capture the essence of the problem here, and that 
the doc would be better off just keeping the two bulleted items as a 
definition of multihomed MN, i.e. multiple HoAs and/or multiple CoAs. 
This is clearer, cleaner and most important, is truely what you want to 
express

> draft-ernst-goals-and-benefits, and then propose this sentence. Maybe 
> we can keep just this part, and don't remind the general definition.

exactly (especially because the other definition seems to be somehow 
missing the point and including non multihomed hosts within, right?)
...
> Yes you are right, and more generally as you point out later, we 
> should consider more the path from a CN to the MN's HAs. What we meant 
> here is that at the application layer, any of the addresses currently 
> in use (HoAs and valid CoAs) could be used. What about this new text:
>
> that

this is clearer to me

>> has access to the HA or that it has access to the rest of the 
>> internet (outside its home network)
>> needs to be considered (not really implying that a modification in 
>> the actual text is needed, but just thinking out loud). IMHO, the 
>> host multihoming problem has two differentiated parts: on one hand, 
>> we have a mn that has multiple paths to the HA (for instance multiple 
>> CoAs and perhaps multiple tunnels to the HA). On the other hand, we 
>> have the possibility of a multihomed host that has multiple paths 
>> from its home network to the internet (for instance the case where 
>> the home network is multihomed to multiple providers). Of course you 
>> got the general case, where the host has multiple tunnels and 
>> multiple links from the home network to the internet.
>>
>> different mechanisms to support them. Phrasing it as multiple paths 
>> to the fixed internet seems to hide this two imho different problems, 
>> if you see what i mean.
>
> Yes I think I see what you mean here, and I am not sure that we 
> capture the case "mutliple paths from the Internet to the home 
> network" well in the draft. In the particular sentence you mentioned, 
> we meant that at least one path between a CN and the MN is maintained, 
> either through a home network or not.
>

exactly, in the BT mode, changing the HoA implies changing part of the 
path between the CN and the HA while changing the CoA implies changing  
part of the path between the MN and the HA.

IMHO this distinction is useful to think about the problem and the 
related issues...
I mean, in BT mode, changing the CoA would likely solely involve the HA 
and the MN, while changing the HoA involves the CN and the MN. This 
probably have great impact in the deployability of the related 
mechanisms. OTOH, because of the previous distinction, changing the HoA 
provides protects from different failure modes than changing the CoA.

In RO mode, changing the CoA and/or the HoA means changing part of the 
direct path

To me, dividing the problem this way, makes it easier to deal with it.
>> This seems that only the case of multiple paths between the MN and 
>> the HA is being considered, while as i mention above, the other part 
>> of the problem where there are multiple paths from the home network 
>> to the rest of the internet is not being considered.
>

ok

>>
>> I mean, imho the host multihoming problem is how to deal with the 
>> part of the multiple paths available between the MN and the CN that 
>> can be managed by the MN itself (in particular through interface 
>> and/or address selection)
>>

ok

...

>> communications after an outage, initiating new incoming 
>> communications after an outage and preserving established through an 
>> outage. Failing to preserve established communications is failing to 
>> fulfill the fault tolerance requirement.
>
> What we wanted to say here was not only about fault tolerence, but 
> more generaly if a flow can be transparently redirected for whatever 
> the reason. Imagine that the policies that dictate wich interface to 
> use on the MN change, and now tell the MN to redirect one flow from 
> one interface to another one. Transparent redirection is an issue in 
> that case too.
>

i see and i agree this may be relevant in some scenarios. perhaps it 
would be good to explicitly mention (if it is not already there) the 
different reasons why do you may want flow redirection...

> cannot perform load balancing, and fault recovery and ubiquitous 
> access benefits are reduced: if you loose the interface, then there is 
> not much you can do.

i agree that in reality having one or several interfaces is a big 
difference, but this seems not very relevant from an IP layer 
perspective AFAICS.
I mean, imho, IP layer mechanisms for dealing with one or more 
interfaces would be the same, since they will be based on handling 
different addresses, but maybe i am wrong here...

My main concern is that afterwards, having three parameters really 
makes the taxonomy much more complex, as you already see from the 
amount of different cases to consider

>> parameters are critical for understanding the problems. FWIW, imho 
>> the number of Coas and the number of HoAs are relevant.
>
> I see what you mean. Maybe the number of interfaces can be 
> distinguished only when it is relevant.
>

that would be my preferred approach

...
>> allowing to preserve the establsihed communications. (please note 
>> that a path through a given ISP to a given CN is unavailable, doesn't 
>> mean that the whole ISP is down and that the prefix/CoA is 
>> deprecated)
>

the distinction that i was pointing out is that the prefix of a CoA may 
still be available in the link, but the CoA is unreachable for the 
particular communication. I mean, reachability is not binary, like the 
prefix is available or not, but it depends on who are you talking with 
i.e. the address of the CN

...
> What we wanted to say here, is that you can configure an address on 
> the interface connected to the foreign link, but it is not really a 
> CoA (because we can not register it with a HoA, as we are using it)

so, what is the pointing of having such an address? and more important, 
how does this affects this analysis, which goal is to analyze the MIP 
host behaviour?

> . I think the text is misleading.
>
>>
>> Actually, the case where there are multiple interfaces and one HoA 
>> and one Coa, the faul tolerance features seem to me that are limited 
>> to change the physical interface actually being used. So i would say 
>> that this is transparent for IP and MIP, so would fall out of the 
>> scope of this analysis.
>
> (the one connected to the home network), you need MIPv6 to register 
> your CoA configured on your other interface (so it is not transparent 
> to IP without using MIPv6)
>

ok, but in this case you have 2 CoAs which is a different scenario, 
right?

> not rely on MIPv6 to redirect the flow.

I guess that what you would do in this case, if you have two interfaces 
(connected to the same link), and only one CoA, would be to assign the 
CoA to the working interface when the initial interface fails, which 
would be imho transparent to MIP.

I mean, my point is:
- or you have multiple CoAs, one per interface, in this case, this is 
not transparent for MIP (i.e. it is relevant for us here) but, you are 
not longer in the 1 CoA scenario
- or you have only one CoA that you use in different interfaces when 
there is a failure, which is the considered scenario (only one CoA and 
multiple interfaces) but this is transparent for MIP so not relevant 
for this analysis AFAICT

>> also at a visited network. In this case, if he is at home, it does 
>> not have any CoA registered in the HA. So all incoming connections 
>> are going to be addressed to the HoA. So no load balancing here. I 
>> guess that the only option would for the MN to initiate some 
>> communication using the CoA and other using the HoA. But i could 
>> argue that this is always possible, and that a MN in a visited 
>> network can always use the CoA or the HoA for initating 
>> communications and this would result in some form of load sharing 
>> preference setting
>
> particular case. For example, a CoA could be directly used (without 
> the MIpv6 mechanisms) for a certain type of application to avoid all 
> the encapsulation mechanisms required by MIPv6. The advantage will be 
> a faster initiation and less overhead, and the disadvantage the fact 
> that if you change prefix, you will have to re-start the application. 
> But for a webbrowsing, I think it makes sense.

right, but the point is that this is a general issue (you can always 
use the CoA directly when you are away from home) so i don't see the 
point of describing it in this particular section, if you see what i 
mean

> If the MN is connected to its home link, then it can not register any 
> of its "CoA". Therefore, it is hard to have alternative paths.
>

:-) agree

>> and to MIP, so i would argue that is out of the scope of this 
>> analysis how a node changes the physical interface associated to a 
>> given address
>
> interface for example), you have to redirect the flow using this old 
> CoA to another CoA. There you need MIPv6. We are not talking about how 
> to allocate one address from one interface to another.
>

ok, but the mechanisms involved are exactly the same when the CoA being 
used is unreachable, right?
Bottom line is: is it relevant for us that the CoA is not longer used 
because the interface failed or because the CoA is unreachable?

> quickly against the failure of an interface/CoA.

Yes, i agree that the indication that an interface is down must be 
considered as a trigger for changing the CoA

> Yes, some scenarios are overlapping, but again, we wanted to list all 
> of them, to be sure we do not miss some.
>

well, as you probably guess by now, my point is that you probably can 
cover all the scenarios without cosnidering the distinction in the 
number of physical interfaces (and just pointing out somewhere else the 
particularities of this case, for instance that the indication that an 
inteface is down implies changing the CoA)

>> This flow redirection has not been defined and has not been 
>> considered before, why is that? could you define exactly what is the 
>> point here?
>
> We had a big discussion on this, and I think we failed to be 
> consistent. Either we use this term each time it applies, or we don't 
> use it at all. IMHO, it applies very well in this area, since when you 
> are dealing with multihomed node, you can have different policies to 
> distribute your flow on interfaces / addresses, and then you might 
> want to consider redirection of flows across your interfaces / 
> addresses.
>

yes, but here you only talk about fault tolerance and not about what 
you mentioned earlier w.r.t. moving one flow to an alternative path 
because of preferences and performance.

IMHO, the flow redirection concept is useful only if it is considered 
with all the meanings that you described.
Just for fault tolerance, i would use the idea of preserving 
established communications..

....
>> - Failure detection: If we want to obtain fault tolerance features, 
>> we must be able to identify failures in currently used paths in order 
>> to rehome the communication to an alternative path
>

there are many failure modes.
one case is that there is no media available as you mention and DNS 
seems who will provide information for this.

But in general, a failure may affect other parts of the path, even if 
there is a media avaialble

For instance, consider a failure in the ISP of the home network. If you 
have multiple HoAs you can overcome this by using a different HoA, but 
for that you need to detect it and such detection is not about 
discovering if there is a media avaialble, but an end to end failure 
detection mechanism. (note that here end to end may mean different 
things depending on the scenario. In BT mode, and with multiple CoAs, 
this means between the MN and the HA, while if there are multiple HoA 
available means the e2e path MN-CN)

Such failure detection are not trivial and probably involve some form 
of e2e reachability tests

> Let me check if I understand your point: you mean path selection after 

yes, but the point is that after an outage, you need to discover which 
e2e paths are avaialble, which would alos imply some form of e2e 
reachability test

> Isn't this section 6.1.1?

not exactly.

In section 6.1.1 it is stated:
    o  HoA selection

       In the (*,n,*) cases, multiple HoAs would be available on the MN.
       The MN and its communicating peers (HA and CNs) must be able to
       select the appropriate HoA to be used for a particular packet or
       flow.

       This choice would be made at the time of a new communication flow
       set up.  Usual IPv6 mechanisms for source and destination address
       selection, such as [8] would be used.

The case that i am pointing out is how to select the new path to be 
used for preserving an establsihed communication after a failure.

Not when the flow is set up, as stated in the draft
And here, it is likely that RFC3484 won't necesarily be used, because 
you are likely to also use information obtained from the alternative 
path exploration process

> Isn't this 7.3 flow redirection?

well, i read flow redirection as the whole process of detecting the 
need for redirection (failure detection) exploring paths, selecting 
one, and then rehome.

rehoming is the part of the process which actually moves the 
communication from one path to another, which probably involves some 
signaling

> Again, isn't this captured by 6.1.1 path selection

no, because RFC3484 won't do the trick

> and 6.1.3 media detection?
>

no because an address may be unreachable even if there is a media 
available

>> (like ingress filtering) are also being considered in the shim 
>> design, so probably the mechanisms designed there will be useful 
>> here, with minor modifications (i hope)
>

agree

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Jul 2005 19:41:15 +0200

Hi Nicolas,

agree?

this is clearer to me

ok

ok

...

...

...

I mean, my point is:

:-) agree

....

not exactly.

agree

regards, marcelo

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 21 Jul 2005 21:49:54 -0400

Hello Marcelo,

I split you review into two threads, hope you don't mind.
I'll answer to the issue part tomorrow.

marcelo bagnulo braun wrote:

>>> address, which is not the intention here. An option would to define 
>>> a multihomed node whe it has multiple *global* addresses, however, 
>>> this would result in a funny situation, where all MIP nodes are 
>>> multihomed when they are away from home, since they have, at least, 
>>> one CoA and one HoA i.e. two global addresses.
>>
>>
>> You are perfectly right. This is why we tried to extend the 
>> definition we gave in draft-ernst-goals-and-benefits in the MIP 
>> specific draft.
>>
>
Yes

> This is clearer, cleaner and most important, is truely what you want 
> to express

I think you're right, I'll modify accordingly.

>>> i am not sure what do you have in mind here... in a mip mn, i 
>>> clearly see that a node with multiple valid CoAs qualifies here, but 
>>> a mip mn located in a foreign link, with a single coa and multipel 
>>> hoas, would also qualify as simultaneously using multiple addresses?
>>>
>>> hoa while he is in a foreign link, but the hoa is not a valid 
>>> address AFAIU)
>>
>>
>> should consider more the path from a CN to the MN's HAs. What we 
>> meant here is that at the application layer, any of the addresses 
>> currently in use (HoAs and valid CoAs) could be used. What about this 
>> new text:
>>
>>> we have a mn that has multiple paths to the HA (for instance 
>>> multiple CoAs and perhaps multiple tunnels to the HA). On the other 
>>> hand, we have the possibility of a multihomed host that has multiple 
>>> paths from its home network to the internet (for instance the case 
>>> where the home network is multihomed to multiple providers). Of 
>>> course you got the general case, where the host has multiple tunnels 
>>> and multiple links from the home network to the internet.
>>>
>>> I mean, imho these are different problems and imho are likely to 
>>> have different mechanisms to support them. Phrasing it as multiple 
>>> paths to the fixed internet seems to hide this two imho different 
>>> problems, if you see what i mean.
>>
>>
>> we meant that at least one path between a CN and the MN is 
>> maintained, either through a home network or not.
>>
> path between the CN and the HA while changing the CoA implies 
> changing  part of the path between the MN and the HA.
>
> I mean, in BT mode, changing the CoA would likely solely involve the 
> HA and the MN, while changing the HoA involves the CN and the MN. This 
> mechanisms. OTOH, because of the previous distinction, changing the 
> HoA provides protects from different failure modes than changing the CoA.
>

Your point is noted and I'll try to take this into account for the next 
revision. I also think that this distinction makes sense.

...

> different reasons why do you may want flow redirection...

Actually I have list some reasons in draft-montavont-mip6-mmi. I should 
copy/paste those here.

>>> multiple prefixes are available in the visited link and the case 
>>> that it has multiple physical interfaces...
>>
>>
>> access benefits are reduced: if you loose the interface, then there 
>> is not much you can do.
>
>

I agree with you, and this is something we can discuss at the BOF.

...

>>> that a path through a given ISP to a given CN is unavailable, 
>>> doesn't mean that the whole ISP is down and that the prefix/CoA is 
>>> deprecated)
>>
>>
> the distinction that i was pointing out is that the prefix of a CoA 
> may still be available in the link, but the CoA is unreachable for the 

Ok I understand now. Here we wanted to point out that the CoA cannot be 
used to reach the MN anymore. This is either because the prefix is not 
available anymore or because the path to the visited network is not 
working anymore. I'll modify the text to be more general.

>>> Anyway, in this case there is by definition 1 hoa and 1 coa. 
>>> Creating another address would result in more than one HoA or Coa, 
>>> which would result in a different scenario, so, i think this does 
>>> not apply here
>>
>>
> so, what is the pointing of having such an address? and more 
> important, how does this affects this analysis, which goal is to 
> analyze the MIP host behaviour?

Let me explain this tricky case once more, tell me if this text is better:

      These goals are achievable, but in a limited manner. As long as the MN
      remains connected in its home network, it can not register its CoA with
      its HoA. If the MN looses its CoA (either it connects to another network,
      or it switches off its interface), MIPv6 does not provide mechanisms to
      redirect flows that were using this CoA to any other address. This issue
      is detailed in Section 6.2.3. If the MN is getting away from its home
      network, it will be able to register its CoA with its HA and then
      transparently redirect flows from its HoA to its CoA.

>> I am not sure I get this one. Let me re-word what we wanted to say: 
>> If you are using your HoA, and you shutdown the corresponding 
>> interface (the one connected to the home network), you need MIPv6 to 
>> register your CoA configured on your other interface (so it is not 
>> transparent to IP without using MIPv6)
>>
>
>> But when you have both interfaces available and you initiate some 
>> flow directly through the "CoA", if you loose this interface, then 
>> you can not rely on MIPv6 to redirect the flow.
>
>
> I guess that what you would do in this case, if you have two 
> interfaces (connected to the same link), and only one CoA, would be to 
> assign the CoA to the working interface when the initial interface 
> fails, which would be imho transparent to MIP.
>
> I mean, my point is:

Ok, I see your problem. The fact is that here when we analyse the case, 
we make assumptions from the initial situation (explained by the 
scenario, i.e n,1,1) to get into a potantial situation (e.g. what happen 
if you loose one of the address). I think what could be useful is to 
investigate different scenarios from a particular configuration (*,*,*)

> point of describing it in this particular section, if you see what i mean

Ok maybe then we should state this more generally, and avoid to remind 
it in each scenario. This is what I meant also in the previous case (n,1,1)

...

>> No, I think you misunderstood our point (maybe because our text is 
>> not clear enough): if you loose a CoA (because you loose the 
>> corresponding interface for example), you have to redirect the flow 
>> using this old CoA to another CoA. There you need MIPv6. We are not 
>> talking about how to allocate one address from one interface to another.
>>
>
> ok, but the mechanisms involved are exactly the same when the CoA 
> being used is unreachable, right?

you're right, what is important is that the CoA is not longer available. 
The reason why is given as example.

>
>>> Actually, the problem that is on the IP layer is the case when the 
>>> MN decides to use another CoA when it has multiple ones, and this, 
>>> is independent of the number of physical interfaces available in the MN
>>
>>
>> Yes, but in this particular scenario, we wanted to point out that 
>> this is a movement detection that has to be taken into account, to 
>> react quickly against the failure of an interface/CoA.
>
>
> number of physical interfaces (and just pointing out somewhere else 
> the particularities of this case, for instance that the indication 
> that an inteface is down implies changing the CoA)

I think yes, we can discuss this at the next BOF. It would be nice to 
have other's opinion.

>> use it at all. IMHO, it applies very well in this area, since when 
>> you are dealing with multihomed node, you can have different policies 
>> to distribute your flow on interfaces / addresses, and then you might 

Agree with you. I'll make the changes.

Nicolas

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 21 Jul 2005 21:49:54 -0400

Hello Marcelo,

Yes

...

...

...

Nicolas

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 22 Jul 2005 16:34:31 +0900

> >>>    In [3], a node is said to be multihomed when it has multiple
> >IPv6>>    addresses,
> >>>
> >>> address, which is not the intention here. An option would to
> >define >> a multihomed node whe it has multiple *global* addresses,
> >however, >> this would result in a funny situation, where all MIP
> >nodes are >> multihomed when they are away from home, since they
> >have, at least, >> one CoA and one HoA i.e. two global addresses.
> >>
> >>
> >    interfaces (see the entire definition).  For a mobile node
> >    operating MIPv6, this may translate into the MN having multiple
> >    HoAs and/or multiple CoAs:
> >
> > But, this is not so, because if you apply directly the definition,
> > you end up with the aforementioned conclusion, that any MN away from
> > home fulfills the requirements for being multihomed, right?
> >
> > So actually, the above definition would actually translate in the
> > MIP scenario in:
> >

Hold on, for me, a node that has a HoA and a CoA is multihomed because
it can decide to use either the CoA or the HoA, right ?  Of course, if
it uses the CoA, it has nothing to do with mobility, when it moves away
and acquires a new CoA connections would break. So, this has not to be
covered by the mip6 analysis draft but remains a multihoming case.

Note that the MN can also decide to use RO or not, so this is yet
another case where we can consider the MN has multihomed. But we didn't
cover this scenario in our draft.

> > definition does not capture the essence of the problem here, and
> > that the doc would be better off just keeping the two bulleted items
> > as a definition of multihomed MN, i.e. multiple HoAs and/or multiple
> > CoAs. This is clearer, cleaner and most important, is truely what
> > you want to express
> 
> >>> and limit ourselves to define what a MIP multihomed node is, which
> >i >> would define as:
> >>>
> >> draft-ernst-goals-and-benefits, and then propose this sentence.
> >Maybe > we can keep just this part, and don't remind the general
> >definition.
> >
> >

Anyway, I agree with the suggestion that reminding the definition of the
other draft is useless, as what trully matters here is the number of
HoAs and CoAs from the IP layer point of view.

Thierry

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 22 Jul 2005 12:14:28 +0200

> I split you review into two threads, hope you don't mind.

good, this mail was becoming way too long
...

>> may still be available in the link, but the CoA is unreachable for 
>> the particular communication. I mean, reachability is not binary, 
>> like the prefix is available or not, but it depends on who are you 
>> talking with i.e. the address of the CN
>
> Ok I understand now. Here we wanted to point out that the CoA cannot 
> be used to reach the MN anymore. This is either because the prefix is 
> not available anymore or because the path to the visited network is 
> not working anymore. I'll modify the text to be more general.
>

ok, but note that the situation may even be more complex and that a 
given CoA is good for communicating with CN1 but is not good for 
communicating with CN2.
In the multi6 work, we no longer talk about a given address being 
reachable but we talk about a given address pair is reachable.
imho such distinction may also be useful here

>      transparently redirect flows from its HoA to its CoA.

ok, i think i get it now.

>>>> In order to have both of them working, the node must be at home, 
>>>> and also at a visited network. In this case, if he is at home, it 
>>>> does not have any CoA registered in the HA. So all incoming 
>>>> connections are going to be addressed to the HoA. So no load 
>>>> balancing here. I guess that the only option would for the MN to 
>>>> initiate some communication using the CoA and other using the HoA. 
>>>> But i could argue that this is always possible, and that a MN in a 
>>>> visited network can always use the CoA or the HoA for initating 
>>> the encapsulation mechanisms required by MIPv6. The advantage will 
>>> be a faster initiation and less overhead, and the disadvantage the 
>>> fact that if you change prefix, you will have to re-start the 
>>> application. But for a webbrowsing, I think it makes sense.
>>
>>

agree

> you're right, what is important is that the CoA is not longer 
> available. The reason why is given as example.
>
>>
>>>> this is exactly the same that occurs in the (1,1,n) scenario 
>>>> AFAICT, so having multiple interfaces doesn't really changes 
>>>> anything
>>>
>>>
>>> Yes, some scenarios are overlapping, but again, we wanted to list 
>>> all of them, to be sure we do not miss some.
>>>
>>

ok, fair enough

regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 22 Jul 2005 12:14:28 +0200

agree

ok, fair enough

regards, marcelo

---

From: Nicolas Montavont <[email-masked]>
Date: Fri, 22 Jul 2005 10:12:46 -0400

> imho such distinction may also be useful here
This is a very intersting distinction that we should take into account. 
I am thinking to multiple coas registration / flows filtering here, 
where only one address pair becomes unreachable  (let say CoA1 <-> CN1) 
and not other pairs using CoA1. We need a mechanism to change the 
registered CoA1 with CN1, without modifying other bindings related to 
CoA1. This is one more reason why it would be useful to be able to 
independantly manage CN/flows.

Nicolas

---

From: Nicolas Montavont <[email-masked]>
Date: Fri, 22 Jul 2005 10:12:46 -0400

Nicolas

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 22 Jul 2005 16:41:19 +0200

> This is a very intersting distinction that we should take into 
> account. I am thinking to multiple coas registration / flows filtering 
> here, where only one address pair becomes unreachable  (let say CoA1 
> <-> CN1) and not other pairs using CoA1. We need a mechanism to change 
> the registered CoA1 with CN1, without modifying other bindings related 
> to CoA1. This is one more reason why it would be useful to be able to 

since you find it interesting, i will move to ascii art to put a simple 
example of a situation where this could happen

I will only consider CoAs, now.
Suppose that you have a given visited network, which is multihomed to 
ISPA and ISPB, and each one of the ISPs has delegated a prefix i.e. 
PrefA and PrefB

The MN arrives to the visited network and configures one CoA from each 
prefix, let's say PrefA:MN and PrefB:MN

The situation then is:

        +---------------------+
        | Rest of the Internet|---------|
        +---------------------+         |
          |                 |          +----+
       +-----+          +-------+      | CN2|
       |ISPA |          | ISPB  |--|   +----+
       +-----+          +-------+  |
          |                 |     +----+
        +---------------------+   | CN1| PrefB:CN1
        | Visited Network     |   +----+
        |    PrefA    PrefB   |
        +---------------------+
                |
             +-----+
             |  MN | CoA1: PrefA:MN
             +-----+ CoA2: PrefB:MN

Now consider the case where the link between ISPB and the rest of the 
internet fails
Which addresses does MN has to use in order to maintain a communication 
with CN1? and with CN2?

With CN1, the only path available between CN1 and the MN is through 
ISPB, so the MN must use PrefB:MN as CoA for this communication
With CN2, the only path available between CN2 and the MN is through 
ISPA, so the MN must use PrefA:MN as CoA for this communication

(this is site multihoming example adapted to mobile host multihoming, 
sorry for that, but there maybe better examples that express this 
situation in a more relevant fashion for this case)

Regards, marcelo

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 22 Jul 2005 16:41:19 +0200

The situation then is:

        +---------------------+

Regards, marcelo

---

From: Nicolas Montavont <[email-masked]>
Date: Fri, 22 Jul 2005 11:00:05 -0400

Marcelo,

This is the issues list of your review.

>>> we must be able to identify failures in currently used paths in 
>>> order to rehome the communication to an alternative path
>>
>>
> For instance, consider a failure in the ISP of the home network. If 
> you have multiple HoAs you can overcome this by using a different HoA, 
> but for that you need to detect it and such detection is not about 

Agree with you. We need to extend the scope of the issue not to restrict 
ourselves to media detection.

>> Let me check if I understand your point: you mean path selection 
>> after an outage?
>
>

Ok so this can be viewed as path establishment / maintenance.

>>> select which one to use to rehome the communication. this is not 
>>> done only with RFC3484
>>
>>

Ok, I see. So this would be a new issue, sometinhg like path selection 
after failure, or path recovery.

>
>>>
>>> - Rehoming: after we decided we will use an alternative path, we 
>>> need to actually move the communication to an alternative path, 
>>> which may require some signaling
>>
>>

Ok so we can do is to split the flow redirection issue into failure 
detection, path exploration, path recovery and re-homing, something like 
that.

>>> an outage has occurred, some of the available addresses are no 
>>> longer working, so in order to initiate new communications it is 
>>> likely that several addresses need to be retried, in particular 
>>> source addresses. Such behaviour is not currently supported by 
>>> RFC3484 and additional mechanisms are needed
>>
>>

But if after an outage, we perform path exploration and then run path 
selection, isn't that ok? I mean, we don't need another issue for that I 
guess, it is just to put together others issues, or am I missing something?

Nicolas

>
>>>
>>> Note that these issues and some other issues included in this 
>>> section (like ingress filtering) are also being considered in the 
>>> shim design, so probably the mechanisms designed there will be 
>>> useful here, with minor modifications (i hope)
>>
>>

---

From: Nicolas Montavont <[email-masked]>
Date: Fri, 22 Jul 2005 11:00:05 -0400

Marcelo,

Nicolas

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 22 Jul 2005 17:18:20 +0200

El 22/07/2005, a las 17:00, Nicolas Montavont escribió:
> detection, path exploration, path recovery and re-homing, something 
> like that.
>

well you can split preserving established communications in failure 
detection, path exploration, path selection, and rehoming... i am not 
sure how to handle the other issues that you wanted to include within 
flow redirection, like redirecting a flow because of preferences 
issues... i guess we could extend some of those concepts to this too

>>
>>>>
>>>> - Address selection for initiating communication after outages: 
>>>> When an outage has occurred, some of the available addresses are no 
> selection, isn't that ok?

right, see above

regards, marcelo

>  I mean, we don't need another issue for that I guess, it is just to 
> put together others issues, or am I missing something?
>
> Nicolas
>
>>
>>>>

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 26 Jul 2005 22:54:35 +0900

Hi Marcelo

At Fri, 22 Jul 2005 16:41:19 +0200,
> prefix, let's say PrefA:MN and PrefB:MN

I think PrefB:MN can be selected according to the same mechanism of
IPv6 source address selection. (i.e. by Address longest match).

> ISPA, so the MN must use PrefA:MN as CoA for this communication

It depens on where the HA is located, but..
When the MN attempts to use PrefB:MN, it fails to send CoTI/HoTI and will
not receive CoT/HoT.  Therefore, it will give up using PrefB:MN and will
pick up PrefA:MN. right?

So is there any possible issue here?

regards,
ryuji

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 26 Jul 2005 16:11:49 +0200

Hi Ryuiji,

very good points, some comments below

> IPv6 source address selection. (i.e. by Address longest match).

right

> It depens on where the HA is located, but..

right

> not receive CoT/HoT.  Therefore, it will give up using PrefB:MN and 

ok, this is interesting, since the HoTI/HoT CoTI/CoT message could in 
fact be used, as you mention, as a mechanism to explore paths

> So is there any possible issue here?

i don't know, but maybe it is worth exploring a bit further...
The point in this scenario is that you need to use different CoAs to 
communicate with different CN.

I mean, only the following combination of address work:
- PrefB:MN, CN1
- PrefA:MN, CN2

The other two combinations, i.e. PrefA:MN, CN1 and PrefB:MN, CN2 don't 
work

So, when the MN is in RO mode, it would need to use different CoAs with 
different CNs, which i am not sure it is supported...
in particular, which CoA will the MN register in the HA in this 
scenario?
I guess that only one CoA will be reachable from the HA, depending 
whether the HA is in ISPB or somewhere else.
But in any case, maybe more inteligence in the CoA selection may be 
needed for this case...

Regards, marcelo

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 26 Jul 2005 23:19:55 +0900

Hello Marcelo

At Tue, 26 Jul 2005 16:11:49 +0200,
> communicate with different CN.

OK.

> in particular, which CoA will the MN register in the HA in this 

To send CoTI for both PrefA:MN and PrefB:MN, the MN must register the
CoAs to HA (i.e. MCoA). The MN may stop using RO mode and sends
packets through its HA.

> whether the HA is in ISPB or somewhere else.

right. However, the MN will know the destination unreachable by
receiving ICMP error messages.  Then, the MN should use different HA
(i.e. HoA) for the unreachable destination.

> But in any case, maybe more inteligence in the CoA selection may be 

If we need to consdider the case where HA lost reachability to a
destination, we have to consider a nice HoA selection mechanism. But i
think it can be achieved by MN receiving ICMP error messages.

ryuji

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 26 Jul 2005 17:29:07 +0200

El 26/07/2005, a las 16:19, Ryuji Wakikawa escribió:
> destination,

ok, this is another good point that is that the MN through one of its 
CoAs can reach the CN but the HA cannot.

>  we have to consider a nice HoA selection mechanism. But i

First of all, imho having a fault tolernace mechanism (such as a 
multihoming mechanism) based on ICMP unreachable mechanism seems not a 
good idea (AFAIK, relying in ICMP has been discarded in MIPv6 design 
and in multi6 design, becuase ISMP are filtered too often to rely on 
them)

So i would not count on ICMPs
I would use them as hints, but i wouldn't asume that they will be there 
and base the mechanism on it.

Second, i guess we need to explore the different scenarios in more 
detail but at least, i would like to know if we agree that the 
reachability property is related to an address pair, an not to a given 
HoA or CoA.

I mean, it is not good to say, "ok, i will use this CoA because it it 
reachable", but what would be more appropriate would be to say "this 
CoA is reachable from this particular CN address" and maybe for a 
different CN, a different CoA is needed.

The idea is to talk about working address pairs, rather than a 
reachable address

Is this good?

regards, marcelo

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 27 Jul 2005 19:03:12 +0900

Hi Marcelo

On 2005/07/27, at 0:29, marcelo bagnulo braun wrote:

>>>> When the MN attempts to use PrefB:MN, it fails to send CoTI/HoTI  
>>>> and
>>>> will
> ok, this is another good point that is that the MN through one of  
> its CoAs can reach the CN but the HA cannot.

Yes. But I am not sure if it is worth to see this problem.

> multihoming mechanism) based on ICMP unreachable mechanism seems  
> not a good idea (AFAIK, relying in ICMP has been discarded in MIPv6  
> design and in multi6 design, becuase ISMP are filtered too often to  
> rely on them)

Right, at least MN can have some notification from networks such as  
ICMP error messages, no response from the destination, etc.
If we can assume RO, HoTI will not be delivered to the destination  
due to HA reachability lost. That's another choice.

> I would use them as hints, but i wouldn't asume that they will be  
> there and base the mechanism on it.

yes, these are hints.

> reachability property is related to an address pair, an not to a  
> given HoA or CoA.

> I mean, it is not good to say, "ok, i will use this CoA because it  
> it reachable", but what would be more appropriate would be to say  
> "this CoA is reachable from this particular CN address" and maybe  
> for a different CN, a different CoA is needed.

This shouldn't be happened in the Internet.

If we consider such scenarios., there are more complicated case.
Ex. CoA-x is reachable for the traffic using port-xxx, but CoA-y is  
not due to port filtering.

> The idea is to talk about working address pairs, rather than a  

You want to use  reachability to the destination as a selection  
parameter?
IMO, from end nodes, the reachability to a destination should be assumed
if the end node has connectivity to the Internet.

ryuji

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 27 Jul 2005 20:46:18 +0200

....
> This shouldn't be happened in the Internet.

well, i guess failures shouldn't occur, but they do :-)

I mean, i think that outages may affect connectivty and because of 
using PA addresses in multihomed environments, the result is the 
situation expressed above, where certain locations are reachable using 
a given source address but when using others...

> not due to port filtering.

right, we are currently disucssing this specific issue in shim

moreover, in the shim design, we are considering also the possibility 
of one way failure, resulting in one way connectivity (in other words, 
we are not assumning bidirectional connectivity) (the cause for this 
may be for instance ingress filtering)

bottom line is: we are desingning a fault tolerance mechanism, so we 
should support most failure modes

> You want to use  reachability to the destination as a selection 

well, my point is that different source addresses may need to be used 
to reach different destinations

> if the end node has connectivity to the Internet.

not if you are designing a fault tolerance mechanism imho

i mean the point of fault tolerance should be to provide a protection 
domain as big as possible

regards, marcelo