Subject: [Monami6] Is a terminology needed

From: Nicolas Montavont <[email-masked]>
Date: Tue, 12 Jul 2005 18:01:16 -0400

Folks,

I was updating our draft MMI (Mobile IPv6 for Multiple Interfaces, which 
I am about to submit) and I realized that some terms we are using may be 
confusing. In the meantime, we didn't talk about a terminology document 
in the purpose of our next BOF. Although most of the mobility related 
terminology is defined in RFC 3753, maybe more terms are needed in our 
context.

Some terms I am referring to are the following:

    - Terminology in draft-ernst-generic-goals-and-benefits-01.txt 
(definition of Multihomed Node and Multihomed Network)

    - Previous / new interface in case of a vertical handover

    - Definition of the granularity of the mobility (details are given 
in our draft MMI, which can only be found on Monami6 home page now) : 
According to the capacity of the MN and its peers (HA, CN, MR...), 
different kind of functionality can be achieved, such as the use of only 
one interface at a time (very basic support of multiple interfaces), 
flow filtering, etc. Maybe we could propose a classification of these 
functionalities.

    - An interface in use comes down / up: basically we loose the 
network connection via an interface either because the interface is 
physically remove from the terminal, or because we lost the signal

    - available interface: an interface which is connected and 
configured to a link, and allows an IP-level communication

    - If we consider a multihomed MN with several HoAs, when we talk 
about a flow, we have to specify via which HoA this flow was initiated. 
Should we define a terminology to express that?

    - when considering MIP6 or NEMO, we often say "when the MN/MR is 
away from its home network...". But if the MN/MR has several HoAs/HAs, 
this explanation is meaningless. We should refer to a particular HoA / 
HA. For example, we should say someting like "when the MN/MR is away 
from its home network for interface 1 / HoA1..."
   
I am sure I am missing other terms.

What do you think?
Would it be useful to add a work item on the terminology in the goals of 
a potantial WG?

Nicolas

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

---

From: Thierry Ernst <[email-masked]>
Date: Wed, 13 Jul 2005 12:06:07 +0900

Hi Nicolas,

> I was updating our draft MMI (Mobile IPv6 for Multiple Interfaces,
> which I am about to submit) and I realized that some terms we are
> using may be confusing. In the meantime, we didn't talk about a
> terminology document in the purpose of our next BOF. Although most of
> the mobility related terminology is defined in RFC 3753, maybe more
> terms are needed in our context.

I think some of the terms can be added in
draft-ernst-generic-goals-and-benefits
and others in
draft-montavont-mobileip-multihoming-pb-statement

>     - Previous / new interface in case of a vertical handover

I'm not sure this is needed.  Also, we should consider which address is
used rather than which interface. 

In the context of mobility, we have to consider which HoA and CoA
addresses are used, i.e. which identifier and locator to use more
generic word. 

May be it would be useful to relate HoA and CoA to the concept of
identifier and locator, and would allow us to make a clearer link with
work not related to mobiility. 

> different kind of functionality can be achieved, such as the use of
> only one interface at a time (very basic support of multiple
> interfaces), flow filtering, etc. Maybe we could propose a
> classification of these functionalities.

Agree. This should be reflected into the taxonomy of
draft-montavont-mobileip-multihoming-pb-statement

> physically remove from the terminal, or because we lost the signal

I don't see a use for it. Could you justify ?
 
> configured to a link, and allows an IP-level communication

Agree

> about a flow, we have to specify via which HoA this flow was
> initiated. Should we define a terminology to express that?

Actually, what matters is the address used to established the flow, not
that it is a HoA or a CoA.  Isn't there any de facto standard terms used
in documents dealing with flow establishment or flow redirection, that
we may refer to ? 

> from its home network for interface 1 / HoA1..."

Agree. Anyone can propose a term and its definition ?

> Would it be useful to add a work item on the terminology in the goals
> of a potantial WG?

We can surely add the definition of the terminology as an additional
work item, but it could also well be included into the problem statement
item

Thierry

---

From: Nicolas Montavont <[email-masked]>
Date: Wed, 13 Jul 2005 10:54:55 -0400

Hello,

>draft-montavont-mobileip-multihoming-pb-statement
Don't you think it would be a better idea to have a separate document to 
have all definitions together?

>used rather than which interface. 
I agree with you, but this is to explain some scenarios. For example, in 
a high level scenario, you may want to explain that when one interface 
fails, you have to use another one. Then you have to perform a 
redirection from the "old" interface to the "new" one. The way you do it 
is to use the addresses allocated to these interfaces, as you said.

I think this terminology is very useful when you want to describe a 
particular scenario. Here is an example from MMI:

The mechanism for a MN to redirect flows from one of its interfaces
   (the previous interface) to another one (the new interface) is to
   perform a redirection between the IP address (previous IP address)
   allocated to the previous interface to the IP address (new IP
   address) allocated to the new interface.  To do so, the MN sends a
   Binding Update through the new interface to register the IP address
   allocated to the new interface as new CoA for the redirected flows.

This also makes me think that we could propose a definition for "failure 
of an interface".

>work not related to mobiility. 
Agree with that.

>draft-montavont-mobileip-multihoming-pb-statement
Actually this may not linked to host mobility only. This granularity can 
ba achieved in a mobile network as well. So 
draft-ernst-goals-and-benefits may be better. But in any case, if we use 
specific terms to relate to a certain level of granularity, we should 
propose a clear definition for them.

>I don't see a use for it. Could you justify ?
again, this is to explain some scenarios. For example, assume you have a 
terminal which can potantially have 2 interfaces, WLAN and UMTS, and 
assume that the WLAN technology is preferred. When the WLAN network card 
is plugged into the terminal and the terminal success in establishing an 
IP-level connection, then we could say the WLAN interface came UP, and 
flow would be redirected on this interface. If we clearly define waht 
means "interface comes up", then we could explain multihoming scenarios 
in a simple way.

>that it is a HoA or a CoA. 
>
If a CoA was used to initiate the flow, you won't be able to use MIP to 
redirect the flow, so I think it matters. That is one limit of the use 
of MIP for multihoming management.

> Isn't there any de facto standard terms used
We can at least add this item to be discussed during the BOF.

Nicolas

---

From: Nicolas Montavont <[email-masked]>
Date: Wed, 13 Jul 2005 10:54:55 -0400

Hello,

Agree with that.

Nicolas

---

From: Ryuji Wakikawa <[email-masked]>
Date: Thu, 14 Jul 2005 00:37:36 +0900

Hello Nicolas

On 2005/07/13, at 23:54, Nicolas Montavont wrote:

> Don't you think it would be a better idea to have a separate  
> document to have all definitions together?

It is nice if all related terms are explained in one document, but  
why not draft-ernst-generic draft?
We have a few new terms for multihoming.

> I agree with you, but this is to explain some scenarios. For  
> example, in a high level scenario, you may want to explain that  
> when one interface fails, you have to use another one. Then you  
> have to perform a redirection from the "old" interface to the "new"  
> one. The way you do it is to use the addresses allocated to these  
> interfaces, as you said.
>
> This also makes me think that we could propose a definition for  
> "failure of an interface".

We already use these words frequently in several document.
I am not sure if it's worth to re-define these well-known term in  
multihoming specific document.

>>>    in our draft MMI, which can only be found on Monami6 home page  
>>> now) : According to the capacity of the MN and its peers (HA, CN,  
>>> MR...), different kind of functionality can be achieved, such as  
>>> the use of
> Actually this may not linked to host mobility only. This  
> granularity can ba achieved in a mobile network as well. So draft- 
> ernst-goals-and-benefits may be better. But in any case, if we use  
> specific terms to relate to a certain level of granularity, we  
> should propose a clear definition for them.
>
>
>>
>>
>>> network connection via an interface either because the interface  
>>> is physically remove from the terminal, or because we lost the  
>>> signal
>>>
>>>
>>
> again, this is to explain some scenarios. For example, assume you  
> have a terminal which
> can potantially have 2 interfaces, WLAN and UMTS, and assume that  
> the WLAN technology
> is preferred. When the WLAN network card is plugged into the  
> terminal and the terminal success
> in establishing an IP-level connection, then we could say the WLAN  
> interface came UP, and flow would
> be redirected on this interface. If we clearly define waht means  
> "interface comes up", then we could explain
> multihoming scenarios in a simple way.
>

What we are interested in that IP reachability is  ready or not  
rather than "interface comes up".

>>>    - If we consider a multihomed MN with several HoAs, when we  
>>> talk about a flow, we have to specify via which HoA this flow was
> If a CoA was used to initiate the flow, you won't be able to use  
> MIP to redirect the flow, so I think it matters. That is one limit  
> of the use of MIP for multihoming management.

if an application starts session from CoA, this session is nothing to  
do with mobility and multihoming.
Why do we need to take care of them?

ryuji

>>>    - when considering MIP6 or NEMO, we often say "when the MN/MR  
>>> is away from its home network...". But if the MN/MR has several  
>>> HoAs/HAs,
>>> HA. For example, we should say someting like "when the MN/MR is  
>>> away from its home network for interface 1 / HoA1..."
>>>
>>>
>>

---

From: Nicolas Montavont <[email-masked]>
Date: Wed, 13 Jul 2005 13:59:02 -0400

Ryuji,

> We have a few new terms for multihoming.

I have no objection for that.

>> example, in a high level scenario, you may want to explain that  when 
>> one interface fails, you have to use another one. Then you  have to 
>> perform a redirection from the "old" interface to the "new"  one. The 
>> way you do it is to use the addresses allocated to these  interfaces, 
>> as you said.
>>

I am not talking of re-defining this terminology, but maybe we could 
provide some clear definition somewhere, to make sure we are always 
talking about the same things.

>> Actually this may not linked to host mobility only. This  granularity 
>> can ba achieved in a mobile network as well. So draft- 
>>>> is physically remove from the terminal, or because we lost the  signal
>>>>
>>>>
>>>

I agree with you, but the preferences policy will probably be on 
interfaces rather than on addresses. So what you want to know, is "is my 
interface is plugged, and can I use it for communication", whatever the 
address(es) configured on the interface. Then, when you have to perform 
the redirection, you will consider these adresses. So I think, when you 
want to explain scenario, it would be easier to say "an interface 
becomes available" or an "interface comes UP".

>> If a CoA was used to initiate the flow, you won't be able to use  MIP 
>> to redirect the flow, so I think it matters. That is one limit  of 
>> the use of MIP for multihoming management.
>
>

Because as a multihoming solution, we should be able to redirect any 
flow. So the fact that a flow can be directly started from a CoA is an 
issue from MIP6, that prevent to redirect this flow.

Nicolas

---

From: Nicolas Montavont <[email-masked]>
Date: Wed, 13 Jul 2005 13:59:02 -0400

Ryuji,

Nicolas

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 14 Jul 2005 10:42:45 +0800

Hello,

> I have no objection for that.

I think it would be counterproductive to has a separate terminology
draft to hold a mere <10 terms.  Given that most terms related to
multihoming would already have been defined by Multi6 and various other
documents in the past.

Putting them into the Goals and Benefits draft seems helpful.  Speaking
of which, we would also have to consider the realignment of draft-ernst
against RFC3582.  We would not want to duplicate text, it might be
helpful reaffirm our stand of focusing on multiple interfaces, such as
in the title.

> talking about the same things.

I am unsure about this.  The terms "new interface", "previous
interface", and "failed interface" sounds pretty self-defining and
self-explanatory to me.  For instance, how are you going to define "new
interface" using words that are simpler than "new interface"?

> >>> work not related to mobiility.

Curious, I have tried to do that in draft-montavont, and was
unsuccessful.  So now those arguments used no longer apply?

> >> should propose a clear definition for them.

Just to make sure we are on the same page, what sort of granularity do
you have in mind? Something like

(1) Use only one interface at any one time
(2) Use multiple interfaces simultaneously
(3) multiple paths to Home Agents only
(4) multiple paths to Home agents and CNs
etc etc?

> becomes available" or an "interface comes UP".

I agree with Nicolas on giving equal attention to "interface" and
"address".  In any case, based on the suggested definition below, it
actually helps us to map "interface" to "address", since to allow
IP-level communications inherently imply the need to configure an
address on that interface.

> issue from MIP6, that prevent to redirect this flow.

Perhaps all this suggest that we should define things to be
out-of-scoped before hand.   Cases such as a mobile node choosing to use
CoA to start a flow, and later hoping to transfer the flow to somewhere
else clearly should not be considered by a solution that uses Mobile IP
for multi-homing management.  This may suggest that we should scope our
discussion based on the assumption that all flows are tied to HoA as the
upper-layer identifier.

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: Thu, 14 Jul 2005 10:42:45 +0800

Hello,

/rgds
/cwng

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 14 Jul 2005 14:19:53 +0900

Hi,

Let me summarize with my own words:

1. If new terms must be defined, draft-ernst-generic is a good place  

- we should reflect in the document (e.g. in the title) that we are
focusing on multiple interfaces.

- according to most people, terms such as "new interface", "previous
interfaces" are not needed.

2.  We have to limit the scope of the Monami6 work to MIP6-specific
issues. 

- as such, we must discuss what is MIP6-specific vs what is not

- it is transparent to the upper layer that an interface is configured
with a HoA, a CoA or just a normal global address. As such, I don't
think that Monami6 should deal with"source/destination" address
selection, nor on generic"preference settings".

- however, we should deal with the exchanges of policies between the MN
and the HA because this is very MIP6 specific

Thierry

On Thu, 14 Jul 2005 10:42:45 +0800
Chan-Wah Ng <[email-masked]> wrote:

> > >>>> I was updating our draft MMI (Mobile IPv6 for Multiple
> > >Interfaces,>>> which I am about to submit) and I realized that some
> > >terms we are>>> using may be confusing. In the meantime, we didn't
> > >talk about a>>> terminology document in the purpose of our next
> > >BOF. Although  most of>>> the mobility related terminology is
> > >defined in RFC 3753, maybe more>>> terms are needed in our context.
> > >>>>
> > >>>>
> > >>>
> multihoming would already have been defined by Multi6 and various
> other documents in the past.
> 
> Putting them into the Goals and Benefits draft seems helpful. 
> Speaking of which, we would also have to consider the realignment of
> draft-ernst against RFC3582.  We would not want to duplicate text, it
> might be helpful reaffirm our stand of focusing on multiple
> interfaces, such as in the title.
> 
> > >
> > >>
> > >>>
> > >>>
> > >>>>    - Terminology in
> > >draft-ernst-generic-goals-and-benefits-01.txt  >>> (definition of
> > >Multihomed Node and Multihomed Network)>>>
> > >when > one interface fails, you have to use another one. Then you 
> > >have to > perform a redirection from the "old" interface to the
> > >"new"  one. The > way you do it is to use the addresses allocated
> > >to these  interfaces, > as you said.
> > >>
> > >> I think this terminology is very useful when you want to describe
> > >a  > particular scenario. Here is an example from MMI:
> > >>
> > >> The mechanism for a MN to redirect flows from one of its
> > >interfaces>   (the previous interface) to another one (the new
> > >interface) is to>   perform a redirection between the IP address
> > >(previous IP address)>   allocated to the previous interface to the
> > >IP address (new IP>   address) allocated to the new interface.  To
> > >do so, the MN sends a>   Binding Update through the new interface
> > >to register the IP address>   allocated to the new interface as new
> > >CoA for the redirected flows.>
> > >>
> self-explanatory to me.  For instance, how are you going to define
> "new interface" using words that are simpler than "new interface"?
> 
> > >>
> > >>> In the context of mobility, we have to consider which HoA and
> > >CoA>> addresses are used, i.e. which identifier and locator to use
> > >more>> generic word.
> > >>> May be it would be useful to relate HoA and CoA to the concept
> > >of>> identifier and locator, and would allow us to make a clearer
> > >link  with>> work not related to mobiility.
> > >>>
> > >> Agree with that.
> 
> > >>>>    in our draft MMI, which can only be found on Monami6 home
> > >page  >>> now) : According to the capacity of the MN and its peers
> > >(HA, CN,  >>> MR...), different kind of functionality can be
> > >achieved, such as  >>> the use of
> > >granularity > can ba achieved in a mobile network as well. So
> > >draft- > ernst-goals-and-benefits may be better. But in any case,
> > >if we use  > specific terms to relate to a certain level of
> > >granularity, we  > should propose a clear definition for them.
> > >>
> 
> > >>>>    - An interface in use comes down / up: basically we loose
> > >the  >>> network connection via an interface either because the
> > >interface  >>> is physically remove from the terminal, or because
> > >we lost the  signal>>>
> > >>>>
> > >>>
> > >> in establishing an IP-level connection, then we could say the
> > >WLAN  > interface came UP, and flow would
> > interfaces rather than on addresses. So what you want to know, is
> > "is my interface is plugged, and can I use it for communication",
> > whatever the address(es) configured on the interface. Then, when you
> > have to perform the redirection, you will consider these adresses.
> > So I think, when you want to explain scenario, it would be easier to
> > say "an interface becomes available" or an "interface comes UP".
> > 
> 
> > >>>> talk about a flow, we have to specify via which HoA this flow
> > >was>>> initiated. Should we define a terminology to express that?
> > >>>>
> > >>>>
> > >>>
> > >>> Actually, what matters is the address used to established the 
> > >flow, >> not
> > >MIP > to redirect the flow, so I think it matters. That is one
> > >limit  of > the use of MIP for multihoming management.
> > >
> > >
> > > if an application starts session from CoA, this session is nothing
> > > to  do with mobility and multihoming.
> > flow. So the fact that a flow can be directly started from a CoA is
> > an issue from MIP6, that prevent to redirect this flow.
> > 
> 
> out-of-scoped before hand.   Cases such as a mobile node choosing to
> use CoA to start a flow, and later hoping to transfer the flow to
> somewhere else clearly should not be considered by a solution that
> uses Mobile IP for multi-homing management.  This may suggest that we
> should scope our discussion based on the assumption that all flows are
> tied to HoA as the upper-layer identifier.
> 
> /rgds
> /cwng

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 14 Jul 2005 10:41:22 -0400

Thank you Thierry for clarifying this. Some more comments inline...

>1. If new terms must be defined, draft-ernst-generic is a good place  
Agree on that.

>focusing on multiple interfaces.
i am not sure of that. We are also dealing with the case where you have 
several addresses on one interface (in both 
draft-ernst-gaols-and-benefits and draft-montavont-mobileip-pb-statement).

>interfaces" are not needed.
Can we keep this in mind and once we write the definitions in a 
document, we can have a consensus on it?
Giving a definition for these terms would allow us to (1) always use 
these terms in our documents and (2) make sure people understand them. 
If you look at the definitions of new AR and previous AR, it also seems 
obvious, but they are in RFC 3753.

>2.  We have to limit the scope of the Monami6 work to MIP6-specific
We had a discussion two weeks ago about NEMO issues on Moanmi6 mailing 
list, and lot of people express a positive feeling to deal with those in 
Monami6. This was also our intend when we initiated Monami6 (take a look 
at our charter).

On the contrary, I think we should take the oppotunity of this BOF to 
have a consensus if people agree to move NEMO Multihoming work into 
Monami6 if a WG is created. Having said that, I agree that we can focus 
first on solutions linked to MIPv6, since the problem is better 
understood, and we have potantial solutions.

>selection, nor on generic"preference settings".
You are right, preference settings must be taken as input. But we could 
clarify what are the impacts of the address selection on future 
operations (such as when the MN looses its address) in a problem 
statement draft.

>and the HA because this is very MIP6 specific
Yes it is, but again, we should keep in mind that these exchanges might 
be extended to other nodes, such as CN, MR, MNNs...

Nicolas

>>>>>>>   - Definition of the granularity of the mobility (details are
>>>>>>>              
>>>>>>>
>>>>given
>>>>        
>>>>

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 14 Jul 2005 10:41:22 -0400

Agree on that.

Nicolas

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 14 Jul 2005 10:51:30 -0400

Hi,

I cut most of the text as Thierry proposed another email that summurizes 
this threat.

>unsuccessful.  So now those arguments used no longer apply?
I think we should keep the terminology HoA and CoA when we talk about 
MIP6. But, in our problem statement, we could use the terminology 
locator/identifier.

>(4) multiple paths to Home agents and CNs
Not really. I was thinking to the classification presented in our draft 
MMI (a new revision is being processed and can be viewed on 
http://clarinet.u-strasbg.fr/~montavont/ietf/draft-montavont-mobileip-mmi-02.txt)

The proposed classification is:
    - Per-correspondant node mobility
    - Per-flow mobility
    - Per-flow Load balancing

But I hope that we can propose a unified classification combining these 
two views.

>discussion based on the assumption that all flows are tied to HoA as the
That was my intend.

Nicolas

---

From: Nicolas Montavont <[email-masked]>
Date: Thu, 14 Jul 2005 10:51:30 -0400

Hi,

That was my intend.

Nicolas

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 15 Jul 2005 11:29:49 +0900

Hi,

> >1. If new terms must be defined, draft-ernst-generic is a good place 
OK.

> i am not sure of that. We are also dealing with the case where you
> have several addresses on one interface (in both 
OK with you, may be I miss read the meaning of "focusing" the thread. 

> document, we can have a consensus on it?
This was my own view, and I think we shouldn't include terms if there is
no rough consensus it's needed. We can include terms once the need
arises.
> If you look at the definitions of new AR and previous AR, it also
> seems obvious, but they are in RFC 3753.
> 
> list, and lot of people express a positive feeling to deal with those
> in Monami6. This was also our intend when we initiated Monami6 (take a
> look at our charter).
>
> Monami6 if a WG is created. Having said that, I agree that we can
> focus first on solutions linked to MIPv6, since the problem is better 

Actually, I didn't intend to say we shouldn't work on NEMO issues, as
long as they are related. 

The important thing is to avoid duplication of effort, so any issue that
applies to both MIP6 and NEMO should be dealt with Monami6. Issues that
are proper to NEMO could later be moved to Monami6.  But, this is
something that should be discussed in the NEMO WG, and the decision can
only come once a MONAM6 WG is approved.

> >- it is transparent to the upper layer that an interface is
> >configured with a HoA, a CoA or just a normal global address. As
> >such, I don't think that Monami6 should deal with"source/destination"
> >address selection, nor on generic"preference settings".
> >  
> >
> You are right, preference settings must be taken as input. But we
> could clarify what are the impacts of the address selection on future 

Do you mean to write more text in draft-montavont or another document ? 

> >- however, we should deal with the exchanges of policies between the
> >MN and the HA because this is very MIP6 specific
> >  
> >
> Yes it is, but again, we should keep in mind that these exchanges
> might be extended to other nodes, such as CN, MR, MNNs...

Yes, right, but we have to be extremely careful with whatever is not
directly linked to mobility as some folk may argue that there are other
approaches than a mobility-based approach for exchanging such
policies. And, this would lead to an endless debate. I don't want to go
down that path in Monami6.

Thierry

> >>>>Interfaces,>>> which I am about to submit) and I realized that
> >some>>>terms we are>>> using may be confusing. In the meantime, we
> >didn't>>>talk about a>>> terminology document in the purpose of our
> >next>>>BOF. Although  most of>>> the mobility related terminology is
> >>>>defined in RFC 3753, maybe more>>> terms are needed in our
> >context.>>>        
> >>>>
> >>>>>>>              
> >>>>>>>
> >>draft-ernst against RFC3582.  We would not want to duplicate text,
> >it>might be helpful reaffirm our stand of focusing on multiple
> >>>>(previous IP address)>   allocated to the previous interface to
> >the>>>IP address (new IP>   address) allocated to the new interface. 
> >To>>>do so, the MN sends a>   Binding Update through the new
> >interface>>>to register the IP address>   allocated to the new
> >interface as new>>>CoA for the redirected flows.>
> >>>>        
> >>>>
> >>>I am not talking of re-defining this terminology, but maybe we
> >could>>provide some clear definition somewhere, to make sure we are
> >always >>talking about the same things.
> >>>      
> >>>
> >>Just to make sure we are on the same page, what sort of granularity
> >do>you have in mind? Something like
> >>
> >>>whatever the address(es) configured on the interface. Then, when
> >you>>have to perform the redirection, you will consider these
> >adresses.>>So I think, when you want to explain scenario, it would be
> >easier to>>say "an interface becomes available" or an "interface
> >comes UP".>>
> >>>      
> >>>
> >>>Because as a multihoming solution, we should be able to redirect
> >any>>flow. So the fact that a flow can be directly started from a CoA
> >is>>an issue from MIP6, that prevent to redirect this flow.
> >>>
> >>>      
> >>>
> >>uses Mobile IP for multi-homing management.  This may suggest that
> >we>should scope our discussion based on the assumption that all flows
> >are>tied to HoA as the upper-layer identifier.
> >>
> >>/rgds
> >>/cwng
> >>    
> >>
> >

-- 
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: Chan-Wah Ng <[email-masked]>
Date: Fri, 15 Jul 2005 11:07:59 +0800

> OK with you, may be I miss read the meaning of "focusing" the thread. 

I am the one who brought up this focusing thing.  I might have not
written concisely, I don't mean we should not focus on multiple address.
My point is, there is an RFC 3582.  I have received comments from people
(some of which are sitting ion the IESG) on the relevance of
draft-ernst-generic in view of RFC 3582.   So, we should draw a clear
distinction between our work from the Shim6/Multi6 work scope in order
for Monami6 to move forward.  Realigning draft-ernst-generic is one step
towards this direction.

> > seems obvious, but they are in RFC 3753.

I think having a terminology draft or not is not crucially important
right now.  Let's focus on the charter ... we are bound to produce some
informational documents as a milestone, and these could very well
include a terminology document.

/rgds
/cwng

---

From: Chan-Wah Ng <[email-masked]>
Date: Fri, 15 Jul 2005 11:07:59 +0800

/rgds
/cwng

---

From: "Koojana Kuladinithi" <[email-masked]>
Date: Mon, 18 Jul 2005 08:25:39 +0200

Hi

>for Monami6 to move forward.  Realigning draft-ernst-generic 

Talking abt the Terminology, the word "re-homing/ re-homing trasparency"
that is used in RFC 3582, 

"3.1.6.  Transport-Layer Survivability

   Multihoming solutions should provide re-homing transparency for
   transport-layer sessions; i.e., exchange of data between devices on
   the multihomed site and devices elsewhere on the Internet may proceed
   with no greater interruption than that associated with the transient
   packet loss during the re-homing event. New transport-layer sessions
should be able to be created following a
   re-homing event.  Transport-layer sessions include those involving
transport-layer
   protocols such as TCP, UDP and SCTP over IP.  Applications which
   communicate over raw IP and other network-layer protocols may also
   enjoy re-homing transparency."

Monami6 specific drafts too address the same as "Transparent Flow
handoff (see section 4.1 in generic drafts)". imho, it's good to use
some common terminologies. 

Don't confuse with this email to the above thread. I wanted to emphasise
that it's better to use some termonologies that are already being used. 

Regards

Koojnaa