Subject: RE: [Monami6] Do we need to update the Monami6 charter ?

From: "BINET David RD-CORE-CAE" <[email-masked]>
Date: Tue, 2 Aug 2005 14:53:34 +0200

Hello, 

Comment inline
> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de marcelo 
> bagnulo braun
> Envoyé : jeudi 28 juillet 2005 21:58
> À : Monami6 BOF proposal
> Objet : Re: [Monami6] Do we need to update the Monami6 charter ?
> 
> 
> El 27/07/2005, a las 23:54, Nicolas Montavont escribió:
> 
> > marcelo bagnulo braun wrote:
> >
> >> As i said in another message, imho the monami work should 
> be aimed to 
> >> solve the mip host multihoming problem, as described in 
> the problem 
> >> statement draft, and should not limit itself to 
> registering multiple 
> >> CoAs
> 
> > This is definitly not what we want to do.
> >
> 
> well, if you read the proposed charter, it states that:
> 
> The expected output of the WG is:
> 
> A document explaining the needs for and the design goals of 
> multihoming [Informational] An analysis document of 
> multihoming under the operation of Mobile IPv6 
> [Informational] A solution to register multiple care-of 
> addresses for a given home address [Standard Track] A 
> solution to exchange policies between the parties involved in 
> the mobility management (presumably the mobile node/mobile 
> router, the home agent and possibly the correspondent nodes 
> in case of Routing
> Optimization) [Standard Track]

Do the policies exchanged between parties concern only Routing Optimization or can we imagine that such policies could be used for other means such as selection of CoA for example. We can imagine that in multihoming situation, it could be convenient to try to set up some means to prioritize use of a specific CoA according to some trafic engineering process or for some quality of service reason. In this case, some exchanges between MR or MN and HA could be useful. 
I am not sure such item has to be addressed by this next working group (I hope it will be !)

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

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

---

From: Chan-Wah NG <[email-masked]>
Date: Tue, 02 Aug 2005 21:09:36 +0800

Hello David,

On Tue, 2005-08-02 at 14:53 +0200, BINET David RD-CORE-CAE wrote:
> Do the policies exchanged between parties concern only Routing Optimization or can we imagine that such policies could be used for other means such as selection of CoA for example. 

Actually, the reason why the term "Route Optimization" appears is
because that is the only situation where CN would be informed of the
CoAs in the MN.

> We can imagine that in multihoming situation, it could be convenient to try to set up some means to prioritize use of a specific CoA according to some trafic engineering process or for some quality of service reason. In this case, some exchanges between MR or MN and HA could be useful. 

I tend to agree.  I personally think that the use of such mechanism for
purposes rather than to influence the selection of CoAs is out of scope.
I mean, other WGs are defining such mechnaism at the same time.  For
instance, I believe that NSIS is also looking at the signaling of path
perference to influence the choice of NSIS path.

/rgds
/cwng

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 3 Aug 2005 00:06:40 +0900

In order to clarify, shall we rephrase the text to:

 "A solution to exchange policies influencing the choice of the
interface between the parties involved in the mobility management
(presumably the mobile node/mobile router, the home agent and possibly
the correspondent nodes when routing optimization is performed) 
[Standard Track]"

i.e. 2 changes:
- clarifying that the policies are to influence the choice of the
interface
- wrote "when RO is performed" instead of "in case of RO")

On Tue, 02 Aug 2005 21:09:36 +0800
Chan-Wah NG <[email-masked]> wrote:

> > Do the policies exchanged between parties concern only Routing
> > Optimization or can we imagine that such policies could be used for
> > other means such as selection of CoA for example. 
> 
> > We can imagine that in multihoming situation, it could be convenient
> > to try to set up some means to prioritize use of a specific CoA
> > according to some trafic engineering process or for some quality of
> > service reason. In this case, some exchanges between MR or MN and HA
> > could be useful. I am not sure such item has to be addressed by this
> > next working group (I hope it will be !)
> > 
> 
> I tend to agree.  I personally think that the use of such mechanism
> for purposes rather than to influence the selection of CoAs is out of
> scope. I mean, other WGs are defining such mechnaism at the same time.
>  For

-- 
Thierry Ernst, PhD
WIDE, Jun Murai Lab., Keio University, Japan
Nautilus6 Chair: http://www.nautilus6.org
Web: http://www.sfc.wide.ad.jp/~ernst/
T:+81-44-580-1600 F:+81-44-580-1437
--

---

From: Nicolas Montavont <[email-masked]>
Date: Tue, 02 Aug 2005 17:14:24 -0400

Hi,

>perference to influence the choice of NSIS path.
Chan-Wah, I am not sure I get your point. Actually it is our intend to 
propose a solution to extend BU with flow identification options (see 
soliman-flow-move, nomadv6 or HA-filtering). It is not the policy that 
we want to push, but rather how preferences can be transported with 
CoAs. I think this is something on what we want to work in Monami6. It 
would be very useful that the mobile device (MN, MR) could be able to 
set up priorities on distant nodes.

Nicolas

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 2 Aug 2005 17:28:48 +0200

Hi Thierry,

>  "A solution to exchange policies influencing the choice of the

I am not sure about this...
selecting interfaces may be quite different from selecting addresses.

I mean, in a case where the multihomed node has a single interface, but 
multiple global HoAs/Coas, then this solution wouldn't apply?

Regards, marcelo

>  between the parties involved in the mobility management

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 3 Aug 2005 00:35:04 +0900

> I mean, in a case where the multihomed node has a single interface,
> but multiple global HoAs/Coas, then this solution wouldn't apply?

I'm not sure I get you here: our purpose is to address the case where we
have a MN/MR has multiple interfaces and wants to use them
simultaneously.

Thierry.

---

From: Chan-Wah NG <[email-masked]>
Date: Tue, 02 Aug 2005 23:41:02 +0800

Hello all,

On Tue, 2005-08-02 at 17:14 -0400, Nicolas Montavont wrote:

<headers snipped>

> set up priorities on distant nodes.

Okay, either I am not expressing myself well, or I misread David's
comments ... likely both.  Let me try again.

There is multiple ways one can influence address selections.  One can
use a separate protocol just to do that, or integrate it into the
signalling of the address bindings.  If a separate protocol is used,
then its IMHO a re-invention of the wheel, and should be out-of-scope
IMHO.  

OTOH, if the preference is transferred along with the BU, then we are
pretty much limited to conveying the preference/priority of the CoA, and
this I think is in-scope.  However, from what I read from David's
comments, if this preference conveyance is also to be used to influence
other mechanism such as QoS Policy,  then I think its a bit too
ambitious, and frankly, such functionality is better provided with NSIS
running on top of MIP6 than trying to do it all in the BU.

I am definitely supportive of incorporating mechanisms for signaling
preference settings on the CoAs into multiple CoAs registration.  This
is, IMHO, one area which I feel draft-wakikawa is lacking (or not
extensive enough).

/rgds
/cwng

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 2 Aug 2005 17:54:08 +0200

> have a MN/MR has multiple interfaces and wants to use them

i thought that you also wanted to consider the case when the MN/MR has 
multiple CoAs/HoAs and want to use them simoultaneously, and you wanted 
to provide a tool to define policy about how to use them

i mean, perhaps the different addresses have different features, in 
terms of security, congestion, cost and so on.

Regards, marcelo

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 3 Aug 2005 01:05:59 +0900

> >> selecting interfaces may be quite different from selecting
> >addresses.>
> multiple CoAs/HoAs and want to use them simoultaneously, and you
> wanted to provide a tool to define policy about how to use them
> 

Yes, but when the MN/MR has multiple interfaces (with the result of
having multiple CoA and possibly HoAs).

Thierry

---

From: Nicolas Montavont <[email-masked]>
Date: Tue, 02 Aug 2005 18:07:17 -0400

Agree with you Marcelo, I think we should let addresses instead of 
interfaces. The priority will be made on the addresses, not on the 
interface. (remark that the address that the MN will select may depend 
on the corresponding interface, but I think we agree that we won't 
investigate selection criteria here)

Nicolas

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 2 Aug 2005 18:25:24 +0200

> having multiple CoA and possibly HoAs).

agree that this happens when there are multiple interfaces, but my 
point is that it may also happen when there are multiple address and a 
single interface, and that policing may be useful in that situation 
also

regards, marcelo

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 3 Aug 2005 01:46:19 +0900

Hold on, this is not what the charter says, so if this is something you
really want to do, we first have to fix the charter.

But, I would like to point that our purpose is not to solve all possible
multihoming configurations. I would rather concentrate on the case where
the MN has multiple interfaces because that is the configuration where
the solution is needed.

Thierry.

 On Tue, 02 Aug 2005 18:07:17 -0400
Nicolas Montavont <[email-masked]> wrote:

> >addresses.>>
> >>> I mean, in a case where the multihomed node has a single
> >interface,>> but multiple global HoAs/Coas, then this solution
> >wouldn't apply?>
> >>
> >> I'm not sure I get you here: our purpose is to address the case
> >where we> have a MN/MR has multiple interfaces and wants to use them
> >> simultaneously.
> >>
> >
> > i thought that you also wanted to consider the case when the MN/MR
> > has multiple CoAs/HoAs and want to use them simoultaneously, and you

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Wed, 3 Aug 2005 09:42:10 +0200

Hi 

Charter says abt only the case where MN has multiple interfaces as
Thierry pointed. When the MN has a single interface with multiple
addresses, why don't we consider that too (as pointed by Marcelo &
Nicoals). 

I aggreed with Nicolas that we should not add the selection of an
address based on policies. This is again a different topic.  

Koojana

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Thierry Ernst
>Sent: Tuesday, August 02, 2005 6:46 PM
>To: Monami6 BOF proposal
>Subject: Re: [Monami6] Do we need to update the Monami6 charter ?
>
>
>
>Hold on, this is not what the charter says, so if this is 
>something you really want to do, we first have to fix the charter.
>
>But, I would like to point that our purpose is not to solve 
>all possible multihoming configurations. I would rather 
>concentrate on the case where the MN has multiple interfaces 
>because that is the configuration where the solution is needed.
>
>Thierry.
>
>
>
>> >> [email-masked] https://www1.ietf.org/mailman/listinfo/monami6
>> >>
>> >
>> >
>> > [email-masked] https://www1.ietf.org/mailman/listinfo/monami6
>> >
>> 
>> 
>> 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/monami6
>
>
>-- 
>Thierry Ernst, PhD

---

From: Chan-Wah NG <[email-masked]>
Date: Wed, 03 Aug 2005 16:00:27 +0800

> address based on policies. This is again a different topic.  

I have personally drafted the words "Where the effects of having
multiple prefixes on a single interface is identical to the effects of
having multiple interfaces each with a single prefix, Monami6 may
consider a generalized approach to cater for multiple prefixes available
to a mobile node as well" into the draft charter.

So, I see no conflict in Thierry's wording of "multiple interfaces", and
marcelo's and koojana's concern of multiple addresses on a single
interface.

The interpretation of this is that we will look at any problem with the
basic prespective that the MN has multiple interfaces.   If one can show
that multiple addresses on a single link can be equivalent transformed
to the case of multiple "virtual" links so to speak, then it applies as
well.  There are technical and non-technical reasons why we would want
to solve things this way, main of which are (1) multiple prefixes on a
single link has more subtle complexity, and (2) to keep the separation
from Shim6 clear.

I would go with Thierry's wordings, at the same time assure marcelo that
most of our investigative work would equivalently apply to simpler
mutliple-addresses-on-a-single-link cases.  this will allow us to focus
on the main problem, and avoid venturing into the more complicated path
selection preference problems of mutliple exit routers etc which are
already being investigated in Shim6.

/rgds
/cwng

-- 
Chan-Wah NG <[email-masked]>
Panasonic Singapore Labs

---

From: Ryuji Wakikawa <[email-masked]>
Date: Wed, 03 Aug 2005 17:40:20 +0900

The big difference between multiple interfaces and multiple addresses
(at single IF) is what kind of policy we can use for.  In the multiple
interfaces case, we simply use interface characteristics as a
policy. I mean if there are W-CDMA and WiFi, throughput, delay and
battery cost are all different.

However there are multiple addresses, MN has to survey network
environment of each address whether AR is active, busy, failed,
etc. This issue is already addressed at other WG such as shim. (right marcelo?) 
If addresses are HoAs, MN/R must know whether HA is active,
overloaded, etc. This is addressed by the HAHA protocol.

To avoid conflicts, we should work on multiple interfaces at the
beginning of monami, and may look at multiple addresses later. Since
there is no technical difference other than the selection policy, I
prefer Thierry's description.

ryuji

At Tue, 2 Aug 2005 18:25:24 +0200,
marcelo bagnulo braun wrote:
> >>> where we

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 03 Aug 2005 05:49:07 -0700

> battery cost are all different.

Yes, but the issue of which CoA is working or not, the node has to rely 
on sending packets that test whether things are working, unless you only 
want to worry about the class of failures when the interface is dead. 
(You could have failures upstream in e.g. the WiFi providers network 
that you want to be able to detect so you can switch over.)

> etc. This issue is already addressed at other WG such as shim. (right marcelo?) 

If there are multiple CoAs, due to there being multiple prefixes on the 
same interface, then in terms of knowing whether a given CoA is usable 
it is exactly the same problem as for the multiple interface case; you 
need to use packets as an indication whether or not packets get through.

Thus if what we care about primarily is reliability/availability, then 
the two cases look almost identical.

If we also care about other qualities (bandwidth, cost, etc), then in 
the multiple interfaces the mobile node might have some specific local 
knowledge (bandwidth and cost of using WiFi vs. GRPS for example) that 
help in certain cases, but not in other cases (for example, a host with 
two WiFi interfaces attached to different providers for redundancy would 
know less).

As the two WiFi example shows, if you care about non-local qualities 
(e.g., congestion upstream) you need to try to measure those qualities.
That doesn't mean that the local WiFi/GPRS distinction isn't useful; it 
just means its applicability is a bit limited.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 03 Aug 2005 05:57:01 -0700

> Yes, but the issue of which CoA is working or not, the node has to rely 

"Yes. but *if* the issue is whether a CoA is working or not .." might be 
a bit more comprehensible.

   Erik