Subject: [Monami6] new revised charter

From: Nicolas Montavont <[email-masked]>
Date: Fri, 09 Sep 2005 14:54:35 -0400

Folks,

We are working on a new revision of the charter, which will be reviewed 
by the IESG next week. You can find it at:

http://www.nautilus6.org/ietf/monami6-charter.txt

It is still under revision, but if you have any comments on this current 
version, please go ahead.

Thierry and Nicolas

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

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 10 Sep 2005 12:00:46 +0200

Hi,

i think that this new charter is much clear with respect to the scope 
of the work.

Just two comments/questions:

- Is the provision of fault tolerance for the HA-MR tunnel in the scope 
of the proposed work? I mean, the charter says that the goal is to 
support multiple tunnels between different Home Agent addresses and 
different CoAs, does this support includes the support for fault 
tolerance? i.e. if one tunnels fails, try to use an alternative one. In 
case this is within the scope, perhaps it would be good to explicitly 
mention it in the charter.

- According to the proposed scope of the work, the first deliverable, 
should deal with multiple CoAs in MR and mobile hosts, rather than with 
multiple global addresses, rigth?

I mean currently it is stated that:

- A document explaining the needs and the design goals for mobile
   hosts and mobile routers using multiple global addresses on its
   interface(s). [Informational]

In order to scope of the proposed, I would suggest to rephrase it to:

- A document explaining the needs and the design goals for mobile
   hosts and mobile routers using multiple Care-Off addresses on its
   interface(s). [Informational]

Thanks, marcelo

El 09/09/2005, a las 20:54, Nicolas Montavont escribió:

> Folks,
>
> We are working on a new revision of the charter, which will be 
> reviewed by the IESG next week. You can find it at:
>
> It is still under revision, but if you have any comments on this 
> current version, please go ahead.
>
> Thierry and Nicolas
>

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 12 Sep 2005 14:48:59 +0900

Hi Marcelo, everyone,

On Sat, 10 Sep 2005 12:00:46 +0200
> i think that this new charter is much clear with respect to the scope 

Thanks. We hope so ! ;-)

> - Is the provision of fault tolerance for the HA-MR tunnel in the
> scope of the proposed work? I mean, the charter says that the goal is
> to support multiple tunnels between different Home Agent addresses and
> tolerance? i.e. if one tunnels fails, try to use an alternative one.
> In case this is within the scope, perhaps it would be good to
> explicitly mention it in the charter.

This is an interesting comment, and so far we failed to discuss
if this should be in scope or not.

> should deal with multiple CoAs in MR and mobile hosts, rather than
> with multiple global addresses, rigth?

Not, the 1st 2 deliverables are Informational documents, not the
solutions (items 3 and 4).

>    interface(s). [Informational]

There is a missunderstanding here. 

This document is not about the goals and motivations of monami6, but
about the motivations and goals for having multiple addresses
(particularly when multiple interfaces are used). 

The current existing document (i.e draft-ernst-generic) is dealing with
the topic from a more abstract level: it doen't cover the topic from the
point of view of MIPv6, it doens't even cover the topic from a sole
mobility point of view. The need for multiple interfaces used
simulateneously is universal, for any kind of nodes, fixed or mobile,
using MIP6, NEMO, HIP, Shim or whatever,.

Our intention is to keep this document general so that it could be
used and applied for further work in this area. 

But this message seems difficult to convey, particularly given the
constraints we have in using words which may be understood in a specific
way, different from our intentions. 

Thierry

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 12 Sep 2005 10:49:12 +0200

> if this should be in scope or not.

imho this is an important part of the support of multiple CoAs, and it 
would be good to at least consider what would it take to support this 
(maybe it is easy to do this..)

> This document is not about the goals and motivations of monami6,

but this is what you really need to do, right? i mean a document 
explaining the goals and the motivations of the work that you are going 
to do in this working group.

I mean, one one hand, i guess that a generic document it is something 
that may be useful, but i am not really sure it would belong to a 
scoped working like this one and on the other hand, i guess that the 
charter should have to deliver a document with the goals for the work 
being done in this particular working group.

Regards, marcelo

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 12 Sep 2005 20:34:16 +0900

Hi,

> explaining the goals and the motivations of the work that you are
> going to do in this working group.

Well, I'm not sure, this may contradict the charter and wouldn't give
the larger picture.  A vision of what the largest picture is is IMHO
needed.

> being done in this particular working group.

So, if I follow your reasoning, there is no venue at the IETF to produce
such a generic document, which is:
1. a shame
2. is pointing out to the inefficiencies of the IETF
(the IETF is unable to work on complex issues because it is unable to
accept a document being written which may be useful to clarify where a
technology is leading to).

If it cannot be done at the IETF it can be done in a review paper for
some journal, but the impact is not the same and it wouldn't be
perceived as an IETF vision.  Sad.

Thierry

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 12 Sep 2005 15:06:25 +0200

El 12/09/2005, a las 13:34, Thierry Ernst escribió:

> technology is leading to).

i beg to differ.
I think that in the meeting seemed to be some form of consensus to work 
in a much more scoped problem (multiple CoAs support) and that is what 
i guess that the charter should express, which includes the description 
and the motivations of this particular (multiple coAs) problem.

We could work in the more general problem, but my reading of the 
meeting was that where not enough interest at this point in time to 
work on it.

so imho this is not a problem with the inefficiencies of the IETF, is 
just that the community want to work in a more scoped problem, which i 
guess is fine

(note that i argued in the meeting to work in the more general multiple 
address problem, but i guess we need to accept that most folks are 
interested in a more limited work on this area)

Regards, marcelo

---

From: Thierry Ernst <[email-masked]>
Date: Mon, 12 Sep 2005 23:04:49 +0900

Hi,

> > (the IETF is unable to work on complex issues because it is unable
> > to accept a document being written which may be useful to clarify
> > where a technology is leading to).
> >

> i beg to differ.
> I think that in the meeting seemed to be some form of consensus to
> work in a much more scoped problem (multiple CoAs support) and that is
> what i guess that the charter should express, which includes the
> description and the motivations of this particular (multiple coAs)
> problem.
> 

I was not speaking about the solutions, on which there is a consensus,
but about the informational document. The content was not discussed at
the BOF (it was briefly presented, but not "discussed"). I don't think
we need a "motivations and goals" document for the WG, because
"motivations and goals" for the WG are now pretty clear and is
self-contented in the charter which should now be clear about what will
be done (and why). So, it should give a enlarged picture about the
motivations and goals of having multiple simultaneous interfaces and a
multitude of global addresses, i.e. giving hints about why this work is
done in Monami6 and why there will be more work to do in the future to
fully benefit from such a configuration.

> (note that i argued in the meeting to work in the more general
> multiple address problem, but i guess we need to accept that most
> folks are interested in a more limited work on this area)

Exactly, and the charter is limiting the scope of the work.
 
Thierry.

---

From: Jari Arkko <[email-masked]>
Date: Tue, 13 Sep 2005 15:13:54 +0300

Thierry, Marcelo,

>way, different from our intentions. 
I actually tend to agree with Marcelo on this one. I do
see the usefulness of a generic document, but I think
it would serve the group better to focus on its main
task. It might take a lot of effort to get a complete,
high-quality, and agreed-upon document about the
general case (as we have seen in various multi6
documents, for instance). But if you just have the
care-of address problem without generic failure
detection, the WG's task should in fact be quite
easily achievable. And then you could recharter and
work on a more general problem.

In fact, if you look at the charter

>- An analysis document explaining what are the limitations for
>  mobile hosts using multiple simultaneous Care-of Addresses and Home
>  Agent addresses using Mobile IPv6, whether issues are specific to
>  Mobile IPv6 or not [Informational].
>  
>
You may ask that if the first item is made more specific
to care-of addresses, then is there a need for two separate
items any more? But this is related to confusion that
I at least have on what the second item means. Here's
a couple of questions that I have about it:

o  Is this expected to cover Nemo issues too? Presumably
    they are the same, but the wording is strange.
o  What limitations are we talking about? Presumably
    the limitations that exist in the protocol prior to
    monami6 completing, but it doesn't say so. Or
    limitations that the third item in the charter has?
o  There are certain things that you CAN do today
    with mobile IPv6 and multiple interfaces. Is this
    an explanation of that? (Here's what you can do:
    the mobile node/router can do its own policy
    decisions and failure detection and choose to use
    a particular care-of address. Here's what you
    can't do: have the home agent make decisions,
    use multiple flows over different care-of addresses.)
o  Why does it talk about home agent addresses?
    Interestingly, if you compare the four charter items
    you have the following differences:

         needs:  global addresses
         limitations:  care-of addresses and home agent addresses
         solution: care-of addresses
         policy: interfaces

    This troubles me a bit. Wouldn't it make more sense
    to have all three aligned on the care-of address issue,
    or everything else except the needs document aligned
    on that at least?

Anyway, here's my take on how I would adjust the
charter:

- A document explaining the needs and the design
  goals for mobile hosts and mobile routers using
  multiple care-of addresses. [Informational]

- A document explaining how to use existing
  Mobile IPv6 and Nemo protocols with multiple
  potential care-of addresses, and what limitations
  such usage has. [Informational]

- A protocol extension to Mobile IPv6 and Nemo to
  support the registration of multiple Care-of Addresses
  for a given home address [Standard Track].

- A "Flow/binding policies exchange" solution for an
  exchange of policies from the mobile host/router
  to the Home Agent and from the Home Agent to
  the mobile host/router influencing the choice
  of the care-of address [Standard Track].

--Jari

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 13 Sep 2005 15:04:25 +0200

>  of the care-of address [Standard Track].

I agree with these charter items as phrased by Jari.

besides...

I still would like to see some item about the provision of fault 
tolerance capabilities when there are multiple tunnels between the HA 
and the Mobile Node/mobile Router though...

something in the lines of:

- A fault tolerance mechanism that allows to determine if the
currently used tunnel between the HA and the MN/MR is available,
the exploration of alternative tunnels and the capability of
diverting the traffic to available tunnels.

or something in these lines...

regards, marcelo

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 13 Sep 2005 22:42:08 +0900

Hi Jari,

Thanks for your comments, see mine below.

On Tue, 13 Sep 2005 15:13:54 +0300
Jari Arkko <[email-masked]> wrote:

> >The current existing document (i.e draft-ernst-generic) is dealing
> >with the topic from a more abstract level: it doen't cover the topic
> >from the point of view of MIPv6, it doens't even cover the topic from
> >a sole mobility point of view. The need for multiple interfaces used
> >constraints we have in using words which may be understood in a
> >specific way, different from our intentions. 
> >  
> >

I'm not sure we speak about the same thing. There should be no question
whether the WG objectives are achievable or not because the solutions
we would like to produce are limited in scope, as written in the
charter (last 2 deliverables). So, to understand each other, let's put
the"Standard Track" deliverables on the aside.

Regarding the "Informational" documents, producing a problem statement
for the limited part of the problem is counter productive, and at most
un-necessary. 

So, my take would be either to do a proper analysis of the entire
problem scope and limite our actual work on some of the issues (the 2
last deliverables), or to just do the 2 last deliverables, and no
informational documents.

I guess folks would understand better by reading the PB statement and
analysis drafts which already exist (particularly the existing MIP6
analysis, which is already good in shape).

> a couple of questions that I have about it:

Following your thinking, I agree that 2 documents wouldn't be necessary.
But I don't subscribe to this thinking ;-)

>     they are the same, but the wording is strange.

No.

>     limitations that the third item in the charter has?

All limitations taken at large. 

>     an explanation of that? 

This would be pointless IMHO.

>     (Here's what you can do:

OK, agree on the lack of clarity, but it's tricky. At first, we wanted
to use the word "multihoming" but we were criticized that the term is
not currently understood how we want it to be. Then, we tried to itemize
the "multihoming configurations", but either we list all, and it would
take pages and pages, or either we list some.  

This discussion tend to convince me to use the word "multihoming" back
for the informational items, and to be specific for the standard track
solutions.

>   such usage has. [Informational]

Here is where you have it wrong. An analysis is already been
produced by the NEMO WG, and that document is listing **all** the issues
that could happen. Issues are divised according to a taxonomy of all the
potential configurations. There is thus no need to re-do this analysis
in a document considering MIP6 and NEMO, this would be a clear
duplication of effort. 

So, our objective is to produce a similar analysis for MIP6, and the
intention is to list all the issues coming with all the configurations. 

>   for a given home address [Standard Track].

Agree on this one, actually I just noticed that we tried to be
brief to the point we didn't specify this would work for both MIP6 and
NEMO.

>   of the care-of address [Standard Track].

No change, seems we agree on this one.

Thierry

---

From: Jari Arkko <[email-masked]>
Date: Tue, 13 Sep 2005 17:02:45 +0300

Hi Thierry,

>the"Standard Track" deliverables on the aside.
Sure. (But limiting scope of even informational documents
may reduce the amount of work the WG needs to do.)

>This would be pointless IMHO.
Ok. Is this because its obvious, too limited for
actual usage, because people will deploy monami6
full solution anyway, or some other reason?

>for the informational items, and to be specific for the standard track
This is one good way forward. Or at least keeping the
needs document generic.

>in a document considering MIP6 and NEMO, this would be a clear
Ok. If its already done then there's no need to repeat
it. I looked briefly at draft-ietf-nemo-multihoming-issues
and it does a very good job on describing the issues.
I'm not quite sure if it covers everything that I
thought under "using existing protocols" -- but
some of at least is there. Note: even if my classification
above was Informational, I meant this to be more
of an implementable document than an analysis
document. But I see from above that you don't think
its necessary -- lets discuss that.

>brief to the point we didn't specify this would work for both MIP6 and
Ok.

>No change, seems we agree on this one.
There was a small change -- s/interface/care-of address/

--Jari

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 13 Sep 2005 15:01:48 -0700

> o  Why does it talk about home agent addresses?

It's probably my fault ;-)

My point is that the easy to solve problem here includes the cases of 
the MN/MR having multiple CoAs, but also the cases when a single HA has 
multiple addresses. The latter can occur when the HA is 
multi-interfaced, when it has multiple IP address prefixes on the same 
interface (e.g., due to the HA being in a multihomed site), or a 
combination of the two.

If we can solve the multiple CoA, we can also solve the multiple home 
agent address case; they are both part of the same exchange between the 
MR/MN and the HA, and would not impact any other parts.

FWIW I share you concern that having the WG come to consensus on a 
problem statement for the grand unified theory of multiple addresses 
(HoA, CoA, etc.) might be interesting but might also be a distraction 
from producing the standards track documents. This problem space is 
huge, and quickly wanders into the semantics of IP addresses (the 
identifier, locator, and route discussions).
The current drafts in this space appear to only look at things from a 
rather limited perspective and don't touch on other aspects, such as 
operational aspects (why there might be multiple home addresses or 
multiple mobile network prefixes; traffic engineering issues; etc.) The 
implicit assumption seems to be that multiple addresses appear just 
because MN/MR so desires, but multiple addresses might also appear 
because the site (the site of the home agent(s), or the visited site) is 
multihomed. Thus I think the general problem statement of multiple 
addresses (due to multihoming) and how to deal with them, must be a lot 
larger in scope to cover the terrain.
In terms of the WG making progress, it might be wise to limit the 
problem statement and analysis to the part of the problem space that the 
WG is set out to address, and not try to get community consensus on the 
full space. As an example, it took the multi6 WG a few good years to 
come to consensus on a "Goals for IPv6 Site-Multihoming" document, and 
that doesn't touch on host multihoming or mobility.
So I suspect getting community consensus on a larger scope document to 
be even harder.

   Erik

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 14 Sep 2005 00:10:56 +0200

Hi Thierry,

On 2005-09-13 15:42 Thierry Ernst said the following:

[...]
> for the informational items, and to be specific for the standard track

That brings back the potential overlap with shim6.  I think that if you
are clear about the focus through the surrounding wording, you could use
'multihoming', but I still believe that although *you* will know exactly
what you mean when you use that word, a lot of other people will have
quite different interpretations of what it means in this connection.

This is based on my observation of the BOF discussion, and I could be
wrong.

	Henrik

---

From: Jari Arkko <[email-masked]>
Date: Wed, 14 Sep 2005 13:36:49 +0300

Erik Nordmark wrote:

> the MN/MR having multiple CoAs, but also the cases when a single HA 
> has multiple addresses. The latter can occur when the HA is 
> agent address case; they are both part of the same exchange between 
> the MR/MN and the HA, and would not impact any other parts.

Ah. Ok. Would the home agent address issue be covered just in the
Informational document, or also in the solution and flow drafts?

--Jari

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 14 Sep 2005 06:57:27 -0700

> Informational document, or also in the solution and flow drafts?

I think it would make sense to cover it across all three.

     Erik