Subject: RE: [Monami6] new revised charter

From: "BINET David RD-CORE-CAE" <[email-masked]>
Date: Mon, 12 Sep 2005 14:43:09 +0200

> 
> 
> El 12/09/2005, a las 7:48, Thierry Ernst escribió:
> 
> >
> > Hi Marcelo, everyone,
> >
> > On Sat, 10 Sep 2005 12:00:46 +0200
> > marcelo bagnulo braun <[email-masked]> wrote:
> >> i think that this new charter is much clear with respect 
> to the scope 
> >> of the work.
> >
> > Thanks. We hope so ! ;-)
> >
> >> 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.
> >
> > This is an interesting comment, and so far we failed to discuss if 
> > this should be in scope or not.
Do we want to consider only "fault tolerance" or do we want to consider larger scope and consider for example "selection of best path" according to some policies or to some link-parameters ? 
I think such consideration (fault tolerance) can lead to open the charter on policy decisions. 
> >
> 
> 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..)
> 
> >> - 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?
> >
> > Not, the 1st 2 deliverables are Informational documents, not the 
> > solutions (items 3 and 4).
> >
> >> 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]
> >
> > There is a missunderstanding here.
> >
> > 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.
I agree with Marcelo. Such Monami working group will multiaddressing solutions in mobility (MIP and Nemo)context. So, I think that the first document has to consider mobility context or there will can lead to some mismatch between needs and solutions.
But, maybe there is surely some need for a generic document on multiaddressing but Monami is maybe not the best place for it since it concerns a broader scope than "mobility context" 
> Regards, marcelo
Regards 
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

---

From: Nicolas Montavont <[email-masked]>
Date: Mon, 12 Sep 2005 08:54:46 -0400

[ . . . ]

>>take to support this (maybe it is easy to do this..)
The support of fault tolerance we have now in the charter is the support 
of multiple CoAs: you can establish multiple tunnels with your HA(s) and 
when one fails, you can use another one.

However, work on failure detection will be certainly limited. We might 
rely on BU/BACK exchange and some local information to detect a failure. 
We are working now on a paragraph that explains this point. Here is the 
current text (still under revision):

"The WG will not work on tunnel selection based on dynamic discovery of
tunnel characteristics, but will assume that it is given by policy or
other mechanisms external to the Monami6 work. In particular, the WG
will consider that a tunnel is alive as long as BU/BACK can be exchanged
with the corresponding peer. In addition, local information, such as an
interface went down, can be used to quickly detect failure of
tunnel(s)."

Nicolas

---

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

Hi Nocolas,
El 12/09/2005, a las 14:54, Nicolas Montavont escribió:

> [ . . . ]
>
>> Do we want to consider only "fault tolerance" or do we want to 
>> consider larger scope and consider for example "selection of best 
>> path" according to some policies or to some link-parameters ? I think 
>> such consideration (fault tolerance) can lead to open the charter on 
>> policy decisions.
>>> 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..)
>>>
> The support of fault tolerance we have now in the charter is the 
> support of multiple CoAs: you can establish multiple tunnels with your 
> HA(s) and when one fails, you can use another one.
>
> rely on BU/BACK exchange and some local information to detect a 
> failure. We are working now on a paragraph that explains this point. 
> Here is the current text (still under revision):
>

i am not sure this would provide what we need... i mean in terms of 
frequency for instance.
I would suggest to leave it open to different mechanisms for detecting 
outages and that we discuss it in the working group (i mean, we should 
have something to discuss in the working group if created, right? :-)

---

From: Nicolas Montavont <[email-masked]>
Date: Mon, 12 Sep 2005 09:26:53 -0400

Marcelo,

marcelo bagnulo braun wrote:

>>> path" according to some policies or to some link-parameters ? I 
>>> think such consideration (fault tolerance) can lead to open the 
>>> charter on policy decisions.
>>>
>> support of multiple CoAs: you can establish multiple tunnels with 
>> your HA(s) and when one fails, you can use another one.
>>
>> However, work on failure detection will be certainly limited. We 
>> might rely on BU/BACK exchange and some local information to detect a 

actually it depends: you can trigger a BU/BACK exchange to make sure a 
tunnel is still alive, when it is needed.

> have something to discuss in the working group if created, right? :-)

You're right, but I think we don't need to write in the charter what we 
are going to discuss. I mean, the charter is dedicated to provide the 
purpose of a WG, and to list documents that will be produced. It doesn't 
prevent to explore new issues if the community feels so.

About the assessment of tunnel liveness, our thought was to state in the 
charter that we won't work on a specific mechanism to check the liveness 
of tunnel (other than BU/BACK exchange and use of local information). 
But if the need is felt, we can still work on this later, if we 
re-charter (note that this work can also be done in another place, 
because this is a very generic problem)

Nicolas

---

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

El 12/09/2005, a las 15:26, Nicolas Montavont escribió:
>> I would suggest to leave it open to different mechanisms for 
>> detecting outages and that we discuss it in the working group (i 
>> mean, we should have something to discuss in the working group if 
>> created, right? :-)
>
> You're right, but I think we don't need to write in the charter what 
> we are going to discuss. I mean, the charter is dedicated to provide 
> the purpose of a WG, and to list documents that will be produced. It 
> doesn't prevent to explore new issues if the community feels so.
>
> About the assessment of tunnel liveness, our thought was to state in 
> the charter that we won't work on a specific mechanism to check the 
> liveness of tunnel (other than BU/BACK exchange and use of local 
> information). But if the need is felt, we can still work on this 
> later, if we re-charter (note that this work can also be done in 
> another place, because this is a very generic problem)
>

well, as i stated before, imho fault tolerance is an important part of 
the support of multiple tunnels, in particular the capability of 
detecting outages and selecting the tunnel that is working. In addition 
i think is within the scope of the proposed work, i.e. the support of 
multiple CoAs and multiple HA addresses, i.e. if you want to support 
multiple CoAs you should try to provide the fault toleracen features 
that they enable.

I guess we should hear what other folks think about this point.

Regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 12 Sep 2005 11:45:27 -0700

> tunnel is still alive, when it is needed.

But a BU/Back would be a bit inefficient, since it entails a bunch of 
security processing, followed by an attempt on the HA to change the 
binding (even though the CoA is the same).

Sending an ICMP echo (or something similar) would be a lot less work at 
both ends.

My point is that *if* the WG is going to work on a liveness test 
protocol, it shouldn't constrain itself to the solution being frequent 
BU/Back exchanges.

    Erik

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Tue, 13 Sep 2005 09:22:33 +0200

Hi Marcelo
>I guess we should hear what other folks think about this point.

I need to clarify onething-> If you talk abt failure detection ->

"Failure detection" could also be addressed w.r.t different issues.

Reminding the discussion people had during the BOF,
If it relates to ISP  -> this should be addressed in shim6, or if it's
relate to SCTP with multiple tunnels, it's handled by SCTP itself.

I don't know whether we should again mention "Failure detection" in
monami6 charter. 

Regards, koojana

---

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

> HA(s) and when one fails, you can use another one.

Right.

> interface went down, can be used to quickly detect failure of

I like this general direction. There's other ongoing work in the
IETF to look a the failure detection area, and I think it would
be better if monami6 restricted itself to "local detection" as
outlined above. Maybe later, when we learn more about
what those other attemps have gotten we can return to
a more general approach. (For instance, where IPsec is
used between the mobile node and home agent, it is
possible that mechanisms similar to those used in IKE
DPD could be used.)

Nit: s/interface went down/interface up/down events/

--Jari