Subject: [Netext] Redirection Problem Statement
From: behcetsarikaya at yahoo.com (Behcet Sarikaya)
Date: Fri, 27 Feb 2009 09:45:33 -0800 (PST)

Hi Jouni, 
? My comments inline.

Regards,

--behcet

________________________________

From: jouni korhonen <jouni.nospam at gmail.com>
To: Behcet Sarikaya <sarikaya at ieee.org>
Cc: netext at mail.mobileip.jp
Sent: Friday, February 27, 2009 6:49:24 AM
Subject: Re: [Netext] Redirection Problem Statement

[behcet] Initial attachment time redirection?would?not be in the scope of?LMA reliability so yes you are right.
However I would question such a?problem because AAA can easily solve it, I think.
?
?
Cheers,
??? Jouni

> 
> Regards,
> 
> Behcet
> 
> From: jouni korhonen <jouni.nospam at gmail.com>
> To: netext at mail.mobileip.jp
> Sent: Thursday, February 26, 2009 3:51:51 AM
> Subject: [Netext] Redirection Problem Statement
> 
> Hi all,
> 
> It seems my previous mail went to void or something. This short PS document discusses about redirection functionality for the PMIP6 base protocol that could be part of the PBU/PBA exchange. There are obvious use cases for the redirection such as load balancing, LMA maintenance and signaling reduction within a PMIPv6 domain (during redirection or moving MNs under other LMAs). The problem scope falls under the improvements and/or deployment considerations in the current proposed charter.
> 
> The document is available here:
> http://www.ietf.org/internet-drafts/draft-korhonen-netext-redirect-ps-00.txt
> 
> Comments are welcome.
> 
> Cheers,
>? ? Jouni
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 
> 

Hi Bechet,

On Feb 26, 2009, at 5:21 PM, Behcet Sarikaya wrote:

> Hi Jouni,
>? Have you read HA Reliability draft:
> http://tools.ietf.org/html/draft-ietf-mip6-hareliability-04
> Ryuji and I discussed a couple of times issuing PMIPv6 version of HA Reliability. He seems to be too busy these days to do that.
>? I think PMIPv6 HA Or LMA reliability solves the problem you described.

Yes, I have read the I-D.. but not the latest revision though. The I-D contains functionality that could be usable for the redirection of the established mobility session, not really for the initial attachment time redirection.

      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090227/5fcef721/attachment.html>

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Fri, 27 Feb 2009 11:38:30 -0500
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Domagoj,

> Extending the access system signaling may not be always 
> possible and in such cases the IP layer mechanism would get 
> used. Considering the already deployed WiFi equipement as an 
> example, even if the 802.11 would be extended to provide 
> support for PMIP6 hints, is it realistic to expect the 
> existing APs to be upgraded? 

WiFi is not a good example here IMHO. One of the emphasis in NetExt is to consider possible deployment scenarios. So, either a candidate access deployment already has or willing to define the necessary extensions or expresses need to have an IP-based mechanism. 

> 
> > How does handover work in Wimax today without indication 
> from the MN 
> > at the IP layer?
> 
> Curretnly it doesn't work (the inter-tech HO), this is an 
> open issue. Link layer extensions are not an option as the 
> .16 version upon which the NWG Rel
> 1.5 is based is closed for changes.
> 

Good to know. We will need further discussion to go over this.

> > 
> > To be clear, I do not wish to start from a point where we 
> > assume that MN involvement at the IP layer is necessary; at least for this BOF.
> 
> Is MN involvement at the link layer less of a concern then 
> the MN involvement at the IP layer? It should not be. 

Yes, it is less of a concern for _this BOF_ because this BoF is about working on some problems related to network-based mobility where we do not want to start from making changes to the MN. As I mentioned in my e-mail, defining an IP layer mechanism which an access system already has or will define will be redundant and ignored.

> Ideally, the MN is not involved at all at any layer. My 
> thinking is that, if it must be involved, it makes sense to 
> address those changes at the IP layer - once and for all.
> 

As a general design guideline yes. It's not easy for this BOF.

> > The focus of this effort is to identify the problems which need to be 
> > solved. During the process, we can list what works and what doesn't as 
> > it is, without MN involvement; it needs to be done thoroughly.
> 
> ok, let's try to see first what scenarios can be addressed 
> without the MN involvement.
> 

Good. I want to start with the clear understanding that we are _not_ starting with defining MN involvement (at IP layer). Once we get chartered (hopefully), we can have a discussion on the topic as part of Inter-tech handovers and arrive at consensus. 

> > But, the starting point is not "we need MN involvement".  
> 
> I would just like the term "MN involvement" to include the 
> link layer extensions as well. Otherwise we're sweeping the 
> problem under the rug.
> 

Sure. One thing we can do is to clearly list where MN participation is necessary.
Whether this would be done by L2 or IP is another thing. 

Thanks,

-Rajeev

> domagoj
> 
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp 
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Koodli, 
> > Rajeev
> > Sent: 26. veljaca 2009 19:38
> > To: netext at mail.mobileip.jp
> > Subject: Re: [Netext] Inter-technology handover PS
> > 
> > 
> >  
> > Hi Domagoj,
> > 
> > 
> > > 
> > > Using access specific mechanims is fine for the cases where
> > the access
> > > system actually provides the needed functionality.
> > 
> > Good. My reasoning is that if there is a functionality which is 
> > crucial to an access system, it will provide it. We defining a 
> > mechanism at IP layer, which I would prefer as well, will 
> turn out to 
> > be redundant and ignored.
> > 
> > 
> > > I don't think that we can expect every access system to readily 
> > > support whatever is needed by PMIP6 (WiMAX being one
> > example of such
> > > access system, it doesn't provide any clue about the HI). In such 
> > > cases it makes sense to put the additional functionality 
> at the IP 
> > > layer, i.e. at the MAG/LMA/MN as they need to be updated 
> anyway to 
> > > support inter-tech handover. Such add-on at the IP-layer could be 
> > > reused without modifications with any access system which 
> does not 
> > > provide the appropriate L2 hints.
> > 
> > How does handover work in Wimax today without indication 
> from the MN 
> > at the IP layer?
> > 
> > To be clear, I do not wish to start from a point where we 
> assume that 
> > MN involvement at the IP layer is necessary; at least for this BOF. 
> > The focus of this effort is to identify the problems which 
> need to be 
> > solved. During the process, we can list what works and what 
> doesn't as 
> > it is, without MN involvement; it needs to be done thoroughly.
> > But, the starting point is not "we need MN involvement". 
> > 
> > -Rajeev
> > 
> > 
> > 
> > > 
> > > domagoj
> > > 
> > > > -----Original Message-----
> > > > From: netext-bounces at mail.mobileip.jp 
> > > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of 
> ext Koodli, 
> > > > Rajeev
> > > > Sent: 24. veljaca 2009 23:01
> > > > To: netext at mail.mobileip.jp
> > > > Subject: Re: [Netext] Inter-technology handover PS
> > > > 
> > > > 
> > > > Hello folks,
> > > > 
> > > > Few thoughts on what we may need to focus here..
> > > > 
> > > > 1. For the purposes of this ID (i.e., inter-tech
> > > handovers), what is
> > > > most relevant here? What breaks today? Or, what we can
> > improve? The
> > > > breakdown of issues is a good start, but we need to tie
> > it together
> > > > for the problem at hand - inter-tech handovers.
> > > > 
> > > > 2. What _requires_ an IP protocol support on the MN side? 
> > > > Could this be done in an access-specific way? For instance,
> > > the HI in
> > > > PMIP6 is left up to the access system to determine, based on 
> > > > access-specific means where MN does take part. We need to ask a 
> > > > similar question here: if MN involvement is necessary, why
> > > couldn't we
> > > > let an access system provide the functionality?
> > > > 
> > > > 3. Assuming specific mechanisms (e.g., IEEE 802.21 etc.) is not 
> > > > necessary. Folks can use whatever they want, but specifying 
> > > > dependencies needs to be avoided.
> > > > 
> > > > Regards,
> > > > 
> > > > -Rajeev
> > > >  
> > > > 
> > > > > -----Original Message-----
> > > > > From: netext-bounces at mail.mobileip.jp 
> > > > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
> > > > Suresh Krishnan
> > > > > Sent: Thursday, February 19, 2009 3:19 PM
> > > > > To: cjbc at it.uc3m.es
> > > > > Cc: netext at mail.mobileip.jp
> > > > > Subject: Re: [Netext] Inter-technology handover PS
> > > > > 
> > > > > Hi Carlos,
> > > > >    Thanks for your comments. Please find responses inline
> > > > > 
> > > > > On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
> > > > > > * PGP Signed by an unknown key
> > > > > > 
> > > > > > Hi Suresh,
> > > > > > 
> > > > > > 	Thanks for the draft. I think it's short and clear. 
> > > > > Some comments
> > > > > > below:
> > > > > > 
> > > > > > 	- Section 2.1. Formation of interface identifier. The
> > > > > issue described
> > > > > > there only applies if SLAAC is used, right? If DHCP is
> > > > > used, the issue
> > > > > > is then on the network side, to ensure that the address
> > > > provided to
> > > > > > the new interface of the MN is the same that it was (or
> > > is still)
> > > > > > using on the previous interface, right?
> > > > > 
> > > > > Yes. This is correct. I can probably add a new section on
> > > > the network
> > > > > side about the DHCPv6 issue
> > > > > 
> > > > > > 
> > > > > > 	- Section 2.2 Usage of the same address on multiple
> > > > > interfaces. Since
> > > > > > it seems that we cannot assume that is safe to use the same
> > > > > address on
> > > > > > multiple interfaces (without requiring changes on the MN
> > > > > side), this
> > > > > > implies that: a) if NETEXT work is restricted to work on
> > > > solutions
> > > > > > that do not impose changes on the MN, use cases requiring
> > > > the MN to
> > > > > > use the same address simultaneously are out of the scope of
> > > > > NETEXT, b)
> > > > > > we allow for changes on the MN side. Additionally, it might
> > > > > be good to
> > > > > > analyse if it is OK for the MN to receive (and send)
> > > > > traffic addressed
> > > > > > to the IPv6 address of one interface through a different
> > > > interface
> > > > > > (weak end-system model defined in RFC 1122 or
> > > > > draft-thaler-ip-model-evolution).
> > > > > 
> > > > > While I agree with your analysis of the problem, are we
> > > delving too
> > > > > much into the solution space by adding any such text?
> > > > > 
> > > > > > 
> > > > > > 	- IMHO, it'd be good to explicitly describe what a
> > > > > "change on the MN"
> > > > > > within the scope of NETEXT. For example, is it fine
> > > assuming IEEE
> > > > > > 802.21 support on the MN or is this "a change on the MN"?
> > > > > 
> > > > > Probably something to add to the charter?
> > > > > 
> > > > > Cheers
> > > > > Suresh
> > > > > 
> > > > > _______________________________________________
> > > > > NetExt mailing list
> > > > > NetExt at mail.mobileip.jp
> > > > > http://www.mobileip.jp/mailman/listinfo/netext
> > > > > 
> > > > 
> > > > 
> > > > This email and any attachments may contain legally
> > > privileged and/or
> > > > confidential information of Starent Networks, Corp.
> > > > and is intended only for the individual or entity named in the 
> > > > message.  The information transmitted may not be used to
> > create or
> > > > change any contractual obligations of Starent Networks,
> > Corp.  Any
> > > > review, retransmission, dissemination or other use of, or
> > taking of
> > > > any action in reliance upon this e-mail and its attachments
> > > by persons
> > > > or entities other than the intended recipient is
> > prohibited. If you
> > > > are not the intended recipient, please notify the sender
> > > immediately
> > > > -- by replying to this message or by sending an email to 
> > > > postmaster at starentnetworks.com -- and destroy all 
> copies of this 
> > > > message and any attachments without reading or disclosing their 
> > > > contents. Thank you.
> > > > 
> > > > _______________________________________________
> > > > NetExt mailing list
> > > > NetExt at mail.mobileip.jp
> > > > http://www.mobileip.jp/mailman/listinfo/netext
> > > > 
> > > 
> > > 
> > 
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> > 
> 
> 

From: jouni.nospam at gmail.com (jouni korhonen)
Date: Fri, 27 Feb 2009 14:49:24 +0200
Subject: [Netext] Redirection Problem Statement
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Bechet,

On Feb 26, 2009, at 5:21 PM, Behcet Sarikaya wrote:

> Hi Jouni,
>   Have you read HA Reliability draft:
> http://tools.ietf.org/html/draft-ietf-mip6-hareliability-04
> Ryuji and I discussed a couple of times issuing PMIPv6 version of HA  
> Reliability. He seems to be too busy these days to do that.
>   I think PMIPv6 HA Or LMA reliability solves the problem you  
> described.

Yes, I have read the I-D.. but not the latest revision though. The I-D  
contains functionality that could be usable for the redirection of the  
established mobility session, not really for the initial attachment  
time redirection.

Cheers,
	Jouni

>
> Regards,
>
> Behcet
>
> From: jouni korhonen <jouni.nospam at gmail.com>
> To: netext at mail.mobileip.jp
> Sent: Thursday, February 26, 2009 3:51:51 AM
> Subject: [Netext] Redirection Problem Statement
>
> Hi all,
>
> It seems my previous mail went to void or something. This short PS  
> document discusses about redirection functionality for the PMIP6  
> base protocol that could be part of the PBU/PBA exchange. There are  
> obvious use cases for the redirection such as load balancing, LMA  
> maintenance and signaling reduction within a PMIPv6 domain (during  
> redirection or moving MNs under other LMAs). The problem scope falls  
> under the improvements and/or deployment considerations in the  
> current proposed charter.
>
> The document is available here:
> http://www.ietf.org/internet-drafts/draft-korhonen-netext-redirect-ps-00.txt
>
> Comments are welcome.
>
> Cheers,
>     Jouni
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>
>

From: jouni.nospam at gmail.com (jouni korhonen)
Date: Fri, 27 Feb 2009 14:12:42 +0200
Subject: [Netext] Redirection Problem Statement
In-Reply-To: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1058BD9E8@ftrdmel1>
References: <[email-masked]> <DD8B8FEBBFAF9E488F63FF0F1A69EDD1058BD90D@ftrdmel1> <[email-masked]> <DD8B8FEBBFAF9E488F63FF0F1A69EDD1058BD9E8@ftrdmel1>
Message-ID: <[email-masked]>

Hi Pierrick,

[snip]

>>> You seem to consider LMA switching only during PBU/PBA exchange.
>>> When LMA redirection is expected to take place during an active
>>> session, I the LMA should be able to initiate redirection: I mean
>>> that the LMA should be able to notify, thanks to a dedicated
>>> message, attached MAGs to switch to r2LMA. This feature could be
>>> useful when the operator wants to shutdown a LMA for maintenance
>>> reason. What do you think?
>>
>> I am primarily interested in the LMA redirection during the initial
>> PBU/PBA exchange. The reason being that there is no state established
>> yet on the LMA side (which also means the LMA has not either  
>> contacted
>> the backend system). I would gain a lot in signaling and avoid
>> unnecessary setup of state in various places.
>>
>> The LMA initiated redirection of an existing session is interesting
>> and should also be studied. However, it involves a lot more,
>> especially if we want to maintain the mobility session.
>>
>
> For sure, LMA initiated redirection leads to a more sophisticated  
> mechanism; but, depending on the interest of the WG, it could be  
> interesting to include it in the ps draft. Let's see other comments  
> on the ML....

There were few I-Ds on this front:
	o draft-krishnan-mext-ha-redirect-01
	o draft-ietf-mip6-hareliability-04

The latter is rather thorough, but does not necessarily fit in PMIP6  
context. The PS I-D surfaces the LMA initiated redirect when the  
mobility session is already up & running but does not go into details  
such are related context transfer and how to deal with routing (when  
the HNP gets moved from LMA to another). I am open for proposals.

Cheers,
	Jouni

>
>
> Regards,
> Pierrick
>
>> Cheers,
>> 	Jouni
>>

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Fri, 27 Feb 2009 11:08:41 +0100
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Rajeev,

> > Using access specific mechanims is fine for the cases where 
> the access 
> > system actually provides the needed functionality.
> 
> Good. My reasoning is that if there is a functionality which 
> is crucial to an access system, it will provide it. We 
> defining a mechanism at IP layer, which I would prefer as 
> well, will turn out to be redundant and ignored.
 
Extending the access system signaling may not be always possible and in such
cases the IP layer mechanism would get used. Considering the already
deployed WiFi equipement as an example, even if the 802.11 would be extended
to provide support for PMIP6 hints, is it realistic to expect the existing
APs to be upgraded? 

> How does handover work in Wimax today without indication from 
> the MN at the IP layer?

Curretnly it doesn't work (the inter-tech HO), this is an open issue. Link
layer extensions are not an option as the .16 version upon which the NWG Rel
1.5 is based is closed for changes.

> 
> To be clear, I do not wish to start from a point where we 
> assume that MN involvement at the IP layer is necessary; at 
> least for this BOF. 

Is MN involvement at the link layer less of a concern then the MN
involvement at the IP layer? It should not be. Ideally, the MN is not
involved at all at any layer. My thinking is that, if it must be involved,
it makes sense to address those changes at the IP layer - once and for all.

> The focus of this effort is to identify 
> the problems which need to be solved. During the process, we 
> can list what works and what doesn't as it is, without MN 
> involvement; it needs to be done thoroughly.

ok, let's try to see first what scenarios can be addressed without the MN
involvement.

> But, the starting point is not "we need MN involvement".  

I would just like the term "MN involvement" to include the link layer
extensions as well. Otherwise we're sweeping the problem under the rug.

domagoj

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext 
> Koodli, Rajeev
> Sent: 26. veljaca 2009 19:38
> To: netext at mail.mobileip.jp
> Subject: Re: [Netext] Inter-technology handover PS
> 
> 
>  
> Hi Domagoj,
> 
> 
> > 
> > Using access specific mechanims is fine for the cases where 
> the access 
> > system actually provides the needed functionality.
> 
> Good. My reasoning is that if there is a functionality which 
> is crucial to an access system, it will provide it. We 
> defining a mechanism at IP layer, which I would prefer as 
> well, will turn out to be redundant and ignored.
> 
> 
> > I don't think that we can expect every access system to readily 
> > support whatever is needed by PMIP6 (WiMAX being one 
> example of such 
> > access system, it doesn't provide any clue about the HI). In such 
> > cases it makes sense to put the additional functionality at the IP 
> > layer, i.e. at the MAG/LMA/MN as they need to be updated anyway to 
> > support inter-tech handover. Such add-on at the IP-layer could be 
> > reused without modifications with any access system which does not 
> > provide the appropriate L2 hints.
> 
> How does handover work in Wimax today without indication from 
> the MN at the IP layer?
> 
> To be clear, I do not wish to start from a point where we 
> assume that MN involvement at the IP layer is necessary; at 
> least for this BOF. The focus of this effort is to identify 
> the problems which need to be solved. During the process, we 
> can list what works and what doesn't as it is, without MN 
> involvement; it needs to be done thoroughly.
> But, the starting point is not "we need MN involvement". 
> 
> -Rajeev
> 
> 
> 
> > 
> > domagoj
> > 
> > > -----Original Message-----
> > > From: netext-bounces at mail.mobileip.jp 
> > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Koodli, 
> > > Rajeev
> > > Sent: 24. veljaca 2009 23:01
> > > To: netext at mail.mobileip.jp
> > > Subject: Re: [Netext] Inter-technology handover PS
> > > 
> > > 
> > > Hello folks,
> > > 
> > > Few thoughts on what we may need to focus here..
> > > 
> > > 1. For the purposes of this ID (i.e., inter-tech
> > handovers), what is
> > > most relevant here? What breaks today? Or, what we can 
> improve? The 
> > > breakdown of issues is a good start, but we need to tie 
> it together 
> > > for the problem at hand - inter-tech handovers.
> > > 
> > > 2. What _requires_ an IP protocol support on the MN side? 
> > > Could this be done in an access-specific way? For instance,
> > the HI in
> > > PMIP6 is left up to the access system to determine, based on 
> > > access-specific means where MN does take part. We need to ask a 
> > > similar question here: if MN involvement is necessary, why
> > couldn't we
> > > let an access system provide the functionality?
> > > 
> > > 3. Assuming specific mechanisms (e.g., IEEE 802.21 etc.) is not 
> > > necessary. Folks can use whatever they want, but specifying 
> > > dependencies needs to be avoided.
> > > 
> > > Regards,
> > > 
> > > -Rajeev
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: netext-bounces at mail.mobileip.jp 
> > > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
> > > Suresh Krishnan
> > > > Sent: Thursday, February 19, 2009 3:19 PM
> > > > To: cjbc at it.uc3m.es
> > > > Cc: netext at mail.mobileip.jp
> > > > Subject: Re: [Netext] Inter-technology handover PS
> > > > 
> > > > Hi Carlos,
> > > >    Thanks for your comments. Please find responses inline
> > > > 
> > > > On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
> > > > > * PGP Signed by an unknown key
> > > > > 
> > > > > Hi Suresh,
> > > > > 
> > > > > 	Thanks for the draft. I think it's short and clear. 
> > > > Some comments
> > > > > below:
> > > > > 
> > > > > 	- Section 2.1. Formation of interface identifier. The
> > > > issue described
> > > > > there only applies if SLAAC is used, right? If DHCP is
> > > > used, the issue
> > > > > is then on the network side, to ensure that the address
> > > provided to
> > > > > the new interface of the MN is the same that it was (or
> > is still)
> > > > > using on the previous interface, right?
> > > > 
> > > > Yes. This is correct. I can probably add a new section on
> > > the network
> > > > side about the DHCPv6 issue
> > > > 
> > > > > 
> > > > > 	- Section 2.2 Usage of the same address on multiple
> > > > interfaces. Since
> > > > > it seems that we cannot assume that is safe to use the same
> > > > address on
> > > > > multiple interfaces (without requiring changes on the MN
> > > > side), this
> > > > > implies that: a) if NETEXT work is restricted to work on
> > > solutions
> > > > > that do not impose changes on the MN, use cases requiring
> > > the MN to
> > > > > use the same address simultaneously are out of the scope of
> > > > NETEXT, b)
> > > > > we allow for changes on the MN side. Additionally, it might
> > > > be good to
> > > > > analyse if it is OK for the MN to receive (and send)
> > > > traffic addressed
> > > > > to the IPv6 address of one interface through a different
> > > interface
> > > > > (weak end-system model defined in RFC 1122 or
> > > > draft-thaler-ip-model-evolution).
> > > > 
> > > > While I agree with your analysis of the problem, are we
> > delving too
> > > > much into the solution space by adding any such text?
> > > > 
> > > > > 
> > > > > 	- IMHO, it'd be good to explicitly describe what a
> > > > "change on the MN"
> > > > > within the scope of NETEXT. For example, is it fine
> > assuming IEEE
> > > > > 802.21 support on the MN or is this "a change on the MN"?
> > > > 
> > > > Probably something to add to the charter?
> > > > 
> > > > Cheers
> > > > Suresh
> > > > 
> > > > _______________________________________________
> > > > NetExt mailing list
> > > > NetExt at mail.mobileip.jp
> > > > http://www.mobileip.jp/mailman/listinfo/netext
> > > > 
> > > 
> > > 
> > > This email and any attachments may contain legally
> > privileged and/or
> > > confidential information of Starent Networks, Corp.
> > > and is intended only for the individual or entity named in the 
> > > message.  The information transmitted may not be used to 
> create or 
> > > change any contractual obligations of Starent Networks, 
> Corp.  Any 
> > > review, retransmission, dissemination or other use of, or 
> taking of 
> > > any action in reliance upon this e-mail and its attachments
> > by persons
> > > or entities other than the intended recipient is 
> prohibited. If you 
> > > are not the intended recipient, please notify the sender
> > immediately
> > > -- by replying to this message or by sending an email to 
> > > postmaster at starentnetworks.com -- and destroy all copies of this 
> > > message and any attachments without reading or disclosing their 
> > > contents. Thank you.
> > > 
> > > _______________________________________________
> > > NetExt mailing list
> > > NetExt at mail.mobileip.jp
> > > http://www.mobileip.jp/mailman/listinfo/netext
> > > 
> > 
> > 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: Telemaco.Melia at alcatel-lucent.com (MELIA TELEMACO)
Date: Fri, 27 Feb 2009 10:21:37 +0100
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Rajeev,

Please see below.

telemaco 

-----Message d'origine-----
De : netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] De la part de Koodli, Rajeev
Envoy? : jeudi 26 f?vrier 2009 19:38
? : netext at mail.mobileip.jp
Objet : Re: [Netext] Inter-technology handover PS

 
Hi Domagoj,

> 
> Using access specific mechanims is fine for the cases where the access 
> system actually provides the needed functionality.

Good. My reasoning is that if there is a functionality which is crucial to an access system, it will provide it. We defining a mechanism at IP layer, which I would prefer as well, will turn out to be redundant and ignored.

> I don't think that we can expect every access system to readily 
> support whatever is needed by PMIP6 (WiMAX being one example of such 
> access system, it doesn't provide any clue about the HI). In such 
> cases it makes sense to put the additional functionality at the IP 
> layer, i.e. at the MAG/LMA/MN as they need to be updated anyway to 
> support inter-tech handover. Such add-on at the IP-layer could be 
> reused without modifications with any access system which does not 
> provide the appropriate L2 hints.

How does handover work in Wimax today without indication from the MN at the IP layer?

[TELE] Well people already documented some of the issues in http://tools.ietf.org/html/draft-patil-dhc-apn-attachtype-options-00. I might agree that this is not in scope of netext, but at least we need to clearly identify the issues.

To be clear, I do not wish to start from a point where we assume that MN involvement at the IP layer is necessary; at least for this BOF. The focus of this effort is to identify the problems which need to be solved. During the process, we can list what works and what doesn't as it is, without MN involvement; it needs to be done thoroughly.
But, the starting point is not "we need MN involvement". 

-Rajeev

> 
> domagoj
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp 
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Koodli, 
> > Rajeev
> > Sent: 24. veljaca 2009 23:01
> > To: netext at mail.mobileip.jp
> > Subject: Re: [Netext] Inter-technology handover PS
> > 
> > 
> > Hello folks,
> > 
> > Few thoughts on what we may need to focus here..
> > 
> > 1. For the purposes of this ID (i.e., inter-tech
> handovers), what is
> > most relevant here? What breaks today? Or, what we can improve? The 
> > breakdown of issues is a good start, but we need to tie it together 
> > for the problem at hand - inter-tech handovers.
> > 
> > 2. What _requires_ an IP protocol support on the MN side? 
> > Could this be done in an access-specific way? For instance,
> the HI in
> > PMIP6 is left up to the access system to determine, based on 
> > access-specific means where MN does take part. We need to ask a 
> > similar question here: if MN involvement is necessary, why
> couldn't we
> > let an access system provide the functionality?
> > 
> > 3. Assuming specific mechanisms (e.g., IEEE 802.21 etc.) is not 
> > necessary. Folks can use whatever they want, but specifying 
> > dependencies needs to be avoided.
> > 
> > Regards,
> > 
> > -Rajeev
> >  
> > 
> > > -----Original Message-----
> > > From: netext-bounces at mail.mobileip.jp 
> > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
> > Suresh Krishnan
> > > Sent: Thursday, February 19, 2009 3:19 PM
> > > To: cjbc at it.uc3m.es
> > > Cc: netext at mail.mobileip.jp
> > > Subject: Re: [Netext] Inter-technology handover PS
> > > 
> > > Hi Carlos,
> > >    Thanks for your comments. Please find responses inline
> > > 
> > > On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
> > > > * PGP Signed by an unknown key
> > > > 
> > > > Hi Suresh,
> > > > 
> > > > 	Thanks for the draft. I think it's short and clear. 
> > > Some comments
> > > > below:
> > > > 
> > > > 	- Section 2.1. Formation of interface identifier. The
> > > issue described
> > > > there only applies if SLAAC is used, right? If DHCP is
> > > used, the issue
> > > > is then on the network side, to ensure that the address
> > provided to
> > > > the new interface of the MN is the same that it was (or
> is still)
> > > > using on the previous interface, right?
> > > 
> > > Yes. This is correct. I can probably add a new section on
> > the network
> > > side about the DHCPv6 issue
> > > 
> > > > 
> > > > 	- Section 2.2 Usage of the same address on multiple
> > > interfaces. Since
> > > > it seems that we cannot assume that is safe to use the same
> > > address on
> > > > multiple interfaces (without requiring changes on the MN
> > > side), this
> > > > implies that: a) if NETEXT work is restricted to work on
> > solutions
> > > > that do not impose changes on the MN, use cases requiring
> > the MN to
> > > > use the same address simultaneously are out of the scope of
> > > NETEXT, b)
> > > > we allow for changes on the MN side. Additionally, it might
> > > be good to
> > > > analyse if it is OK for the MN to receive (and send)
> > > traffic addressed
> > > > to the IPv6 address of one interface through a different
> > interface
> > > > (weak end-system model defined in RFC 1122 or
> > > draft-thaler-ip-model-evolution).
> > > 
> > > While I agree with your analysis of the problem, are we
> delving too
> > > much into the solution space by adding any such text?
> > > 
> > > > 
> > > > 	- IMHO, it'd be good to explicitly describe what a
> > > "change on the MN"
> > > > within the scope of NETEXT. For example, is it fine
> assuming IEEE
> > > > 802.21 support on the MN or is this "a change on the MN"?
> > > 
> > > Probably something to add to the charter?
> > > 
> > > Cheers
> > > Suresh
> > > 
> > > _______________________________________________
> > > NetExt mailing list
> > > NetExt at mail.mobileip.jp
> > > http://www.mobileip.jp/mailman/listinfo/netext
> > > 
> > 
> > 
> > This email and any attachments may contain legally
> privileged and/or
> > confidential information of Starent Networks, Corp.
> > and is intended only for the individual or entity named in the 
> > message.  The information transmitted may not be used to create or 
> > change any contractual obligations of Starent Networks, Corp.  Any 
> > review, retransmission, dissemination or other use of, or taking of 
> > any action in reliance upon this e-mail and its attachments
> by persons
> > or entities other than the intended recipient is prohibited. If you 
> > are not the intended recipient, please notify the sender
> immediately
> > -- by replying to this message or by sending an email to 
> > postmaster at starentnetworks.com -- and destroy all copies of this 
> > message and any attachments without reading or disclosing their 
> > contents. Thank you.
> > 
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> > 
> 
> 

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Fri, 27 Feb 2009 08:46:36 +0800
Subject: [Netext] Inter-technology handovers PS considering Multihoming PS and Localized Routing PS
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi David,

Thanks for you summaries and comparisons. Please see in-line for some of
my thoughts. Thanks.

BR,
Mohana

-----Original Message-----
From: netext-bounces at mail.mobileip.jp
[mailto:netext-bounces at mail.mobileip.jp] On Behalf Of David Cypher
Sent: Friday, February 27, 2009 12:20 AM
To: netext at mail.mobileip.jp
Subject: [Netext] Inter-technology handovers PS considering Multihoming
PS and Localized Routing PS

Taking a look at the other two problem statements in terms of 
existing services and new services,
I do not think that any of the three problem statements can really be 
addressed in isolation.

Multihoming Problem Statement
Mobile node should be able to have more than one interface to the
network
- same access technology interfaces
	i) same IPv6 address	(not supported in RFC 5213)
	ii) different IPv6 address (supported)
- different access technology interfaces
	i) same IPv6 address	(supported but only for handover
(temporarily))
	ii) different IPv6 address	(supported)
[Mohana] RFC 5213 supports same address during inter access technology
handoff for session continuity. The multihoming PS is about being able
to get packets addressed to a HNP via both the interfaces or a single
address via both interfaes for the purpose of flow based routing and
simultaneous usage such as being able to utilize multiple inetrfaces for
flows that belong to a single HNP.

Also, I think our focus is multihoming for different accesstechnology
interfaces. 

NEW SERVICE being requested
- A) the ability to have the same IPv6 address on more than one 
interface (whether the access technology is the same or different) 
for a long period of time (i.e., not part of a handover/handoff).

[Mohana] Yes, this is multihoming and is different from inter access
technology handoff. I agree there is some overlap between multihoming
and inter access technology handoff. We are about to have a revised
draft soon for multihoming. In that we will classify issues that are
tied to simultaneous attachment via different access technology types as
main multihoming issues. And issues that are related to one interface
connected and another interface involved in handoff as some sub issues.
All the rest should be handled in the cateogory of pure inter access
technology handoff. 

Route optimization (RO) Problem statement
NEW SERVICES being requested
- A ) the ability to discover if a route between MN(MAG) and CN is 
better than the existing route between MN (LMA) and CN and
- B) the ability to use the route if found.

What interface will be used to find this optimized route if multiple 
accesses exist and multihoming is truly provided?
All of them?  One of them?  Which one?  Will there be a primary 
access interface or MN-HNP needed?

[Mohana] This is a good point. I think currently the RO preoblem
statement is considering route optimization with respect to a single
interface. Which interface to use in a simultanously connected MN is not
considered. I agree route optimization for multihomined or multiple
interfaced Mn is distantly related to multihoming, but it is not really
mutilhoming. I mean we cant lump all the issues w.r.t. multiple
interfaces into multihoming. In the multihoming PS draft we have kind of
defined the issues that are directly related multihoming.

SUMMARY of the three problem statements
======================================
Inter-technology and multihoming problem statements appear to be 
interrelated.  Inter-technology (2.2) claims that there are problems 
with mobile nodes' operating systems that do not permit multihoming 
(same address on multiple interfaces), which is what the Multihoming 
Problem statement is wanting.

Inter-technology PS 3.2 needs to be able to distinguish between 
handover and multiple interfaces.  This is another issue related to 
Multihoming (multiple interfaces)

Cannot look at inter-technology and multihoming as separate problem 
statements.  Instead perhaps the problem statements should be written 
from a NEW SERVICE being requested.

Cannot look at route optimization and multihoming as separate 
problems since the route optimized is dependent upon the attachment 
point and the address used for that attachment.

For example from the original PMIP the services were
- to supply the mobile node with a single set of MN-HNPs as it moved 
throughout the PMIP domain while maintaining only one active 
interface at a time or temporarily two during a handover.  (a single 
set of MN-HNPs for all of the mobile node's interfaces provided only 
one interface active at a time and used for handover only between two 
interfaces)
- to supply the mobile node with a single set of MN-HNPs per 
interface, if more than one interface was attached to the PMIP 
domain. (a different set of MN-HNPs for each interface)

SUMMARY of new services:
=============================================
The NEW SERVICES being requested by the three PSs are:
- multiple interfaces active at the same time and not part of handover
	i) using the same MN-HNPs
	ii) using different MN-HNPs
- a method for determining which service(s) the mobile node wants
- a method for determining the mobile node's intended usage of the 
multiple connections
- a method for determining the mobile node's capabilities to support 
PMIP services.
- the ability to discover if a route between MN(MAG) (on which 
interface) and CN is better than the existing route between MN (LMA) 
(on which interface) and CN and
- the ability to use the route if found.

David Cypher

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

From: xiayangsong at huawei.com (Frank Xia)
Date: Thu, 26 Feb 2009 17:40:30 -0600
Subject: [Netext] Review of the Multihoming PS I-D
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Rajeev

I just had a quick look on your draft
http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt.
It is great, and I also would appreciate you if you can review
my draft 
http://www.ietf.org/internet-drafts/draft-xia-netext-flow-binding-00.txt
which tried to solve the same problems.

Just I discussed with Gerardo in the mailing list
who I assume  is also working on 3GPP 23.861,
the motivation of flowing binding is to make full use of
precious air resource.  IMO, MAGs have more information
on the usage of air interface than LMA.

Thus, relating to your draft, my points are
1) In most case, MAGs initiate flow binding, which is
    consistent with MN's behavior in Mobile IPv6 flow binding.
2)T-MAG may be involved in flowing binding decision.
   S-MAG request offloading some traffic to T-MAG which
   has right to decide on it's own discretion.
3)Mostly your draft deal with downstreams redirection,
  while upstreams traffic treatment need more consideration.

BR
Frank

----- Original Message ----- 
From: "Koodli, Rajeev" <rkoodli at starentnetworks.com>
To: <netext at mail.mobileip.jp>
Sent: Thursday, February 26, 2009 4:11 PM
Subject: Re: [Netext] Review of the Multihoming PS I-D

Hi,

> IMO, the flow binding( or flow handover/flow mobility)
> requirement is not neccessarily tied to address configuration
> model of mobile nodes.
>
> Multiple interface may or may not shared HNP.

My point is that when you move a flow (say belonging to HNP-1) from one 
interface to another (which has, say HNP-2), you can achieve flow mobility. 
In that sense you share HNP-1 across the two interfaces.

Regards,

-Rajeev

>
> BR
> Frank
>
>
> ----- Original Message -----
> From: "Koodli, Rajeev" <rkoodli at starentnetworks.com>
> To: <netext at mail.mobileip.jp>
> Sent: Thursday, February 26, 2009 1:22 PM
> Subject: Re: [Netext] Review of the Multihoming PS I-D
>
>
>
> Hello folks,
>
> If we allow the same HNP across multiple interfaces (as a form of
> multihoming), then moving one or more flows would be a
> natural extension I
> think. At least, that's my thinking when writing
> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover
> -00.txt last
> year.
>
> Regards,
>
> -Rajeev
>
>
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Frank Xia
> > Sent: Thursday, February 19, 2009 8:42 AM
> > To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com
> > Cc: netext at mail.mobileip.jp;
> > Mohana.Jeyatharan at sg.panasonic.com;
> Telemaco.Melia at alcatel-lucent.com
> > Subject: Re: [Netext] Review of the Multihoming PS I-D
> >
> > Hi Gerardo
> >
> > I know there is official requirement from 3GPP, and I am  not
> > offically  asked  to push in IETF either  :-).
> >
> > >From business perspective,  what operators care is how
> > to make full use of their scarce air resource.
> > This is one of main motivation to have dual mode terminals
> > with 3GPP and WiFi (you can buy one from T-Mobile :-) ).
> >
> > When the dual mode terminal moves  home where WLAN access is
> > available,  it prefer offloading some low QoS service from
> > 3GPP to WiFi.  At the same time, high QoS service still
> > remains in 3GPP.
> >
> > BR
> > Frank
> >
> >
> > ----- Original Message -----
> > From: "Giaretta, Gerardo" <gerardog at qualcomm.com>
> > To: "Frank Xia" <xiayangsong at huawei.com>; <cjbc at it.uc3m.es>;
> > <Basavaraj.Patil at nokia.com>
> > Cc: <netext at mail.mobileip.jp>; <Mohana.Jeyatharan at sg.panasonic.com>;
> > <Telemaco.Melia at alcatel-lucent.com>
> > Sent: Thursday, February 19, 2009 9:56 AM
> > Subject: RE: [Netext] Review of the Multihoming PS I-D
> >
> >
> > Hi Frank,
> >
> > I am happy if Huawei wants you to push this in the IETF, I
> > hope you can make it :-)
> >
> > I wanted just to provide the indication that there is not any
> > official requirement from 3GPP.
> >
> > We can then discuss about whatever business can drive this
> > (what radios do you have in mind when you talk about
> > multihoming and flow mobility for PMIP?).
> >
> > Gerardo
> >
> > > -----Original Message-----
> > > From: Frank Xia [mailto:xiayangsong at huawei.com]
> > > Sent: Thursday, February 19, 2009 7:51 AM
> > > To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com
> > > Cc: netext at mail.mobileip.jp; Mohana.Jeyatharan at sg.panasonic.com;
> > > Telemaco.Melia at alcatel-lucent.com
> > > Subject: Re: [Netext] Review of the Multihoming PS I-D
> > >
> > > Hi All
> > >
> > > My 3GPP colleagues also suggested me  pushing in  IETF community.
> > > If we talk about 3GPP requirment, there is even no specific PMIPv6
> > > multi-homing requirement.
> > >
> > > My point is business driving technical employment.
> > > IMO, flow mobility is  clearly required in PMIP deployment
> > environment.
> > >
> > > BR
> > > Frank
> > >
> > > ----- Original Message -----
> > > From: "Giaretta, Gerardo" <gerardog at qualcomm.com>
> > > To: <cjbc at it.uc3m.es>; <Basavaraj.Patil at nokia.com>
> > > Cc: <netext at mail.mobileip.jp>;
> <Mohana.Jeyatharan at sg.panasonic.com>;
> > > <Telemaco.Melia at alcatel-lucent.com>
> > > Sent: Thursday, February 19, 2009 4:16 AM
> > > Subject: Re: [Netext] Review of the Multihoming PS I-D
> > >
> > >
> > > Hi all,
> > >
> > > To clarify flow mobility is not a requirement for PMIPv6
> > right now in
> > > 3GPP.
> > > There is a study item ongoing but 3GPP has not yet decided
> > that flow
> > > mobility is needed for PMIPv6.
> > >
> > > Cheers,
> > > Gerardo
> > > (from Budapest, 3GPP SA2 meeting)
> > >
> > > > -----Original Message-----
> > > > From: netext-bounces at mail.mobileip.jp
> > > > [mailto:netext-bounces at mail.mobileip.jp]
> > > > On Behalf Of Carlos Jes?s Bernardos Cano
> > > > Sent: Thursday, February 19, 2009 1:21 AM
> > > > To: Basavaraj.Patil at nokia.com
> > > > Cc: Mohana.Jeyatharan at sg.panasonic.com;
> > > > Telemaco.Melia at alcatel-lucent.com;
> > > > netext at mail.mobileip.jp
> > > > Subject: Re: [Netext] Review of the Multihoming PS I-D
> > > >
> > > > Hi,
> > > >
> > > > One question: flow mobility seems to be an interesting
> > feature that
> > > > is a requirement from 3GPP, it is related with
> > multihoming but it is
> > > > not strictly a multihoming isse, right? I mean, multihoming
> > > > extensions would likely make easier to support flow
> mobility, but
> > > > would probably require additional mechanisms. How do we capture
> > > > this? I'm not sure the multihoming PS is the right place
> > for that,
> > > > maybe the multihoming PS can point out that, but we need
> > an explicit
> > > > document (and charter item) for dealing with flow mobility.
> > > > What
> > > > do others think?
> > > >
> > > > Thanks!
> > > >
> > > > Carlos
> > > >
> > > > El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com
> > > > escribi?:
> > > > > It may be of interest in the context of multihoming to
> > consider moving
> > > > > a flow from one interface to another. A flow which is
> > associated with
> > > > > an interface on the MN may be moved to another
> > interface in the case
> > > > > of a multihomed host for various reasons. This may be
> > viewed as a
> > > > > handover as well from the flow perspective. Multihoming
> > enables the
> > > > > possibility to move flows between interfaces. I think
> > we could keep
> > > > > this in the context of the multihoming discussion if there is
> > > > > consensus
> > > > > on
> > > > it.
> > > > >
> > > > > -Raj
> > > > >
> > > > >
> > > > > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan"
> > > > > <Mohana.Jeyatharan at sg.panasonic.com> wrote:
> > > > >
> > > > > > Hi Hidetoshi,
> > > > > >
> > > > > > In Multihoming PS ID, there are some handoff
> > optimization scenarios
> > > > involved.
> > > > > > For example optmizing the handoff of a certain
> > interface by means of
> > > > > > another, and achieving flow mobility via another
> > interface during
> > > > > > disconnection. These events are triggered due to handoff or
> > > > > > disconnection, but the scenarios are associated with
> > multihoming.
> > > > > > That is being able to receive a flow that is usually
> > destined to an
> > > > > > interface via another "connected" interface. This is
> > where these
> > > > > > scenarios are different from normal handoff and more tied to
> > > > > > multihoming.
> > > > > >
> > > > > > However, I agree that these are also tied with
> > handoff and some
> > > > > > confusion is there. Anyway, we are planning to revise the
> > > > > > multihoming PS draft and are thinking of focusing on the
> > > > > > disconnection scenario, handoff optimization as less
> > focus scenarios
> > > > > > and
> > > > focus on scenarios that are cateogorized by Raj.
> > > > > >
> > > > > > BR,
> > > > > > Mohana
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
> > > > > > Sent: Tuesday, February 17, 2009 12:42 PM
> > > > > > To: Mohana Jeyatharan
> > > > > > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch;
> > > > > > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> > > > > > Subject: Re: [Netext] Review of the Multihoming PS I-D
> > > > > >
> > > > > > Hi Mohana and all,
> > > > > >
> > > > > > I think your scenario is viable, but we should probably more
> > > > > > carefully clarify the difference between multihoming
> > and handover.
> > > > > > Assigning the same address to different interfaces on
> > the MN for a
> > > > > > sufficiently long time sounds like multihoming;
> > however, if this
> > > > > > situation holds only for a short period of time for
> > MN's movement or
> > > > > > fail over or for whatever reason, that sounds like
> > handover. This
> > > > > > difference would affect the behavior of the LMA and MAG(s).
> > > > > >
> > > > > > In Section 2 of the Multihoming PS document, Issues
> related to
> > > > > > handoff performance and those related to flow
> > mobility during sudden
> > > > > > disconnection appear to be categorized into handover.
> > If all agree
> > > > > > that these issues should also be included in
> > multihoming, that's
> > > > > > fine. I would just like to make sure of it first of all.
> > > > > >
> > > > > > Regards,
> > > > > > --
> > > > > > Hidetoshi
> > > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > NetExt mailing list
> > > > > NetExt at mail.mobileip.jp
> > > > > http://www.mobileip.jp/mailman/listinfo/netext
> > > > --
> > > >  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> > > >  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > >   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> > > >         Deployment Experiences on Vehicular networks
> > > >                   http://www.weedev.org/
> > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >
> > > _______________________________________________
> > > NetExt mailing list
> > > NetExt at mail.mobileip.jp
> > > http://www.mobileip.jp/mailman/listinfo/netext
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> >
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>
>

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext 

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Thu, 26 Feb 2009 17:11:44 -0500
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

> IMO, the flow binding( or flow handover/flow mobility) 
> requirement is not neccessarily tied to address configuration 
> model of mobile nodes.
> 
> Multiple interface may or may not shared HNP.

My point is that when you move a flow (say belonging to HNP-1) from one interface to another (which has, say HNP-2), you can achieve flow mobility. In that sense you share HNP-1 across the two interfaces.

Regards,

-Rajeev

> 
> BR
> Frank
> 
> 
> ----- Original Message -----
> From: "Koodli, Rajeev" <rkoodli at starentnetworks.com>
> To: <netext at mail.mobileip.jp>
> Sent: Thursday, February 26, 2009 1:22 PM
> Subject: Re: [Netext] Review of the Multihoming PS I-D
> 
> 
> 
> Hello folks,
> 
> If we allow the same HNP across multiple interfaces (as a form of 
> multihoming), then moving one or more flows would be a 
> natural extension I 
> think. At least, that's my thinking when writing 
> http://www.ietf.org/internet-drafts/draft-koodli-flow-handover
> -00.txt last 
> year.
> 
> Regards,
> 
> -Rajeev
> 
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Frank Xia
> > Sent: Thursday, February 19, 2009 8:42 AM
> > To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com
> > Cc: netext at mail.mobileip.jp;
> > Mohana.Jeyatharan at sg.panasonic.com; 
> Telemaco.Melia at alcatel-lucent.com
> > Subject: Re: [Netext] Review of the Multihoming PS I-D
> >
> > Hi Gerardo
> >
> > I know there is official requirement from 3GPP, and I am  not
> > offically  asked  to push in IETF either  :-).
> >
> > >From business perspective,  what operators care is how
> > to make full use of their scarce air resource.
> > This is one of main motivation to have dual mode terminals
> > with 3GPP and WiFi (you can buy one from T-Mobile :-) ).
> >
> > When the dual mode terminal moves  home where WLAN access is
> > available,  it prefer offloading some low QoS service from
> > 3GPP to WiFi.  At the same time, high QoS service still
> > remains in 3GPP.
> >
> > BR
> > Frank
> >
> >
> > ----- Original Message -----
> > From: "Giaretta, Gerardo" <gerardog at qualcomm.com>
> > To: "Frank Xia" <xiayangsong at huawei.com>; <cjbc at it.uc3m.es>;
> > <Basavaraj.Patil at nokia.com>
> > Cc: <netext at mail.mobileip.jp>; <Mohana.Jeyatharan at sg.panasonic.com>;
> > <Telemaco.Melia at alcatel-lucent.com>
> > Sent: Thursday, February 19, 2009 9:56 AM
> > Subject: RE: [Netext] Review of the Multihoming PS I-D
> >
> >
> > Hi Frank,
> >
> > I am happy if Huawei wants you to push this in the IETF, I
> > hope you can make it :-)
> >
> > I wanted just to provide the indication that there is not any
> > official requirement from 3GPP.
> >
> > We can then discuss about whatever business can drive this
> > (what radios do you have in mind when you talk about
> > multihoming and flow mobility for PMIP?).
> >
> > Gerardo
> >
> > > -----Original Message-----
> > > From: Frank Xia [mailto:xiayangsong at huawei.com]
> > > Sent: Thursday, February 19, 2009 7:51 AM
> > > To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com
> > > Cc: netext at mail.mobileip.jp; Mohana.Jeyatharan at sg.panasonic.com;
> > > Telemaco.Melia at alcatel-lucent.com
> > > Subject: Re: [Netext] Review of the Multihoming PS I-D
> > >
> > > Hi All
> > >
> > > My 3GPP colleagues also suggested me  pushing in  IETF community.
> > > If we talk about 3GPP requirment, there is even no specific PMIPv6
> > > multi-homing requirement.
> > >
> > > My point is business driving technical employment.
> > > IMO, flow mobility is  clearly required in PMIP deployment
> > environment.
> > >
> > > BR
> > > Frank
> > >
> > > ----- Original Message -----
> > > From: "Giaretta, Gerardo" <gerardog at qualcomm.com>
> > > To: <cjbc at it.uc3m.es>; <Basavaraj.Patil at nokia.com>
> > > Cc: <netext at mail.mobileip.jp>; 
> <Mohana.Jeyatharan at sg.panasonic.com>;
> > > <Telemaco.Melia at alcatel-lucent.com>
> > > Sent: Thursday, February 19, 2009 4:16 AM
> > > Subject: Re: [Netext] Review of the Multihoming PS I-D
> > >
> > >
> > > Hi all,
> > >
> > > To clarify flow mobility is not a requirement for PMIPv6
> > right now in
> > > 3GPP.
> > > There is a study item ongoing but 3GPP has not yet decided
> > that flow
> > > mobility is needed for PMIPv6.
> > >
> > > Cheers,
> > > Gerardo
> > > (from Budapest, 3GPP SA2 meeting)
> > >
> > > > -----Original Message-----
> > > > From: netext-bounces at mail.mobileip.jp
> > > > [mailto:netext-bounces at mail.mobileip.jp]
> > > > On Behalf Of Carlos Jes?s Bernardos Cano
> > > > Sent: Thursday, February 19, 2009 1:21 AM
> > > > To: Basavaraj.Patil at nokia.com
> > > > Cc: Mohana.Jeyatharan at sg.panasonic.com;
> > > > Telemaco.Melia at alcatel-lucent.com;
> > > > netext at mail.mobileip.jp
> > > > Subject: Re: [Netext] Review of the Multihoming PS I-D
> > > >
> > > > Hi,
> > > >
> > > > One question: flow mobility seems to be an interesting
> > feature that
> > > > is a requirement from 3GPP, it is related with
> > multihoming but it is
> > > > not strictly a multihoming isse, right? I mean, multihoming
> > > > extensions would likely make easier to support flow 
> mobility, but
> > > > would probably require additional mechanisms. How do we capture
> > > > this? I'm not sure the multihoming PS is the right place
> > for that,
> > > > maybe the multihoming PS can point out that, but we need
> > an explicit
> > > > document (and charter item) for dealing with flow mobility.
> > > > What
> > > > do others think?
> > > >
> > > > Thanks!
> > > >
> > > > Carlos
> > > >
> > > > El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com
> > > > escribi?:
> > > > > It may be of interest in the context of multihoming to
> > consider moving
> > > > > a flow from one interface to another. A flow which is
> > associated with
> > > > > an interface on the MN may be moved to another
> > interface in the case
> > > > > of a multihomed host for various reasons. This may be
> > viewed as a
> > > > > handover as well from the flow perspective. Multihoming
> > enables the
> > > > > possibility to move flows between interfaces. I think
> > we could keep
> > > > > this in the context of the multihoming discussion if there is
> > > > > consensus
> > > > > on
> > > > it.
> > > > >
> > > > > -Raj
> > > > >
> > > > >
> > > > > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan"
> > > > > <Mohana.Jeyatharan at sg.panasonic.com> wrote:
> > > > >
> > > > > > Hi Hidetoshi,
> > > > > >
> > > > > > In Multihoming PS ID, there are some handoff
> > optimization scenarios
> > > > involved.
> > > > > > For example optmizing the handoff of a certain
> > interface by means of
> > > > > > another, and achieving flow mobility via another
> > interface during
> > > > > > disconnection. These events are triggered due to handoff or
> > > > > > disconnection, but the scenarios are associated with
> > multihoming.
> > > > > > That is being able to receive a flow that is usually
> > destined to an
> > > > > > interface via another "connected" interface. This is
> > where these
> > > > > > scenarios are different from normal handoff and more tied to
> > > > > > multihoming.
> > > > > >
> > > > > > However, I agree that these are also tied with
> > handoff and some
> > > > > > confusion is there. Anyway, we are planning to revise the
> > > > > > multihoming PS draft and are thinking of focusing on the
> > > > > > disconnection scenario, handoff optimization as less
> > focus scenarios
> > > > > > and
> > > > focus on scenarios that are cateogorized by Raj.
> > > > > >
> > > > > > BR,
> > > > > > Mohana
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
> > > > > > Sent: Tuesday, February 17, 2009 12:42 PM
> > > > > > To: Mohana Jeyatharan
> > > > > > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch;
> > > > > > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> > > > > > Subject: Re: [Netext] Review of the Multihoming PS I-D
> > > > > >
> > > > > > Hi Mohana and all,
> > > > > >
> > > > > > I think your scenario is viable, but we should probably more
> > > > > > carefully clarify the difference between multihoming
> > and handover.
> > > > > > Assigning the same address to different interfaces on
> > the MN for a
> > > > > > sufficiently long time sounds like multihoming;
> > however, if this
> > > > > > situation holds only for a short period of time for
> > MN's movement or
> > > > > > fail over or for whatever reason, that sounds like
> > handover. This
> > > > > > difference would affect the behavior of the LMA and MAG(s).
> > > > > >
> > > > > > In Section 2 of the Multihoming PS document, Issues 
> related to
> > > > > > handoff performance and those related to flow
> > mobility during sudden
> > > > > > disconnection appear to be categorized into handover.
> > If all agree
> > > > > > that these issues should also be included in
> > multihoming, that's
> > > > > > fine. I would just like to make sure of it first of all.
> > > > > >
> > > > > > Regards,
> > > > > > --
> > > > > > Hidetoshi
> > > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > NetExt mailing list
> > > > > NetExt at mail.mobileip.jp
> > > > > http://www.mobileip.jp/mailman/listinfo/netext
> > > > --
> > > >  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> > > >  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > >   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> > > >         Deployment Experiences on Vehicular networks
> > > >                   http://www.weedev.org/
> > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >
> > > _______________________________________________
> > > NetExt mailing list
> > > NetExt at mail.mobileip.jp
> > > http://www.mobileip.jp/mailman/listinfo/netext
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> >
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext 
> 
> 

From: xiayangsong at huawei.com (Frank Xia)
Date: Thu, 26 Feb 2009 14:12:18 -0600
Subject: [Netext] Review of the Multihoming PS I-D
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Rajeev

IMO, the flow binding( or flow handover/flow mobility)
requirement is not neccessarily tied to address configuration
model of mobile nodes.

Multiple interface may or may not shared HNP.

BR
Frank

----- Original Message ----- 
From: "Koodli, Rajeev" <rkoodli at starentnetworks.com>
To: <netext at mail.mobileip.jp>
Sent: Thursday, February 26, 2009 1:22 PM
Subject: Re: [Netext] Review of the Multihoming PS I-D

Hello folks,

If we allow the same HNP across multiple interfaces (as a form of 
multihoming), then moving one or more flows would be a natural extension I 
think. At least, that's my thinking when writing 
http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt last 
year.

Regards,

-Rajeev

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Frank Xia
> Sent: Thursday, February 19, 2009 8:42 AM
> To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com
> Cc: netext at mail.mobileip.jp;
> Mohana.Jeyatharan at sg.panasonic.com; Telemaco.Melia at alcatel-lucent.com
> Subject: Re: [Netext] Review of the Multihoming PS I-D
>
> Hi Gerardo
>
> I know there is official requirement from 3GPP, and I am  not
> offically  asked  to push in IETF either  :-).
>
> >From business perspective,  what operators care is how
> to make full use of their scarce air resource.
> This is one of main motivation to have dual mode terminals
> with 3GPP and WiFi (you can buy one from T-Mobile :-) ).
>
> When the dual mode terminal moves  home where WLAN access is
> available,  it prefer offloading some low QoS service from
> 3GPP to WiFi.  At the same time, high QoS service still
> remains in 3GPP.
>
> BR
> Frank
>
>
> ----- Original Message -----
> From: "Giaretta, Gerardo" <gerardog at qualcomm.com>
> To: "Frank Xia" <xiayangsong at huawei.com>; <cjbc at it.uc3m.es>;
> <Basavaraj.Patil at nokia.com>
> Cc: <netext at mail.mobileip.jp>; <Mohana.Jeyatharan at sg.panasonic.com>;
> <Telemaco.Melia at alcatel-lucent.com>
> Sent: Thursday, February 19, 2009 9:56 AM
> Subject: RE: [Netext] Review of the Multihoming PS I-D
>
>
> Hi Frank,
>
> I am happy if Huawei wants you to push this in the IETF, I
> hope you can make it :-)
>
> I wanted just to provide the indication that there is not any
> official requirement from 3GPP.
>
> We can then discuss about whatever business can drive this
> (what radios do you have in mind when you talk about
> multihoming and flow mobility for PMIP?).
>
> Gerardo
>
> > -----Original Message-----
> > From: Frank Xia [mailto:xiayangsong at huawei.com]
> > Sent: Thursday, February 19, 2009 7:51 AM
> > To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com
> > Cc: netext at mail.mobileip.jp; Mohana.Jeyatharan at sg.panasonic.com;
> > Telemaco.Melia at alcatel-lucent.com
> > Subject: Re: [Netext] Review of the Multihoming PS I-D
> >
> > Hi All
> >
> > My 3GPP colleagues also suggested me  pushing in  IETF community.
> > If we talk about 3GPP requirment, there is even no specific PMIPv6
> > multi-homing requirement.
> >
> > My point is business driving technical employment.
> > IMO, flow mobility is  clearly required in PMIP deployment
> environment.
> >
> > BR
> > Frank
> >
> > ----- Original Message -----
> > From: "Giaretta, Gerardo" <gerardog at qualcomm.com>
> > To: <cjbc at it.uc3m.es>; <Basavaraj.Patil at nokia.com>
> > Cc: <netext at mail.mobileip.jp>; <Mohana.Jeyatharan at sg.panasonic.com>;
> > <Telemaco.Melia at alcatel-lucent.com>
> > Sent: Thursday, February 19, 2009 4:16 AM
> > Subject: Re: [Netext] Review of the Multihoming PS I-D
> >
> >
> > Hi all,
> >
> > To clarify flow mobility is not a requirement for PMIPv6
> right now in
> > 3GPP.
> > There is a study item ongoing but 3GPP has not yet decided
> that flow
> > mobility is needed for PMIPv6.
> >
> > Cheers,
> > Gerardo
> > (from Budapest, 3GPP SA2 meeting)
> >
> > > -----Original Message-----
> > > From: netext-bounces at mail.mobileip.jp
> > > [mailto:netext-bounces at mail.mobileip.jp]
> > > On Behalf Of Carlos Jes?s Bernardos Cano
> > > Sent: Thursday, February 19, 2009 1:21 AM
> > > To: Basavaraj.Patil at nokia.com
> > > Cc: Mohana.Jeyatharan at sg.panasonic.com;
> > > Telemaco.Melia at alcatel-lucent.com;
> > > netext at mail.mobileip.jp
> > > Subject: Re: [Netext] Review of the Multihoming PS I-D
> > >
> > > Hi,
> > >
> > > One question: flow mobility seems to be an interesting
> feature that
> > > is a requirement from 3GPP, it is related with
> multihoming but it is
> > > not strictly a multihoming isse, right? I mean, multihoming
> > > extensions would likely make easier to support flow mobility, but
> > > would probably require additional mechanisms. How do we capture
> > > this? I'm not sure the multihoming PS is the right place
> for that,
> > > maybe the multihoming PS can point out that, but we need
> an explicit
> > > document (and charter item) for dealing with flow mobility.
> > > What
> > > do others think?
> > >
> > > Thanks!
> > >
> > > Carlos
> > >
> > > El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com
> > > escribi?:
> > > > It may be of interest in the context of multihoming to
> consider moving
> > > > a flow from one interface to another. A flow which is
> associated with
> > > > an interface on the MN may be moved to another
> interface in the case
> > > > of a multihomed host for various reasons. This may be
> viewed as a
> > > > handover as well from the flow perspective. Multihoming
> enables the
> > > > possibility to move flows between interfaces. I think
> we could keep
> > > > this in the context of the multihoming discussion if there is
> > > > consensus
> > > > on
> > > it.
> > > >
> > > > -Raj
> > > >
> > > >
> > > > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan"
> > > > <Mohana.Jeyatharan at sg.panasonic.com> wrote:
> > > >
> > > > > Hi Hidetoshi,
> > > > >
> > > > > In Multihoming PS ID, there are some handoff
> optimization scenarios
> > > involved.
> > > > > For example optmizing the handoff of a certain
> interface by means of
> > > > > another, and achieving flow mobility via another
> interface during
> > > > > disconnection. These events are triggered due to handoff or
> > > > > disconnection, but the scenarios are associated with
> multihoming.
> > > > > That is being able to receive a flow that is usually
> destined to an
> > > > > interface via another "connected" interface. This is
> where these
> > > > > scenarios are different from normal handoff and more tied to
> > > > > multihoming.
> > > > >
> > > > > However, I agree that these are also tied with
> handoff and some
> > > > > confusion is there. Anyway, we are planning to revise the
> > > > > multihoming PS draft and are thinking of focusing on the
> > > > > disconnection scenario, handoff optimization as less
> focus scenarios
> > > > > and
> > > focus on scenarios that are cateogorized by Raj.
> > > > >
> > > > > BR,
> > > > > Mohana
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
> > > > > Sent: Tuesday, February 17, 2009 12:42 PM
> > > > > To: Mohana Jeyatharan
> > > > > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch;
> > > > > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> > > > > Subject: Re: [Netext] Review of the Multihoming PS I-D
> > > > >
> > > > > Hi Mohana and all,
> > > > >
> > > > > I think your scenario is viable, but we should probably more
> > > > > carefully clarify the difference between multihoming
> and handover.
> > > > > Assigning the same address to different interfaces on
> the MN for a
> > > > > sufficiently long time sounds like multihoming;
> however, if this
> > > > > situation holds only for a short period of time for
> MN's movement or
> > > > > fail over or for whatever reason, that sounds like
> handover. This
> > > > > difference would affect the behavior of the LMA and MAG(s).
> > > > >
> > > > > In Section 2 of the Multihoming PS document, Issues related to
> > > > > handoff performance and those related to flow
> mobility during sudden
> > > > > disconnection appear to be categorized into handover.
> If all agree
> > > > > that these issues should also be included in
> multihoming, that's
> > > > > fine. I would just like to make sure of it first of all.
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Hidetoshi
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > NetExt mailing list
> > > > NetExt at mail.mobileip.jp
> > > > http://www.mobileip.jp/mailman/listinfo/netext
> > > --
> > >  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> > >  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> > >         Deployment Experiences on Vehicular networks
> > >                   http://www.weedev.org/
> > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext 

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Thu, 26 Feb 2009 14:22:43 -0500
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hello folks,

If we allow the same HNP across multiple interfaces (as a form of multihoming), then moving one or more flows would be a natural extension I think. At least, that's my thinking when writing http://www.ietf.org/internet-drafts/draft-koodli-flow-handover-00.txt last year.

Regards,

-Rajeev

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Frank Xia
> Sent: Thursday, February 19, 2009 8:42 AM
> To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com
> Cc: netext at mail.mobileip.jp; 
> Mohana.Jeyatharan at sg.panasonic.com; Telemaco.Melia at alcatel-lucent.com
> Subject: Re: [Netext] Review of the Multihoming PS I-D
> 
> Hi Gerardo
> 
> I know there is official requirement from 3GPP, and I am  not 
> offically  asked  to push in IETF either  :-).
> 
> >From business perspective,  what operators care is how
> to make full use of their scarce air resource.
> This is one of main motivation to have dual mode terminals 
> with 3GPP and WiFi (you can buy one from T-Mobile :-) ).
> 
> When the dual mode terminal moves  home where WLAN access is 
> available,  it prefer offloading some low QoS service from 
> 3GPP to WiFi.  At the same time, high QoS service still 
> remains in 3GPP.
> 
> BR
> Frank
> 
> 
> ----- Original Message -----
> From: "Giaretta, Gerardo" <gerardog at qualcomm.com>
> To: "Frank Xia" <xiayangsong at huawei.com>; <cjbc at it.uc3m.es>; 
> <Basavaraj.Patil at nokia.com>
> Cc: <netext at mail.mobileip.jp>; <Mohana.Jeyatharan at sg.panasonic.com>;
> <Telemaco.Melia at alcatel-lucent.com>
> Sent: Thursday, February 19, 2009 9:56 AM
> Subject: RE: [Netext] Review of the Multihoming PS I-D
> 
> 
> Hi Frank,
> 
> I am happy if Huawei wants you to push this in the IETF, I 
> hope you can make it :-)
> 
> I wanted just to provide the indication that there is not any 
> official requirement from 3GPP.
> 
> We can then discuss about whatever business can drive this 
> (what radios do you have in mind when you talk about 
> multihoming and flow mobility for PMIP?).
> 
> Gerardo
> 
> > -----Original Message-----
> > From: Frank Xia [mailto:xiayangsong at huawei.com]
> > Sent: Thursday, February 19, 2009 7:51 AM
> > To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com
> > Cc: netext at mail.mobileip.jp; Mohana.Jeyatharan at sg.panasonic.com;
> > Telemaco.Melia at alcatel-lucent.com
> > Subject: Re: [Netext] Review of the Multihoming PS I-D
> >
> > Hi All
> >
> > My 3GPP colleagues also suggested me  pushing in  IETF community.
> > If we talk about 3GPP requirment, there is even no specific PMIPv6 
> > multi-homing requirement.
> >
> > My point is business driving technical employment.
> > IMO, flow mobility is  clearly required in PMIP deployment 
> environment.
> >
> > BR
> > Frank
> >
> > ----- Original Message -----
> > From: "Giaretta, Gerardo" <gerardog at qualcomm.com>
> > To: <cjbc at it.uc3m.es>; <Basavaraj.Patil at nokia.com>
> > Cc: <netext at mail.mobileip.jp>; <Mohana.Jeyatharan at sg.panasonic.com>;
> > <Telemaco.Melia at alcatel-lucent.com>
> > Sent: Thursday, February 19, 2009 4:16 AM
> > Subject: Re: [Netext] Review of the Multihoming PS I-D
> >
> >
> > Hi all,
> >
> > To clarify flow mobility is not a requirement for PMIPv6 
> right now in 
> > 3GPP.
> > There is a study item ongoing but 3GPP has not yet decided 
> that flow 
> > mobility is needed for PMIPv6.
> >
> > Cheers,
> > Gerardo
> > (from Budapest, 3GPP SA2 meeting)
> >
> > > -----Original Message-----
> > > From: netext-bounces at mail.mobileip.jp 
> > > [mailto:netext-bounces at mail.mobileip.jp]
> > > On Behalf Of Carlos Jes?s Bernardos Cano
> > > Sent: Thursday, February 19, 2009 1:21 AM
> > > To: Basavaraj.Patil at nokia.com
> > > Cc: Mohana.Jeyatharan at sg.panasonic.com;
> > > Telemaco.Melia at alcatel-lucent.com;
> > > netext at mail.mobileip.jp
> > > Subject: Re: [Netext] Review of the Multihoming PS I-D
> > >
> > > Hi,
> > >
> > > One question: flow mobility seems to be an interesting 
> feature that 
> > > is a requirement from 3GPP, it is related with 
> multihoming but it is 
> > > not strictly a multihoming isse, right? I mean, multihoming 
> > > extensions would likely make easier to support flow mobility, but 
> > > would probably require additional mechanisms. How do we capture 
> > > this? I'm not sure the multihoming PS is the right place 
> for that, 
> > > maybe the multihoming PS can point out that, but we need 
> an explicit 
> > > document (and charter item) for dealing with flow mobility.
> > > What
> > > do others think?
> > >
> > > Thanks!
> > >
> > > Carlos
> > >
> > > El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com
> > > escribi?:
> > > > It may be of interest in the context of multihoming to 
> consider moving
> > > > a flow from one interface to another. A flow which is 
> associated with
> > > > an interface on the MN may be moved to another 
> interface in the case
> > > > of a multihomed host for various reasons. This may be 
> viewed as a
> > > > handover as well from the flow perspective. Multihoming 
> enables the
> > > > possibility to move flows between interfaces. I think 
> we could keep
> > > > this in the context of the multihoming discussion if there is 
> > > > consensus
> > > > on
> > > it.
> > > >
> > > > -Raj
> > > >
> > > >
> > > > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan"
> > > > <Mohana.Jeyatharan at sg.panasonic.com> wrote:
> > > >
> > > > > Hi Hidetoshi,
> > > > >
> > > > > In Multihoming PS ID, there are some handoff 
> optimization scenarios
> > > involved.
> > > > > For example optmizing the handoff of a certain 
> interface by means of
> > > > > another, and achieving flow mobility via another 
> interface during
> > > > > disconnection. These events are triggered due to handoff or
> > > > > disconnection, but the scenarios are associated with 
> multihoming.
> > > > > That is being able to receive a flow that is usually 
> destined to an
> > > > > interface via another "connected" interface. This is 
> where these
> > > > > scenarios are different from normal handoff and more tied to
> > > > > multihoming.
> > > > >
> > > > > However, I agree that these are also tied with 
> handoff and some
> > > > > confusion is there. Anyway, we are planning to revise the
> > > > > multihoming PS draft and are thinking of focusing on the
> > > > > disconnection scenario, handoff optimization as less 
> focus scenarios
> > > > > and
> > > focus on scenarios that are cateogorized by Raj.
> > > > >
> > > > > BR,
> > > > > Mohana
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
> > > > > Sent: Tuesday, February 17, 2009 12:42 PM
> > > > > To: Mohana Jeyatharan
> > > > > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch;
> > > > > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> > > > > Subject: Re: [Netext] Review of the Multihoming PS I-D
> > > > >
> > > > > Hi Mohana and all,
> > > > >
> > > > > I think your scenario is viable, but we should probably more
> > > > > carefully clarify the difference between multihoming 
> and handover.
> > > > > Assigning the same address to different interfaces on 
> the MN for a
> > > > > sufficiently long time sounds like multihoming; 
> however, if this
> > > > > situation holds only for a short period of time for 
> MN's movement or
> > > > > fail over or for whatever reason, that sounds like 
> handover. This
> > > > > difference would affect the behavior of the LMA and MAG(s).
> > > > >
> > > > > In Section 2 of the Multihoming PS document, Issues related to
> > > > > handoff performance and those related to flow 
> mobility during sudden
> > > > > disconnection appear to be categorized into handover. 
> If all agree
> > > > > that these issues should also be included in 
> multihoming, that's
> > > > > fine. I would just like to make sure of it first of all.
> > > > >
> > > > > Regards,
> > > > > --
> > > > > Hidetoshi
> > > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > NetExt mailing list
> > > > NetExt at mail.mobileip.jp
> > > > http://www.mobileip.jp/mailman/listinfo/netext
> > > --
> > >  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> > >  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> > >         Deployment Experiences on Vehicular networks
> > >                   http://www.weedev.org/
> > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Thu, 26 Feb 2009 14:20:06 -0500
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Gerardo,

I mostly agree with you. But, to be clear, the "gaps" need to be addressed either by the access systems or by the IP layer.

Regards,

-Rajeev

> -----Original Message-----
> From: Giaretta, Gerardo [mailto:gerardog at qualcomm.com] 
> Sent: Thursday, February 26, 2009 10:00 AM
> To: MELIA TELEMACO; Domagoj Premec; Koodli, Rajeev; 
> netext at mail.mobileip.jp
> Subject: RE: [Netext] Inter-technology handover PS
> 
> Hi all,
> 
> Sorry jumping into the discussion. I think Rajeev may have a 
> point here. My understanding is that PMIP makes sense when 
> the access provides the capability to use it, so there is a 
> layer 2 signaling which provides the necessary information to the MAG.
> 
> Inventing a layer 3 protocol for handover indication or 
> similar would mean reinventing the wheel in my opinion. We 
> have already one protocol which does that and it is MIPv4 in 
> FA mode :-)
> 
> Cheers
> Gerardo
> 
> 
> 
> 
> 
> -----Original Message-----
> From: MELIA TELEMACO <Telemaco.Melia at alcatel-lucent.com>
> Sent: Thursday, February 26, 2009 9:42 AM
> To: Domagoj Premec <domagoj.premec.ext at nsn.com>; ext Koodli, 
> Rajeev <rkoodli at starentnetworks.com>; netext at mail.mobileip.jp 
> <netext at mail.mobileip.jp>
> Subject: Re: [Netext] Inter-technology handover PS
> 
> 
> Hi,
> 
> I could not agree more on this.
> 
> telemaco
> 
> -----Message d'origine-----
> De : netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] De la part de 
> Domagoj Premec Envoy? : jeudi 26 f?vrier 2009 13:25 ? : 'ext 
> Koodli, Rajeev'; netext at mail.mobileip.jp Objet : Re: [Netext] 
> Inter-technology handover PS
> 
> Hi Rajeev,
> 
> > 2. What _requires_ an IP protocol support on the MN side?
> > Could this be done in an access-specific way? For instance, 
> the HI in
> > PMIP6 is left up to the access system to determine, based on 
> > access-specific means where MN does take part. We need to ask a 
> > similar question here: if MN involvement is necessary, why 
> couldn't we 
> > let an access system provide the functionality?
> 
> Using access specific mechanims is fine for the cases where 
> the access system actually provides the needed functionality. 
> I don't think that we can expect every access system to 
> readily support whatever is needed by PMIP6 (WiMAX being one 
> example of such access system, it doesn't provide any clue 
> about the HI). In such cases it makes sense to put the 
> additional functionality at the IP layer, i.e. at the 
> MAG/LMA/MN as they need to be updated anyway to support 
> inter-tech handover. Such add-on at the IP-layer could be 
> reused without modifications with any access system which 
> does not provide the appropriate L2 hints.
> 
> domagoj
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Koodli, 
> > Rajeev
> > Sent: 24. veljaca 2009 23:01
> > To: netext at mail.mobileip.jp
> > Subject: Re: [Netext] Inter-technology handover PS
> >
> >
> > Hello folks,
> >
> > Few thoughts on what we may need to focus here..
> >
> > 1. For the purposes of this ID (i.e., inter-tech 
> handovers), what is 
> > most relevant here? What breaks today? Or, what we can improve? The 
> > breakdown of issues is a good start, but we need to tie it together 
> > for the problem at hand - inter-tech handovers.
> >
> > 2. What _requires_ an IP protocol support on the MN side?
> > Could this be done in an access-specific way? For instance, 
> the HI in
> > PMIP6 is left up to the access system to determine, based on 
> > access-specific means where MN does take part. We need to ask a 
> > similar question here: if MN involvement is necessary, why 
> couldn't we 
> > let an access system provide the functionality?
> >
> > 3. Assuming specific mechanisms (e.g., IEEE 802.21 etc.) is not 
> > necessary. Folks can use whatever they want, but specifying 
> > dependencies needs to be avoided.
> >
> > Regards,
> >
> > -Rajeev
> >
> >
> > > -----Original Message-----
> > > From: netext-bounces at mail.mobileip.jp 
> > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
> > Suresh Krishnan
> > > Sent: Thursday, February 19, 2009 3:19 PM
> > > To: cjbc at it.uc3m.es
> > > Cc: netext at mail.mobileip.jp
> > > Subject: Re: [Netext] Inter-technology handover PS
> > >
> > > Hi Carlos,
> > >    Thanks for your comments. Please find responses inline
> > >
> > > On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
> > > > * PGP Signed by an unknown key
> > > >
> > > > Hi Suresh,
> > > >
> > > >   Thanks for the draft. I think it's short and clear.
> > > Some comments
> > > > below:
> > > >
> > > >   - Section 2.1. Formation of interface identifier. The
> > > issue described
> > > > there only applies if SLAAC is used, right? If DHCP is
> > > used, the issue
> > > > is then on the network side, to ensure that the address
> > provided to
> > > > the new interface of the MN is the same that it was (or 
> is still) 
> > > > using on the previous interface, right?
> > >
> > > Yes. This is correct. I can probably add a new section on
> > the network
> > > side about the DHCPv6 issue
> > >
> > > >
> > > >   - Section 2.2 Usage of the same address on multiple
> > > interfaces. Since
> > > > it seems that we cannot assume that is safe to use the same
> > > address on
> > > > multiple interfaces (without requiring changes on the MN
> > > side), this
> > > > implies that: a) if NETEXT work is restricted to work on
> > solutions
> > > > that do not impose changes on the MN, use cases requiring
> > the MN to
> > > > use the same address simultaneously are out of the scope of
> > > NETEXT, b)
> > > > we allow for changes on the MN side. Additionally, it might
> > > be good to
> > > > analyse if it is OK for the MN to receive (and send)
> > > traffic addressed
> > > > to the IPv6 address of one interface through a different
> > interface
> > > > (weak end-system model defined in RFC 1122 or
> > > draft-thaler-ip-model-evolution).
> > >
> > > While I agree with your analysis of the problem, are we 
> delving too 
> > > much into the solution space by adding any such text?
> > >
> > > >
> > > >   - IMHO, it'd be good to explicitly describe what a
> > > "change on the MN"
> > > > within the scope of NETEXT. For example, is it fine 
> assuming IEEE
> > > > 802.21 support on the MN or is this "a change on the MN"?
> > >
> > > Probably something to add to the charter?
> > >
> > > Cheers
> > > Suresh
> > >
> > > _______________________________________________
> > > NetExt mailing list
> > > NetExt at mail.mobileip.jp
> > > http://www.mobileip.jp/mailman/listinfo/netext
> > >
> >
> >
> > This email and any attachments may contain legally 
> privileged and/or 
> > confidential information of Starent Networks, Corp.
> > and is intended only for the individual or entity named in the 
> > message.  The information transmitted may not be used to create or 
> > change any contractual obligations of Starent Networks, Corp.  Any 
> > review, retransmission, dissemination or other use of, or taking of 
> > any action in reliance upon this e-mail and its attachments 
> by persons 
> > or entities other than the intended recipient is prohibited. If you 
> > are not the intended recipient, please notify the sender immediately
> > -- by replying to this message or by sending an email to 
> > postmaster at starentnetworks.com -- and destroy all copies of this 
> > message and any attachments without reading or disclosing their 
> > contents. Thank you.
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> >
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Thu, 26 Feb 2009 13:38:26 -0500
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Domagoj,

> 
> Using access specific mechanims is fine for the cases where 
> the access system actually provides the needed functionality. 

Good. My reasoning is that if there is a functionality which is crucial to an access system, it will provide it. We defining a mechanism at IP layer, which I would prefer as well, will turn out to be redundant and ignored.

> I don't think that we can expect every access system to 
> readily support whatever is needed by PMIP6 (WiMAX being one 
> example of such access system, it doesn't provide any clue 
> about the HI). In such cases it makes sense to put the 
> additional functionality at the IP layer, i.e. at the 
> MAG/LMA/MN as they need to be updated anyway to support 
> inter-tech handover. Such add-on at the IP-layer could be 
> reused without modifications with any access system which 
> does not provide the appropriate L2 hints.

How does handover work in Wimax today without indication from the MN at the IP layer?

To be clear, I do not wish to start from a point where we assume that MN involvement at the IP layer is necessary; at least for this BOF. The focus of this effort is to identify the problems which need to be solved. During the process, we can list what works and what doesn't as it is, without MN involvement; it needs to be done thoroughly.
But, the starting point is not "we need MN involvement". 

-Rajeev

> 
> domagoj
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp 
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Koodli, 
> > Rajeev
> > Sent: 24. veljaca 2009 23:01
> > To: netext at mail.mobileip.jp
> > Subject: Re: [Netext] Inter-technology handover PS
> > 
> > 
> > Hello folks,
> > 
> > Few thoughts on what we may need to focus here..
> > 
> > 1. For the purposes of this ID (i.e., inter-tech 
> handovers), what is 
> > most relevant here? What breaks today? Or, what we can improve? The 
> > breakdown of issues is a good start, but we need to tie it together 
> > for the problem at hand - inter-tech handovers.
> > 
> > 2. What _requires_ an IP protocol support on the MN side? 
> > Could this be done in an access-specific way? For instance, 
> the HI in 
> > PMIP6 is left up to the access system to determine, based on 
> > access-specific means where MN does take part. We need to ask a 
> > similar question here: if MN involvement is necessary, why 
> couldn't we 
> > let an access system provide the functionality?
> > 
> > 3. Assuming specific mechanisms (e.g., IEEE 802.21 etc.) is not 
> > necessary. Folks can use whatever they want, but specifying 
> > dependencies needs to be avoided.
> > 
> > Regards,
> > 
> > -Rajeev
> >  
> > 
> > > -----Original Message-----
> > > From: netext-bounces at mail.mobileip.jp 
> > > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
> > Suresh Krishnan
> > > Sent: Thursday, February 19, 2009 3:19 PM
> > > To: cjbc at it.uc3m.es
> > > Cc: netext at mail.mobileip.jp
> > > Subject: Re: [Netext] Inter-technology handover PS
> > > 
> > > Hi Carlos,
> > >    Thanks for your comments. Please find responses inline
> > > 
> > > On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
> > > > * PGP Signed by an unknown key
> > > > 
> > > > Hi Suresh,
> > > > 
> > > > 	Thanks for the draft. I think it's short and clear. 
> > > Some comments
> > > > below:
> > > > 
> > > > 	- Section 2.1. Formation of interface identifier. The
> > > issue described
> > > > there only applies if SLAAC is used, right? If DHCP is
> > > used, the issue
> > > > is then on the network side, to ensure that the address
> > provided to
> > > > the new interface of the MN is the same that it was (or 
> is still) 
> > > > using on the previous interface, right?
> > > 
> > > Yes. This is correct. I can probably add a new section on
> > the network
> > > side about the DHCPv6 issue
> > > 
> > > > 
> > > > 	- Section 2.2 Usage of the same address on multiple
> > > interfaces. Since
> > > > it seems that we cannot assume that is safe to use the same
> > > address on
> > > > multiple interfaces (without requiring changes on the MN
> > > side), this
> > > > implies that: a) if NETEXT work is restricted to work on
> > solutions
> > > > that do not impose changes on the MN, use cases requiring
> > the MN to
> > > > use the same address simultaneously are out of the scope of
> > > NETEXT, b)
> > > > we allow for changes on the MN side. Additionally, it might
> > > be good to
> > > > analyse if it is OK for the MN to receive (and send)
> > > traffic addressed
> > > > to the IPv6 address of one interface through a different
> > interface
> > > > (weak end-system model defined in RFC 1122 or
> > > draft-thaler-ip-model-evolution).
> > > 
> > > While I agree with your analysis of the problem, are we 
> delving too 
> > > much into the solution space by adding any such text?
> > > 
> > > > 
> > > > 	- IMHO, it'd be good to explicitly describe what a
> > > "change on the MN"
> > > > within the scope of NETEXT. For example, is it fine 
> assuming IEEE
> > > > 802.21 support on the MN or is this "a change on the MN"?
> > > 
> > > Probably something to add to the charter?
> > > 
> > > Cheers
> > > Suresh
> > > 
> > > _______________________________________________
> > > NetExt mailing list
> > > NetExt at mail.mobileip.jp
> > > http://www.mobileip.jp/mailman/listinfo/netext
> > > 
> > 
> > 
> > This email and any attachments may contain legally 
> privileged and/or 
> > confidential information of Starent Networks, Corp.
> > and is intended only for the individual or entity named in the 
> > message.  The information transmitted may not be used to create or 
> > change any contractual obligations of Starent Networks, Corp.  Any 
> > review, retransmission, dissemination or other use of, or taking of 
> > any action in reliance upon this e-mail and its attachments 
> by persons 
> > or entities other than the intended recipient is prohibited. If you 
> > are not the intended recipient, please notify the sender 
> immediately 
> > -- by replying to this message or by sending an email to 
> > postmaster at starentnetworks.com -- and destroy all copies of this 
> > message and any attachments without reading or disclosing their 
> > contents. Thank you.
> > 
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> > 
> 
> 

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Thu, 26 Feb 2009 13:28:27 -0500
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

>  Hi Rajeev, 

Hi,
 
> please see below.

See my replies..
> [TELE] We have a document in mipshop 
> (draft-ietf-mipshop-transient-bce-pmipv6) enabling the use of 
> temporary BCE entries for a MN to optimize handovers. Section 
> 4.6 specifies what issues are out of scope. I believe we 
> should start from there and take over this issues in Netext.

Yes, and let's leave it in MIPSHOP for now. We are not discussing the solutions.
Let's put some focus on problem and arrive at consensus. I believe we are making good progress.

> 
> 2. What _requires_ an IP protocol support on the MN side? 
> Could this be done in an access-specific way? For instance, 
> the HI in PMIP6 is left up to the access system to determine, 
> based on access-specific means where MN does take part. We 
> need to ask a similar question here: if MN involvement is 
> necessary, why couldn't we let an access system provide the 
> functionality? 
> 
> [TELE] There are cases (e.g. WIMAX) where link layer 
> mechanisms are not sufficient and require extensions at IP 
> layer. We should take this into account.
> 

How does handover work in Wimax today?

-Rajeev

> 3. Assuming specific mechanisms (e.g., IEEE 802.21 etc.) is 
> not necessary. Folks can use whatever they want, but 
> specifying dependencies needs to be avoided.
> 
> Regards,
> 
> -Rajeev
>  
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp 
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of 
> Suresh Krishnan
> > Sent: Thursday, February 19, 2009 3:19 PM
> > To: cjbc at it.uc3m.es
> > Cc: netext at mail.mobileip.jp
> > Subject: Re: [Netext] Inter-technology handover PS
> > 
> > Hi Carlos,
> >    Thanks for your comments. Please find responses inline
> > 
> > On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
> > > * PGP Signed by an unknown key
> > > 
> > > Hi Suresh,
> > > 
> > > 	Thanks for the draft. I think it's short and clear. 
> > Some comments
> > > below:
> > > 
> > > 	- Section 2.1. Formation of interface identifier. The
> > issue described
> > > there only applies if SLAAC is used, right? If DHCP is
> > used, the issue
> > > is then on the network side, to ensure that the address 
> provided to 
> > > the new interface of the MN is the same that it was (or is still) 
> > > using on the previous interface, right?
> > 
> > Yes. This is correct. I can probably add a new section on 
> the network 
> > side about the DHCPv6 issue
> > 
> > > 
> > > 	- Section 2.2 Usage of the same address on multiple
> > interfaces. Since
> > > it seems that we cannot assume that is safe to use the same
> > address on
> > > multiple interfaces (without requiring changes on the MN
> > side), this
> > > implies that: a) if NETEXT work is restricted to work on 
> solutions 
> > > that do not impose changes on the MN, use cases requiring 
> the MN to 
> > > use the same address simultaneously are out of the scope of
> > NETEXT, b)
> > > we allow for changes on the MN side. Additionally, it might
> > be good to
> > > analyse if it is OK for the MN to receive (and send)
> > traffic addressed
> > > to the IPv6 address of one interface through a different 
> interface 
> > > (weak end-system model defined in RFC 1122 or
> > draft-thaler-ip-model-evolution).
> > 
> > While I agree with your analysis of the problem, are we delving too 
> > much into the solution space by adding any such text?
> > 
> > > 
> > > 	- IMHO, it'd be good to explicitly describe what a
> > "change on the MN"
> > > within the scope of NETEXT. For example, is it fine assuming IEEE
> > > 802.21 support on the MN or is this "a change on the MN"?
> > 
> > Probably something to add to the charter?
> > 
> > Cheers
> > Suresh
> > 
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> > 
> 
> 
> This email and any attachments may contain legally privileged 
> and/or confidential information of Starent Networks, Corp. 
> and is intended only for the individual or entity named in 
> the message.  The information transmitted may not be used to 
> create or change any contractual obligations of Starent 
> Networks, Corp.  Any review, retransmission, dissemination or 
> other use of, or taking of any action in reliance upon this 
> e-mail and its attachments by persons or entities other than 
> the intended recipient is prohibited. If you are not the 
> intended recipient, please notify the sender immediately -- 
> by replying to this message or by sending an email to 
> postmaster at starentnetworks.com -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you.
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Thu, 26 Feb 2009 09:59:44 -0800
Subject: [Netext] Inter-technology handover PS
Message-ID: <[email-masked]>

Hi all,

Sorry jumping into the discussion. I think Rajeev may have a point here. My understanding is that PMIP makes sense when the access provides the capability to use it, so there is a layer 2 signaling which provides the necessary information to the MAG.

Inventing a layer 3 protocol for handover indication or similar would mean reinventing the wheel in my opinion. We have already one protocol which does that and it is MIPv4 in FA mode :-)

Cheers
Gerardo

-----Original Message-----
From: MELIA TELEMACO <Telemaco.Melia at alcatel-lucent.com>
Sent: Thursday, February 26, 2009 9:42 AM
To: Domagoj Premec <domagoj.premec.ext at nsn.com>; ext Koodli, Rajeev <rkoodli at starentnetworks.com>; netext at mail.mobileip.jp <netext at mail.mobileip.jp>
Subject: Re: [Netext] Inter-technology handover PS

Hi,

I could not agree more on this.

telemaco

-----Message d'origine-----
De : netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] De la part de Domagoj Premec
Envoy? : jeudi 26 f?vrier 2009 13:25
? : 'ext Koodli, Rajeev'; netext at mail.mobileip.jp
Objet : Re: [Netext] Inter-technology handover PS

Hi Rajeev,

> 2. What _requires_ an IP protocol support on the MN side?
> Could this be done in an access-specific way? For instance, the HI in
> PMIP6 is left up to the access system to determine, based on
> access-specific means where MN does take part. We need to ask a
> similar question here: if MN involvement is necessary, why couldn't we
> let an access system provide the functionality?

Using access specific mechanims is fine for the cases where the access system actually provides the needed functionality. I don't think that we can expect every access system to readily support whatever is needed by PMIP6 (WiMAX being one example of such access system, it doesn't provide any clue about the HI). In such cases it makes sense to put the additional functionality at the IP layer, i.e. at the MAG/LMA/MN as they need to be updated anyway to support inter-tech handover. Such add-on at the IP-layer could be reused without modifications with any access system which does not provide the appropriate L2 hints.

domagoj

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Koodli,
> Rajeev
> Sent: 24. veljaca 2009 23:01
> To: netext at mail.mobileip.jp
> Subject: Re: [Netext] Inter-technology handover PS
>
>
> Hello folks,
>
> Few thoughts on what we may need to focus here..
>
> 1. For the purposes of this ID (i.e., inter-tech handovers), what is
> most relevant here? What breaks today? Or, what we can improve? The
> breakdown of issues is a good start, but we need to tie it together
> for the problem at hand - inter-tech handovers.
>
> 2. What _requires_ an IP protocol support on the MN side?
> Could this be done in an access-specific way? For instance, the HI in
> PMIP6 is left up to the access system to determine, based on
> access-specific means where MN does take part. We need to ask a
> similar question here: if MN involvement is necessary, why couldn't we
> let an access system provide the functionality?
>
> 3. Assuming specific mechanisms (e.g., IEEE 802.21 etc.) is not
> necessary. Folks can use whatever they want, but specifying
> dependencies needs to be avoided.
>
> Regards,
>
> -Rajeev
>
>
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
> Suresh Krishnan
> > Sent: Thursday, February 19, 2009 3:19 PM
> > To: cjbc at it.uc3m.es
> > Cc: netext at mail.mobileip.jp
> > Subject: Re: [Netext] Inter-technology handover PS
> >
> > Hi Carlos,
> >    Thanks for your comments. Please find responses inline
> >
> > On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
> > > * PGP Signed by an unknown key
> > >
> > > Hi Suresh,
> > >
> > >   Thanks for the draft. I think it's short and clear.
> > Some comments
> > > below:
> > >
> > >   - Section 2.1. Formation of interface identifier. The
> > issue described
> > > there only applies if SLAAC is used, right? If DHCP is
> > used, the issue
> > > is then on the network side, to ensure that the address
> provided to
> > > the new interface of the MN is the same that it was (or is still)
> > > using on the previous interface, right?
> >
> > Yes. This is correct. I can probably add a new section on
> the network
> > side about the DHCPv6 issue
> >
> > >
> > >   - Section 2.2 Usage of the same address on multiple
> > interfaces. Since
> > > it seems that we cannot assume that is safe to use the same
> > address on
> > > multiple interfaces (without requiring changes on the MN
> > side), this
> > > implies that: a) if NETEXT work is restricted to work on
> solutions
> > > that do not impose changes on the MN, use cases requiring
> the MN to
> > > use the same address simultaneously are out of the scope of
> > NETEXT, b)
> > > we allow for changes on the MN side. Additionally, it might
> > be good to
> > > analyse if it is OK for the MN to receive (and send)
> > traffic addressed
> > > to the IPv6 address of one interface through a different
> interface
> > > (weak end-system model defined in RFC 1122 or
> > draft-thaler-ip-model-evolution).
> >
> > While I agree with your analysis of the problem, are we delving too
> > much into the solution space by adding any such text?
> >
> > >
> > >   - IMHO, it'd be good to explicitly describe what a
> > "change on the MN"
> > > within the scope of NETEXT. For example, is it fine assuming IEEE
> > > 802.21 support on the MN or is this "a change on the MN"?
> >
> > Probably something to add to the charter?
> >
> > Cheers
> > Suresh
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> >
>
>
> This email and any attachments may contain legally privileged and/or
> confidential information of Starent Networks, Corp.
> and is intended only for the individual or entity named in the
> message.  The information transmitted may not be used to create or
> change any contractual obligations of Starent Networks, Corp.  Any
> review, retransmission, dissemination or other use of, or taking of
> any action in reliance upon this e-mail and its attachments by persons
> or entities other than the intended recipient is prohibited. If you
> are not the intended recipient, please notify the sender immediately
> -- by replying to this message or by sending an email to
> postmaster at starentnetworks.com -- and destroy all copies of this
> message and any attachments without reading or disclosing their
> contents. Thank you.
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

From: Telemaco.Melia at alcatel-lucent.com (MELIA TELEMACO)
Date: Thu, 26 Feb 2009 18:40:30 +0100
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
References: <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I could not agree more on this.

telemaco 

-----Message d'origine-----
De : netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] De la part de Domagoj Premec
Envoy? : jeudi 26 f?vrier 2009 13:25
? : 'ext Koodli, Rajeev'; netext at mail.mobileip.jp
Objet : Re: [Netext] Inter-technology handover PS

Hi Rajeev,

> 2. What _requires_ an IP protocol support on the MN side? 
> Could this be done in an access-specific way? For instance, the HI in 
> PMIP6 is left up to the access system to determine, based on 
> access-specific means where MN does take part. We need to ask a 
> similar question here: if MN involvement is necessary, why couldn't we 
> let an access system provide the functionality?

Using access specific mechanims is fine for the cases where the access system actually provides the needed functionality. I don't think that we can expect every access system to readily support whatever is needed by PMIP6 (WiMAX being one example of such access system, it doesn't provide any clue about the HI). In such cases it makes sense to put the additional functionality at the IP layer, i.e. at the MAG/LMA/MN as they need to be updated anyway to support inter-tech handover. Such add-on at the IP-layer could be reused without modifications with any access system which does not provide the appropriate L2 hints.

domagoj

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext Koodli, 
> Rajeev
> Sent: 24. veljaca 2009 23:01
> To: netext at mail.mobileip.jp
> Subject: Re: [Netext] Inter-technology handover PS
> 
> 
> Hello folks,
> 
> Few thoughts on what we may need to focus here..
> 
> 1. For the purposes of this ID (i.e., inter-tech handovers), what is 
> most relevant here? What breaks today? Or, what we can improve? The 
> breakdown of issues is a good start, but we need to tie it together 
> for the problem at hand - inter-tech handovers.
> 
> 2. What _requires_ an IP protocol support on the MN side? 
> Could this be done in an access-specific way? For instance, the HI in 
> PMIP6 is left up to the access system to determine, based on 
> access-specific means where MN does take part. We need to ask a 
> similar question here: if MN involvement is necessary, why couldn't we 
> let an access system provide the functionality?
> 
> 3. Assuming specific mechanisms (e.g., IEEE 802.21 etc.) is not 
> necessary. Folks can use whatever they want, but specifying 
> dependencies needs to be avoided.
> 
> Regards,
> 
> -Rajeev
>  
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp 
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
> Suresh Krishnan
> > Sent: Thursday, February 19, 2009 3:19 PM
> > To: cjbc at it.uc3m.es
> > Cc: netext at mail.mobileip.jp
> > Subject: Re: [Netext] Inter-technology handover PS
> > 
> > Hi Carlos,
> >    Thanks for your comments. Please find responses inline
> > 
> > On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
> > > * PGP Signed by an unknown key
> > > 
> > > Hi Suresh,
> > > 
> > > 	Thanks for the draft. I think it's short and clear. 
> > Some comments
> > > below:
> > > 
> > > 	- Section 2.1. Formation of interface identifier. The
> > issue described
> > > there only applies if SLAAC is used, right? If DHCP is
> > used, the issue
> > > is then on the network side, to ensure that the address
> provided to
> > > the new interface of the MN is the same that it was (or is still) 
> > > using on the previous interface, right?
> > 
> > Yes. This is correct. I can probably add a new section on
> the network
> > side about the DHCPv6 issue
> > 
> > > 
> > > 	- Section 2.2 Usage of the same address on multiple
> > interfaces. Since
> > > it seems that we cannot assume that is safe to use the same
> > address on
> > > multiple interfaces (without requiring changes on the MN
> > side), this
> > > implies that: a) if NETEXT work is restricted to work on
> solutions
> > > that do not impose changes on the MN, use cases requiring
> the MN to
> > > use the same address simultaneously are out of the scope of
> > NETEXT, b)
> > > we allow for changes on the MN side. Additionally, it might
> > be good to
> > > analyse if it is OK for the MN to receive (and send)
> > traffic addressed
> > > to the IPv6 address of one interface through a different
> interface
> > > (weak end-system model defined in RFC 1122 or
> > draft-thaler-ip-model-evolution).
> > 
> > While I agree with your analysis of the problem, are we delving too 
> > much into the solution space by adding any such text?
> > 
> > > 
> > > 	- IMHO, it'd be good to explicitly describe what a
> > "change on the MN"
> > > within the scope of NETEXT. For example, is it fine assuming IEEE
> > > 802.21 support on the MN or is this "a change on the MN"?
> > 
> > Probably something to add to the charter?
> > 
> > Cheers
> > Suresh
> > 
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> > 
> 
> 
> This email and any attachments may contain legally privileged and/or 
> confidential information of Starent Networks, Corp.
> and is intended only for the individual or entity named in the 
> message.  The information transmitted may not be used to create or 
> change any contractual obligations of Starent Networks, Corp.  Any 
> review, retransmission, dissemination or other use of, or taking of 
> any action in reliance upon this e-mail and its attachments by persons 
> or entities other than the intended recipient is prohibited. If you 
> are not the intended recipient, please notify the sender immediately 
> -- by replying to this message or by sending an email to 
> postmaster at starentnetworks.com -- and destroy all copies of this 
> message and any attachments without reading or disclosing their 
> contents. Thank you.
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

From: Telemaco.Melia at alcatel-lucent.com (MELIA TELEMACO)
Date: Thu, 26 Feb 2009 18:39:11 +0100
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

 Hi Rajeev, 

please see below.

Telemaco

-----Message d'origine-----
De : netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] De la part de Koodli, Rajeev
Envoy? : mardi 24 f?vrier 2009 23:01
? : netext at mail.mobileip.jp
Objet : Re: [Netext] Inter-technology handover PS

Hello folks,

Few thoughts on what we may need to focus here..

1. For the purposes of this ID (i.e., inter-tech handovers), what is most relevant here? What breaks today? Or, what we can improve? The breakdown of issues is a good start, but we need to tie it together for the problem at hand - inter-tech handovers.

[TELE] We have a document in mipshop (draft-ietf-mipshop-transient-bce-pmipv6) enabling the use of temporary BCE entries for a MN to optimize handovers. Section 4.6 specifies what issues are out of scope. I believe we should start from there and take over this issues in Netext.

2. What _requires_ an IP protocol support on the MN side? Could this be done in an access-specific way? For instance, the HI in PMIP6 is left up to the access system to determine, based on access-specific means where MN does take part. We need to ask a similar question here: if MN involvement is necessary, why couldn't we let an access system provide the functionality? 

[TELE] There are cases (e.g. WIMAX) where link layer mechanisms are not sufficient and require extensions at IP layer. We should take this into account.

3. Assuming specific mechanisms (e.g., IEEE 802.21 etc.) is not necessary. Folks can use whatever they want, but specifying dependencies needs to be avoided.

Regards,

-Rajeev

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Suresh Krishnan
> Sent: Thursday, February 19, 2009 3:19 PM
> To: cjbc at it.uc3m.es
> Cc: netext at mail.mobileip.jp
> Subject: Re: [Netext] Inter-technology handover PS
> 
> Hi Carlos,
>    Thanks for your comments. Please find responses inline
> 
> On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
> > * PGP Signed by an unknown key
> > 
> > Hi Suresh,
> > 
> > 	Thanks for the draft. I think it's short and clear. 
> Some comments
> > below:
> > 
> > 	- Section 2.1. Formation of interface identifier. The
> issue described
> > there only applies if SLAAC is used, right? If DHCP is
> used, the issue
> > is then on the network side, to ensure that the address provided to 
> > the new interface of the MN is the same that it was (or is still) 
> > using on the previous interface, right?
> 
> Yes. This is correct. I can probably add a new section on the network 
> side about the DHCPv6 issue
> 
> > 
> > 	- Section 2.2 Usage of the same address on multiple
> interfaces. Since
> > it seems that we cannot assume that is safe to use the same
> address on
> > multiple interfaces (without requiring changes on the MN
> side), this
> > implies that: a) if NETEXT work is restricted to work on solutions 
> > that do not impose changes on the MN, use cases requiring the MN to 
> > use the same address simultaneously are out of the scope of
> NETEXT, b)
> > we allow for changes on the MN side. Additionally, it might
> be good to
> > analyse if it is OK for the MN to receive (and send)
> traffic addressed
> > to the IPv6 address of one interface through a different interface 
> > (weak end-system model defined in RFC 1122 or
> draft-thaler-ip-model-evolution).
> 
> While I agree with your analysis of the problem, are we delving too 
> much into the solution space by adding any such text?
> 
> > 
> > 	- IMHO, it'd be good to explicitly describe what a
> "change on the MN"
> > within the scope of NETEXT. For example, is it fine assuming IEEE
> > 802.21 support on the MN or is this "a change on the MN"?
> 
> Probably something to add to the charter?
> 
> Cheers
> Suresh
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

From: Telemaco.Melia at alcatel-lucent.com (MELIA TELEMACO)
Date: Thu, 26 Feb 2009 18:14:24 +0100
Subject: [Netext] Few considerations on the weak/strong host model
Message-ID: <[email-masked]>

Hi all,

After the recent discussions on multihoming support (we did write this
email before David's review), we decided to have a look on what we can
do today without modifying the host. We know this is already digging
into the solution space, necessary however to get the complete picture.
Here our findings.

We have been doing a bit of research on the applicability of the weak
model as defined in RFC 1122.
[short reminder on what the weak host model is: in the weak host model,
an IP host (either IPv4 or IPv6) can send packets on an interface that
is not assigned the source IP address of the packet being sent. An IP
host can also receive packets on an interface that is not assigned the
destination IP address of the packet being received.]

It seems that Windows XP and Windows Server 2003 use the weak host model
for sends and receives for all IPv4 interfaces and the strong host model
for sends and receives for all IPv6 interfaces. This behavior cannot be
configured. The Next Generation TCP/IP stack in Windows Vista and
Windows Server 2008 should support strong host sends and receives for
both IPv4 and IPv6 by default. You can configure the stack to use the
weak host send/receive.
It seems that Linux uses by default the weak model for IPv4 and IPv6.
We've also tried Mac OS X 10.5 (Leopard) and it also seems to use the
weak model for both IPv4 and IPv6. In addition we've tested it with a
Linux laptop and a macbook pro.

The above tests resulted to be quite promising. Of course if people
encountered different behaviors they should speak up.

We believe the adoption of this solution would help PMIPv6 in
multihoming operations by letting the LMA to route packets (flows) to
the right interface (same or different HNP). 

What do people think?

Cheers
Carlos&Telemaco

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090226/b4672209/attachment.html>

From: david.cypher at nist.gov (David Cypher)
Date: Thu, 26 Feb 2009 11:20:12 -0500
Subject: [Netext] Inter-technology handovers PS considering Multihoming PS and Localized Routing PS
Message-ID: <[email-masked]>

Taking a look at the other two problem statements in terms of 
existing services and new services,
I do not think that any of the three problem statements can really be 
addressed in isolation.

Multihoming Problem Statement
Mobile node should be able to have more than one interface to the network
- same access technology interfaces
	i) same IPv6 address	(not supported in RFC 5213)
	ii) different IPv6 address (supported)
- different access technology interfaces
	i) same IPv6 address	(supported but only for handover (temporarily))
	ii) different IPv6 address	(supported)

NEW SERVICE being requested
- A) the ability to have the same IPv6 address on more than one 
interface (whether the access technology is the same or different) 
for a long period of time (i.e., not part of a handover/handoff).

Route optimization (RO) Problem statement
NEW SERVICES being requested
- A ) the ability to discover if a route between MN(MAG) and CN is 
better than the existing route between MN (LMA) and CN and
- B) the ability to use the route if found.

What interface will be used to find this optimized route if multiple 
accesses exist and multihoming is truly provided?
All of them?  One of them?  Which one?  Will there be a primary 
access interface or MN-HNP needed?

SUMMARY of the three problem statements
======================================
Inter-technology and multihoming problem statements appear to be 
interrelated.  Inter-technology (2.2) claims that there are problems 
with mobile nodes' operating systems that do not permit multihoming 
(same address on multiple interfaces), which is what the Multihoming 
Problem statement is wanting.

Inter-technology PS 3.2 needs to be able to distinguish between 
handover and multiple interfaces.  This is another issue related to 
Multihoming (multiple interfaces)

Cannot look at inter-technology and multihoming as separate problem 
statements.  Instead perhaps the problem statements should be written 
from a NEW SERVICE being requested.

Cannot look at route optimization and multihoming as separate 
problems since the route optimized is dependent upon the attachment 
point and the address used for that attachment.

For example from the original PMIP the services were
- to supply the mobile node with a single set of MN-HNPs as it moved 
throughout the PMIP domain while maintaining only one active 
interface at a time or temporarily two during a handover.  (a single 
set of MN-HNPs for all of the mobile node's interfaces provided only 
one interface active at a time and used for handover only between two 
interfaces)
- to supply the mobile node with a single set of MN-HNPs per 
interface, if more than one interface was attached to the PMIP 
domain. (a different set of MN-HNPs for each interface)

SUMMARY of new services:
=============================================
The NEW SERVICES being requested by the three PSs are:
- multiple interfaces active at the same time and not part of handover
	i) using the same MN-HNPs
	ii) using different MN-HNPs
- a method for determining which service(s) the mobile node wants
- a method for determining the mobile node's intended usage of the 
multiple connections
- a method for determining the mobile node's capabilities to support 
PMIP services.
- the ability to discover if a route between MN(MAG) (on which 
interface) and CN is better than the existing route between MN (LMA) 
(on which interface) and CN and
- the ability to use the route if found.

David Cypher

From: david.cypher at nist.gov (David Cypher)
Date: Thu, 26 Feb 2009 10:52:10 -0500
Subject: [Netext] Inter-technology handover PS
Message-ID: <[email-masked]>

I've taken a different perspective when looking at the 
"Inter-technology handover Problem Statement."

First I looked at what are (were) the services to be provided by the 
original PMIP defined in RFC 5213
and I arrived at these five services:
1) No requirement for mobile node participation in any 
mobility-related signalling

2) Mobile Home network prefix (MN-HNP) assigned per interface

3) Each interface considered a separate mobility session

4) Ensures that the mobile node does not detect any change with 
respect to its layer-3 attachment even after changing its point of 
attachment in the network.

5) Handoff occurs as two different cases when using
	- i) different interfaces (same technology or different technology)
	- ii) same interface different MAGs

Second I looked at the issues identified in the
Inter-technology handovers Problem statement
2.1 Formation of interface identifier
Original PMIP Service Handover between different interfaces
may not work if stateless IPv6 auto address configuration is 
used?  This is true by definition of the procedures defined in RFC 4862.

If a MN-HNP (with length of 64) is used with stateless IPv6 auto 
address configuration, then this situation cannot be prevented.
Solution: use either DHCP or MN-HNP (with length 128).

2.2 Usage of the same address on multiple interfaces
This violates the Original PMIP service definition of MN-HNP being 
assigned per interface. Except for the short-lived period for 
handover for one interface to another interface.
NEW SERVICE being requested same address on multiple interfaces and 
not part of a handover.

2.3 Limitiations of interface
I do not understand

3.1 Access selection
For what purpose does the network want to decide which access 
technology to let the MN join with?
PMIP is to provide access and a single link to the MN.
It does this when the mobile node attaches to a MAG.  Once the MN is 
attached, the network knows the access type.  Is the network trying 
to provide predictive handover?

3.2 Detecting handover
When a MN only has one interface there is no problem, since it can 
only connect to one MAG at a time, which indicates handover.
When a MN has more than one interface the network has no clue what 
the intent (two same interfaces, two different interfaces) of the MN 
is.  Currently if a second interface using the same technology 
attaches to the same MAG or different MAG.  It will be treated as a 
second interface and receive another set of MN-HNPs.  Unless the MAG 
was indicated that it was a handover between interfaces.

NEW SERVICE being requested ability to determine the intent (handover 
or multiple access) of the mobile node when it attaches with a second 
interface either of the same access technology type or a different 
access technology type.
Since only the mobile node knows what it is intending, this issue has 
no solution without this information being exchanged from the MN to 
the network.

3.3 Predictive handover
When a MN only has one interface there is no problem.
When a MN has more than two interfaces
- a) should the PMIP service assume a handover between the two 
interfaces? (resulting in only one path to the MN over one interface) ?
or
- b) should the PMIP service assume a second interface (multiple 
attachments and no handover)?
- c) should the PMIP service provide the same MN-HNP?
or
- d) should the PMIP service provide a different MN-HNP?

Using the original service of PMIP for if PMIP receives some 
indication from somewhere that this is a hand over, then the result 
is a single path to the MN using the same MN-HNP.
Using the original service of PMIP for if PMIP does not receive some 
indication from somewhere that this is a hand over (it assumes 
multiple access), then the result is a two separate mobility sessions 
to the MN using the different MN-HNPs.

Are different behaviors wanted than these? It seems so.

The third I thought that NETEXT wants to provide new services, 
instead of noting and fixing existing problems with the PMIP protocol 
and I arrived at these new services:
- A) the ability to know how the MN wants to use multiple interfaces
	i) redundancy (same address)
	ii) another connection point (different address)
	iii) handover (must be same address otherwise IP connection breaks)
- B) the ability to use stateless IPv6 address autoconfiguration with 
a 64bit prefix length and always get the same IPv6 address on every interface.
- C) the ability to control which interface the MN uses to access the PMIP

-------------------
Conclusion
It is evident that PMIP cannot obtain the information from (A) or 
control (C) of the MN without modification to the mobile node. (B) 
requires a change of what stateless IPv6 address autoconfiguration 
(i.e., not possible).

David Cypher

From: behcetsarikaya at yahoo.com (Behcet Sarikaya)
Date: Thu, 26 Feb 2009 07:21:57 -0800 (PST)
Subject: [Netext] Redirection Problem Statement
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Jouni,
? Have you read HA Reliability draft:
http://tools.ietf.org/html/draft-ietf-mip6-hareliability-04
Ryuji and I discussed a couple of times issuing PMIPv6 version of HA Reliability. He seems to be too busy these days to do that.
? I think PMIPv6 HA Or LMA reliability solves the problem you described.

Regards,

Behcet

________________________________
From: jouni korhonen <jouni.nospam at gmail.com>
To: netext at mail.mobileip.jp
Sent: Thursday, February 26, 2009 3:51:51 AM
Subject: [Netext] Redirection Problem Statement

Hi all,

It seems my previous mail went to void or something. This short PS document discusses about redirection functionality for the PMIP6 base protocol that could be part of the PBU/PBA exchange. There are obvious use cases for the redirection such as load balancing, LMA maintenance and signaling reduction within a PMIPv6 domain (during redirection or moving MNs under other LMAs). The problem scope falls under the improvements and/or deployment considerations in the current proposed charter.

The document is available here:
http://www.ietf.org/internet-drafts/draft-korhonen-netext-redirect-ps-00.txt

Comments are welcome.

Cheers,
??? Jouni
_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090226/cd558606/attachment.html>

From: pierrick.seite at orange-ftgroup.com (pierrick.seite at orange-ftgroup.com)
Date: Thu, 26 Feb 2009 15:17:55 +0100
Subject: [Netext] Redirection Problem Statement
In-Reply-To: <[email-masked]>
References: <[email-masked]> <DD8B8FEBBFAF9E488F63FF0F1A69EDD1058BD90D@ftrdmel1> <[email-masked]>
Message-ID: <DD8B8FEBBFAF9E488F63FF0F1A69EDD1058BD9E8@ftrdmel1>

Hi Jouni,

Thanks for the prompt response. Please see inline for comments. 

PS: I forgot to CC the ML in my first message....

Regards,
Pierrick

> -----Message d'origine-----
> De : jouni korhonen [mailto:jouni.nospam at gmail.com]
> Envoy? : jeudi 26 f?vrier 2009 13:56
> ? : SEITE Pierrick RD-RESA-REN
> Objet : Re: [Netext] Redirection Problem Statement
> 
> Hi Pierrick,
> 
> Thanks for the review. See my comments inline.
> 
> On Feb 26, 2009, at 2:15 PM, <pierrick.seite at orange-ftgroup.com> wrote:
> 
> >
> > Hello Jouni,
> >
> > I've read your draft. This draft is very interesting since LMA
> > redirection is clearly a key feature for PMIP deployment. Moreover,
> > the document is well written and the problem statement is complete
> > and comprehensible. However, I've a couple of questions.
> >
> > Difference between LMA discovery and LMA redirection at initial
> > attach is not totally clear for me. When do we need LMA redirection
> > at initial attach? One example could be: if MAG finds out LMA via
> > AAA infrastructure and if LMA information in MN's profile has not
> > been updated, then LMA redirection by rfLMA during PBU/PBA exchange
> > could be useful. Is it a correct unrestanding?
> 
> Your described AAA scenario is a good example case. One of the main
> motivations is to detach the redirection functionality from external
> infrastructures, especially from DNS. For example in load balancing
> cases, a LMA or a cluster of LMAs knows the current load situation
> best. If the LMA were constantly to update its runtime load situation
> to either AAA or DNS infrastructure, it is guaranteed that when a
> random MAG learns this updated information, the information is already
> outdated. Furthermore, keeping external infrastructures up to date
> with e.g. LMA availability and load status would cause excessive
> additional signaling.
> 

Ok, it clarifies well the use-case. I agree with you.

> > You seem to consider LMA switching only during PBU/PBA exchange.
> > When LMA redirection is expected to take place during an active
> > session, I the LMA should be able to initiate redirection: I mean
> > that the LMA should be able to notify, thanks to a dedicated
> > message, attached MAGs to switch to r2LMA. This feature could be
> > useful when the operator wants to shutdown a LMA for maintenance
> > reason. What do you think?
> 
> I am primarily interested in the LMA redirection during the initial
> PBU/PBA exchange. The reason being that there is no state established
> yet on the LMA side (which also means the LMA has not either contacted
> the backend system). I would gain a lot in signaling and avoid
> unnecessary setup of state in various places.
> 
> The LMA initiated redirection of an existing session is interesting
> and should also be studied. However, it involves a lot more,
> especially if we want to maintain the mobility session.
> 

For sure, LMA initiated redirection leads to a more sophisticated mechanism; but, depending on the interest of the WG, it could be interesting to include it in the ps draft. Let's see other comments on the ML....
 
Regards,
Pierrick

> Cheers,
> 	Jouni
> 
> >
> >
> > Best regards,
> > Pierrick
> >
> >> -----Message d'origine-----
> >> De : netext-bounces at mail.mobileip.jp [mailto:netext-
> >> bounces at mail.mobileip.jp] De la part de jouni korhonen
> >> Envoy? : jeudi 26 f?vrier 2009 10:52
> >> ? : netext at mail.mobileip.jp
> >> Objet : [Netext] Redirection Problem Statement
> >>
> >> Hi all,
> >>
> >> It seems my previous mail went to void or something. This short PS
> >> document discusses about redirection functionality for the PMIP6 base
> >> protocol that could be part of the PBU/PBA exchange. There are
> >> obvious
> >> use cases for the redirection such as load balancing, LMA maintenance
> >> and signaling reduction within a PMIPv6 domain (during redirection or
> >> moving MNs under other LMAs). The problem scope falls under the
> >> improvements and/or deployment considerations in the current proposed
> >> charter.
> >>
> >> The document is available here:
> >> http://www.ietf.org/internet-drafts/draft-korhonen-netext-redirect-
> >> ps-
> >> 00.txt
> >>
> >> Comments are welcome.
> >>
> >> Cheers,
> >> 	Jouni
> >> _______________________________________________
> >> NetExt mailing list
> >> NetExt at mail.mobileip.jp
> >> http://www.mobileip.jp/mailman/listinfo/netext

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Thu, 26 Feb 2009 13:25:26 +0100
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Rajeev,

> 2. What _requires_ an IP protocol support on the MN side? 
> Could this be done in an access-specific way? For instance, 
> the HI in PMIP6 is left up to the access system to determine, 
> based on access-specific means where MN does take part. We 
> need to ask a similar question here: if MN involvement is 
> necessary, why couldn't we let an access system provide the 
> functionality? 

Using access specific mechanims is fine for the cases where the access
system actually provides the needed functionality. I don't think that we can
expect every access system to readily support whatever is needed by PMIP6
(WiMAX being one example of such access system, it doesn't provide any clue
about the HI). In such cases it makes sense to put the additional
functionality at the IP layer, i.e. at the MAG/LMA/MN as they need to be
updated anyway to support inter-tech handover. Such add-on at the IP-layer
could be reused without modifications with any access system which does not
provide the appropriate L2 hints.

domagoj

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext 
> Koodli, Rajeev
> Sent: 24. veljaca 2009 23:01
> To: netext at mail.mobileip.jp
> Subject: Re: [Netext] Inter-technology handover PS
> 
> 
> Hello folks,
> 
> Few thoughts on what we may need to focus here..
> 
> 1. For the purposes of this ID (i.e., inter-tech handovers), 
> what is most relevant here? What breaks today? Or, what we 
> can improve? The breakdown of issues is a good start, but we 
> need to tie it together for the problem at hand - inter-tech 
> handovers.
> 
> 2. What _requires_ an IP protocol support on the MN side? 
> Could this be done in an access-specific way? For instance, 
> the HI in PMIP6 is left up to the access system to determine, 
> based on access-specific means where MN does take part. We 
> need to ask a similar question here: if MN involvement is 
> necessary, why couldn't we let an access system provide the 
> functionality? 
> 
> 3. Assuming specific mechanisms (e.g., IEEE 802.21 etc.) is 
> not necessary. Folks can use whatever they want, but 
> specifying dependencies needs to be avoided.
> 
> Regards,
> 
> -Rajeev
>  
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp 
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of 
> Suresh Krishnan
> > Sent: Thursday, February 19, 2009 3:19 PM
> > To: cjbc at it.uc3m.es
> > Cc: netext at mail.mobileip.jp
> > Subject: Re: [Netext] Inter-technology handover PS
> > 
> > Hi Carlos,
> >    Thanks for your comments. Please find responses inline
> > 
> > On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
> > > * PGP Signed by an unknown key
> > > 
> > > Hi Suresh,
> > > 
> > > 	Thanks for the draft. I think it's short and clear. 
> > Some comments
> > > below:
> > > 
> > > 	- Section 2.1. Formation of interface identifier. The
> > issue described
> > > there only applies if SLAAC is used, right? If DHCP is
> > used, the issue
> > > is then on the network side, to ensure that the address 
> provided to 
> > > the new interface of the MN is the same that it was (or is still) 
> > > using on the previous interface, right?
> > 
> > Yes. This is correct. I can probably add a new section on 
> the network 
> > side about the DHCPv6 issue
> > 
> > > 
> > > 	- Section 2.2 Usage of the same address on multiple
> > interfaces. Since
> > > it seems that we cannot assume that is safe to use the same
> > address on
> > > multiple interfaces (without requiring changes on the MN
> > side), this
> > > implies that: a) if NETEXT work is restricted to work on 
> solutions 
> > > that do not impose changes on the MN, use cases requiring 
> the MN to 
> > > use the same address simultaneously are out of the scope of
> > NETEXT, b)
> > > we allow for changes on the MN side. Additionally, it might
> > be good to
> > > analyse if it is OK for the MN to receive (and send)
> > traffic addressed
> > > to the IPv6 address of one interface through a different 
> interface 
> > > (weak end-system model defined in RFC 1122 or
> > draft-thaler-ip-model-evolution).
> > 
> > While I agree with your analysis of the problem, are we delving too 
> > much into the solution space by adding any such text?
> > 
> > > 
> > > 	- IMHO, it'd be good to explicitly describe what a
> > "change on the MN"
> > > within the scope of NETEXT. For example, is it fine assuming IEEE
> > > 802.21 support on the MN or is this "a change on the MN"?
> > 
> > Probably something to add to the charter?
> > 
> > Cheers
> > Suresh
> > 
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> > 
> 
> 
> This email and any attachments may contain legally privileged 
> and/or confidential information of Starent Networks, Corp. 
> and is intended only for the individual or entity named in 
> the message.  The information transmitted may not be used to 
> create or change any contractual obligations of Starent 
> Networks, Corp.  Any review, retransmission, dissemination or 
> other use of, or taking of any action in reliance upon this 
> e-mail and its attachments by persons or entities other than 
> the intended recipient is prohibited. If you are not the 
> intended recipient, please notify the sender immediately -- 
> by replying to this message or by sending an email to 
> postmaster at starentnetworks.com -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you.
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

From: jouni.nospam at gmail.com (jouni korhonen)
Date: Thu, 26 Feb 2009 11:51:51 +0200
Subject: [Netext] Redirection Problem Statement
Message-ID: <[email-masked]>

Hi all,

It seems my previous mail went to void or something. This short PS  
document discusses about redirection functionality for the PMIP6 base  
protocol that could be part of the PBU/PBA exchange. There are obvious  
use cases for the redirection such as load balancing, LMA maintenance  
and signaling reduction within a PMIPv6 domain (during redirection or  
moving MNs under other LMAs). The problem scope falls under the  
improvements and/or deployment considerations in the current proposed  
charter.

The document is available here:
http://www.ietf.org/internet-drafts/draft-korhonen-netext-redirect-ps-00.txt

Comments are welcome.

Cheers,
	Jouni

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Thu, 26 Feb 2009 05:35:34 +0100
Subject: [Netext]  draft-korhonen-netext-redirect-ps-00
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Jouni,

The redirection capability enhancements to PMIP6 are likely to be useful in
deployments. Additionally redirection at initial attach can be considered as
a form of achieving loadbalancing.

The focus of the discussions in this ML has been on the multihoming and
localized routing problem statements. I would encourage people to take a
look at the above I-D and provide comments.

Loadbalancing is considered in the context of multihoming in the charter.
But we could consider loadbalancing enhancements if there is interest as
part of the BoF discussion.

-Raj

On 2/9/09 6:43 AM, "ext jouni korhonen" <jouni.nospam at gmail.com> wrote:

> Hi All,
>
> I wrote a small discussion paper on PMIPv6 redirection functionality.
> The aim is to
> come up with a good redirection support for the base protocol. Obvious
> use cases
> are load balancing, signaling reduction within a PMIPv6 Domain and
> eventually reduced
> latencies during mobility session setup. The problem area falls under
> the improvements
> and/or deployment considerations in the current proposed charter.
>
> The I-D can be found here:
> http://www.ietf.org/internet-drafts/draft-korhonen-netext-redirect-ps-00.txt
>
> Comments are welcome!
>
> Cheers,
>         Jouni
>
>
>
> Begin forwarded message:
>
>> From: IETF I-D Submission Tool <idsubmission at ietf.org>
>> Date: February 9, 2009 2:30:00 PM GMT+02:00
>> To: jouni.nospam at gmail.com
>> Subject: New Version Notification for  draft-korhonen-netext-
>> redirect-ps-00
>>
>>
>> A new version of I-D, draft-korhonen-netext-redirect-ps-00.txt has
>> been successfuly submitted by Jouni Korhonen and posted to the IETF
>> repository.
>>
>> Filename:      draft-korhonen-netext-redirect-ps
>> Revision:      00
>> Title:                 Proxy Mobile IPv6 Mobility Session Redirection Problem
>> Statement
>> Creation_date:         2009-02-09
>> WG ID:                 Independent Submission
>> Number_of_pages: 7
>>
>> Abstract:
>> This document discusses a Proxy Mobile IPv6 mobility session
>> redirection functionality at the Proxy Mobile IPv6 base protocol
>> level.  The redirection functionality would allow a Local Mobility
>> Anchor to redirect the Mobile Access Gateway during the Proxy Binding
>> Update and Acknowledgement exchange to an alternative Local Mobility
>> Anchor.  The benefit of redirection at the protocol level is that it
>> removes the dependence on having such functionality provided by the
>> Authentication, Authorization and, Accounting elements or the Domain
>> Name System in a Proxy Mobile IPv6 Domain.  Furthermore, doing the
>> redirection at the base protocol level reduces the amount of
>> signaling, unnecessary costly setup of mobility sessions and
>> unnecessary costly interactions with backend systems.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Tue, 24 Feb 2009 17:00:40 -0500
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hello folks,

Few thoughts on what we may need to focus here..

1. For the purposes of this ID (i.e., inter-tech handovers), what is most relevant here? What breaks today? Or, what we can improve? The breakdown of issues is a good start, but we need to tie it together for the problem at hand - inter-tech handovers.

2. What _requires_ an IP protocol support on the MN side? Could this be done in an access-specific way? For instance, the HI in PMIP6 is left up to the access system to determine, based on access-specific means where MN does take part. We need to ask a similar question here: if MN involvement is necessary, why couldn't we let an access system provide the functionality? 

3. Assuming specific mechanisms (e.g., IEEE 802.21 etc.) is not necessary. Folks can use whatever they want, but specifying dependencies needs to be avoided.

Regards,

-Rajeev

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Suresh Krishnan
> Sent: Thursday, February 19, 2009 3:19 PM
> To: cjbc at it.uc3m.es
> Cc: netext at mail.mobileip.jp
> Subject: Re: [Netext] Inter-technology handover PS
> 
> Hi Carlos,
>    Thanks for your comments. Please find responses inline
> 
> On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
> > * PGP Signed by an unknown key
> > 
> > Hi Suresh,
> > 
> > 	Thanks for the draft. I think it's short and clear. 
> Some comments
> > below:
> > 
> > 	- Section 2.1. Formation of interface identifier. The 
> issue described 
> > there only applies if SLAAC is used, right? If DHCP is 
> used, the issue 
> > is then on the network side, to ensure that the address provided to 
> > the new interface of the MN is the same that it was (or is still) 
> > using on the previous interface, right?
> 
> Yes. This is correct. I can probably add a new section on the 
> network side about the DHCPv6 issue
> 
> > 
> > 	- Section 2.2 Usage of the same address on multiple 
> interfaces. Since 
> > it seems that we cannot assume that is safe to use the same 
> address on 
> > multiple interfaces (without requiring changes on the MN 
> side), this 
> > implies that: a) if NETEXT work is restricted to work on solutions 
> > that do not impose changes on the MN, use cases requiring the MN to 
> > use the same address simultaneously are out of the scope of 
> NETEXT, b) 
> > we allow for changes on the MN side. Additionally, it might 
> be good to 
> > analyse if it is OK for the MN to receive (and send) 
> traffic addressed 
> > to the IPv6 address of one interface through a different interface 
> > (weak end-system model defined in RFC 1122 or 
> draft-thaler-ip-model-evolution).
> 
> While I agree with your analysis of the problem, are we 
> delving too much into the solution space by adding any such text?
> 
> > 
> > 	- IMHO, it'd be good to explicitly describe what a 
> "change on the MN"
> > within the scope of NETEXT. For example, is it fine assuming IEEE 
> > 802.21 support on the MN or is this "a change on the MN"?
> 
> Probably something to add to the charter?
> 
> Cheers
> Suresh
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Tue, 24 Feb 2009 19:16:34 +0100
Subject: [Netext] First Problem Statement about Localized Routing in	PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <1235499394.5013.106.camel@localhost>

OK, fair enough. If we clearly state that we would only focus on
deployment scenarios in which all nodes are offered PMIPv6 support, I'm
very fine with this. I just wanted to make the scope of the netext work
quite clear.

Thanks!

Carlos

El mar, 24-02-2009 a las 13:14 -0500, Koodli, Rajeev escribi?:
> Hi,
>  
> 
> > 	- If my previous understanding is correct, then RFC5213 
> > does not only define any mechanism to perform local routing 
> > between two MNs connected to the same PMIPv6 domain (not even 
> > for the case in which both are attached to the same MAG). 
> > Then, IMHO it would be better to change the terminology in 
> > the PS and avoid using CN or coming up with different terms 
> > for a CN that is getting network-based mobility service from 
> > a CN that is not (i.e. it is just a regular IPv6 node getting 
> > access from a MAG).
> 
> We should assume, i.e., state in the PS document clearly, that all nodes are offered PMIP6 support.
> 5213 may say something else, but for our purposes, at least for now, we should assume that all nodes are "punished" the same way by PMIP6! :-)
> 
> > 
> > 	- Currently, the PS only addresses the case of local 
> > routing between two MNs connected to the same PMIPv6 domain. 
> > I think the scenario of optimising traffic between an MN and 
> > a regular IPv6 host that is locally connected to a MAG should 
> > also be addressed. Not sure the implications on the potential 
> > solutions, but it might have an impact on the classification 
> > scheme that is used in the PS now (A[number of MAGs][number of LMAs]).
> > 
> 
> Please see above. I would not be for this given the issues in detecting who is offered PMIP6 and who is not.. Also see my previous e-mail regarding deployment focus. 
> 
> May be we can come back to such extensions later on.. Let's focus on things we can do within a short, reasonable period of time.
> 
> Thanks,
> 
> -Rajeev
> 
> 
> > 	Thanks,
> > 
> > 	Carlos
> > 
> > El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?:
> > > Hi all,
> > > 
> > > please find the link to a first version of a Localized 
> > Routing Problem 
> > > Statement below.
> > > The abstract of the PS document is as follows:
> > > 
> > > Abstract:
> > > 
> > >    Proxy Mobile IPv6 is the IETF standard for network-based 
> > localized
> > >    mobility management.  In Proxy Mobile IPv6, mobile nodes are
> > >    topologically anchored at a Local Mobility Anchor, which 
> > forwards all
> > >    data for registered mobile nodes.  The set up and support for
> > >    localized routing, which allows forwarding of data 
> > packets between
> > >    mobile nodes and correspondent nodes directly without 
> > traversing an
> > >    LMA, is not considered.  This document describes the 
> > problem space of
> > >    localized routing in Proxy Mobile IPv6.
> > > 
> > > 
> > > Any comments to this version of the problem statement are welcome.
> > > 
> > > 
> > http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps-0
> > > 0.txt
> > > 
> > > Best regards,
> > > marco
> > > 
> > > 
> > > _______________________________________________
> > > NetExt mailing list
> > > NetExt at mail.mobileip.jp
> > > http://www.mobileip.jp/mailman/listinfo/netext
> > -- 
> >  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> >  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> >         Deployment Experiences on Vehicular networks
> >                   http://www.weedev.org/
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 
> 
> 
> This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.
-- 
 Carlos Jes?s Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090224/a219c102/attachment-0001.bin>

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Tue, 24 Feb 2009 13:14:09 -0500
Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted
In-Reply-To: <1234339777.21602.198.camel@localhost>
Message-ID: <[email-masked]>

Hi,

> 	- If my previous understanding is correct, then RFC5213 
> does not only define any mechanism to perform local routing 
> between two MNs connected to the same PMIPv6 domain (not even 
> for the case in which both are attached to the same MAG). 
> Then, IMHO it would be better to change the terminology in 
> the PS and avoid using CN or coming up with different terms 
> for a CN that is getting network-based mobility service from 
> a CN that is not (i.e. it is just a regular IPv6 node getting 
> access from a MAG).

We should assume, i.e., state in the PS document clearly, that all nodes are offered PMIP6 support.
5213 may say something else, but for our purposes, at least for now, we should assume that all nodes are "punished" the same way by PMIP6! :-)

> 
> 	- Currently, the PS only addresses the case of local 
> routing between two MNs connected to the same PMIPv6 domain. 
> I think the scenario of optimising traffic between an MN and 
> a regular IPv6 host that is locally connected to a MAG should 
> also be addressed. Not sure the implications on the potential 
> solutions, but it might have an impact on the classification 
> scheme that is used in the PS now (A[number of MAGs][number of LMAs]).
> 

Please see above. I would not be for this given the issues in detecting who is offered PMIP6 and who is not.. Also see my previous e-mail regarding deployment focus. 

May be we can come back to such extensions later on.. Let's focus on things we can do within a short, reasonable period of time.

Thanks,

-Rajeev

> 	Thanks,
> 
> 	Carlos
> 
> El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?:
> > Hi all,
> > 
> > please find the link to a first version of a Localized 
> Routing Problem 
> > Statement below.
> > The abstract of the PS document is as follows:
> > 
> > Abstract:
> > 
> >    Proxy Mobile IPv6 is the IETF standard for network-based 
> localized
> >    mobility management.  In Proxy Mobile IPv6, mobile nodes are
> >    topologically anchored at a Local Mobility Anchor, which 
> forwards all
> >    data for registered mobile nodes.  The set up and support for
> >    localized routing, which allows forwarding of data 
> packets between
> >    mobile nodes and correspondent nodes directly without 
> traversing an
> >    LMA, is not considered.  This document describes the 
> problem space of
> >    localized routing in Proxy Mobile IPv6.
> > 
> > 
> > Any comments to this version of the problem statement are welcome.
> > 
> > 
> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps-0
> > 0.txt
> > 
> > Best regards,
> > marco
> > 
> > 
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> -- 
>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
>         Deployment Experiences on Vehicular networks
>                   http://www.weedev.org/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 

This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Tue, 24 Feb 2009 19:13:10 +0100
Subject: [Netext] First Problem Statement about	LocalizedRoutingin	PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <1235499190.5013.103.camel@localhost>

Hi Rajeev,

El mar, 24-02-2009 a las 13:04 -0500, Koodli, Rajeev escribi?:
> Hi Carlos,
> 
> I seem to have missed a reply.. 
> 
> > > What does it mean to say it is not getting network-based 
> > mobility support? 
> > > Isn't the whole point of PMIP to make mobility transparent 
> > to the MN?
> > 
> > I fully agree that the whole point of PMIP is make mobility 
> > management transparent to the MN. However, as far as I 
> > understand from my reading of RFC5213, a mobile node attached 
> > to a PMIPv6 domain might not be entitled to the network-based 
> > mobility management service, and RFC5213 (section 6.14) still 
> > support this node to get connectivity (regular
> > access) from the MAG.
> 
> I don't quite understand how 5213 provides protocol support to distiniguish between nodes for which mobility support is offered, and those for which it is not offered. I mentioned this in my prvious e-mail..

Well, the network itself (the MAG) can decide whether to provide to a
node (upon its attachment) with a prefix anchored at the LMA (in this
case the network would provide PMIPv6 support) or with a prefix locally
anchored at the MAG (in this case, no mobility support is provided, if
the node moves to a different MAG, it will have to configure a new IPv6
address). This is my understanding from RFC5213.

> 
> > 
> > Related to this, it is also my interpretation of RFC5213 (section
> > 6.10.5) that the local routing support provided by the basic 
> > spec (controlled with the EnableMAGLocalRouting flag) only 
> > applies to communications between a PMIPv6 MN and a regular 
> > IPv6 host attached to the same MAG.
> > 
> 
> If there is no protocol support to differentiate the nodes, the above is moot.

As I described above, I think RFC5213 provides support to differentiate
the nodes.

> 
> > This is just to try to clarify what RFC5213 provides (actually, very
> > little) and what does not in regards to local routing 
> > support. Do you see my point?
> > 
> 
> Okay, thanks. For our purposes here, let us assume that we are dealing with a scenario where the PMIP6 is provided to nodes. One of the main emphasis in this BOF effort is to focus on deployment considerations, and I believe addressing the local forwarding for a PMIP6 domain would be worthwhile.

Fully agree local routing is quite interesting and should be addressed
(I never meant the opposite).

Thanks,

Carlos

> 
> Later on, we could consider working on other extensions.
> 
> Thanks,
> 
> -Rajeev
> 
> 
> > Thanks!
> > 
> > Carlos
> > 
> > > 
> > > 
> > > > 
> > > > 	- If my previous understanding is correct, then RFC5213 
> > does not 
> > > > only define any mechanism to perform local routing 
> > between two MNs 
> > > > connected to the same PMIPv6 domain (not even for the 
> > case in which 
> > > > both are attached to the same MAG).
> > > > Then, IMHO it would be better to change the terminology in the PS 
> > > > and avoid using CN or coming up with different terms for 
> > a CN that 
> > > > is getting network-based mobility service from a CN that is not 
> > > > (i.e. it is just a regular IPv6 node getting access from a MAG).
> > > 
> > > See above.
> > > 
> > > > 
> > > > 	- Currently, the PS only addresses the case of local routing 
> > > > between two MNs connected to the same PMIPv6 domain.
> > > > I think the scenario of optimising traffic between an MN and a 
> > > > regular IPv6 host that is locally connected to a MAG 
> > should also be 
> > > > addressed. Not sure the implications on the potential 
> > solutions, but 
> > > > it might have an impact on the classification scheme that 
> > is used in 
> > > > the PS now (A[number of MAGs][number of LMAs]).
> > > > 
> > > 
> > > Our focus should be on solving the problem for nodes 
> > attached to a PMIP6 domain.
> > > 
> > > Thanks,
> > > 
> > > -Rajeev
> > > 
> > > 
> > > > 	Thanks,
> > > > 
> > > > 	Carlos
> > > > 
> > > > El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?:
> > > > > Hi all,
> > > > > 
> > > > > please find the link to a first version of a Localized
> > > > Routing Problem
> > > > > Statement below.
> > > > > The abstract of the PS document is as follows:
> > > > > 
> > > > > Abstract:
> > > > > 
> > > > >    Proxy Mobile IPv6 is the IETF standard for network-based
> > > > localized
> > > > >    mobility management.  In Proxy Mobile IPv6, mobile nodes are
> > > > >    topologically anchored at a Local Mobility Anchor, which
> > > > forwards all
> > > > >    data for registered mobile nodes.  The set up and support for
> > > > >    localized routing, which allows forwarding of data
> > > > packets between
> > > > >    mobile nodes and correspondent nodes directly without
> > > > traversing an
> > > > >    LMA, is not considered.  This document describes the
> > > > problem space of
> > > > >    localized routing in Proxy Mobile IPv6.
> > > > > 
> > > > > 
> > > > > Any comments to this version of the problem statement 
> > are welcome.
> > > > > 
> > > > > 
> > > > 
> > http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps
> > > > -0
> > > > > 0.txt
> > > > > 
> > > > > Best regards,
> > > > > marco
> > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > NetExt mailing list
> > > > > NetExt at mail.mobileip.jp
> > > > > http://www.mobileip.jp/mailman/listinfo/netext
> > > > -- 
> > > >  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> > > >  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > >   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> > > >         Deployment Experiences on Vehicular networks
> > > >                   http://www.weedev.org/
> > > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > > 
> > > 
> > > 
> > > This email and any attachments may contain legally 
> > privileged and/or confidential information of Starent 
> > Networks, Corp. and is intended only for the individual or 
> > entity named in the message.  The information transmitted may 
> > not be used to create or change any contractual obligations 
> > of Starent Networks, Corp.  Any review, retransmission, 
> > dissemination or other use of, or taking of any action in 
> > reliance upon this e-mail and its attachments by persons or 
> > entities other than the intended recipient is prohibited. If 
> > you are not the intended recipient, please notify the sender 
> > immediately -- by replying to this message or by sending an 
> > email to postmaster at starentnetworks.com -- and destroy all 
> > copies of this message and any attachments without reading or 
> > disclosing their contents. Thank you.
> > -- 
> >  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> >  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> >         Deployment Experiences on Vehicular networks
> >                   http://www.weedev.org/
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 
-- 
 Carlos Jes?s Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090224/71d50c44/attachment.bin>

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Tue, 24 Feb 2009 13:04:30 -0500
Subject: [Netext] First Problem Statement about LocalizedRoutingin	PMIPv6 submitted
In-Reply-To: <1234370715.5174.9.camel@localhost>
Message-ID: <[email-masked]>

Hi Carlos,

I seem to have missed a reply.. 

> > What does it mean to say it is not getting network-based 
> mobility support? 
> > Isn't the whole point of PMIP to make mobility transparent 
> to the MN?
> 
> I fully agree that the whole point of PMIP is make mobility 
> management transparent to the MN. However, as far as I 
> understand from my reading of RFC5213, a mobile node attached 
> to a PMIPv6 domain might not be entitled to the network-based 
> mobility management service, and RFC5213 (section 6.14) still 
> support this node to get connectivity (regular
> access) from the MAG.

I don't quite understand how 5213 provides protocol support to distiniguish between nodes for which mobility support is offered, and those for which it is not offered. I mentioned this in my prvious e-mail..

> 
> Related to this, it is also my interpretation of RFC5213 (section
> 6.10.5) that the local routing support provided by the basic 
> spec (controlled with the EnableMAGLocalRouting flag) only 
> applies to communications between a PMIPv6 MN and a regular 
> IPv6 host attached to the same MAG.
> 

If there is no protocol support to differentiate the nodes, the above is moot.

> This is just to try to clarify what RFC5213 provides (actually, very
> little) and what does not in regards to local routing 
> support. Do you see my point?
> 

Okay, thanks. For our purposes here, let us assume that we are dealing with a scenario where the PMIP6 is provided to nodes. One of the main emphasis in this BOF effort is to focus on deployment considerations, and I believe addressing the local forwarding for a PMIP6 domain would be worthwhile.

Later on, we could consider working on other extensions.

Thanks,

-Rajeev

> Thanks!
> 
> Carlos
> 
> > 
> > 
> > > 
> > > 	- If my previous understanding is correct, then RFC5213 
> does not 
> > > only define any mechanism to perform local routing 
> between two MNs 
> > > connected to the same PMIPv6 domain (not even for the 
> case in which 
> > > both are attached to the same MAG).
> > > Then, IMHO it would be better to change the terminology in the PS 
> > > and avoid using CN or coming up with different terms for 
> a CN that 
> > > is getting network-based mobility service from a CN that is not 
> > > (i.e. it is just a regular IPv6 node getting access from a MAG).
> > 
> > See above.
> > 
> > > 
> > > 	- Currently, the PS only addresses the case of local routing 
> > > between two MNs connected to the same PMIPv6 domain.
> > > I think the scenario of optimising traffic between an MN and a 
> > > regular IPv6 host that is locally connected to a MAG 
> should also be 
> > > addressed. Not sure the implications on the potential 
> solutions, but 
> > > it might have an impact on the classification scheme that 
> is used in 
> > > the PS now (A[number of MAGs][number of LMAs]).
> > > 
> > 
> > Our focus should be on solving the problem for nodes 
> attached to a PMIP6 domain.
> > 
> > Thanks,
> > 
> > -Rajeev
> > 
> > 
> > > 	Thanks,
> > > 
> > > 	Carlos
> > > 
> > > El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?:
> > > > Hi all,
> > > > 
> > > > please find the link to a first version of a Localized
> > > Routing Problem
> > > > Statement below.
> > > > The abstract of the PS document is as follows:
> > > > 
> > > > Abstract:
> > > > 
> > > >    Proxy Mobile IPv6 is the IETF standard for network-based
> > > localized
> > > >    mobility management.  In Proxy Mobile IPv6, mobile nodes are
> > > >    topologically anchored at a Local Mobility Anchor, which
> > > forwards all
> > > >    data for registered mobile nodes.  The set up and support for
> > > >    localized routing, which allows forwarding of data
> > > packets between
> > > >    mobile nodes and correspondent nodes directly without
> > > traversing an
> > > >    LMA, is not considered.  This document describes the
> > > problem space of
> > > >    localized routing in Proxy Mobile IPv6.
> > > > 
> > > > 
> > > > Any comments to this version of the problem statement 
> are welcome.
> > > > 
> > > > 
> > > 
> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps
> > > -0
> > > > 0.txt
> > > > 
> > > > Best regards,
> > > > marco
> > > > 
> > > > 
> > > > _______________________________________________
> > > > NetExt mailing list
> > > > NetExt at mail.mobileip.jp
> > > > http://www.mobileip.jp/mailman/listinfo/netext
> > > -- 
> > >  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> > >  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> > >         Deployment Experiences on Vehicular networks
> > >                   http://www.weedev.org/
> > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > 
> > 
> > 
> > This email and any attachments may contain legally 
> privileged and/or confidential information of Starent 
> Networks, Corp. and is intended only for the individual or 
> entity named in the message.  The information transmitted may 
> not be used to create or change any contractual obligations 
> of Starent Networks, Corp.  Any review, retransmission, 
> dissemination or other use of, or taking of any action in 
> reliance upon this e-mail and its attachments by persons or 
> entities other than the intended recipient is prohibited. If 
> you are not the intended recipient, please notify the sender 
> immediately -- by replying to this message or by sending an 
> email to postmaster at starentnetworks.com -- and destroy all 
> copies of this message and any attachments without reading or 
> disclosing their contents. Thank you.
> -- 
>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
>         Deployment Experiences on Vehicular networks
>                   http://www.weedev.org/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Tue, 24 Feb 2009 08:41:46 +0100
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <1235461306.5013.3.camel@localhost>

Hi Suresh,

El lun, 23-02-2009 a las 18:31 -0500, Suresh Krishnan escribi?:
> Hi Raj,
> 
> On 23/02/09 12:28 AM, Basavaraj.Patil at nokia.com wrote:
> > 
> > 
> > On 2/19/09 5:19 PM, "Suresh Krishnan" <suresh.krishnan at ericsson.com> wrote:
> > 
> > 
> >>>       - IMHO, it'd be good to explicitly describe what a "change on the MN"
> >>> within the scope of NETEXT. For example, is it fine assuming IEEE 802.21
> >>> support on the MN or is this "a change on the MN"?
> > 
> > Whether an MN supports 802.21 functionality is not something that can be
> > assumed IMO. A change on the MN from the Netext perspective would be some
> > new functionality or signaling enhancement that may be specified to
> > accomplish a specific goal w.r.t handovers or multihoming. Having said that
> > please do note that Netext solutions should not immediately delve into
> > specifying changes or solutions that affect the MN. We have to emphasise
> > that changes to the host are to be considered *ONLY* when all other means
> > are exhausted.
> 
> Even though you quoted me, it was Carlos's text you were responding to 
> :-). I agree with your assessment.

I also agree. My point was to make more clear what we understand in
NETEXT by an MN change.

> 
> > 
> >> Probably something to add to the charter?
> > 
> > We may add some text to the charter to make the view on host changes clear.
> 
> OK.

Good, that'd help.

Thanks,

Carlos

> 
> Cheers
> Suresh
-- 
 Carlos Jes?s Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090224/b2fa81b2/attachment.bin>

From: suresh.krishnan at ericsson.com (Suresh Krishnan)
Date: Mon, 23 Feb 2009 18:31:59 -0500
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Raj,

On 23/02/09 12:28 AM, Basavaraj.Patil at nokia.com wrote:
> 
> 
> On 2/19/09 5:19 PM, "Suresh Krishnan" <suresh.krishnan at ericsson.com> wrote:
> 
> 
>>>       - IMHO, it'd be good to explicitly describe what a "change on the MN"
>>> within the scope of NETEXT. For example, is it fine assuming IEEE 802.21
>>> support on the MN or is this "a change on the MN"?
> 
> Whether an MN supports 802.21 functionality is not something that can be
> assumed IMO. A change on the MN from the Netext perspective would be some
> new functionality or signaling enhancement that may be specified to
> accomplish a specific goal w.r.t handovers or multihoming. Having said that
> please do note that Netext solutions should not immediately delve into
> specifying changes or solutions that affect the MN. We have to emphasise
> that changes to the host are to be considered *ONLY* when all other means
> are exhausted.

Even though you quoted me, it was Carlos's text you were responding to 
:-). I agree with your assessment.

> 
>> Probably something to add to the charter?
> 
> We may add some text to the charter to make the view on host changes clear.

OK.

Cheers
Suresh

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Mon, 23 Feb 2009 06:28:06 +0100
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

On 2/19/09 5:19 PM, "Suresh Krishnan" <suresh.krishnan at ericsson.com> wrote:

>>       - IMHO, it'd be good to explicitly describe what a "change on the MN"
>> within the scope of NETEXT. For example, is it fine assuming IEEE 802.21
>> support on the MN or is this "a change on the MN"?

Whether an MN supports 802.21 functionality is not something that can be
assumed IMO. A change on the MN from the Netext perspective would be some
new functionality or signaling enhancement that may be specified to
accomplish a specific goal w.r.t handovers or multihoming. Having said that
please do note that Netext solutions should not immediately delve into
specifying changes or solutions that affect the MN. We have to emphasise
that changes to the host are to be considered *ONLY* when all other means
are exhausted.

>
> Probably something to add to the charter?

We may add some text to the charter to make the view on host changes clear.

-Raj

>
> Cheers
> Suresh
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Fri, 20 Feb 2009 09:08:29 +0100
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
References: <[email-masked]> <1234810902.5187.92.camel@localhost>  <[email-masked]>
Message-ID: <1235117309.4633.3.camel@localhost>

Hi Suresh,

	Thanks for the reply.  Some minor comments inline.

El jue, 19-02-2009 a las 18:19 -0500, Suresh Krishnan escribi?:
> Hi Carlos,
>    Thanks for your comments. Please find responses inline
> 
> On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
> > * PGP Signed by an unknown key
> > 
> > Hi Suresh,
> > 
> > 	Thanks for the draft. I think it's short and clear. Some comments
> > below:
> > 
> > 	- Section 2.1. Formation of interface identifier. The issue described
> > there only applies if SLAAC is used, right? If DHCP is used, the issue
> > is then on the network side, to ensure that the address provided to the
> > new interface of the MN is the same that it was (or is still) using on
> > the previous interface, right?
> 
> Yes. This is correct. I can probably add a new section on the network 
> side about the DHCPv6 issue

OK.

> 
> > 
> > 	- Section 2.2 Usage of the same address on multiple interfaces. Since
> > it seems that we cannot assume that is safe to use the same address on
> > multiple interfaces (without requiring changes on the MN side), this
> > implies that: a) if NETEXT work is restricted to work on solutions that
> > do not impose changes on the MN, use cases requiring the MN to use the
> > same address simultaneously are out of the scope of NETEXT, b) we allow
> > for changes on the MN side. Additionally, it might be good to analyse if
> > it is OK for the MN to receive (and send) traffic addressed to the IPv6
> > address of one interface through a different interface (weak end-system
> > model defined in RFC 1122 or draft-thaler-ip-model-evolution).
> 
> While I agree with your analysis of the problem, are we delving too much 
> into the solution space by adding any such text?

Well, it's true it is borderline. My point was just to try to analyse
how much support the MN could probably provide and what is missing.

> 
> > 
> > 	- IMHO, it'd be good to explicitly describe what a "change on the MN"
> > within the scope of NETEXT. For example, is it fine assuming IEEE 802.21
> > support on the MN or is this "a change on the MN"?
> 
> Probably something to add to the charter?

That's a possibility. My point was again to make clear what we
understand -- within the scope of NETEXT -- by "MN involvement/changes"

Thanks,

Carlos

> 
> Cheers
> Suresh
> 
-- 
 Carlos Jes?s Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090220/35ea48d1/attachment.bin>

From: yokota at kddilabs.jp (Hidetoshi Yokota)
Date: Fri, 20 Feb 2009 10:47:08 +0900
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<1234810902.5187.92.camel@localhost> <[email-masked]>
Message-ID: <[email-masked]>

Hi Carlos and Suresh,

Suresh Krishnan wrote:
> Hi Carlos,
>   Thanks for your comments. Please find responses inline
> 
> On 16/02/09 02:01 PM, Carlos Jesu's Bernardos Cano wrote:
>> * PGP Signed by an unknown key
>>
>> Hi Suresh,
>>
>>     Thanks for the draft. I think it's short and clear. Some comments
>> below:
>>
>>     - Section 2.1. Formation of interface identifier. The issue described
>> there only applies if SLAAC is used, right? If DHCP is used, the issue
>> is then on the network side, to ensure that the address provided to the
>> new interface of the MN is the same that it was (or is still) using on
>> the previous interface, right?
> 
> Yes. This is correct. I can probably add a new section on the network 
> side about the DHCPv6 issue

I agree. I think DHCPv6 is as important. We should consider interworking
with DHCPv6 server/relay and should mention it in the PS.

>>
>>     - Section 2.2 Usage of the same address on multiple interfaces. Since
>> it seems that we cannot assume that is safe to use the same address on
>> multiple interfaces (without requiring changes on the MN side), this
>> implies that: a) if NETEXT work is restricted to work on solutions that
>> do not impose changes on the MN, use cases requiring the MN to use the
>> same address simultaneously are out of the scope of NETEXT, b) we allow
>> for changes on the MN side. Additionally, it might be good to analyse if
>> it is OK for the MN to receive (and send) traffic addressed to the IPv6
>> address of one interface through a different interface (weak end-system
>> model defined in RFC 1122 or draft-thaler-ip-model-evolution).
> 
> While I agree with your analysis of the problem, are we delving too much 
> into the solution space by adding any such text?

This is a hard question. As Jari suggested in another e-mail, we should
try best to find a solution that doesn't require a host change, then to
find one with the least impact or change on the host side. In the latter
case, we will be spending most of the time to decide whether to make it
in or out of scope...

>>
>>     - IMHO, it'd be good to explicitly describe what a "change on the MN"
>> within the scope of NETEXT. For example, is it fine assuming IEEE 802.21
>> support on the MN or is this "a change on the MN"?
> 
> Probably something to add to the charter?

This is also a hard question, but one of the purposes of NETEXT, I
guess. The definition of the change on the MN is a more comprehensive
isse, not limited to the inter-technology handover, so I believe that it
should be described somewhere in the charter or a more comprehensive PS,
if any.

Anyway, it's good that you brought it up.

Regards,
--
Hidetoshi

> Cheers
> Suresh
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 
> 
> 

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Fri, 20 Feb 2009 08:28:04 +0800
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Telemaco,

Please see in-line.

BR,
Mohana

-----Original Message-----
From: MELIA TELEMACO [mailto:Telemaco.Melia at alcatel-lucent.com] 
Sent: Thursday, February 19, 2009 4:13 PM
To: Mohana Jeyatharan; pierrick.seite at orange-ftgroup.com; liebsch at nw.neclab.eu; yokota at kddilabs.jp
Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
Subject: RE: [Netext] Review of the Multihoming PS I-D

Hi Mohana,

Few comments below:

If same address is assigned to different interfaces, MN and LMA need to share routing policy to route each flow to the correct interface. But distribution of policies is an issue; I mean, distribution of policies could be done via an interface between LMA and MN, but it would be a severe violation of PMIP architecture. 
[Mohana] Distribution of policy can be done by MN-AR interface as well. No need of MN-LMA interaction....

[TELE] About policies distribution: I am not sure what is the feeling of people here, but this thread is very similar to what has been discussed in the MIP4 session last time @Minneapolis on Multiple CoA Support (Sri). The major concern from Jari and Henrik was that policy distribution cannot be ignored and left behind (you can check the minutes), the protocol might become useless otherwise.

[Mohana] Yes, true. First simultanoeus reachability for single HNP. Following that it will be at some point, one needs to work of flowbindings etc. 

So, even if other distribution schemes can be possible, I do not really see why sharing same address on several interfaces can facilitate IP flow mobility. Mainly because routing in that case is a tricky problem. It seems to me that this feature brings more issues than benefits...
[Mohana] I am not so sure about the issues you are conecrned with. 

On the other hand RFC 5213 provides a basic support of IP mobility between different interfaces. But here the issue is on the determination of the "handoff indicator" at the MAG. Don't you think that clarification on the determination of the "handoff indicator" in case of multihoming and IP flow mobility would worth the effort in Netext?
[Mohana] Of course for IP flow mobility and multihoming, proper MN-MAG triggers may need to be present. RFC 5213 does not specify how MAGs get the HI indicator options. It canbe via L2 or some other way. But for multihoming host may need to accept packets destined to one interface via another. 

[TELE] Glad that you mention this, Carlos already did before. I think that this change affects the terminal as much as having the same address configured on two interfaces. The PS document should capture this.
[Mohana] In the Multihoming PS document, it is explained that host needs some changes to achieve this. But, there was no dwelling into solution space. Wondering whether this is essential in a PS? What do your'll think?

An intelligent client can do this knowing that this is PMIPv6. Anyway, in some SDOs the mobility management mechansims are known to the Mn if it wants to. They do have mobility mode selection kind of methods. Thus such multihoming in PMIPv6 can be achievable without much difficulty.  

My two cents,
Regards,
Pierrick

> -----Message d'origine-----
> De?: netext-bounces at mail.mobileip.jp [mailto:netext- 
> bounces at mail.mobileip.jp] De la part de MELIA TELEMACO Envoy??: mardi 
> 17 f?vrier 2009 17:41 ??: Marco Liebsch; Hidetoshi Yokota Cc?: 
> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com Objet?: Re: 
> [Netext] Review of the Multihoming PS I-D
> 
> Hi,
> 
> I guess there are two important emerging aspects out of this discussion:
> - involvement of the mobile node in the multihoming process
> - transfer of policies, how and where to
> 
> I would like also to stress the fact that we should not necessarily 
> see multihoming as a solution to optimize mobility.
> A node can be multihomed without moving at all (nomadic user) and we 
> have other documents (transient BCE) looking at how to optimize mobility.
> 
> How folks see things?
> 
> telemaco
> 
> 
> -----Message d'origine-----
> De : Marco Liebsch [mailto:liebsch at nw.neclab.eu] Envoy? : mardi 17 
> f?vrier 2009 15:06 ? : Hidetoshi Yokota Cc : netext at mail.mobileip.jp; 
> MELIA TELEMACO; Basavaraj.Patil at nokia.com Objet : Re: [Netext] Review 
> of the Multihoming PS I-D
> 
> Hidetoshi Yokota wrote:
> > Hi Marco,
> >
> > Marco Liebsch wrote:
> >
> >> Hidetoshi,
> >>
> >
> > I'm still talking about definitions and categorization. I'm not 
> > downplaying any of them.
> >
> sure.
> 
> >
> >> I think we have different opinions on an important aspect:
> >> My understanding of your opinion is that as soon as the MN gets
> >> (e.g.) HNP1 assigned to interface 1 (IF1) as a result of the 
> >> registration, it can use the same HNP1 for a different interface, 
> >> e.g. IF2, without having this HNP1 received from the network as a 
> >> result of IF2's registration.
> >> Correct?
> >>
> >
> > No, I'm not going that far, yet :-). I'm still trying to understand 
> > what people are thinking about multihoming, handover and IP flow 
> > mobility, etc. My understanding is that if the MN wants to use HNP1 
> > on IF2, it would have to register it with the LMA via the 
> > corresponding MAG; otherwise, there would be no guarantee that 
> > packets are coming back
> to IF2.
> >
> Ok.
> 
> >
> >> I think the MN can use HNP1 only for IF2, if the LMA assigns the 
> >> same
> >> HNP1 to IF2 during its registration. To result then in the same IP 
> >> address, it's up to the MN to take the same suffix for both interfaces'
> IP address.
> >> That's again something where we have the same opinion.
> >>
> >
> > I think this is a sensible behavior. The key thing is to give a hint 
> > to the LMA on which interface the MN wants to get packets.
> >
> Well, yes, the LMA needs a hint about the routing policy (which flow 
> goes which way). But here the MN plays a role and that hint may not 
> come with
> PMIPv6 signaling.
> 
> >
> >> So, when we talk about using the same IP address on both 
> >> interfaces, still the allowed prefix for each interface is network 
> >> controlled, whereas the MN is free to chose any suffix. That's at least my view.
> >>
> >
> > I personally agree with your view. In addition, the LMA should get 
> > in sync with the MN especially when those two interfaces are 
> > connected to different MAGs.
> >
> Thanks for the clarification.
> 
> Greetings,
> marco
> 
> > Regards,
> >
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

From: suresh.krishnan at ericsson.com (Suresh Krishnan)
Date: Thu, 19 Feb 2009 18:19:22 -0500
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <1234810902.5187.92.camel@localhost>
References: <[email-masked]> <1234810902.5187.92.camel@localhost>
Message-ID: <[email-masked]>

Hi Carlos,
   Thanks for your comments. Please find responses inline

On 16/02/09 02:01 PM, Carlos Jes?s Bernardos Cano wrote:
> * PGP Signed by an unknown key
> 
> Hi Suresh,
> 
> 	Thanks for the draft. I think it's short and clear. Some comments
> below:
> 
> 	- Section 2.1. Formation of interface identifier. The issue described
> there only applies if SLAAC is used, right? If DHCP is used, the issue
> is then on the network side, to ensure that the address provided to the
> new interface of the MN is the same that it was (or is still) using on
> the previous interface, right?

Yes. This is correct. I can probably add a new section on the network 
side about the DHCPv6 issue

> 
> 	- Section 2.2 Usage of the same address on multiple interfaces. Since
> it seems that we cannot assume that is safe to use the same address on
> multiple interfaces (without requiring changes on the MN side), this
> implies that: a) if NETEXT work is restricted to work on solutions that
> do not impose changes on the MN, use cases requiring the MN to use the
> same address simultaneously are out of the scope of NETEXT, b) we allow
> for changes on the MN side. Additionally, it might be good to analyse if
> it is OK for the MN to receive (and send) traffic addressed to the IPv6
> address of one interface through a different interface (weak end-system
> model defined in RFC 1122 or draft-thaler-ip-model-evolution).

While I agree with your analysis of the problem, are we delving too much 
into the solution space by adding any such text?

> 
> 	- IMHO, it'd be good to explicitly describe what a "change on the MN"
> within the scope of NETEXT. For example, is it fine assuming IEEE 802.21
> support on the MN or is this "a change on the MN"?

Probably something to add to the charter?

Cheers
Suresh

From: xiayangsong at huawei.com (Frank Xia)
Date: Thu, 19 Feb 2009 10:41:37 -0600
Subject: [Netext] Review of the Multihoming PS I-D
References: <[email-masked]> <1235035272.4619.39.camel@localhost> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Gerardo

I know there is official requirement from 3GPP,
and I am  not offically  asked  to push in IETF either  :-).

>From business perspective,  what operators care is how
to make full use of their scarce air resource.
This is one of main motivation to have dual mode terminals
with 3GPP and WiFi (you can buy one from T-Mobile :-) ).

When the dual mode terminal moves  home where WLAN
access is available,  it prefer offloading some low QoS service
from 3GPP to WiFi.  At the same time, high QoS service
still remains in 3GPP.

BR
Frank

----- Original Message ----- 
From: "Giaretta, Gerardo" <gerardog at qualcomm.com>
To: "Frank Xia" <xiayangsong at huawei.com>; <cjbc at it.uc3m.es>; 
<Basavaraj.Patil at nokia.com>
Cc: <netext at mail.mobileip.jp>; <Mohana.Jeyatharan at sg.panasonic.com>; 
<Telemaco.Melia at alcatel-lucent.com>
Sent: Thursday, February 19, 2009 9:56 AM
Subject: RE: [Netext] Review of the Multihoming PS I-D

Hi Frank,

I am happy if Huawei wants you to push this in the IETF, I hope you can make 
it :-)

I wanted just to provide the indication that there is not any official 
requirement from 3GPP.

We can then discuss about whatever business can drive this (what radios do 
you have in mind when you talk about multihoming and flow mobility for 
PMIP?).

Gerardo

> -----Original Message-----
> From: Frank Xia [mailto:xiayangsong at huawei.com]
> Sent: Thursday, February 19, 2009 7:51 AM
> To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com
> Cc: netext at mail.mobileip.jp; Mohana.Jeyatharan at sg.panasonic.com;
> Telemaco.Melia at alcatel-lucent.com
> Subject: Re: [Netext] Review of the Multihoming PS I-D
>
> Hi All
>
> My 3GPP colleagues also suggested me  pushing in  IETF community.
> If we talk about 3GPP requirment, there is even no specific PMIPv6
> multi-homing requirement.
>
> My point is business driving technical employment.
> IMO, flow mobility is  clearly required in PMIP deployment environment.
>
> BR
> Frank
>
> ----- Original Message -----
> From: "Giaretta, Gerardo" <gerardog at qualcomm.com>
> To: <cjbc at it.uc3m.es>; <Basavaraj.Patil at nokia.com>
> Cc: <netext at mail.mobileip.jp>; <Mohana.Jeyatharan at sg.panasonic.com>;
> <Telemaco.Melia at alcatel-lucent.com>
> Sent: Thursday, February 19, 2009 4:16 AM
> Subject: Re: [Netext] Review of the Multihoming PS I-D
>
>
> Hi all,
>
> To clarify flow mobility is not a requirement for PMIPv6 right now in 
> 3GPP.
> There is a study item ongoing but 3GPP has not yet decided that flow
> mobility is needed for PMIPv6.
>
> Cheers,
> Gerardo
> (from Budapest, 3GPP SA2 meeting)
>
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp
> > [mailto:netext-bounces at mail.mobileip.jp]
> > On Behalf Of Carlos Jes?s Bernardos Cano
> > Sent: Thursday, February 19, 2009 1:21 AM
> > To: Basavaraj.Patil at nokia.com
> > Cc: Mohana.Jeyatharan at sg.panasonic.com; 
> > Telemaco.Melia at alcatel-lucent.com;
> > netext at mail.mobileip.jp
> > Subject: Re: [Netext] Review of the Multihoming PS I-D
> >
> > Hi,
> >
> > One question: flow mobility seems to be an interesting feature that is a
> > requirement from 3GPP, it is related with multihoming but it is not
> > strictly a
> > multihoming isse, right? I mean, multihoming extensions would likely 
> > make
> > easier to support flow mobility, but would probably require additional
> > mechanisms. How do we capture this? I'm not sure the multihoming PS is 
> > the
> > right place for that, maybe the multihoming PS can point out that, but 
> > we
> > need
> > an explicit document (and charter item) for dealing with flow mobility.
> > What
> > do others think?
> >
> > Thanks!
> >
> > Carlos
> >
> > El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com
> > escribi?:
> > > It may be of interest in the context of multihoming to consider moving
> > > a flow from one interface to another. A flow which is associated with
> > > an interface on the MN may be moved to another interface in the case
> > > of a multihomed host for various reasons. This may be viewed as a
> > > handover as well from the flow perspective. Multihoming enables the
> > > possibility to move flows between interfaces. I think we could keep
> > > this in the context of the multihoming discussion if there is 
> > > consensus
> > > on
> > it.
> > >
> > > -Raj
> > >
> > >
> > > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan"
> > > <Mohana.Jeyatharan at sg.panasonic.com> wrote:
> > >
> > > > Hi Hidetoshi,
> > > >
> > > > In Multihoming PS ID, there are some handoff optimization scenarios
> > involved.
> > > > For example optmizing the handoff of a certain interface by means of
> > > > another, and achieving flow mobility via another interface during
> > > > disconnection. These events are triggered due to handoff or
> > > > disconnection, but the scenarios are associated with multihoming.
> > > > That is being able to receive a flow that is usually destined to an
> > > > interface via another "connected" interface. This is where these
> > > > scenarios are different from normal handoff and more tied to
> > > > multihoming.
> > > >
> > > > However, I agree that these are also tied with handoff and some
> > > > confusion is there. Anyway, we are planning to revise the
> > > > multihoming PS draft and are thinking of focusing on the
> > > > disconnection scenario, handoff optimization as less focus scenarios
> > > > and
> > focus on scenarios that are cateogorized by Raj.
> > > >
> > > > BR,
> > > > Mohana
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
> > > > Sent: Tuesday, February 17, 2009 12:42 PM
> > > > To: Mohana Jeyatharan
> > > > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch;
> > > > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> > > > Subject: Re: [Netext] Review of the Multihoming PS I-D
> > > >
> > > > Hi Mohana and all,
> > > >
> > > > I think your scenario is viable, but we should probably more
> > > > carefully clarify the difference between multihoming and handover.
> > > > Assigning the same address to different interfaces on the MN for a
> > > > sufficiently long time sounds like multihoming; however, if this
> > > > situation holds only for a short period of time for MN's movement or
> > > > fail over or for whatever reason, that sounds like handover. This
> > > > difference would affect the behavior of the LMA and MAG(s).
> > > >
> > > > In Section 2 of the Multihoming PS document, Issues related to
> > > > handoff performance and those related to flow mobility during sudden
> > > > disconnection appear to be categorized into handover. If all agree
> > > > that these issues should also be included in multihoming, that's
> > > > fine. I would just like to make sure of it first of all.
> > > >
> > > > Regards,
> > > > --
> > > > Hidetoshi
> > > >
> > >
> > >
> > > _______________________________________________
> > > NetExt mailing list
> > > NetExt at mail.mobileip.jp
> > > http://www.mobileip.jp/mailman/listinfo/netext
> > --
> >  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> >  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> >         Deployment Experiences on Vehicular networks
> >                   http://www.weedev.org/
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Thu, 19 Feb 2009 07:56:29 -0800
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]> <1235035272.4619.39.camel@localhost> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Frank,

I am happy if Huawei wants you to push this in the IETF, I hope you can make it :-) 

I wanted just to provide the indication that there is not any official requirement from 3GPP.

We can then discuss about whatever business can drive this (what radios do you have in mind when you talk about multihoming and flow mobility for PMIP?). 

Gerardo

> -----Original Message-----
> From: Frank Xia [mailto:xiayangsong at huawei.com]
> Sent: Thursday, February 19, 2009 7:51 AM
> To: Giaretta, Gerardo; cjbc at it.uc3m.es; Basavaraj.Patil at nokia.com
> Cc: netext at mail.mobileip.jp; Mohana.Jeyatharan at sg.panasonic.com;
> Telemaco.Melia at alcatel-lucent.com
> Subject: Re: [Netext] Review of the Multihoming PS I-D
> 
> Hi All
> 
> My 3GPP colleagues also suggested me  pushing in  IETF community.
> If we talk about 3GPP requirment, there is even no specific PMIPv6
> multi-homing requirement.
> 
> My point is business driving technical employment.
> IMO, flow mobility is  clearly required in PMIP deployment environment.
> 
> BR
> Frank
> 
> ----- Original Message -----
> From: "Giaretta, Gerardo" <gerardog at qualcomm.com>
> To: <cjbc at it.uc3m.es>; <Basavaraj.Patil at nokia.com>
> Cc: <netext at mail.mobileip.jp>; <Mohana.Jeyatharan at sg.panasonic.com>;
> <Telemaco.Melia at alcatel-lucent.com>
> Sent: Thursday, February 19, 2009 4:16 AM
> Subject: Re: [Netext] Review of the Multihoming PS I-D
> 
> 
> Hi all,
> 
> To clarify flow mobility is not a requirement for PMIPv6 right now in 3GPP.
> There is a study item ongoing but 3GPP has not yet decided that flow
> mobility is needed for PMIPv6.
> 
> Cheers,
> Gerardo
> (from Budapest, 3GPP SA2 meeting)
> 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp
> > [mailto:netext-bounces at mail.mobileip.jp]
> > On Behalf Of Carlos Jes?s Bernardos Cano
> > Sent: Thursday, February 19, 2009 1:21 AM
> > To: Basavaraj.Patil at nokia.com
> > Cc: Mohana.Jeyatharan at sg.panasonic.com; Telemaco.Melia at alcatel-lucent.com;
> > netext at mail.mobileip.jp
> > Subject: Re: [Netext] Review of the Multihoming PS I-D
> >
> > Hi,
> >
> > One question: flow mobility seems to be an interesting feature that is a
> > requirement from 3GPP, it is related with multihoming but it is not
> > strictly a
> > multihoming isse, right? I mean, multihoming extensions would likely make
> > easier to support flow mobility, but would probably require additional
> > mechanisms. How do we capture this? I'm not sure the multihoming PS is the
> > right place for that, maybe the multihoming PS can point out that, but we
> > need
> > an explicit document (and charter item) for dealing with flow mobility.
> > What
> > do others think?
> >
> > Thanks!
> >
> > Carlos
> >
> > El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com
> > escribi?:
> > > It may be of interest in the context of multihoming to consider moving
> > > a flow from one interface to another. A flow which is associated with
> > > an interface on the MN may be moved to another interface in the case
> > > of a multihomed host for various reasons. This may be viewed as a
> > > handover as well from the flow perspective. Multihoming enables the
> > > possibility to move flows between interfaces. I think we could keep
> > > this in the context of the multihoming discussion if there is consensus
> > > on
> > it.
> > >
> > > -Raj
> > >
> > >
> > > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan"
> > > <Mohana.Jeyatharan at sg.panasonic.com> wrote:
> > >
> > > > Hi Hidetoshi,
> > > >
> > > > In Multihoming PS ID, there are some handoff optimization scenarios
> > involved.
> > > > For example optmizing the handoff of a certain interface by means of
> > > > another, and achieving flow mobility via another interface during
> > > > disconnection. These events are triggered due to handoff or
> > > > disconnection, but the scenarios are associated with multihoming.
> > > > That is being able to receive a flow that is usually destined to an
> > > > interface via another "connected" interface. This is where these
> > > > scenarios are different from normal handoff and more tied to
> > > > multihoming.
> > > >
> > > > However, I agree that these are also tied with handoff and some
> > > > confusion is there. Anyway, we are planning to revise the
> > > > multihoming PS draft and are thinking of focusing on the
> > > > disconnection scenario, handoff optimization as less focus scenarios
> > > > and
> > focus on scenarios that are cateogorized by Raj.
> > > >
> > > > BR,
> > > > Mohana
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
> > > > Sent: Tuesday, February 17, 2009 12:42 PM
> > > > To: Mohana Jeyatharan
> > > > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch;
> > > > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> > > > Subject: Re: [Netext] Review of the Multihoming PS I-D
> > > >
> > > > Hi Mohana and all,
> > > >
> > > > I think your scenario is viable, but we should probably more
> > > > carefully clarify the difference between multihoming and handover.
> > > > Assigning the same address to different interfaces on the MN for a
> > > > sufficiently long time sounds like multihoming; however, if this
> > > > situation holds only for a short period of time for MN's movement or
> > > > fail over or for whatever reason, that sounds like handover. This
> > > > difference would affect the behavior of the LMA and MAG(s).
> > > >
> > > > In Section 2 of the Multihoming PS document, Issues related to
> > > > handoff performance and those related to flow mobility during sudden
> > > > disconnection appear to be categorized into handover. If all agree
> > > > that these issues should also be included in multihoming, that's
> > > > fine. I would just like to make sure of it first of all.
> > > >
> > > > Regards,
> > > > --
> > > > Hidetoshi
> > > >
> > >
> > >
> > > _______________________________________________
> > > NetExt mailing list
> > > NetExt at mail.mobileip.jp
> > > http://www.mobileip.jp/mailman/listinfo/netext
> > --
> >  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> >  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> >         Deployment Experiences on Vehicular networks
> >                   http://www.weedev.org/
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: xiayangsong at huawei.com (Frank Xia)
Date: Thu, 19 Feb 2009 09:50:32 -0600
Subject: [Netext] Review of the Multihoming PS I-D
References: <[email-masked]> <1235035272.4619.39.camel@localhost> <[email-masked]>
Message-ID: <[email-masked]>

Hi All

My 3GPP colleagues also suggested me  pushing in  IETF community.
If we talk about 3GPP requirment, there is even no specific PMIPv6
multi-homing requirement.

My point is business driving technical employment.
IMO, flow mobility is  clearly required in PMIP deployment environment.

BR
Frank

----- Original Message ----- 
From: "Giaretta, Gerardo" <gerardog at qualcomm.com>
To: <cjbc at it.uc3m.es>; <Basavaraj.Patil at nokia.com>
Cc: <netext at mail.mobileip.jp>; <Mohana.Jeyatharan at sg.panasonic.com>; 
<Telemaco.Melia at alcatel-lucent.com>
Sent: Thursday, February 19, 2009 4:16 AM
Subject: Re: [Netext] Review of the Multihoming PS I-D

Hi all,

To clarify flow mobility is not a requirement for PMIPv6 right now in 3GPP. 
There is a study item ongoing but 3GPP has not yet decided that flow 
mobility is needed for PMIPv6.

Cheers,
Gerardo
(from Budapest, 3GPP SA2 meeting)

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp]
> On Behalf Of Carlos Jes?s Bernardos Cano
> Sent: Thursday, February 19, 2009 1:21 AM
> To: Basavaraj.Patil at nokia.com
> Cc: Mohana.Jeyatharan at sg.panasonic.com; Telemaco.Melia at alcatel-lucent.com;
> netext at mail.mobileip.jp
> Subject: Re: [Netext] Review of the Multihoming PS I-D
>
> Hi,
>
> One question: flow mobility seems to be an interesting feature that is a
> requirement from 3GPP, it is related with multihoming but it is not 
> strictly a
> multihoming isse, right? I mean, multihoming extensions would likely make
> easier to support flow mobility, but would probably require additional
> mechanisms. How do we capture this? I'm not sure the multihoming PS is the
> right place for that, maybe the multihoming PS can point out that, but we 
> need
> an explicit document (and charter item) for dealing with flow mobility. 
> What
> do others think?
>
> Thanks!
>
> Carlos
>
> El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com
> escribi?:
> > It may be of interest in the context of multihoming to consider moving
> > a flow from one interface to another. A flow which is associated with
> > an interface on the MN may be moved to another interface in the case
> > of a multihomed host for various reasons. This may be viewed as a
> > handover as well from the flow perspective. Multihoming enables the
> > possibility to move flows between interfaces. I think we could keep
> > this in the context of the multihoming discussion if there is consensus 
> > on
> it.
> >
> > -Raj
> >
> >
> > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan"
> > <Mohana.Jeyatharan at sg.panasonic.com> wrote:
> >
> > > Hi Hidetoshi,
> > >
> > > In Multihoming PS ID, there are some handoff optimization scenarios
> involved.
> > > For example optmizing the handoff of a certain interface by means of
> > > another, and achieving flow mobility via another interface during
> > > disconnection. These events are triggered due to handoff or
> > > disconnection, but the scenarios are associated with multihoming.
> > > That is being able to receive a flow that is usually destined to an
> > > interface via another "connected" interface. This is where these
> > > scenarios are different from normal handoff and more tied to 
> > > multihoming.
> > >
> > > However, I agree that these are also tied with handoff and some
> > > confusion is there. Anyway, we are planning to revise the
> > > multihoming PS draft and are thinking of focusing on the
> > > disconnection scenario, handoff optimization as less focus scenarios 
> > > and
> focus on scenarios that are cateogorized by Raj.
> > >
> > > BR,
> > > Mohana
> > >
> > >
> > > -----Original Message-----
> > > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
> > > Sent: Tuesday, February 17, 2009 12:42 PM
> > > To: Mohana Jeyatharan
> > > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch;
> > > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> > > Subject: Re: [Netext] Review of the Multihoming PS I-D
> > >
> > > Hi Mohana and all,
> > >
> > > I think your scenario is viable, but we should probably more
> > > carefully clarify the difference between multihoming and handover.
> > > Assigning the same address to different interfaces on the MN for a
> > > sufficiently long time sounds like multihoming; however, if this
> > > situation holds only for a short period of time for MN's movement or
> > > fail over or for whatever reason, that sounds like handover. This
> > > difference would affect the behavior of the LMA and MAG(s).
> > >
> > > In Section 2 of the Multihoming PS document, Issues related to
> > > handoff performance and those related to flow mobility during sudden
> > > disconnection appear to be categorized into handover. If all agree
> > > that these issues should also be included in multihoming, that's
> > > fine. I would just like to make sure of it first of all.
> > >
> > > Regards,
> > > --
> > > Hidetoshi
> > >
> >
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> --
>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
>         Deployment Experiences on Vehicular networks
>                   http://www.weedev.org/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext 

From: gerardog at qualcomm.com (Giaretta, Gerardo)
Date: Thu, 19 Feb 2009 02:16:12 -0800
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <1235035272.4619.39.camel@localhost>
References: <[email-masked]> <1235035272.4619.39.camel@localhost>
Message-ID: <[email-masked]>

Hi all,

To clarify flow mobility is not a requirement for PMIPv6 right now in 3GPP. There is a study item ongoing but 3GPP has not yet decided that flow mobility is needed for PMIPv6.

Cheers,
Gerardo
(from Budapest, 3GPP SA2 meeting)

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp]
> On Behalf Of Carlos Jes?s Bernardos Cano
> Sent: Thursday, February 19, 2009 1:21 AM
> To: Basavaraj.Patil at nokia.com
> Cc: Mohana.Jeyatharan at sg.panasonic.com; Telemaco.Melia at alcatel-lucent.com;
> netext at mail.mobileip.jp
> Subject: Re: [Netext] Review of the Multihoming PS I-D
> 
> Hi,
> 
> 	One question: flow mobility seems to be an interesting feature that is a
> requirement from 3GPP, it is related with multihoming but it is not strictly a
> multihoming isse, right? I mean, multihoming extensions would likely make
> easier to support flow mobility, but would probably require additional
> mechanisms. How do we capture this? I'm not sure the multihoming PS is the
> right place for that, maybe the multihoming PS can point out that, but we need
> an explicit document (and charter item) for dealing with flow mobility. What
> do others think?
> 
> 	Thanks!
> 
> 	Carlos
> 
> El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com
> escribi?:
> > It may be of interest in the context of multihoming to consider moving
> > a flow from one interface to another. A flow which is associated with
> > an interface on the MN may be moved to another interface in the case
> > of a multihomed host for various reasons. This may be viewed as a
> > handover as well from the flow perspective. Multihoming enables the
> > possibility to move flows between interfaces. I think we could keep
> > this in the context of the multihoming discussion if there is consensus on
> it.
> >
> > -Raj
> >
> >
> > On 2/17/09 1:51 AM, "ext Mohana Jeyatharan"
> > <Mohana.Jeyatharan at sg.panasonic.com> wrote:
> >
> > > Hi Hidetoshi,
> > >
> > > In Multihoming PS ID, there are some handoff optimization scenarios
> involved.
> > > For example optmizing the handoff of a certain interface by means of
> > > another, and achieving flow mobility via another interface during
> > > disconnection. These events are triggered due to handoff or
> > > disconnection, but the scenarios are associated with multihoming.
> > > That is being able to receive a flow that is usually destined to an
> > > interface via another "connected" interface. This is where these
> > > scenarios are different from normal handoff and more tied to multihoming.
> > >
> > > However, I agree that these are also tied with handoff and some
> > > confusion is there. Anyway, we are planning to revise the
> > > multihoming PS draft and are thinking of focusing on the
> > > disconnection scenario, handoff optimization as less focus scenarios and
> focus on scenarios that are cateogorized by Raj.
> > >
> > > BR,
> > > Mohana
> > >
> > >
> > > -----Original Message-----
> > > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
> > > Sent: Tuesday, February 17, 2009 12:42 PM
> > > To: Mohana Jeyatharan
> > > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch;
> > > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> > > Subject: Re: [Netext] Review of the Multihoming PS I-D
> > >
> > > Hi Mohana and all,
> > >
> > > I think your scenario is viable, but we should probably more
> > > carefully clarify the difference between multihoming and handover.
> > > Assigning the same address to different interfaces on the MN for a
> > > sufficiently long time sounds like multihoming; however, if this
> > > situation holds only for a short period of time for MN's movement or
> > > fail over or for whatever reason, that sounds like handover. This
> > > difference would affect the behavior of the LMA and MAG(s).
> > >
> > > In Section 2 of the Multihoming PS document, Issues related to
> > > handoff performance and those related to flow mobility during sudden
> > > disconnection appear to be categorized into handover. If all agree
> > > that these issues should also be included in multihoming, that's
> > > fine. I would just like to make sure of it first of all.
> > >
> > > Regards,
> > > --
> > > Hidetoshi
> > >
> >
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> --
>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
>         Deployment Experiences on Vehicular networks
>                   http://www.weedev.org/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

From: liebsch at nw.neclab.eu (Marco Liebsch)
Date: Thu, 19 Feb 2009 10:54:23 +0100
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <1235035272.4619.39.camel@localhost>
References: <[email-masked]> <1235035272.4619.39.camel@localhost>
Message-ID: <[email-masked]>

Hi,

Carlos Jes?s Bernardos Cano wrote:
> Hi,
>
> 	One question: flow mobility seems to be an interesting feature that is
> a requirement from 3GPP, it is related with multihoming but it is not
> strictly a multihoming isse, right? I mean, multihoming extensions would
> likely make easier to support flow mobility, but would probably require
> additional mechanisms. How do we capture this? I'm not sure the
> multihoming PS is the right place for that, maybe the multihoming PS can
> point out that, but we need an explicit document (and charter item) for
> dealing with flow mobility. What do others think?
>   
As I said already, in my opinion moving flows is a use case for a special
multi-homing case, where the MN can use the same address on multiple 
interfaces.
Couple of things need to be done to extend PMIP to support these use cases.
Here I see the charter item for NetExt. The actual move of flows is 
associated
with the policy configuration, which is enforced on the LMA for downlink
and on the MN for uplink traffic. This goes in my opinion beyond the scope
of NetExt, as other components and protocol interfaces may play a role
here. Similar to using MIPv6 for mobility management, but using Diameter
for authentication, bootstrapping etc. Regarding NetExt, multi-homing and
routing policy control are separate things, in my view.

marco

> 	Thanks!
>
> 	Carlos
>
> El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com
> escribi?:
>   
>> It may be of interest in the context of multihoming to consider moving a
>> flow from one interface to another. A flow which is associated with an
>> interface on the MN may be moved to another interface in the case of a
>> multihomed host for various reasons. This may be viewed as a handover as
>> well from the flow perspective. Multihoming enables the possibility to move
>> flows between interfaces. I think we could keep this in the context of the
>> multihoming discussion if there is consensus on it.
>>
>> -Raj
>>
>>
>> On 2/17/09 1:51 AM, "ext Mohana Jeyatharan"
>> <Mohana.Jeyatharan at sg.panasonic.com> wrote:
>>
>>     
>>> Hi Hidetoshi,
>>>
>>> In Multihoming PS ID, there are some handoff optimization scenarios involved.
>>> For example optmizing the handoff of a certain interface by means of another,
>>> and achieving flow mobility via another interface during disconnection. These
>>> events are triggered due to handoff or disconnection, but the scenarios are
>>> associated with multihoming. That is being able to receive a flow that is
>>> usually destined to an interface via another "connected" interface. This is
>>> where these scenarios are different from normal handoff and more tied to
>>> multihoming.
>>>
>>> However, I agree that these are also tied with handoff and some confusion is
>>> there. Anyway, we are planning to revise the multihoming PS draft and are
>>> thinking of focusing on the disconnection scenario, handoff optimization as
>>> less focus scenarios and focus on scenarios that are cateogorized by Raj.
>>>
>>> BR,
>>> Mohana
>>>
>>>
>>> -----Original Message-----
>>> From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
>>> Sent: Tuesday, February 17, 2009 12:42 PM
>>> To: Mohana Jeyatharan
>>> Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch;
>>> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>> Subject: Re: [Netext] Review of the Multihoming PS I-D
>>>
>>> Hi Mohana and all,
>>>
>>> I think your scenario is viable, but we should probably more carefully
>>> clarify the difference between multihoming and handover. Assigning the
>>> same address to different interfaces on the MN for a sufficiently long
>>> time sounds like multihoming; however, if this situation holds only for
>>> a short period of time for MN's movement or fail over or for whatever
>>> reason, that sounds like handover. This difference would affect the
>>> behavior of the LMA and MAG(s).
>>>
>>> In Section 2 of the Multihoming PS document, Issues related to handoff
>>> performance and those related to flow mobility during sudden
>>> disconnection appear to be categorized into handover. If all agree that
>>> these issues should also be included in multihoming, that's fine. I
>>> would just like to make sure of it first of all.
>>>
>>> Regards,
>>> --
>>> Hidetoshi
>>>
>>>       
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>     
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>     

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Thu, 19 Feb 2009 10:21:12 +0100
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <1235035272.4619.39.camel@localhost>

Hi,

	One question: flow mobility seems to be an interesting feature that is
a requirement from 3GPP, it is related with multihoming but it is not
strictly a multihoming isse, right? I mean, multihoming extensions would
likely make easier to support flow mobility, but would probably require
additional mechanisms. How do we capture this? I'm not sure the
multihoming PS is the right place for that, maybe the multihoming PS can
point out that, but we need an explicit document (and charter item) for
dealing with flow mobility. What do others think?

	Thanks!

	Carlos

El mi?, 18-02-2009 a las 21:39 +0100, Basavaraj.Patil at nokia.com
escribi?:
> It may be of interest in the context of multihoming to consider moving a
> flow from one interface to another. A flow which is associated with an
> interface on the MN may be moved to another interface in the case of a
> multihomed host for various reasons. This may be viewed as a handover as
> well from the flow perspective. Multihoming enables the possibility to move
> flows between interfaces. I think we could keep this in the context of the
> multihoming discussion if there is consensus on it.
> 
> -Raj
> 
> 
> On 2/17/09 1:51 AM, "ext Mohana Jeyatharan"
> <Mohana.Jeyatharan at sg.panasonic.com> wrote:
> 
> > Hi Hidetoshi,
> >
> > In Multihoming PS ID, there are some handoff optimization scenarios involved.
> > For example optmizing the handoff of a certain interface by means of another,
> > and achieving flow mobility via another interface during disconnection. These
> > events are triggered due to handoff or disconnection, but the scenarios are
> > associated with multihoming. That is being able to receive a flow that is
> > usually destined to an interface via another "connected" interface. This is
> > where these scenarios are different from normal handoff and more tied to
> > multihoming.
> >
> > However, I agree that these are also tied with handoff and some confusion is
> > there. Anyway, we are planning to revise the multihoming PS draft and are
> > thinking of focusing on the disconnection scenario, handoff optimization as
> > less focus scenarios and focus on scenarios that are cateogorized by Raj.
> >
> > BR,
> > Mohana
> >
> >
> > -----Original Message-----
> > From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
> > Sent: Tuesday, February 17, 2009 12:42 PM
> > To: Mohana Jeyatharan
> > Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch;
> > netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> > Subject: Re: [Netext] Review of the Multihoming PS I-D
> >
> > Hi Mohana and all,
> >
> > I think your scenario is viable, but we should probably more carefully
> > clarify the difference between multihoming and handover. Assigning the
> > same address to different interfaces on the MN for a sufficiently long
> > time sounds like multihoming; however, if this situation holds only for
> > a short period of time for MN's movement or fail over or for whatever
> > reason, that sounds like handover. This difference would affect the
> > behavior of the LMA and MAG(s).
> >
> > In Section 2 of the Multihoming PS document, Issues related to handoff
> > performance and those related to flow mobility during sudden
> > disconnection appear to be categorized into handover. If all agree that
> > these issues should also be included in multihoming, that's fine. I
> > would just like to make sure of it first of all.
> >
> > Regards,
> > --
> > Hidetoshi
> >
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
-- 
 Carlos Jes?s Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090219/045b541a/attachment.bin>

From: Telemaco.Melia at alcatel-lucent.com (MELIA TELEMACO)
Date: Thu, 19 Feb 2009 09:13:14 +0100
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <DD8B8FEBBFAF9E488F63FF0F1A69EDD10583A56C@ftrdmel1> <[email-masked]>
Message-ID: <[email-masked]>

Hi Mohana,

Few comments below:

If same address is assigned to different interfaces, MN and LMA need to share routing policy to route each flow to the correct interface. But distribution of policies is an issue; I mean, distribution of policies could be done via an interface between LMA and MN, but it would be a severe violation of PMIP architecture. 
[Mohana] Distribution of policy can be done by MN-AR interface as well. No need of MN-LMA interaction....

[TELE] About policies distribution: I am not sure what is the feeling of people here, but this thread is very similar to what has been discussed in the MIP4 session last time @Minneapolis on Multiple CoA Support (Sri). The major concern from Jari and Henrik was that policy distribution cannot be ignored and left behind (you can check the minutes), the protocol might become useless otherwise.

So, even if other distribution schemes can be possible, I do not really see why sharing same address on several interfaces can facilitate IP flow mobility. Mainly because routing in that case is a tricky problem. It seems to me that this feature brings more issues than benefits...
[Mohana] I am not so sure about the issues you are conecrned with. 

On the other hand RFC 5213 provides a basic support of IP mobility between different interfaces. But here the issue is on the determination of the "handoff indicator" at the MAG. Don't you think that clarification on the determination of the "handoff indicator" in case of multihoming and IP flow mobility would worth the effort in Netext?
[Mohana] Of course for IP flow mobility and multihoming, proper MN-MAG triggers may need to be present. RFC 5213 does not specify how MAGs get the HI indicator options. It canbe via L2 or some other way. But for multihoming host may need to accept packets destined to one interface via another. 

[TELE] Glad that you mention this, Carlos already did before. I think that this change affects the terminal as much as having the same address configured on two interfaces. The PS document should capture this.

An intelligent client can do this knowing that this is PMIPv6. Anyway, in some SDOs the mobility management mechansims are known to the Mn if it wants to. They do have mobility mode selection kind of methods. Thus such multihoming in PMIPv6 can be achievable without much difficulty.  

My two cents,
Regards,
Pierrick

> -----Message d'origine-----
> De?: netext-bounces at mail.mobileip.jp [mailto:netext- 
> bounces at mail.mobileip.jp] De la part de MELIA TELEMACO Envoy??: mardi 
> 17 f?vrier 2009 17:41 ??: Marco Liebsch; Hidetoshi Yokota Cc?: 
> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com Objet?: Re: 
> [Netext] Review of the Multihoming PS I-D
> 
> Hi,
> 
> I guess there are two important emerging aspects out of this discussion:
> - involvement of the mobile node in the multihoming process
> - transfer of policies, how and where to
> 
> I would like also to stress the fact that we should not necessarily 
> see multihoming as a solution to optimize mobility.
> A node can be multihomed without moving at all (nomadic user) and we 
> have other documents (transient BCE) looking at how to optimize mobility.
> 
> How folks see things?
> 
> telemaco
> 
> 
> -----Message d'origine-----
> De : Marco Liebsch [mailto:liebsch at nw.neclab.eu] Envoy? : mardi 17 
> f?vrier 2009 15:06 ? : Hidetoshi Yokota Cc : netext at mail.mobileip.jp; 
> MELIA TELEMACO; Basavaraj.Patil at nokia.com Objet : Re: [Netext] Review 
> of the Multihoming PS I-D
> 
> Hidetoshi Yokota wrote:
> > Hi Marco,
> >
> > Marco Liebsch wrote:
> >
> >> Hidetoshi,
> >>
> >
> > I'm still talking about definitions and categorization. I'm not 
> > downplaying any of them.
> >
> sure.
> 
> >
> >> I think we have different opinions on an important aspect:
> >> My understanding of your opinion is that as soon as the MN gets
> >> (e.g.) HNP1 assigned to interface 1 (IF1) as a result of the 
> >> registration, it can use the same HNP1 for a different interface, 
> >> e.g. IF2, without having this HNP1 received from the network as a 
> >> result of IF2's registration.
> >> Correct?
> >>
> >
> > No, I'm not going that far, yet :-). I'm still trying to understand 
> > what people are thinking about multihoming, handover and IP flow 
> > mobility, etc. My understanding is that if the MN wants to use HNP1 
> > on IF2, it would have to register it with the LMA via the 
> > corresponding MAG; otherwise, there would be no guarantee that 
> > packets are coming back
> to IF2.
> >
> Ok.
> 
> >
> >> I think the MN can use HNP1 only for IF2, if the LMA assigns the 
> >> same
> >> HNP1 to IF2 during its registration. To result then in the same IP 
> >> address, it's up to the MN to take the same suffix for both interfaces'
> IP address.
> >> That's again something where we have the same opinion.
> >>
> >
> > I think this is a sensible behavior. The key thing is to give a hint 
> > to the LMA on which interface the MN wants to get packets.
> >
> Well, yes, the LMA needs a hint about the routing policy (which flow 
> goes which way). But here the MN plays a role and that hint may not 
> come with
> PMIPv6 signaling.
> 
> >
> >> So, when we talk about using the same IP address on both 
> >> interfaces, still the allowed prefix for each interface is network 
> >> controlled, whereas the MN is free to chose any suffix. That's at least my view.
> >>
> >
> > I personally agree with your view. In addition, the LMA should get 
> > in sync with the MN especially when those two interfaces are 
> > connected to different MAGs.
> >
> Thanks for the clarification.
> 
> Greetings,
> marco
> 
> > Regards,
> >
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

From: yokota at kddilabs.jp (Hidetoshi Yokota)
Date: Thu, 19 Feb 2009 13:40:08 +0900
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Raj,

Basavaraj.Patil at nokia.com wrote:
> It may be of interest in the context of multihoming to consider moving a
> flow from one interface to another. A flow which is associated with an
> interface on the MN may be moved to another interface in the case of a
> multihomed host for various reasons. This may be viewed as a handover as
> well from the flow perspective. Multihoming enables the possibility to move
> flows between interfaces. I think we could keep this in the context of the
> multihoming discussion if there is consensus on it.

Ok, but one question: if the flow is moved to another interface by the
way that the same address is assigned after releasing it from the old
interface, namely, *not* simultaneously (e.g., single radio case), is
this type of flow mobility still called multihoming? Or, by definition,
a flow mobility can be realized only in the situation where the
simultaneous address assignment is feasible?

Regards,
-- 
Hidetoshi

> -Raj
> 
> 
> On 2/17/09 1:51 AM, "ext Mohana Jeyatharan"
> <Mohana.Jeyatharan at sg.panasonic.com> wrote:
> 
>> Hi Hidetoshi,
>>
>> In Multihoming PS ID, there are some handoff optimization scenarios involved.
>> For example optmizing the handoff of a certain interface by means of another,
>> and achieving flow mobility via another interface during disconnection. These
>> events are triggered due to handoff or disconnection, but the scenarios are
>> associated with multihoming. That is being able to receive a flow that is
>> usually destined to an interface via another "connected" interface. This is
>> where these scenarios are different from normal handoff and more tied to
>> multihoming.
>>
>> However, I agree that these are also tied with handoff and some confusion is
>> there. Anyway, we are planning to revise the multihoming PS draft and are
>> thinking of focusing on the disconnection scenario, handoff optimization as
>> less focus scenarios and focus on scenarios that are cateogorized by Raj.
>>
>> BR,
>> Mohana
>>
>>
>> -----Original Message-----
>> From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
>> Sent: Tuesday, February 17, 2009 12:42 PM
>> To: Mohana Jeyatharan
>> Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch;
>> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>> Subject: Re: [Netext] Review of the Multihoming PS I-D
>>
>> Hi Mohana and all,
>>
>> I think your scenario is viable, but we should probably more carefully
>> clarify the difference between multihoming and handover. Assigning the
>> same address to different interfaces on the MN for a sufficiently long
>> time sounds like multihoming; however, if this situation holds only for
>> a short period of time for MN's movement or fail over or for whatever
>> reason, that sounds like handover. This difference would affect the
>> behavior of the LMA and MAG(s).
>>
>> In Section 2 of the Multihoming PS document, Issues related to handoff
>> performance and those related to flow mobility during sudden
>> disconnection appear to be categorized into handover. If all agree that
>> these issues should also be included in multihoming, that's fine. I
>> would just like to make sure of it first of all.
>>
>> Regards,
>> --
>> Hidetoshi
>>
> 
> 
> 
> 

From: xiayangsong at huawei.com (Frank Xia)
Date: Wed, 18 Feb 2009 20:00:22 -0600
Subject: [Netext]  Flow Binding in Proxy Mobile IPv6
Message-ID: <[email-masked]>

Hi Folks

I have drafted the document. Comments are welcome!
http://www.ietf.org/internet-drafts/draft-xia-netext-flow-binding-00.txt.

Abstract
  This document introduces extensions to Proxy
  Mobile IPv6 that allows networks dynamically 
  binding IP flows to different interfaces of a mobile node.

BR
Frank
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090218/a29f52a0/attachment.html>

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Thu, 19 Feb 2009 08:38:23 +0800
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <DD8B8FEBBFAF9E488F63FF0F1A69EDD10583A56C@ftrdmel1>
Message-ID: <[email-masked]>

Hi Pierrick,

Saw your mail. Some good thoughts in your mail. Please see some in-line ...
BR,
Mohana

-----Original Message-----
From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of pierrick.seite at orange-ftgroup.com
Sent: Wednesday, February 18, 2009 6:40 PM
To: Telemaco.Melia at alcatel-lucent.com; liebsch at nw.neclab.eu; yokota at kddilabs.jp
Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
Subject: Re: [Netext] Review of the Multihoming PS I-D

Hi Telemaco, Marco, Hidetoshi and all,

Just for a better understanding of this thread.

If same address is assigned to different interfaces, MN and LMA need to share routing policy to route each flow to the correct interface. But distribution of policies is an issue; I mean, distribution of policies could be done via an interface between LMA and MN, but it would be a severe violation of PMIP architecture. 
[Mohana] Distribution of policy can be done by MN-AR interface as well. No need of MN-LMA interaction....

So, even if other distribution schemes can be possible, I do not really see why sharing same address on several interfaces can facilitate IP flow mobility. Mainly because routing in that case is a tricky problem. It seems to me that this feature brings more issues than benefits...
[Mohana] I am not so sure about the issues you are conecrned with. 

On the other hand RFC 5213 provides a basic support of IP mobility between different interfaces. But here the issue is on the determination of the "handoff indicator" at the MAG. Don't you think that clarification on the determination of the "handoff indicator" in case of multihoming and IP flow mobility would worth the effort in Netext?
[Mohana] Of course for IP flow mobility and multihoming, proper MN-MAG triggers may need to be present. RFC 5213 does not specify how MAGs get the HI indicator options. It canbe via L2 or some other way. But for multihoming host may need to accept packets destined to one interface via another. An intelligent client can do this knowing that this is PMIPv6. Anyway, in some SDOs the mobility management mechansims are known to the Mn if it wants to. They do have mobility mode selection kind of methods. Thus such multihoming in PMIPv6 can be achievable without much difficulty.  

My two cents,
Regards,
Pierrick

> -----Message d'origine-----
> De?: netext-bounces at mail.mobileip.jp [mailto:netext-
> bounces at mail.mobileip.jp] De la part de MELIA TELEMACO
> Envoy??: mardi 17 f?vrier 2009 17:41
> ??: Marco Liebsch; Hidetoshi Yokota
> Cc?: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Objet?: Re: [Netext] Review of the Multihoming PS I-D
> 
> Hi,
> 
> I guess there are two important emerging aspects out of this discussion:
> - involvement of the mobile node in the multihoming process
> - transfer of policies, how and where to
> 
> I would like also to stress the fact that we should not necessarily see
> multihoming as a solution to optimize mobility.
> A node can be multihomed without moving at all (nomadic user) and we have
> other documents (transient BCE) looking at how to optimize mobility.
> 
> How folks see things?
> 
> telemaco
> 
> 
> -----Message d'origine-----
> De : Marco Liebsch [mailto:liebsch at nw.neclab.eu]
> Envoy? : mardi 17 f?vrier 2009 15:06
> ? : Hidetoshi Yokota
> Cc : netext at mail.mobileip.jp; MELIA TELEMACO; Basavaraj.Patil at nokia.com
> Objet : Re: [Netext] Review of the Multihoming PS I-D
> 
> Hidetoshi Yokota wrote:
> > Hi Marco,
> >
> > Marco Liebsch wrote:
> >
> >> Hidetoshi,
> >>
> >
> > I'm still talking about definitions and categorization. I'm not
> > downplaying any of them.
> >
> sure.
> 
> >
> >> I think we have different opinions on an important aspect:
> >> My understanding of your opinion is that as soon as the MN gets
> >> (e.g.) HNP1 assigned to interface 1 (IF1) as a result of the
> >> registration, it can use the same HNP1 for a different interface,
> >> e.g. IF2, without having this HNP1 received from the network as a
> >> result of IF2's registration.
> >> Correct?
> >>
> >
> > No, I'm not going that far, yet :-). I'm still trying to understand
> > what people are thinking about multihoming, handover and IP flow
> > mobility, etc. My understanding is that if the MN wants to use HNP1 on
> > IF2, it would have to register it with the LMA via the corresponding
> > MAG; otherwise, there would be no guarantee that packets are coming back
> to IF2.
> >
> Ok.
> 
> >
> >> I think the MN can use HNP1 only for IF2, if the LMA assigns the same
> >> HNP1 to IF2 during its registration. To result then in the same IP
> >> address, it's up to the MN to take the same suffix for both interfaces'
> IP address.
> >> That's again something where we have the same opinion.
> >>
> >
> > I think this is a sensible behavior. The key thing is to give a hint
> > to the LMA on which interface the MN wants to get packets.
> >
> Well, yes, the LMA needs a hint about the routing policy (which flow goes
> which way). But here the MN plays a role and that hint may not come with
> PMIPv6 signaling.
> 
> >
> >> So, when we talk about using the same IP address on both interfaces,
> >> still the allowed prefix for each interface is network controlled,
> >> whereas the MN is free to chose any suffix. That's at least my view.
> >>
> >
> > I personally agree with your view. In addition, the LMA should get in
> > sync with the MN especially when those two interfaces are connected to
> > different MAGs.
> >
> Thanks for the clarification.
> 
> Greetings,
> marco
> 
> > Regards,
> >
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Thu, 19 Feb 2009 08:23:14 +0800
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hello Raj,

Yes, agree with you. Flow mobility can be achieved by means of
multihoming. So the system should support multihoming and flow mobility
parameters can be set using some other mechanisms (flow binding). So
flow mobility is dependent on multihoming.
Thanks.
BR,
Mohana

-----Original Message-----
From: Basavaraj.Patil at nokia.com [mailto:Basavaraj.Patil at nokia.com] 
Sent: Thursday, February 19, 2009 4:39 AM
To: Mohana Jeyatharan; yokota at kddilabs.jp
Cc: domagoj.premec.ext at nsn.com; Telemaco.Melia at alcatel-lucent.com;
marco.liebsch at nw.neclab.eu; netext at mail.mobileip.jp
Subject: Re: [Netext] Review of the Multihoming PS I-D

It may be of interest in the context of multihoming to consider moving a
flow from one interface to another. A flow which is associated with an
interface on the MN may be moved to another interface in the case of a
multihomed host for various reasons. This may be viewed as a handover as
well from the flow perspective. Multihoming enables the possibility to
move
flows between interfaces. I think we could keep this in the context of
the
multihoming discussion if there is consensus on it.

-Raj

On 2/17/09 1:51 AM, "ext Mohana Jeyatharan"
<Mohana.Jeyatharan at sg.panasonic.com> wrote:

> Hi Hidetoshi,
>
> In Multihoming PS ID, there are some handoff optimization scenarios
involved.
> For example optmizing the handoff of a certain interface by means of
another,
> and achieving flow mobility via another interface during
disconnection. These
> events are triggered due to handoff or disconnection, but the
scenarios are
> associated with multihoming. That is being able to receive a flow that
is
> usually destined to an interface via another "connected" interface.
This is
> where these scenarios are different from normal handoff and more tied
to
> multihoming.
>
> However, I agree that these are also tied with handoff and some
confusion is
> there. Anyway, we are planning to revise the multihoming PS draft and
are
> thinking of focusing on the disconnection scenario, handoff
optimization as
> less focus scenarios and focus on scenarios that are cateogorized by
Raj.
>
> BR,
> Mohana
>
>
> -----Original Message-----
> From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
> Sent: Tuesday, February 17, 2009 12:42 PM
> To: Mohana Jeyatharan
> Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch;
> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Re: [Netext] Review of the Multihoming PS I-D
>
> Hi Mohana and all,
>
> I think your scenario is viable, but we should probably more carefully
> clarify the difference between multihoming and handover. Assigning the
> same address to different interfaces on the MN for a sufficiently long
> time sounds like multihoming; however, if this situation holds only
for
> a short period of time for MN's movement or fail over or for whatever
> reason, that sounds like handover. This difference would affect the
> behavior of the LMA and MAG(s).
>
> In Section 2 of the Multihoming PS document, Issues related to handoff
> performance and those related to flow mobility during sudden
> disconnection appear to be categorized into handover. If all agree
that
> these issues should also be included in multihoming, that's fine. I
> would just like to make sure of it first of all.
>
> Regards,
> --
> Hidetoshi
>

From: xiayangsong at huawei.com (Frank Xia)
Date: Wed, 18 Feb 2009 15:08:26 -0600
Subject: [Netext] Review of the Multihoming PS I-D
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Raj

Flow binding ( or IP flow mobility) is an explicit requirement
from 3GPP. It should be included in the context.

BR
Frank

----- Original Message ----- 
From: <Basavaraj.Patil at nokia.com>
To: <Mohana.Jeyatharan at sg.panasonic.com>; <yokota at kddilabs.jp>
Cc: <netext at mail.mobileip.jp>; <Telemaco.Melia at alcatel-lucent.com>
Sent: Wednesday, February 18, 2009 2:39 PM
Subject: Re: [Netext] Review of the Multihoming PS I-D

>
> It may be of interest in the context of multihoming to consider moving a
> flow from one interface to another. A flow which is associated with an
> interface on the MN may be moved to another interface in the case of a
> multihomed host for various reasons. This may be viewed as a handover as
> well from the flow perspective. Multihoming enables the possibility to 
> move
> flows between interfaces. I think we could keep this in the context of the
> multihoming discussion if there is consensus on it.
>
> -Raj
>
>
> On 2/17/09 1:51 AM, "ext Mohana Jeyatharan"
> <Mohana.Jeyatharan at sg.panasonic.com> wrote:
>
>> Hi Hidetoshi,
>>
>> In Multihoming PS ID, there are some handoff optimization scenarios 
>> involved.
>> For example optmizing the handoff of a certain interface by means of 
>> another,
>> and achieving flow mobility via another interface during disconnection. 
>> These
>> events are triggered due to handoff or disconnection, but the scenarios 
>> are
>> associated with multihoming. That is being able to receive a flow that is
>> usually destined to an interface via another "connected" interface. This 
>> is
>> where these scenarios are different from normal handoff and more tied to
>> multihoming.
>>
>> However, I agree that these are also tied with handoff and some confusion 
>> is
>> there. Anyway, we are planning to revise the multihoming PS draft and are
>> thinking of focusing on the disconnection scenario, handoff optimization 
>> as
>> less focus scenarios and focus on scenarios that are cateogorized by Raj.
>>
>> BR,
>> Mohana
>>
>>
>> -----Original Message-----
>> From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
>> Sent: Tuesday, February 17, 2009 12:42 PM
>> To: Mohana Jeyatharan
>> Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch;
>> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>> Subject: Re: [Netext] Review of the Multihoming PS I-D
>>
>> Hi Mohana and all,
>>
>> I think your scenario is viable, but we should probably more carefully
>> clarify the difference between multihoming and handover. Assigning the
>> same address to different interfaces on the MN for a sufficiently long
>> time sounds like multihoming; however, if this situation holds only for
>> a short period of time for MN's movement or fail over or for whatever
>> reason, that sounds like handover. This difference would affect the
>> behavior of the LMA and MAG(s).
>>
>> In Section 2 of the Multihoming PS document, Issues related to handoff
>> performance and those related to flow mobility during sudden
>> disconnection appear to be categorized into handover. If all agree that
>> these issues should also be included in multihoming, that's fine. I
>> would just like to make sure of it first of all.
>>
>> Regards,
>> --
>> Hidetoshi
>>
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext 

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Wed, 18 Feb 2009 21:44:03 +0100
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hello Yokota san,

On 2/17/09 6:59 AM, "ext Hidetoshi Yokota" <yokota at kddilabs.jp> wrote:

> Ok, a handover could be a special case of IP flow mobility. This
> handover probably means the switching of interfaces (e.g. due to the
> change of access technologies). We should putt aside a "session
> handover" for the moment;-).
>
> I, however, still believe that we should differentiate handover/IP flow
> mobility from multihoming.

I agree with your comment that multihoming and IP flow mobility are not
synonymous. When you have an MN which is multihomed you could achieve IP
flow mobility across different interfaces. But lets keep the definition of
multihoming clear and not mix it with flow mobility.

-Raj

>
> Regards,
> --
> Hidetoshi

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Wed, 18 Feb 2009 21:39:16 +0100
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

It may be of interest in the context of multihoming to consider moving a
flow from one interface to another. A flow which is associated with an
interface on the MN may be moved to another interface in the case of a
multihomed host for various reasons. This may be viewed as a handover as
well from the flow perspective. Multihoming enables the possibility to move
flows between interfaces. I think we could keep this in the context of the
multihoming discussion if there is consensus on it.

-Raj

On 2/17/09 1:51 AM, "ext Mohana Jeyatharan"
<Mohana.Jeyatharan at sg.panasonic.com> wrote:

> Hi Hidetoshi,
>
> In Multihoming PS ID, there are some handoff optimization scenarios involved.
> For example optmizing the handoff of a certain interface by means of another,
> and achieving flow mobility via another interface during disconnection. These
> events are triggered due to handoff or disconnection, but the scenarios are
> associated with multihoming. That is being able to receive a flow that is
> usually destined to an interface via another "connected" interface. This is
> where these scenarios are different from normal handoff and more tied to
> multihoming.
>
> However, I agree that these are also tied with handoff and some confusion is
> there. Anyway, we are planning to revise the multihoming PS draft and are
> thinking of focusing on the disconnection scenario, handoff optimization as
> less focus scenarios and focus on scenarios that are cateogorized by Raj.
>
> BR,
> Mohana
>
>
> -----Original Message-----
> From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
> Sent: Tuesday, February 17, 2009 12:42 PM
> To: Mohana Jeyatharan
> Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch;
> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Re: [Netext] Review of the Multihoming PS I-D
>
> Hi Mohana and all,
>
> I think your scenario is viable, but we should probably more carefully
> clarify the difference between multihoming and handover. Assigning the
> same address to different interfaces on the MN for a sufficiently long
> time sounds like multihoming; however, if this situation holds only for
> a short period of time for MN's movement or fail over or for whatever
> reason, that sounds like handover. This difference would affect the
> behavior of the LMA and MAG(s).
>
> In Section 2 of the Multihoming PS document, Issues related to handoff
> performance and those related to flow mobility during sudden
> disconnection appear to be categorized into handover. If all agree that
> these issues should also be included in multihoming, that's fine. I
> would just like to make sure of it first of all.
>
> Regards,
> --
> Hidetoshi
>

From: pierrick.seite at orange-ftgroup.com (pierrick.seite at orange-ftgroup.com)
Date: Wed, 18 Feb 2009 11:39:32 +0100
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]><[email-masked]>	<[email-masked]><[email-masked]> <[email-masked]><[email-masked]> <[email-masked]><[email-masked]> <[email-masked]>
Message-ID: <DD8B8FEBBFAF9E488F63FF0F1A69EDD10583A56C@ftrdmel1>

Hi Telemaco, Marco, Hidetoshi and all,

Just for a better understanding of this thread.

If same address is assigned to different interfaces, MN and LMA need to share routing policy to route each flow to the correct interface. But distribution of policies is an issue; I mean, distribution of policies could be done via an interface between LMA and MN, but it would be a severe violation of PMIP architecture. 

So, even if other distribution schemes can be possible, I do not really see why sharing same address on several interfaces can facilitate IP flow mobility. Mainly because routing in that case is a tricky problem. It seems to me that this feature brings more issues than benefits...

On the other hand RFC 5213 provides a basic support of IP mobility between different interfaces. But here the issue is on the determination of the "handoff indicator" at the MAG. Don't you think that clarification on the determination of the "handoff indicator" in case of multihoming and IP flow mobility would worth the effort in Netext?

My two cents,
Regards,
Pierrick

> -----Message d'origine-----
> De?: netext-bounces at mail.mobileip.jp [mailto:netext-
> bounces at mail.mobileip.jp] De la part de MELIA TELEMACO
> Envoy??: mardi 17 f?vrier 2009 17:41
> ??: Marco Liebsch; Hidetoshi Yokota
> Cc?: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Objet?: Re: [Netext] Review of the Multihoming PS I-D
> 
> Hi,
> 
> I guess there are two important emerging aspects out of this discussion:
> - involvement of the mobile node in the multihoming process
> - transfer of policies, how and where to
> 
> I would like also to stress the fact that we should not necessarily see
> multihoming as a solution to optimize mobility.
> A node can be multihomed without moving at all (nomadic user) and we have
> other documents (transient BCE) looking at how to optimize mobility.
> 
> How folks see things?
> 
> telemaco
> 
> 
> -----Message d'origine-----
> De : Marco Liebsch [mailto:liebsch at nw.neclab.eu]
> Envoy? : mardi 17 f?vrier 2009 15:06
> ? : Hidetoshi Yokota
> Cc : netext at mail.mobileip.jp; MELIA TELEMACO; Basavaraj.Patil at nokia.com
> Objet : Re: [Netext] Review of the Multihoming PS I-D
> 
> Hidetoshi Yokota wrote:
> > Hi Marco,
> >
> > Marco Liebsch wrote:
> >
> >> Hidetoshi,
> >>
> >
> > I'm still talking about definitions and categorization. I'm not
> > downplaying any of them.
> >
> sure.
> 
> >
> >> I think we have different opinions on an important aspect:
> >> My understanding of your opinion is that as soon as the MN gets
> >> (e.g.) HNP1 assigned to interface 1 (IF1) as a result of the
> >> registration, it can use the same HNP1 for a different interface,
> >> e.g. IF2, without having this HNP1 received from the network as a
> >> result of IF2's registration.
> >> Correct?
> >>
> >
> > No, I'm not going that far, yet :-). I'm still trying to understand
> > what people are thinking about multihoming, handover and IP flow
> > mobility, etc. My understanding is that if the MN wants to use HNP1 on
> > IF2, it would have to register it with the LMA via the corresponding
> > MAG; otherwise, there would be no guarantee that packets are coming back
> to IF2.
> >
> Ok.
> 
> >
> >> I think the MN can use HNP1 only for IF2, if the LMA assigns the same
> >> HNP1 to IF2 during its registration. To result then in the same IP
> >> address, it's up to the MN to take the same suffix for both interfaces'
> IP address.
> >> That's again something where we have the same opinion.
> >>
> >
> > I think this is a sensible behavior. The key thing is to give a hint
> > to the LMA on which interface the MN wants to get packets.
> >
> Well, yes, the LMA needs a hint about the routing policy (which flow goes
> which way). But here the MN plays a role and that hint may not come with
> PMIPv6 signaling.
> 
> >
> >> So, when we talk about using the same IP address on both interfaces,
> >> still the allowed prefix for each interface is network controlled,
> >> whereas the MN is free to chose any suffix. That's at least my view.
> >>
> >
> > I personally agree with your view. In addition, the LMA should get in
> > sync with the MN especially when those two interfaces are connected to
> > different MAGs.
> >
> Thanks for the clarification.
> 
> Greetings,
> marco
> 
> > Regards,
> >
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: Telemaco.Melia at alcatel-lucent.com (MELIA TELEMACO)
Date: Tue, 17 Feb 2009 17:41:06 +0100
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I guess there are two important emerging aspects out of this discussion:
- involvement of the mobile node in the multihoming process
- transfer of policies, how and where to

I would like also to stress the fact that we should not necessarily see multihoming as a solution to optimize mobility.
A node can be multihomed without moving at all (nomadic user) and we have other documents (transient BCE) looking at how to optimize mobility.

How folks see things?

telemaco

-----Message d'origine-----
De : Marco Liebsch [mailto:liebsch at nw.neclab.eu] 
Envoy? : mardi 17 f?vrier 2009 15:06
? : Hidetoshi Yokota
Cc : netext at mail.mobileip.jp; MELIA TELEMACO; Basavaraj.Patil at nokia.com
Objet : Re: [Netext] Review of the Multihoming PS I-D

Hidetoshi Yokota wrote:
> Hi Marco,
>
> Marco Liebsch wrote:
>   
>> Hidetoshi,
>>     
>
> I'm still talking about definitions and categorization. I'm not 
> downplaying any of them.
>   
sure.

>   
>> I think we have different opinions on an important aspect:
>> My understanding of your opinion is that as soon as the MN gets
>> (e.g.) HNP1 assigned to interface 1 (IF1) as a result of the 
>> registration, it can use the same HNP1 for a different interface, 
>> e.g. IF2, without having this HNP1 received from the network as a 
>> result of IF2's registration.
>> Correct?
>>     
>
> No, I'm not going that far, yet :-). I'm still trying to understand 
> what people are thinking about multihoming, handover and IP flow 
> mobility, etc. My understanding is that if the MN wants to use HNP1 on 
> IF2, it would have to register it with the LMA via the corresponding 
> MAG; otherwise, there would be no guarantee that packets are coming back to IF2.
>   
Ok.

>   
>> I think the MN can use HNP1 only for IF2, if the LMA assigns the same
>> HNP1 to IF2 during its registration. To result then in the same IP 
>> address, it's up to the MN to take the same suffix for both interfaces' IP address.
>> That's again something where we have the same opinion.
>>     
>
> I think this is a sensible behavior. The key thing is to give a hint 
> to the LMA on which interface the MN wants to get packets.
>   
Well, yes, the LMA needs a hint about the routing policy (which flow goes which way). But here the MN plays a role and that hint may not come with PMIPv6 signaling.

>   
>> So, when we talk about using the same IP address on both interfaces, 
>> still the allowed prefix for each interface is network controlled, 
>> whereas the MN is free to chose any suffix. That's at least my view.
>>     
>
> I personally agree with your view. In addition, the LMA should get in 
> sync with the MN especially when those two interfaces are connected to 
> different MAGs.
>   
Thanks for the clarification.

Greetings,
marco

> Regards,
>   

From: liebsch at nw.neclab.eu (Marco Liebsch)
Date: Tue, 17 Feb 2009 15:06:19 +0100
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hidetoshi Yokota wrote:
> Hi Marco,
>
> Marco Liebsch wrote:
>   
>> Hidetoshi,
>>     
>
> I'm still talking about definitions and categorization. I'm not
> downplaying any of them.
>   
sure.

>   
>> I think we have different opinions on an important aspect:
>> My understanding of your opinion is that as soon as the MN gets
>> (e.g.) HNP1 assigned to interface 1 (IF1) as a result of the registration,
>> it can use the same HNP1 for a different interface, e.g. IF2, without
>> having this HNP1 received from the network as a result of IF2's
>> registration.
>> Correct?
>>     
>
> No, I'm not going that far, yet :-). I'm still trying to understand what
> people are thinking about multihoming, handover and IP flow mobility,
> etc. My understanding is that if the MN wants to use HNP1 on IF2, it
> would have to register it with the LMA via the corresponding MAG;
> otherwise, there would be no guarantee that packets are coming back to IF2.
>   
Ok.

>   
>> I think the MN can use HNP1 only for IF2, if the LMA assigns the same
>> HNP1 to IF2 during its registration. To result then in the same IP address,
>> it's up to the MN to take the same suffix for both interfaces' IP address.
>> That's again something where we have the same opinion.
>>     
>
> I think this is a sensible behavior. The key thing is to give a hint to
> the LMA on which interface the MN wants to get packets.
>   
Well, yes, the LMA needs a hint about the routing policy (which flow goes
which way). But here the MN plays a role and that hint may not come
with PMIPv6 signaling.

>   
>> So, when we talk about using the same IP address on both interfaces,
>> still the allowed prefix for each interface is network controlled, whereas
>> the MN is free to chose any suffix. That's at least my view.
>>     
>
> I personally agree with your view. In addition, the LMA should get in
> sync with the MN especially when those two interfaces are connected to
> different MAGs.
>   
Thanks for the clarification.

Greetings,
marco

> Regards,
>   

From: yokota at kddilabs.jp (Hidetoshi Yokota)
Date: Tue, 17 Feb 2009 22:35:08 +0900
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Marco,

Marco Liebsch wrote:
> Hidetoshi,

I'm still talking about definitions and categorization. I'm not
downplaying any of them.

> I think we have different opinions on an important aspect:
> My understanding of your opinion is that as soon as the MN gets
> (e.g.) HNP1 assigned to interface 1 (IF1) as a result of the registration,
> it can use the same HNP1 for a different interface, e.g. IF2, without
> having this HNP1 received from the network as a result of IF2's
> registration.
> Correct?

No, I'm not going that far, yet :-). I'm still trying to understand what
people are thinking about multihoming, handover and IP flow mobility,
etc. My understanding is that if the MN wants to use HNP1 on IF2, it
would have to register it with the LMA via the corresponding MAG;
otherwise, there would be no guarantee that packets are coming back to IF2.

> I think the MN can use HNP1 only for IF2, if the LMA assigns the same
> HNP1 to IF2 during its registration. To result then in the same IP address,
> it's up to the MN to take the same suffix for both interfaces' IP address.
> That's again something where we have the same opinion.

I think this is a sensible behavior. The key thing is to give a hint to
the LMA on which interface the MN wants to get packets.

> So, when we talk about using the same IP address on both interfaces,
> still the allowed prefix for each interface is network controlled, whereas
> the MN is free to chose any suffix. That's at least my view.

I personally agree with your view. In addition, the LMA should get in
sync with the MN especially when those two interfaces are connected to
different MAGs.

Regards,
-- 
Hidetoshi

> marco
> 
> Hidetoshi Yokota wrote:
>> Hi Marco,
>>
>> My answer to your last comment was a bit off the mark. Regarding the
>> mesh-relationship between the interfaces and the assigned addresses,
>> this could happen as an extreme case if the same address can be assigned
>> to multiple interfaces and one interface can have multiple addresses
>> simultaneously. If you think this is too complex and impractical, we
>> should narrow down the scope. Do you have any condition to add to avoid
>> the mesh-relationship?
>>
>> Regards,
>>   
> 
> 
> 
> 

From: liebsch at nw.neclab.eu (Marco Liebsch)
Date: Tue, 17 Feb 2009 14:07:19 +0100
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hidetoshi,

I think we have different opinions on an important aspect:
My understanding of your opinion is that as soon as the MN gets
(e.g.) HNP1 assigned to interface 1 (IF1) as a result of the registration,
it can use the same HNP1 for a different interface, e.g. IF2, without
having this HNP1 received from the network as a result of IF2's
registration.
Correct?

I think the MN can use HNP1 only for IF2, if the LMA assigns the same
HNP1 to IF2 during its registration. To result then in the same IP address,
it's up to the MN to take the same suffix for both interfaces' IP address.
That's again something where we have the same opinion.

So, when we talk about using the same IP address on both interfaces,
still the allowed prefix for each interface is network controlled, whereas
the MN is free to chose any suffix. That's at least my view.

marco

Hidetoshi Yokota wrote:
> Hi Marco,
>
> My answer to your last comment was a bit off the mark. Regarding the
> mesh-relationship between the interfaces and the assigned addresses,
> this could happen as an extreme case if the same address can be assigned
> to multiple interfaces and one interface can have multiple addresses
> simultaneously. If you think this is too complex and impractical, we
> should narrow down the scope. Do you have any condition to add to avoid
> the mesh-relationship?
>
> Regards,
>   

From: yokota at kddilabs.jp (Hidetoshi Yokota)
Date: Tue, 17 Feb 2009 21:59:31 +0900
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Domagoj,

Domagoj Premec wrote:
> Hi Hidetoshi, all, 
> 
> In the context of the multi-interfaced host and the IP flow mobility, we could look at handovers as a special case of the IP flow mobility where all the flows are moved to a different interface. The line between the handovers and the IP flow mobility seems to be blurred in this case so we need to set clear boundaries to keep the scenarios apart. Or maybe it would be best to analyse them together?

Ok, a handover could be a special case of IP flow mobility. This 
handover probably means the switching of interfaces (e.g. due to the 
change of access technologies). We should putt aside a "session 
handover" for the moment;-).

I, however, still believe that we should differentiate handover/IP flow 
mobility from multihoming.

Regards,
-- 
Hidetoshi

> domagoj
> 
> 
>> -----Original Message-----
>> From: ext Hidetoshi Yokota [mailto:yokota at kddilabs.jp] 
>> Sent: 17. velja?a 2009 05:42
>> To: Mohana Jeyatharan
>> Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; 
>> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>> Subject: Re: [Netext] Review of the Multihoming PS I-D
>>
>> Hi Mohana and all,
>>
>> I think your scenario is viable, but we should probably more 
>> carefully clarify the difference between multihoming and 
>> handover. Assigning the same address to different interfaces 
>> on the MN for a sufficiently long time sounds like 
>> multihoming; however, if this situation holds only for a 
>> short period of time for MN's movement or fail over or for 
>> whatever reason, that sounds like handover. This difference 
>> would affect the behavior of the LMA and MAG(s).
>>
>> In Section 2 of the Multihoming PS document, Issues related 
>> to handoff performance and those related to flow mobility 
>> during sudden disconnection appear to be categorized into 
>> handover. If all agree that these issues should also be 
>> included in multihoming, that's fine. I would just like to 
>> make sure of it first of all.
>>
>> Regards,
>> --
>> Hidetoshi
>>
>> Mohana Jeyatharan wrote:
>>> Hi Domagoj and All,
>>>
>>> Yes, we too support this. For hosts that want flow mobility 
>> in PMIPv6 domain, may have to configure same address or at 
>> least be able to accept packets that are addressed to another 
>> interface.
>>> Moreover, this is extending PMIPv6 for such hosts and it is 
>> not changing PMIPv6 in anyway. 
>>> BR,
>>> Mohana
>>>
>>> -----Original Message-----
>>> From: netext-bounces at mail.mobileip.jp 
>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Domagoj Premec
>>> Sent: Tuesday, February 17, 2009 6:45 AM
>>> To: 'ext MELIA TELEMACO'; 'Hidetoshi Yokota'; 'Marco Liebsch'
>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>> Subject: Re: [Netext] Review of the Multihoming PS I-D
>>>
>>> Hi,
>>>  
>>> I share the opinion that having the same address assigned 
>> to different 
>>> interfaces is a viable scenario in the context of flow 
>> mobility and I 
>>> believe it should be included in the scope of the inter-tech work.
>>>
>>> domagoj
>>>
>>>
>>>
>>> ________________________________
>>>
>>> 	From: netext-bounces at mail.mobileip.jp 
>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext 
>> MELIA TELEMACO
>>> 	Sent: 16. veljaca 2009 14:14
>>> 	To: Hidetoshi Yokota; Marco Liebsch
>>> 	Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>> 	Subject: Re: [Netext] Review of the Multihoming PS I-D
>>> 	
>>> 	
>>>
>>> 	Hi Hidetoshi,
>>> 	
>>> 	I took the liberty to edit your post according (I hope) 
>> to what Marco 
>>> and I have been saying. Here it goes:
>>> 	
>>>
>>> 	                            Session2_CN1
>>> 	                   Addr_1   Session1_CN1
>>> 	            IF#1                             MAG#1        CN#1
>>> 	                   Addr_2   Session1_CN2
>>>
>>> 	    MN-ID                                            LMA
>>>
>>> 	                   Addr_1
>>> 	            IF#2                             MAG#2         CN#2
>>> 	                   Addr_2   Session2_CN2
>>>
>>> 	According to the pic the MN can a) request multiple addresses 
>>> (depending on the service he might want to get) and b) 
>> configure the 
>>> very same address on multiple interfaces to allow flow 
>> mobility (e.g.
>>> Session2_CN1 can be moved to IF#2 Addr_1). If you do not 
>> configure the 
>>> same address I wonder how the LMA can route flows since the 
>> CN1 always 
>>> send to the same HNP (Addr_1).
>>>
>>> 	Marco this is your understanding as well?
>>>
>>> 	 
>>>
>>> 	thanks
>>>
>>> 	telemaco
>>>
>>> 	
>>> 	
>>> 	-----Message d'origine-----
>>> 	De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
>>> 	Envoy? : lundi 16 f?vrier 2009 13:15
>>> 	A : Marco Liebsch
>>> 	Cc : MELIA TELEMACO; netext at mail.mobileip.jp; 
>>> Basavaraj.Patil at nokia.com
>>> 	Objet : Re: [Netext] Review of the Multihoming PS I-D
>>> 	
>>> 	Hi Marco, Telemaco, Raj and all,
>>> 	
>>> 	This thread is interesting and important for the start. Let me 
>>> clarify the problem that we are trying to solve. The MN has 
>> multiple 
>>> interfaces and multiple addresses assigned by multiple MAGs and can 
>>> setup multiple sessions with multiple CNs (either mobile or 
>> plain IPv6 
>>> hosts) simultaneously. However, the MN has only one MN-ID 
>> and only one 
>>> LMA (in the scople of the multihoming problem we are 
>> discussing now). 
>>> The addresses assigned for the MN can be bound to any 
>> interface of the 
>>> MN and the sessions associated with those addresses can go 
>> through any interface of the MN.
>>> Also, those addresses and corresponding sessions can 
>> migrate to other 
>>> interfaces of the MN in the middle. The following diagram 
>> simply shows 
>>> this
>>> situation:
>>> 	
>>> 	/------- MN --------\
>>> 	                        Session#1
>>> 	               Addr#1   Session#2                 CN#1
>>> 	        IF#1   Addr#2   Session#3   MAG#1         CN#2
>>> 	MN-ID   IF#2   Addr#3   ...         MAG#2   LMA   ...
>>> 	        ...    ...      ...         ...           ...
>>> 	        IF#J   ...      ...         MAG#M         CN#N
>>> 	               Addr#K   ...
>>> 	                        Session#L
>>> 	
>>> 	Is this the correct view that we are discussing now?
>>> 	
>>> 	Regards,
>>> 	--
>>> 	Hidetoshi
>>> 	
>>> 	Marco Liebsch wrote:
>>> 	> Hi,
>>> 	>
>>> 	> I agree that we should consider support of use cases 
>> where mulitple
>>> 	> interfaces of an MN get the same HNP assiged. One 
>> step further, the 
>>> MN
>>> 	> must configure the same suffix to allow flow mobility 
>> and keep flow
>>> 	> distribution etc.
>>> 	> transparent
>>> 	> to a CN.
>>> 	>
>>> 	> Regarding Raj's comments: I fully agree that we need 
>> to specify the
>>> 	> scope of what we'll solve in NetExt and my opinion is 
>> that the 
>>> focus
>>> 	> should be first on the definition of a set of target 
>> use cases, as 
>>> too
>>> 	> many of them are treated under the umbrella of 
>> multihoming. Then 
>>> let's
>>> 	> analyze where RFC5213 needs some more work to support them.
>>> 	>
>>> 	> Whereas I think that most of this work will be on the 
>> LMA to allow 
>>> the
>>> 	> assignment of the same HNP to multiple interfaces and 
>> to support
>>> 	> inter-working with policy based forwarding, I do 
>> *not* think that
>>> 	> PMIPv6 signaling should be extended to support in-band 
>>> configuration
>>> 	> of such policy routing at the LMA. Hence, we should 
>> thoroughly 
>>> define
>>> 	> the scope of the solution space before.
>>> 	>
>>> 	> marco
>>> 	>
>>> 	>
>>> 	>
>>> 	> MELIA TELEMACO schrieb:
>>> 	>> Hello,
>>> 	>>
>>> 	>> In principle I am fine with the 4 points Raj proposed. In 
>>> addition, I
>>> 	>> would stress scenarios where the same HNP (and same 
>> IP address) is
>>> 	>> configured across several interfaces. I believe 
>> these scenarios 
>>> are
>>> 	>> very useful for flow mobility and flow distributions.
>>> 	>> Comments?
>>> 	>>
>>> 	>> telemaco
>>> 	>> -----Message d'origine-----
>>> 	>> De : netext-bounces at mail.mobileip.jp
>>> 	>> [mailto:netext-bounces at mail.mobileip.jp] De la part de
>>> 	>> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009
>>> 15:56 A`
>>> 	>> : netext at mail.mobileip.jp Cc : 
>> Basavaraj.Patil at nokia.com Objet :
>>> 	>> [Netext] Review of the Multihoming PS I-D
>>> 	>>
>>> 	>>
>>> 	>> Hello,
>>> 	>>
>>> 	>> I have reviewed the Netext Multihoming PS I-D
>>> 	>> <draft-jeyatharan-netext-multihoming-ps-00>. Thanks 
>> to Mohana for 
>>> her
>>> 	>> efforts on getting this I-D ready.
>>> 	>>
>>> 	>> 1. My impression after reading the I-D is that it 
>> misses the key
>>> 	>>    problem of multihoming that we are trying to work 
>> on. Proxy
>>> MIP6 as
>>> 	>>    currently specified in RFC5213 has limited support for
>>> 	>>    multihoming. It was decided that multihoming 
>> should be dealt
>>> with
>>> 	>>    separately in Netlmm during the course discussions on this
>>> topic in
>>> 	>>    the past. While many of the issues mentioned in 
>> the I-D are
>>> 	>>    relevant I believe that Netext should be working on a more
>>> narrow
>>> 	>>    scope to enhance PMIP6 to support a few 
>> multihoming scenarios.
>>> 	>>
>>> 	>> 2. Sec 3 of the I-D which analyses multihoming 
>> issues in the case 
>>> of
>>> 	>>    PMIP6/CMIP6 coexisting together is really 
>> misplaced here. I do
>>> not
>>> 	>>    believe we want to address this topic as part of the
>>> multihoming
>>> 	>>    work in Netext. This is simply out of scope.
>>> 	>>
>>> 	>> 3. The I-D focuses on the problem of multiplexing 
>> flows or having
>>> 	>>    flows traverse via one interface or another or 
>> the ability to
>>> move
>>> 	>>    a flow from one interface to another. While these are all
>>> valid
>>> 	>>    things to do in PMIP6, I am not convinced that these are
>>> 	>>    specifically related to multihoming.
>>> 	>>
>>> 	>> Rajeev and I had a discussion on the scope of 
>> multihoming and what 
>>> we
>>> 	>> should really be focusing on. We came up with the following 
>>> specific
>>> 	>> scenarios which we should address:
>>> 	>>
>>> 	>> a. The multihoming work in Netext should address the 
>> limitations 
>>> of
>>> 	>> RFC5213
>>> 	>>    w.r.t multihoming. The issue of having a single 
>> BCE for an MN
>>> 	>>    identified by an MN-ID and attaching via multiple 
>> interfaces
>>> should
>>> 	>>    be resolved.
>>> 	>>
>>> 	>> b. The scenario where an MN is connected via a MAG 
>> to an LMA and 
>>> the
>>> 	>>    ability to establish multiple sessions via the 
>> same MAG. This
>>> is
>>> 	>>    the case where the MN is attached via a specific 
>> access type
>>> and
>>> 	>>    establishes multiple IP sessions via the MAG.
>>> 	>>
>>> 	>> c. The scenario where an MN attaches via different 
>> interfaces 
>>> which
>>> 	>>    are of differing access technologies via MAG1 and MAG2
>>> 	>>    simultaneously. The MAG1/MAG2 entities are attached to the
>>> same
>>> 	>>    LMA.
>>> 	>>
>>> 	>> d. A combination of the scenarios in (b) and (c), i.e having 
>>> multiple
>>> 	>>    sessions via each access type while connected 
>> thru different
>>> MAGs
>>> 	>>    simultaneously.
>>> 	>>
>>> 	>> Lets see if we can build some consensus around the 
>> scope of the 
>>> problem.
>>> 	>>
>>> 	>> -Raj
>>> 	>>
>>> 	>> _______________________________________________
>>> 	>> NetExt mailing list
>>> 	>> NetExt at mail.mobileip.jp
>>> 	>> http://www.mobileip.jp/mailman/listinfo/netext
>>> 	>>
>>> 	>> _______________________________________________
>>> 	>> NetExt mailing list
>>> 	>> NetExt at mail.mobileip.jp
>>> 	>> http://www.mobileip.jp/mailman/listinfo/netext
>>> 	>>  
>>> 	>
>>> 	>
>>> 	> _______________________________________________
>>> 	> NetExt mailing list
>>> 	> NetExt at mail.mobileip.jp
>>> 	> http://www.mobileip.jp/mailman/listinfo/netext
>>> 	>
>>> 	>
>>> 	>
>>> 	
>>> 	
>>>
>>>
>>>
>>> _______________________________________________
>>> NetExt mailing list
>>> NetExt at mail.mobileip.jp
>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>
>>>
>>>
>>
> 
> 
> 
> 

From: liebsch at nw.neclab.eu (Marco Liebsch)
Date: Tue, 17 Feb 2009 13:53:10 +0100
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Domagoj,

as a step towards clear boundaries, I think we should not speak about
flow mobility and flow handover here. As a prerequisite and as actual
work item for NetExt, we have to solve a few things on the PMIPv6
level support for multi-homing: Maintain multiple registrations from
different interfaces, assignment of the same HNP for these interfaces,
inter-working with routing policies. etc. This is also different from basic
dual radio handover support, which is considered in RFC5213 already,
and relies on a single BCE on the LMA. I think this is what also
Hidetoshi referred to. What's needed on the LMA, MAG and for the
protocol operation to support our target use cases for multi-homing,
this is what we need to find out. I don't think NetExt
will solve specific details for flow mobility.

marco

Domagoj Premec wrote:
> Hi Hidetoshi, all, 
>
> In the context of the multi-interfaced host and the IP flow mobility, we could look at handovers as a special case of the IP flow mobility where all the flows are moved to a different interface. The line between the handovers and the IP flow mobility seems to be blurred in this case so we need to set clear boundaries to keep the scenarios apart. Or maybe it would be best to analyse them together?
>
> domagoj
>
>
>   
>> -----Original Message-----
>> From: ext Hidetoshi Yokota [mailto:yokota at kddilabs.jp] 
>> Sent: 17. velja?a 2009 05:42
>> To: Mohana Jeyatharan
>> Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; 
>> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>> Subject: Re: [Netext] Review of the Multihoming PS I-D
>>
>> Hi Mohana and all,
>>
>> I think your scenario is viable, but we should probably more 
>> carefully clarify the difference between multihoming and 
>> handover. Assigning the same address to different interfaces 
>> on the MN for a sufficiently long time sounds like 
>> multihoming; however, if this situation holds only for a 
>> short period of time for MN's movement or fail over or for 
>> whatever reason, that sounds like handover. This difference 
>> would affect the behavior of the LMA and MAG(s).
>>
>> In Section 2 of the Multihoming PS document, Issues related 
>> to handoff performance and those related to flow mobility 
>> during sudden disconnection appear to be categorized into 
>> handover. If all agree that these issues should also be 
>> included in multihoming, that's fine. I would just like to 
>> make sure of it first of all.
>>
>> Regards,
>> --
>> Hidetoshi
>>
>> Mohana Jeyatharan wrote:
>>     
>>> Hi Domagoj and All,
>>>
>>> Yes, we too support this. For hosts that want flow mobility 
>>>       
>> in PMIPv6 domain, may have to configure same address or at 
>> least be able to accept packets that are addressed to another 
>> interface.
>>     
>>> Moreover, this is extending PMIPv6 for such hosts and it is 
>>>       
>> not changing PMIPv6 in anyway. 
>>     
>>> BR,
>>> Mohana
>>>
>>> -----Original Message-----
>>> From: netext-bounces at mail.mobileip.jp 
>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Domagoj Premec
>>> Sent: Tuesday, February 17, 2009 6:45 AM
>>> To: 'ext MELIA TELEMACO'; 'Hidetoshi Yokota'; 'Marco Liebsch'
>>> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>> Subject: Re: [Netext] Review of the Multihoming PS I-D
>>>
>>> Hi,
>>>  
>>> I share the opinion that having the same address assigned 
>>>       
>> to different 
>>     
>>> interfaces is a viable scenario in the context of flow 
>>>       
>> mobility and I 
>>     
>>> believe it should be included in the scope of the inter-tech work.
>>>
>>> domagoj
>>>
>>>
>>>
>>> ________________________________
>>>
>>> 	From: netext-bounces at mail.mobileip.jp 
>>> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext 
>>>       
>> MELIA TELEMACO
>>     
>>> 	Sent: 16. veljaca 2009 14:14
>>> 	To: Hidetoshi Yokota; Marco Liebsch
>>> 	Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
>>> 	Subject: Re: [Netext] Review of the Multihoming PS I-D
>>> 	
>>> 	
>>>
>>> 	Hi Hidetoshi,
>>> 	
>>> 	I took the liberty to edit your post according (I hope) 
>>>       
>> to what Marco 
>>     
>>> and I have been saying. Here it goes:
>>> 	
>>>
>>> 	                            Session2_CN1
>>> 	                   Addr_1   Session1_CN1
>>> 	            IF#1                             MAG#1        CN#1
>>> 	                   Addr_2   Session1_CN2
>>>
>>> 	    MN-ID                                            LMA
>>>
>>> 	                   Addr_1
>>> 	            IF#2                             MAG#2         CN#2
>>> 	                   Addr_2   Session2_CN2
>>>
>>> 	According to the pic the MN can a) request multiple addresses 
>>> (depending on the service he might want to get) and b) 
>>>       
>> configure the 
>>     
>>> very same address on multiple interfaces to allow flow 
>>>       
>> mobility (e.g.
>>     
>>> Session2_CN1 can be moved to IF#2 Addr_1). If you do not 
>>>       
>> configure the 
>>     
>>> same address I wonder how the LMA can route flows since the 
>>>       
>> CN1 always 
>>     
>>> send to the same HNP (Addr_1).
>>>
>>> 	Marco this is your understanding as well?
>>>
>>> 	 
>>>
>>> 	thanks
>>>
>>> 	telemaco
>>>
>>> 	
>>> 	
>>> 	-----Message d'origine-----
>>> 	De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
>>> 	Envoy? : lundi 16 f?vrier 2009 13:15
>>> 	A : Marco Liebsch
>>> 	Cc : MELIA TELEMACO; netext at mail.mobileip.jp; 
>>> Basavaraj.Patil at nokia.com
>>> 	Objet : Re: [Netext] Review of the Multihoming PS I-D
>>> 	
>>> 	Hi Marco, Telemaco, Raj and all,
>>> 	
>>> 	This thread is interesting and important for the start. Let me 
>>> clarify the problem that we are trying to solve. The MN has 
>>>       
>> multiple 
>>     
>>> interfaces and multiple addresses assigned by multiple MAGs and can 
>>> setup multiple sessions with multiple CNs (either mobile or 
>>>       
>> plain IPv6 
>>     
>>> hosts) simultaneously. However, the MN has only one MN-ID 
>>>       
>> and only one 
>>     
>>> LMA (in the scople of the multihoming problem we are 
>>>       
>> discussing now). 
>>     
>>> The addresses assigned for the MN can be bound to any 
>>>       
>> interface of the 
>>     
>>> MN and the sessions associated with those addresses can go 
>>>       
>> through any interface of the MN.
>>     
>>> Also, those addresses and corresponding sessions can 
>>>       
>> migrate to other 
>>     
>>> interfaces of the MN in the middle. The following diagram 
>>>       
>> simply shows 
>>     
>>> this
>>> situation:
>>> 	
>>> 	/------- MN --------\
>>> 	                        Session#1
>>> 	               Addr#1   Session#2                 CN#1
>>> 	        IF#1   Addr#2   Session#3   MAG#1         CN#2
>>> 	MN-ID   IF#2   Addr#3   ...         MAG#2   LMA   ...
>>> 	        ...    ...      ...         ...           ...
>>> 	        IF#J   ...      ...         MAG#M         CN#N
>>> 	               Addr#K   ...
>>> 	                        Session#L
>>> 	
>>> 	Is this the correct view that we are discussing now?
>>> 	
>>> 	Regards,
>>> 	--
>>> 	Hidetoshi
>>> 	
>>> 	Marco Liebsch wrote:
>>> 	> Hi,
>>> 	>
>>> 	> I agree that we should consider support of use cases 
>>>       
>> where mulitple
>>     
>>> 	> interfaces of an MN get the same HNP assiged. One 
>>>       
>> step further, the 
>>     
>>> MN
>>> 	> must configure the same suffix to allow flow mobility 
>>>       
>> and keep flow
>>     
>>> 	> distribution etc.
>>> 	> transparent
>>> 	> to a CN.
>>> 	>
>>> 	> Regarding Raj's comments: I fully agree that we need 
>>>       
>> to specify the
>>     
>>> 	> scope of what we'll solve in NetExt and my opinion is 
>>>       
>> that the 
>>     
>>> focus
>>> 	> should be first on the definition of a set of target 
>>>       
>> use cases, as 
>>     
>>> too
>>> 	> many of them are treated under the umbrella of 
>>>       
>> multihoming. Then 
>>     
>>> let's
>>> 	> analyze where RFC5213 needs some more work to support them.
>>> 	>
>>> 	> Whereas I think that most of this work will be on the 
>>>       
>> LMA to allow 
>>     
>>> the
>>> 	> assignment of the same HNP to multiple interfaces and 
>>>       
>> to support
>>     
>>> 	> inter-working with policy based forwarding, I do 
>>>       
>> *not* think that
>>     
>>> 	> PMIPv6 signaling should be extended to support in-band 
>>> configuration
>>> 	> of such policy routing at the LMA. Hence, we should 
>>>       
>> thoroughly 
>>     
>>> define
>>> 	> the scope of the solution space before.
>>> 	>
>>> 	> marco
>>> 	>
>>> 	>
>>> 	>
>>> 	> MELIA TELEMACO schrieb:
>>> 	>> Hello,
>>> 	>>
>>> 	>> In principle I am fine with the 4 points Raj proposed. In 
>>> addition, I
>>> 	>> would stress scenarios where the same HNP (and same 
>>>       
>> IP address) is
>>     
>>> 	>> configured across several interfaces. I believe 
>>>       
>> these scenarios 
>>     
>>> are
>>> 	>> very useful for flow mobility and flow distributions.
>>> 	>> Comments?
>>> 	>>
>>> 	>> telemaco
>>> 	>> -----Message d'origine-----
>>> 	>> De : netext-bounces at mail.mobileip.jp
>>> 	>> [mailto:netext-bounces at mail.mobileip.jp] De la part de
>>> 	>> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009
>>> 15:56 A`
>>> 	>> : netext at mail.mobileip.jp Cc : 
>>>       
>> Basavaraj.Patil at nokia.com Objet :
>>     
>>> 	>> [Netext] Review of the Multihoming PS I-D
>>> 	>>
>>> 	>>
>>> 	>> Hello,
>>> 	>>
>>> 	>> I have reviewed the Netext Multihoming PS I-D
>>> 	>> <draft-jeyatharan-netext-multihoming-ps-00>. Thanks 
>>>       
>> to Mohana for 
>>     
>>> her
>>> 	>> efforts on getting this I-D ready.
>>> 	>>
>>> 	>> 1. My impression after reading the I-D is that it 
>>>       
>> misses the key
>>     
>>> 	>>    problem of multihoming that we are trying to work 
>>>       
>> on. Proxy
>>     
>>> MIP6 as
>>> 	>>    currently specified in RFC5213 has limited support for
>>> 	>>    multihoming. It was decided that multihoming 
>>>       
>> should be dealt
>>     
>>> with
>>> 	>>    separately in Netlmm during the course discussions on this
>>> topic in
>>> 	>>    the past. While many of the issues mentioned in 
>>>       
>> the I-D are
>>     
>>> 	>>    relevant I believe that Netext should be working on a more
>>> narrow
>>> 	>>    scope to enhance PMIP6 to support a few 
>>>       
>> multihoming scenarios.
>>     
>>> 	>>
>>> 	>> 2. Sec 3 of the I-D which analyses multihoming 
>>>       
>> issues in the case 
>>     
>>> of
>>> 	>>    PMIP6/CMIP6 coexisting together is really 
>>>       
>> misplaced here. I do
>>     
>>> not
>>> 	>>    believe we want to address this topic as part of the
>>> multihoming
>>> 	>>    work in Netext. This is simply out of scope.
>>> 	>>
>>> 	>> 3. The I-D focuses on the problem of multiplexing 
>>>       
>> flows or having
>>     
>>> 	>>    flows traverse via one interface or another or 
>>>       
>> the ability to
>>     
>>> move
>>> 	>>    a flow from one interface to another. While these are all
>>> valid
>>> 	>>    things to do in PMIP6, I am not convinced that these are
>>> 	>>    specifically related to multihoming.
>>> 	>>
>>> 	>> Rajeev and I had a discussion on the scope of 
>>>       
>> multihoming and what 
>>     
>>> we
>>> 	>> should really be focusing on. We came up with the following 
>>> specific
>>> 	>> scenarios which we should address:
>>> 	>>
>>> 	>> a. The multihoming work in Netext should address the 
>>>       
>> limitations 
>>     
>>> of
>>> 	>> RFC5213
>>> 	>>    w.r.t multihoming. The issue of having a single 
>>>       
>> BCE for an MN
>>     
>>> 	>>    identified by an MN-ID and attaching via multiple 
>>>       
>> interfaces
>>     
>>> should
>>> 	>>    be resolved.
>>> 	>>
>>> 	>> b. The scenario where an MN is connected via a MAG 
>>>       
>> to an LMA and 
>>     
>>> the
>>> 	>>    ability to establish multiple sessions via the 
>>>       
>> same MAG. This
>>     
>>> is
>>> 	>>    the case where the MN is attached via a specific 
>>>       
>> access type
>>     
>>> and
>>> 	>>    establishes multiple IP sessions via the MAG.
>>> 	>>
>>> 	>> c. The scenario where an MN attaches via different 
>>>       
>> interfaces 
>>     
>>> which
>>> 	>>    are of differing access technologies via MAG1 and MAG2
>>> 	>>    simultaneously. The MAG1/MAG2 entities are attached to the
>>> same
>>> 	>>    LMA.
>>> 	>>
>>> 	>> d. A combination of the scenarios in (b) and (c), i.e having 
>>> multiple
>>> 	>>    sessions via each access type while connected 
>>>       
>> thru different
>>     
>>> MAGs
>>> 	>>    simultaneously.
>>> 	>>
>>> 	>> Lets see if we can build some consensus around the 
>>>       
>> scope of the 
>>     
>>> problem.
>>> 	>>
>>> 	>> -Raj
>>> 	>>
>>> 	>> _______________________________________________
>>> 	>> NetExt mailing list
>>> 	>> NetExt at mail.mobileip.jp
>>> 	>> http://www.mobileip.jp/mailman/listinfo/netext
>>> 	>>
>>> 	>> _______________________________________________
>>> 	>> NetExt mailing list
>>> 	>> NetExt at mail.mobileip.jp
>>> 	>> http://www.mobileip.jp/mailman/listinfo/netext
>>> 	>>  
>>> 	>
>>> 	>
>>> 	> _______________________________________________
>>> 	> NetExt mailing list
>>> 	> NetExt at mail.mobileip.jp
>>> 	> http://www.mobileip.jp/mailman/listinfo/netext
>>> 	>
>>> 	>
>>> 	>
>>> 	
>>> 	
>>>
>>>
>>>
>>> _______________________________________________
>>> NetExt mailing list
>>> NetExt at mail.mobileip.jp
>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>
>>>
>>>
>>>       
>>     
>
>   

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Tue, 17 Feb 2009 12:56:58 +0100
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Hidetoshi, all, 

In the context of the multi-interfaced host and the IP flow mobility, we could look at handovers as a special case of the IP flow mobility where all the flows are moved to a different interface. The line between the handovers and the IP flow mobility seems to be blurred in this case so we need to set clear boundaries to keep the scenarios apart. Or maybe it would be best to analyse them together?

domagoj

> -----Original Message-----
> From: ext Hidetoshi Yokota [mailto:yokota at kddilabs.jp] 
> Sent: 17. velja?a 2009 05:42
> To: Mohana Jeyatharan
> Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; 
> netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Re: [Netext] Review of the Multihoming PS I-D
> 
> Hi Mohana and all,
> 
> I think your scenario is viable, but we should probably more 
> carefully clarify the difference between multihoming and 
> handover. Assigning the same address to different interfaces 
> on the MN for a sufficiently long time sounds like 
> multihoming; however, if this situation holds only for a 
> short period of time for MN's movement or fail over or for 
> whatever reason, that sounds like handover. This difference 
> would affect the behavior of the LMA and MAG(s).
> 
> In Section 2 of the Multihoming PS document, Issues related 
> to handoff performance and those related to flow mobility 
> during sudden disconnection appear to be categorized into 
> handover. If all agree that these issues should also be 
> included in multihoming, that's fine. I would just like to 
> make sure of it first of all.
> 
> Regards,
> --
> Hidetoshi
> 
> Mohana Jeyatharan wrote:
> > Hi Domagoj and All,
> > 
> > Yes, we too support this. For hosts that want flow mobility 
> in PMIPv6 domain, may have to configure same address or at 
> least be able to accept packets that are addressed to another 
> interface.
> > 
> > Moreover, this is extending PMIPv6 for such hosts and it is 
> not changing PMIPv6 in anyway. 
> > 
> > BR,
> > Mohana
> > 
> > -----Original Message-----
> > From: netext-bounces at mail.mobileip.jp 
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Domagoj Premec
> > Sent: Tuesday, February 17, 2009 6:45 AM
> > To: 'ext MELIA TELEMACO'; 'Hidetoshi Yokota'; 'Marco Liebsch'
> > Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> > Subject: Re: [Netext] Review of the Multihoming PS I-D
> > 
> > Hi,
> >  
> > I share the opinion that having the same address assigned 
> to different 
> > interfaces is a viable scenario in the context of flow 
> mobility and I 
> > believe it should be included in the scope of the inter-tech work.
> > 
> > domagoj
> > 
> > 
> > 
> > ________________________________
> > 
> > 	From: netext-bounces at mail.mobileip.jp 
> > [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext 
> MELIA TELEMACO
> > 	Sent: 16. veljaca 2009 14:14
> > 	To: Hidetoshi Yokota; Marco Liebsch
> > 	Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> > 	Subject: Re: [Netext] Review of the Multihoming PS I-D
> > 	
> > 	
> > 
> > 	Hi Hidetoshi,
> > 	
> > 	I took the liberty to edit your post according (I hope) 
> to what Marco 
> > and I have been saying. Here it goes:
> > 	
> > 
> > 	                            Session2_CN1
> > 	                   Addr_1   Session1_CN1
> > 	            IF#1                             MAG#1        CN#1
> > 	                   Addr_2   Session1_CN2
> > 
> > 	    MN-ID                                            LMA
> > 
> > 	                   Addr_1
> > 	            IF#2                             MAG#2         CN#2
> > 	                   Addr_2   Session2_CN2
> > 
> > 	According to the pic the MN can a) request multiple addresses 
> > (depending on the service he might want to get) and b) 
> configure the 
> > very same address on multiple interfaces to allow flow 
> mobility (e.g.
> > Session2_CN1 can be moved to IF#2 Addr_1). If you do not 
> configure the 
> > same address I wonder how the LMA can route flows since the 
> CN1 always 
> > send to the same HNP (Addr_1).
> > 
> > 	Marco this is your understanding as well?
> > 
> > 	 
> > 
> > 	thanks
> > 
> > 	telemaco
> > 
> > 	
> > 	
> > 	-----Message d'origine-----
> > 	De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
> > 	Envoy? : lundi 16 f?vrier 2009 13:15
> > 	A : Marco Liebsch
> > 	Cc : MELIA TELEMACO; netext at mail.mobileip.jp; 
> > Basavaraj.Patil at nokia.com
> > 	Objet : Re: [Netext] Review of the Multihoming PS I-D
> > 	
> > 	Hi Marco, Telemaco, Raj and all,
> > 	
> > 	This thread is interesting and important for the start. Let me 
> > clarify the problem that we are trying to solve. The MN has 
> multiple 
> > interfaces and multiple addresses assigned by multiple MAGs and can 
> > setup multiple sessions with multiple CNs (either mobile or 
> plain IPv6 
> > hosts) simultaneously. However, the MN has only one MN-ID 
> and only one 
> > LMA (in the scople of the multihoming problem we are 
> discussing now). 
> > The addresses assigned for the MN can be bound to any 
> interface of the 
> > MN and the sessions associated with those addresses can go 
> through any interface of the MN.
> > Also, those addresses and corresponding sessions can 
> migrate to other 
> > interfaces of the MN in the middle. The following diagram 
> simply shows 
> > this
> > situation:
> > 	
> > 	/------- MN --------\
> > 	                        Session#1
> > 	               Addr#1   Session#2                 CN#1
> > 	        IF#1   Addr#2   Session#3   MAG#1         CN#2
> > 	MN-ID   IF#2   Addr#3   ...         MAG#2   LMA   ...
> > 	        ...    ...      ...         ...           ...
> > 	        IF#J   ...      ...         MAG#M         CN#N
> > 	               Addr#K   ...
> > 	                        Session#L
> > 	
> > 	Is this the correct view that we are discussing now?
> > 	
> > 	Regards,
> > 	--
> > 	Hidetoshi
> > 	
> > 	Marco Liebsch wrote:
> > 	> Hi,
> > 	>
> > 	> I agree that we should consider support of use cases 
> where mulitple
> > 	> interfaces of an MN get the same HNP assiged. One 
> step further, the 
> > MN
> > 	> must configure the same suffix to allow flow mobility 
> and keep flow
> > 	> distribution etc.
> > 	> transparent
> > 	> to a CN.
> > 	>
> > 	> Regarding Raj's comments: I fully agree that we need 
> to specify the
> > 	> scope of what we'll solve in NetExt and my opinion is 
> that the 
> > focus
> > 	> should be first on the definition of a set of target 
> use cases, as 
> > too
> > 	> many of them are treated under the umbrella of 
> multihoming. Then 
> > let's
> > 	> analyze where RFC5213 needs some more work to support them.
> > 	>
> > 	> Whereas I think that most of this work will be on the 
> LMA to allow 
> > the
> > 	> assignment of the same HNP to multiple interfaces and 
> to support
> > 	> inter-working with policy based forwarding, I do 
> *not* think that
> > 	> PMIPv6 signaling should be extended to support in-band 
> > configuration
> > 	> of such policy routing at the LMA. Hence, we should 
> thoroughly 
> > define
> > 	> the scope of the solution space before.
> > 	>
> > 	> marco
> > 	>
> > 	>
> > 	>
> > 	> MELIA TELEMACO schrieb:
> > 	>> Hello,
> > 	>>
> > 	>> In principle I am fine with the 4 points Raj proposed. In 
> > addition, I
> > 	>> would stress scenarios where the same HNP (and same 
> IP address) is
> > 	>> configured across several interfaces. I believe 
> these scenarios 
> > are
> > 	>> very useful for flow mobility and flow distributions.
> > 	>> Comments?
> > 	>>
> > 	>> telemaco
> > 	>> -----Message d'origine-----
> > 	>> De : netext-bounces at mail.mobileip.jp
> > 	>> [mailto:netext-bounces at mail.mobileip.jp] De la part de
> > 	>> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009
> > 15:56 A`
> > 	>> : netext at mail.mobileip.jp Cc : 
> Basavaraj.Patil at nokia.com Objet :
> > 	>> [Netext] Review of the Multihoming PS I-D
> > 	>>
> > 	>>
> > 	>> Hello,
> > 	>>
> > 	>> I have reviewed the Netext Multihoming PS I-D
> > 	>> <draft-jeyatharan-netext-multihoming-ps-00>. Thanks 
> to Mohana for 
> > her
> > 	>> efforts on getting this I-D ready.
> > 	>>
> > 	>> 1. My impression after reading the I-D is that it 
> misses the key
> > 	>>    problem of multihoming that we are trying to work 
> on. Proxy
> > MIP6 as
> > 	>>    currently specified in RFC5213 has limited support for
> > 	>>    multihoming. It was decided that multihoming 
> should be dealt
> > with
> > 	>>    separately in Netlmm during the course discussions on this
> > topic in
> > 	>>    the past. While many of the issues mentioned in 
> the I-D are
> > 	>>    relevant I believe that Netext should be working on a more
> > narrow
> > 	>>    scope to enhance PMIP6 to support a few 
> multihoming scenarios.
> > 	>>
> > 	>> 2. Sec 3 of the I-D which analyses multihoming 
> issues in the case 
> > of
> > 	>>    PMIP6/CMIP6 coexisting together is really 
> misplaced here. I do
> > not
> > 	>>    believe we want to address this topic as part of the
> > multihoming
> > 	>>    work in Netext. This is simply out of scope.
> > 	>>
> > 	>> 3. The I-D focuses on the problem of multiplexing 
> flows or having
> > 	>>    flows traverse via one interface or another or 
> the ability to
> > move
> > 	>>    a flow from one interface to another. While these are all
> > valid
> > 	>>    things to do in PMIP6, I am not convinced that these are
> > 	>>    specifically related to multihoming.
> > 	>>
> > 	>> Rajeev and I had a discussion on the scope of 
> multihoming and what 
> > we
> > 	>> should really be focusing on. We came up with the following 
> > specific
> > 	>> scenarios which we should address:
> > 	>>
> > 	>> a. The multihoming work in Netext should address the 
> limitations 
> > of
> > 	>> RFC5213
> > 	>>    w.r.t multihoming. The issue of having a single 
> BCE for an MN
> > 	>>    identified by an MN-ID and attaching via multiple 
> interfaces
> > should
> > 	>>    be resolved.
> > 	>>
> > 	>> b. The scenario where an MN is connected via a MAG 
> to an LMA and 
> > the
> > 	>>    ability to establish multiple sessions via the 
> same MAG. This
> > is
> > 	>>    the case where the MN is attached via a specific 
> access type
> > and
> > 	>>    establishes multiple IP sessions via the MAG.
> > 	>>
> > 	>> c. The scenario where an MN attaches via different 
> interfaces 
> > which
> > 	>>    are of differing access technologies via MAG1 and MAG2
> > 	>>    simultaneously. The MAG1/MAG2 entities are attached to the
> > same
> > 	>>    LMA.
> > 	>>
> > 	>> d. A combination of the scenarios in (b) and (c), i.e having 
> > multiple
> > 	>>    sessions via each access type while connected 
> thru different
> > MAGs
> > 	>>    simultaneously.
> > 	>>
> > 	>> Lets see if we can build some consensus around the 
> scope of the 
> > problem.
> > 	>>
> > 	>> -Raj
> > 	>>
> > 	>> _______________________________________________
> > 	>> NetExt mailing list
> > 	>> NetExt at mail.mobileip.jp
> > 	>> http://www.mobileip.jp/mailman/listinfo/netext
> > 	>>
> > 	>> _______________________________________________
> > 	>> NetExt mailing list
> > 	>> NetExt at mail.mobileip.jp
> > 	>> http://www.mobileip.jp/mailman/listinfo/netext
> > 	>>  
> > 	>
> > 	>
> > 	> _______________________________________________
> > 	> NetExt mailing list
> > 	> NetExt at mail.mobileip.jp
> > 	> http://www.mobileip.jp/mailman/listinfo/netext
> > 	>
> > 	>
> > 	>
> > 	
> > 	
> > 
> > 
> > 
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> > 
> > 
> > 
> 
> 

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Tue, 17 Feb 2009 11:18:25 +0100
Subject: [Netext] First Problem Statement	about	LocalizedRoutingin	PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <1234809135.5187.77.camel@localhost> <[email-masked]>
Message-ID: <1234865905.5187.143.camel@localhost>

Hi Marco,

El mar, 17-02-2009 a las 10:47 +0100, Marco Liebsch escribi?:
> Hi Carlos,
> 
> Carlos Jes?s Bernardos Cano wrote:
> > Hi Marco,
> >
> > 	In my opinion, it is relevant to first identify whether basic RFC5213
> > provides a solution for the PMIPv6 MN - IPv6 CN case (when attached to
> > the same MAG). If so, since that solution would be basically a framework
> > (the use of the EnableMAGLocalRouting flag), it would be good for NETEXT
> > to detail the solution.
> I agree that we should understand what RFC5213 covers. Section 9.2 sais
> "...The correspondent node can be another visiting mobile node as well,
> or a local fixed node..." So, looks like a CN can be both, an IPv6 CN or a
> PMIPv6 attached node. When you say NetExt should detail this solution,
> then this may cover simply the description of local routing rules. I 
> don't expect
> much text here. If you propose to detail RO setup between a PMIPv6 MN 

Agree this simple to define.

> and an IPv6 CN
> which is connected to a different MAG, that I understand from Rajeev 
> should be
> out of scope of NetExt.

Yes, that's also my understanding, though I'd prefer to consider that
also within the scope of NETEXT.

> 
> >  In any case, I find useful to include the use
> > case of the IPv6 CN (either attached to the same MAG than the PMIPv6 MN
> > or to a different one).
> Ok, maybe that needs further discussion then, whether or not we
> include such use case.
> 
> >  I'm not so sure about addressing the MIPv6 CN...
> > but I'm fine with including the short paragraph.
> >   
> We do not talk about RO with a MIPv6 CN anymore, as I understood that
> this is out of scope of NetExt.

Perfect, I fully agree with that.

> 
> > 	I'm not sure if I replied to what you were asking, BTW :-)
> >   
> Yes, somehow you did :-)

:-D

Thanks,

Carlos

> 
> marco
> 
> > 	Thanks,
> >
> > 	Carlos
> >
> > El lun, 16-02-2009 a las 17:57 +0100, Marco Liebsch escribi?:
> >   
> >> Rajeev, Carlos,
> >>
> >> can we conclude from the discussion so far that
> >> a.) this is a reasonable and 'in-scope' use case?
> >> b.) PMIPv6 CN vs. IPv6 CN may not be transparent to a MAG and
> >>   the NetExt solution for PMIPv6 RO?
> >>
> >> If both is a 'yes', I propose to add this case to the RO PS.
> >> If we don't see this as separate use case, we could also add
> >> simply a short paragraph that 'this case may have issues,
> >> which we must look at and take into account'.
> >>
> >> What do you think?
> >>
> >> marco
> >>
> >>
> >>
> >> Koodli, Rajeev wrote:
> >>     
> >>> Hi,
> >>>  
> >>>   
> >>>       
> >>>> I fully agree that the whole point of PMIP is make mobility 
> >>>> management transparent to the MN. However, as far as I 
> >>>> understand from my reading of RFC5213, a mobile node attached 
> >>>> to a PMIPv6 domain might not be entitled to the network-based 
> >>>> mobility management service, and RFC5213 (section 6.14) still 
> >>>> support this node to get connectivity (regular
> >>>> access) from the MAG.
> >>>>     
> >>>>         
> >>> I need to look into this, but I have no idea how a MAG can distinguish the two nodes..
> >>>
> >>>   
> >>>       
> >>>> Related to this, it is also my interpretation of RFC5213 (section
> >>>> 6.10.5) that the local routing support provided by the basic 
> >>>> spec (controlled with the EnableMAGLocalRouting flag) only 
> >>>> applies to communications between a PMIPv6 MN and a regular 
> >>>> IPv6 host attached to the same MAG.
> >>>>     
> >>>>         
> >>> This sounds even more interesting because the "regular IPv6 host" gets better performance!
> >>> So, all you have to do is to declare that you are not a PMIP6 MN to get better VoIP quality :-)
> >>>
> >>> Regards,
> >>>
> >>> -Rajeev
> >>>
> >>>   
> >>>       
> >>>> This is just to try to clarify what RFC5213 provides (actually, very
> >>>> little) and what does not in regards to local routing 
> >>>> support. Do you see my point?
> >>>>
> >>>> Thanks!
> >>>>
> >>>> Carlos
> >>>>
> >>>>     
> >>>>         
> >>>>>       
> >>>>>           
> >>>>>> 	- If my previous understanding is correct, then RFC5213 
> >>>>>>         
> >>>>>>             
> >>>> does not 
> >>>>     
> >>>>         
> >>>>>> only define any mechanism to perform local routing 
> >>>>>>         
> >>>>>>             
> >>>> between two MNs 
> >>>>     
> >>>>         
> >>>>>> connected to the same PMIPv6 domain (not even for the 
> >>>>>>         
> >>>>>>             
> >>>> case in which 
> >>>>     
> >>>>         
> >>>>>> both are attached to the same MAG).
> >>>>>> Then, IMHO it would be better to change the terminology in the PS 
> >>>>>> and avoid using CN or coming up with different terms for 
> >>>>>>         
> >>>>>>             
> >>>> a CN that 
> >>>>     
> >>>>         
> >>>>>> is getting network-based mobility service from a CN that is not 
> >>>>>> (i.e. it is just a regular IPv6 node getting access from a MAG).
> >>>>>>         
> >>>>>>             
> >>>>> See above.
> >>>>>
> >>>>>       
> >>>>>           
> >>>>>> 	- Currently, the PS only addresses the case of local routing 
> >>>>>> between two MNs connected to the same PMIPv6 domain.
> >>>>>> I think the scenario of optimising traffic between an MN and a 
> >>>>>> regular IPv6 host that is locally connected to a MAG 
> >>>>>>         
> >>>>>>             
> >>>> should also be 
> >>>>     
> >>>>         
> >>>>>> addressed. Not sure the implications on the potential 
> >>>>>>         
> >>>>>>             
> >>>> solutions, but 
> >>>>     
> >>>>         
> >>>>>> it might have an impact on the classification scheme that 
> >>>>>>         
> >>>>>>             
> >>>> is used in 
> >>>>     
> >>>>         
> >>>>>> the PS now (A[number of MAGs][number of LMAs]).
> >>>>>>
> >>>>>>         
> >>>>>>             
> >>>>> Our focus should be on solving the problem for nodes 
> >>>>>       
> >>>>>           
> >>>> attached to a PMIP6 domain.
> >>>>     
> >>>>         
> >>>>> Thanks,
> >>>>>
> >>>>> -Rajeev
> >>>>>
> >>>>>
> >>>>>       
> >>>>>           
> >>>>>> 	Thanks,
> >>>>>>
> >>>>>> 	Carlos
> >>>>>>
> >>>>>> El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?:
> >>>>>>         
> >>>>>>             
> >>>>>>> Hi all,
> >>>>>>>
> >>>>>>> please find the link to a first version of a Localized
> >>>>>>>           
> >>>>>>>               
> >>>>>> Routing Problem
> >>>>>>         
> >>>>>>             
> >>>>>>> Statement below.
> >>>>>>> The abstract of the PS document is as follows:
> >>>>>>>
> >>>>>>> Abstract:
> >>>>>>>
> >>>>>>>    Proxy Mobile IPv6 is the IETF standard for network-based
> >>>>>>>           
> >>>>>>>               
> >>>>>> localized
> >>>>>>         
> >>>>>>             
> >>>>>>>    mobility management.  In Proxy Mobile IPv6, mobile nodes are
> >>>>>>>    topologically anchored at a Local Mobility Anchor, which
> >>>>>>>           
> >>>>>>>               
> >>>>>> forwards all
> >>>>>>         
> >>>>>>             
> >>>>>>>    data for registered mobile nodes.  The set up and support for
> >>>>>>>    localized routing, which allows forwarding of data
> >>>>>>>           
> >>>>>>>               
> >>>>>> packets between
> >>>>>>         
> >>>>>>             
> >>>>>>>    mobile nodes and correspondent nodes directly without
> >>>>>>>           
> >>>>>>>               
> >>>>>> traversing an
> >>>>>>         
> >>>>>>             
> >>>>>>>    LMA, is not considered.  This document describes the
> >>>>>>>           
> >>>>>>>               
> >>>>>> problem space of
> >>>>>>         
> >>>>>>             
> >>>>>>>    localized routing in Proxy Mobile IPv6.
> >>>>>>>
> >>>>>>>
> >>>>>>> Any comments to this version of the problem statement 
> >>>>>>>           
> >>>>>>>               
> >>>> are welcome.
> >>>>     
> >>>>         
> >>>>>>>           
> >>>>>>>               
> >>>> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps
> >>>>     
> >>>>         
> >>>>>> -0
> >>>>>>         
> >>>>>>             
> >>>>>>> 0.txt
> >>>>>>>
> >>>>>>> Best regards,
> >>>>>>> marco
> >>>>>>>
> >>>>>>>
> >>>>>>> _______________________________________________
> >>>>>>> NetExt mailing list
> >>>>>>> NetExt at mail.mobileip.jp
> >>>>>>> http://www.mobileip.jp/mailman/listinfo/netext
> >>>>>>>           
> >>>>>>>               
> >>>>>> -- 
> >>>>>>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> >>>>>>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>>>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> >>>>>>         Deployment Experiences on Vehicular networks
> >>>>>>                   http://www.weedev.org/
> >>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>>>
> >>>>>>         
> >>>>>>             
> >>>>> This email and any attachments may contain legally 
> >>>>>       
> >>>>>           
> >>>> privileged and/or confidential information of Starent 
> >>>> Networks, Corp. and is intended only for the individual or 
> >>>> entity named in the message.  The information transmitted may 
> >>>> not be used to create or change any contractual obligations 
> >>>> of Starent Networks, Corp.  Any review, retransmission, 
> >>>> dissemination or other use of, or taking of any action in 
> >>>> reliance upon this e-mail and its attachments by persons or 
> >>>> entities other than the intended recipient is prohibited. If 
> >>>> you are not the intended recipient, please notify the sender 
> >>>> immediately -- by replying to this message or by sending an 
> >>>> email to postmaster at starentnetworks.com -- and destroy all 
> >>>> copies of this message and any attachments without reading or 
> >>>> disclosing their contents. Thank you.
> >>>> -- 
> >>>>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> >>>>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> >>>>         Deployment Experiences on Vehicular networks
> >>>>                   http://www.weedev.org/
> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>
> >>>>     
> >>>>         
> 
-- 
 Carlos Jes?s Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090217/6521ed77/attachment.bin>

From: liebsch at nw.neclab.eu (Marco Liebsch)
Date: Tue, 17 Feb 2009 10:47:40 +0100
Subject: [Netext] First Problem Statement about	LocalizedRoutingin	PMIPv6 submitted
In-Reply-To: <1234809135.5187.77.camel@localhost>
References: <[email-masked]>	 <[email-masked]> <1234809135.5187.77.camel@localhost>
Message-ID: <[email-masked]>

Hi Carlos,

Carlos Jes?s Bernardos Cano wrote:
> Hi Marco,
>
> 	In my opinion, it is relevant to first identify whether basic RFC5213
> provides a solution for the PMIPv6 MN - IPv6 CN case (when attached to
> the same MAG). If so, since that solution would be basically a framework
> (the use of the EnableMAGLocalRouting flag), it would be good for NETEXT
> to detail the solution.
I agree that we should understand what RFC5213 covers. Section 9.2 sais
"...The correspondent node can be another visiting mobile node as well,
or a local fixed node..." So, looks like a CN can be both, an IPv6 CN or a
PMIPv6 attached node. When you say NetExt should detail this solution,
then this may cover simply the description of local routing rules. I 
don't expect
much text here. If you propose to detail RO setup between a PMIPv6 MN 
and an IPv6 CN
which is connected to a different MAG, that I understand from Rajeev 
should be
out of scope of NetExt.

>  In any case, I find useful to include the use
> case of the IPv6 CN (either attached to the same MAG than the PMIPv6 MN
> or to a different one).
Ok, maybe that needs further discussion then, whether or not we
include such use case.

>  I'm not so sure about addressing the MIPv6 CN...
> but I'm fine with including the short paragraph.
>   
We do not talk about RO with a MIPv6 CN anymore, as I understood that
this is out of scope of NetExt.

> 	I'm not sure if I replied to what you were asking, BTW :-)
>   
Yes, somehow you did :-)

marco

> 	Thanks,
>
> 	Carlos
>
> El lun, 16-02-2009 a las 17:57 +0100, Marco Liebsch escribi?:
>   
>> Rajeev, Carlos,
>>
>> can we conclude from the discussion so far that
>> a.) this is a reasonable and 'in-scope' use case?
>> b.) PMIPv6 CN vs. IPv6 CN may not be transparent to a MAG and
>>   the NetExt solution for PMIPv6 RO?
>>
>> If both is a 'yes', I propose to add this case to the RO PS.
>> If we don't see this as separate use case, we could also add
>> simply a short paragraph that 'this case may have issues,
>> which we must look at and take into account'.
>>
>> What do you think?
>>
>> marco
>>
>>
>>
>> Koodli, Rajeev wrote:
>>     
>>> Hi,
>>>  
>>>   
>>>       
>>>> I fully agree that the whole point of PMIP is make mobility 
>>>> management transparent to the MN. However, as far as I 
>>>> understand from my reading of RFC5213, a mobile node attached 
>>>> to a PMIPv6 domain might not be entitled to the network-based 
>>>> mobility management service, and RFC5213 (section 6.14) still 
>>>> support this node to get connectivity (regular
>>>> access) from the MAG.
>>>>     
>>>>         
>>> I need to look into this, but I have no idea how a MAG can distinguish the two nodes..
>>>
>>>   
>>>       
>>>> Related to this, it is also my interpretation of RFC5213 (section
>>>> 6.10.5) that the local routing support provided by the basic 
>>>> spec (controlled with the EnableMAGLocalRouting flag) only 
>>>> applies to communications between a PMIPv6 MN and a regular 
>>>> IPv6 host attached to the same MAG.
>>>>     
>>>>         
>>> This sounds even more interesting because the "regular IPv6 host" gets better performance!
>>> So, all you have to do is to declare that you are not a PMIP6 MN to get better VoIP quality :-)
>>>
>>> Regards,
>>>
>>> -Rajeev
>>>
>>>   
>>>       
>>>> This is just to try to clarify what RFC5213 provides (actually, very
>>>> little) and what does not in regards to local routing 
>>>> support. Do you see my point?
>>>>
>>>> Thanks!
>>>>
>>>> Carlos
>>>>
>>>>     
>>>>         
>>>>>       
>>>>>           
>>>>>> 	- If my previous understanding is correct, then RFC5213 
>>>>>>         
>>>>>>             
>>>> does not 
>>>>     
>>>>         
>>>>>> only define any mechanism to perform local routing 
>>>>>>         
>>>>>>             
>>>> between two MNs 
>>>>     
>>>>         
>>>>>> connected to the same PMIPv6 domain (not even for the 
>>>>>>         
>>>>>>             
>>>> case in which 
>>>>     
>>>>         
>>>>>> both are attached to the same MAG).
>>>>>> Then, IMHO it would be better to change the terminology in the PS 
>>>>>> and avoid using CN or coming up with different terms for 
>>>>>>         
>>>>>>             
>>>> a CN that 
>>>>     
>>>>         
>>>>>> is getting network-based mobility service from a CN that is not 
>>>>>> (i.e. it is just a regular IPv6 node getting access from a MAG).
>>>>>>         
>>>>>>             
>>>>> See above.
>>>>>
>>>>>       
>>>>>           
>>>>>> 	- Currently, the PS only addresses the case of local routing 
>>>>>> between two MNs connected to the same PMIPv6 domain.
>>>>>> I think the scenario of optimising traffic between an MN and a 
>>>>>> regular IPv6 host that is locally connected to a MAG 
>>>>>>         
>>>>>>             
>>>> should also be 
>>>>     
>>>>         
>>>>>> addressed. Not sure the implications on the potential 
>>>>>>         
>>>>>>             
>>>> solutions, but 
>>>>     
>>>>         
>>>>>> it might have an impact on the classification scheme that 
>>>>>>         
>>>>>>             
>>>> is used in 
>>>>     
>>>>         
>>>>>> the PS now (A[number of MAGs][number of LMAs]).
>>>>>>
>>>>>>         
>>>>>>             
>>>>> Our focus should be on solving the problem for nodes 
>>>>>       
>>>>>           
>>>> attached to a PMIP6 domain.
>>>>     
>>>>         
>>>>> Thanks,
>>>>>
>>>>> -Rajeev
>>>>>
>>>>>
>>>>>       
>>>>>           
>>>>>> 	Thanks,
>>>>>>
>>>>>> 	Carlos
>>>>>>
>>>>>> El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?:
>>>>>>         
>>>>>>             
>>>>>>> Hi all,
>>>>>>>
>>>>>>> please find the link to a first version of a Localized
>>>>>>>           
>>>>>>>               
>>>>>> Routing Problem
>>>>>>         
>>>>>>             
>>>>>>> Statement below.
>>>>>>> The abstract of the PS document is as follows:
>>>>>>>
>>>>>>> Abstract:
>>>>>>>
>>>>>>>    Proxy Mobile IPv6 is the IETF standard for network-based
>>>>>>>           
>>>>>>>               
>>>>>> localized
>>>>>>         
>>>>>>             
>>>>>>>    mobility management.  In Proxy Mobile IPv6, mobile nodes are
>>>>>>>    topologically anchored at a Local Mobility Anchor, which
>>>>>>>           
>>>>>>>               
>>>>>> forwards all
>>>>>>         
>>>>>>             
>>>>>>>    data for registered mobile nodes.  The set up and support for
>>>>>>>    localized routing, which allows forwarding of data
>>>>>>>           
>>>>>>>               
>>>>>> packets between
>>>>>>         
>>>>>>             
>>>>>>>    mobile nodes and correspondent nodes directly without
>>>>>>>           
>>>>>>>               
>>>>>> traversing an
>>>>>>         
>>>>>>             
>>>>>>>    LMA, is not considered.  This document describes the
>>>>>>>           
>>>>>>>               
>>>>>> problem space of
>>>>>>         
>>>>>>             
>>>>>>>    localized routing in Proxy Mobile IPv6.
>>>>>>>
>>>>>>>
>>>>>>> Any comments to this version of the problem statement 
>>>>>>>           
>>>>>>>               
>>>> are welcome.
>>>>     
>>>>         
>>>>>>>           
>>>>>>>               
>>>> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps
>>>>     
>>>>         
>>>>>> -0
>>>>>>         
>>>>>>             
>>>>>>> 0.txt
>>>>>>>
>>>>>>> Best regards,
>>>>>>> marco
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> NetExt mailing list
>>>>>>> NetExt at mail.mobileip.jp
>>>>>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>>>>>           
>>>>>>>               
>>>>>> -- 
>>>>>>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
>>>>>>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
>>>>>>         Deployment Experiences on Vehicular networks
>>>>>>                   http://www.weedev.org/
>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>
>>>>>>         
>>>>>>             
>>>>> This email and any attachments may contain legally 
>>>>>       
>>>>>           
>>>> privileged and/or confidential information of Starent 
>>>> Networks, Corp. and is intended only for the individual or 
>>>> entity named in the message.  The information transmitted may 
>>>> not be used to create or change any contractual obligations 
>>>> of Starent Networks, Corp.  Any review, retransmission, 
>>>> dissemination or other use of, or taking of any action in 
>>>> reliance upon this e-mail and its attachments by persons or 
>>>> entities other than the intended recipient is prohibited. If 
>>>> you are not the intended recipient, please notify the sender 
>>>> immediately -- by replying to this message or by sending an 
>>>> email to postmaster at starentnetworks.com -- and destroy all 
>>>> copies of this message and any attachments without reading or 
>>>> disclosing their contents. Thank you.
>>>> -- 
>>>>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
>>>>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
>>>>         Deployment Experiences on Vehicular networks
>>>>                   http://www.weedev.org/
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>
>>>>     
>>>>         

From: liebsch at nw.neclab.eu (Marco Liebsch)
Date: Tue, 17 Feb 2009 10:31:03 +0100
Subject: [Netext] First Problem Statement about LocalizedRoutingin	PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Rajeev,

Koodli, Rajeev wrote:
> Hi Marco,
>  
>   
>> Rajeev, Carlos,
>>
>> can we conclude from the discussion so far that
>> a.) this is a reasonable and 'in-scope' use case?
>>     
>
> What is a)? If you mean a node without PMIP6 support, I would say no. 
> There is no way to distinguish nodes like that way,
correct, you cannot distinguish nodes, but you can distinguish how they
are attached to the infrastructure. And this may have impact on RO.
>  and we should be focussed on solving this for PMIP6 domain IMHO.
>   
>   
>> b.) PMIPv6 CN vs. IPv6 CN may not be transparent to a MAG and
>>   the NetExt solution for PMIPv6 RO?
>>
>>     
>
> We should look at MNs which expect network-based mobility support.
>   
Ok, thanks for your opinion.

marco

> Regards,
>
> -Rajeev
>
>
>   
>> If both is a 'yes', I propose to add this case to the RO PS.
>> If we don't see this as separate use case, we could also add 
>> simply a short paragraph that 'this case may have issues, 
>> which we must look at and take into account'.
>>
>> What do you think?
>>
>> marco
>>
>>
>>
>> Koodli, Rajeev wrote:
>>     
>>> Hi,
>>>  
>>>   
>>>       
>>>> I fully agree that the whole point of PMIP is make mobility 
>>>> management transparent to the MN. However, as far as I understand 
>>>> from my reading of RFC5213, a mobile node attached to a 
>>>>         
>> PMIPv6 domain 
>>     
>>>> might not be entitled to the network-based mobility management 
>>>> service, and RFC5213 (section 6.14) still support this node to get 
>>>> connectivity (regular
>>>> access) from the MAG.
>>>>     
>>>>         
>>> I need to look into this, but I have no idea how a MAG can 
>>>       
>> distinguish the two nodes..
>>     
>>>   
>>>       
>>>> Related to this, it is also my interpretation of RFC5213 (section
>>>> 6.10.5) that the local routing support provided by the basic spec 
>>>> (controlled with the EnableMAGLocalRouting flag) only applies to 
>>>> communications between a PMIPv6 MN and a regular
>>>> IPv6 host attached to the same MAG.
>>>>     
>>>>         
>>> This sounds even more interesting because the "regular IPv6 
>>>       
>> host" gets better performance!
>>     
>>> So, all you have to do is to declare that you are not a PMIP6 MN to 
>>> get better VoIP quality :-)
>>>
>>> Regards,
>>>
>>> -Rajeev
>>>
>>>   
>>>       
>>>> This is just to try to clarify what RFC5213 provides 
>>>>         
>> (actually, very
>>     
>>>> little) and what does not in regards to local routing 
>>>>         
>> support. Do you 
>>     
>>>> see my point?
>>>>
>>>> Thanks!
>>>>
>>>> Carlos
>>>>
>>>>     
>>>>         
>>>>>       
>>>>>           
>>>>>> 	- If my previous understanding is correct, then RFC5213
>>>>>>         
>>>>>>             
>>>> does not
>>>>     
>>>>         
>>>>>> only define any mechanism to perform local routing
>>>>>>         
>>>>>>             
>>>> between two MNs
>>>>     
>>>>         
>>>>>> connected to the same PMIPv6 domain (not even for the
>>>>>>         
>>>>>>             
>>>> case in which
>>>>     
>>>>         
>>>>>> both are attached to the same MAG).
>>>>>> Then, IMHO it would be better to change the terminology 
>>>>>>             
>> in the PS 
>>     
>>>>>> and avoid using CN or coming up with different terms for
>>>>>>         
>>>>>>             
>>>> a CN that
>>>>     
>>>>         
>>>>>> is getting network-based mobility service from a CN that is not 
>>>>>> (i.e. it is just a regular IPv6 node getting access from a MAG).
>>>>>>         
>>>>>>             
>>>>> See above.
>>>>>
>>>>>       
>>>>>           
>>>>>> 	- Currently, the PS only addresses the case of local routing 
>>>>>> between two MNs connected to the same PMIPv6 domain.
>>>>>> I think the scenario of optimising traffic between an MN and a 
>>>>>> regular IPv6 host that is locally connected to a MAG
>>>>>>         
>>>>>>             
>>>> should also be
>>>>     
>>>>         
>>>>>> addressed. Not sure the implications on the potential
>>>>>>         
>>>>>>             
>>>> solutions, but
>>>>     
>>>>         
>>>>>> it might have an impact on the classification scheme that
>>>>>>         
>>>>>>             
>>>> is used in
>>>>     
>>>>         
>>>>>> the PS now (A[number of MAGs][number of LMAs]).
>>>>>>
>>>>>>         
>>>>>>             
>>>>> Our focus should be on solving the problem for nodes
>>>>>       
>>>>>           
>>>> attached to a PMIP6 domain.
>>>>     
>>>>         
>>>>> Thanks,
>>>>>
>>>>> -Rajeev
>>>>>
>>>>>
>>>>>       
>>>>>           
>>>>>> 	Thanks,
>>>>>>
>>>>>> 	Carlos
>>>>>>
>>>>>> El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?:
>>>>>>         
>>>>>>             
>>>>>>> Hi all,
>>>>>>>
>>>>>>> please find the link to a first version of a Localized
>>>>>>>           
>>>>>>>               
>>>>>> Routing Problem
>>>>>>         
>>>>>>             
>>>>>>> Statement below.
>>>>>>> The abstract of the PS document is as follows:
>>>>>>>
>>>>>>> Abstract:
>>>>>>>
>>>>>>>    Proxy Mobile IPv6 is the IETF standard for network-based
>>>>>>>           
>>>>>>>               
>>>>>> localized
>>>>>>         
>>>>>>             
>>>>>>>    mobility management.  In Proxy Mobile IPv6, mobile nodes are
>>>>>>>    topologically anchored at a Local Mobility Anchor, which
>>>>>>>           
>>>>>>>               
>>>>>> forwards all
>>>>>>         
>>>>>>             
>>>>>>>    data for registered mobile nodes.  The set up and support for
>>>>>>>    localized routing, which allows forwarding of data
>>>>>>>           
>>>>>>>               
>>>>>> packets between
>>>>>>         
>>>>>>             
>>>>>>>    mobile nodes and correspondent nodes directly without
>>>>>>>           
>>>>>>>               
>>>>>> traversing an
>>>>>>         
>>>>>>             
>>>>>>>    LMA, is not considered.  This document describes the
>>>>>>>           
>>>>>>>               
>>>>>> problem space of
>>>>>>         
>>>>>>             
>>>>>>>    localized routing in Proxy Mobile IPv6.
>>>>>>>
>>>>>>>
>>>>>>> Any comments to this version of the problem statement
>>>>>>>           
>>>>>>>               
>>>> are welcome.
>>>>     
>>>>         
>>>>>>>           
>>>>>>>               
>> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps
>>     
>>>>     
>>>>         
>>>>>> -0
>>>>>>         
>>>>>>             
>>>>>>> 0.txt
>>>>>>>
>>>>>>> Best regards,
>>>>>>> marco
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> NetExt mailing list
>>>>>>> NetExt at mail.mobileip.jp
>>>>>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>>>>>           
>>>>>>>               
>>>>>> -- 
>>>>>>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
>>>>>>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
>>>>>>         Deployment Experiences on Vehicular networks
>>>>>>                   http://www.weedev.org/
>>>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>>>
>>>>>>         
>>>>>>             
>>>>> This email and any attachments may contain legally
>>>>>       
>>>>>           
>>>> privileged and/or confidential information of Starent 
>>>>         
>> Networks, Corp. 
>>     
>>>> and is intended only for the individual or entity named in the 
>>>> message.  The information transmitted may not be used to create or 
>>>> change any contractual obligations of Starent Networks, Corp.  Any 
>>>> review, retransmission, dissemination or other use of, or 
>>>>         
>> taking of 
>>     
>>>> any action in reliance upon this e-mail and its attachments by 
>>>> persons or entities other than the intended recipient is 
>>>>         
>> prohibited. 
>>     
>>>> If you are not the intended recipient, please notify the sender 
>>>> immediately -- by replying to this message or by sending 
>>>>         
>> an email to 
>>     
>>>> postmaster at starentnetworks.com -- and destroy all copies of this 
>>>> message and any attachments without reading or disclosing their 
>>>> contents. Thank you.
>>>> -- 
>>>>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
>>>>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
>>>>         Deployment Experiences on Vehicular networks
>>>>                   http://www.weedev.org/
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>
>>>>     
>>>>         
>>     

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Tue, 17 Feb 2009 15:51:22 +0800
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Hidetoshi,

In Multihoming PS ID, there are some handoff optimization scenarios involved.
For example optmizing the handoff of a certain interface by means of another, and achieving flow mobility via another interface during disconnection. These events are triggered due to handoff or disconnection, but the scenarios are associated with multihoming. That is being able to receive a flow that is usually destined to an interface via another "connected" interface. This is where these scenarios are different from normal handoff and more tied to multihoming. 

However, I agree that these are also tied with handoff and some confusion is there. Anyway, we are planning to revise the multihoming PS draft and are thinking of focusing on the disconnection scenario, handoff optimization as less focus scenarios and focus on scenarios that are cateogorized by Raj.

BR,
Mohana

-----Original Message-----
From: Hidetoshi Yokota [mailto:yokota at kddilabs.jp] 
Sent: Tuesday, February 17, 2009 12:42 PM
To: Mohana Jeyatharan
Cc: Domagoj Premec; ext MELIA TELEMACO; Marco Liebsch; netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
Subject: Re: [Netext] Review of the Multihoming PS I-D

Hi Mohana and all,

I think your scenario is viable, but we should probably more carefully 
clarify the difference between multihoming and handover. Assigning the 
same address to different interfaces on the MN for a sufficiently long 
time sounds like multihoming; however, if this situation holds only for 
a short period of time for MN's movement or fail over or for whatever 
reason, that sounds like handover. This difference would affect the 
behavior of the LMA and MAG(s).

In Section 2 of the Multihoming PS document, Issues related to handoff 
performance and those related to flow mobility during sudden 
disconnection appear to be categorized into handover. If all agree that 
these issues should also be included in multihoming, that's fine. I 
would just like to make sure of it first of all.

Regards,
-- 
Hidetoshi

Mohana Jeyatharan wrote:
> Hi Domagoj and All,
> 
> Yes, we too support this. For hosts that want flow mobility in PMIPv6 domain, may have to configure same address or at least be able to accept packets that are addressed to another interface.
> 
> Moreover, this is extending PMIPv6 for such hosts and it is not changing PMIPv6 in anyway. 
> 
> BR,
> Mohana
> 
> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Domagoj Premec
> Sent: Tuesday, February 17, 2009 6:45 AM
> To: 'ext MELIA TELEMACO'; 'Hidetoshi Yokota'; 'Marco Liebsch'
> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Re: [Netext] Review of the Multihoming PS I-D
> 
> Hi,
>  
> I share the opinion that having the same address assigned to different
> interfaces is a viable scenario in the context of flow mobility and I
> believe it should be included in the scope of the inter-tech work.
> 
> domagoj
> 
> 
> 
> ________________________________
> 
> 	From: netext-bounces at mail.mobileip.jp
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext MELIA TELEMACO
> 	Sent: 16. veljaca 2009 14:14
> 	To: Hidetoshi Yokota; Marco Liebsch
> 	Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> 	Subject: Re: [Netext] Review of the Multihoming PS I-D
> 	
> 	
> 
> 	Hi Hidetoshi,
> 	
> 	I took the liberty to edit your post according (I hope) to what
> Marco and I have been saying. Here it goes:
> 	
> 
> 	                            Session2_CN1
> 	                   Addr_1   Session1_CN1
> 	            IF#1                             MAG#1        CN#1
> 	                   Addr_2   Session1_CN2
> 
> 	    MN-ID                                            LMA
> 
> 	                   Addr_1
> 	            IF#2                             MAG#2         CN#2
> 	                   Addr_2   Session2_CN2
> 
> 	According to the pic the MN can a) request multiple addresses
> (depending on the service he might want to get) and b) configure the very
> same address on multiple interfaces to allow flow mobility (e.g.
> Session2_CN1 can be moved to IF#2 Addr_1). If you do not configure the same
> address I wonder how the LMA can route flows since the CN1 always send to
> the same HNP (Addr_1).
> 
> 	Marco this is your understanding as well?
> 
> 	 
> 
> 	thanks
> 
> 	telemaco
> 
> 	
> 	
> 	-----Message d'origine-----
> 	De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
> 	Envoy? : lundi 16 f?vrier 2009 13:15
> 	? : Marco Liebsch
> 	Cc : MELIA TELEMACO; netext at mail.mobileip.jp;
> Basavaraj.Patil at nokia.com
> 	Objet : Re: [Netext] Review of the Multihoming PS I-D
> 	
> 	Hi Marco, Telemaco, Raj and all,
> 	
> 	This thread is interesting and important for the start. Let me
> clarify the problem that we are trying to solve. The MN has multiple
> interfaces and multiple addresses assigned by multiple MAGs and can setup
> multiple sessions with multiple CNs (either mobile or plain IPv6 hosts)
> simultaneously. However, the MN has only one MN-ID and only one LMA (in the
> scople of the multihoming problem we are discussing now). The addresses
> assigned for the MN can be bound to any interface of the MN and the sessions
> associated with those addresses can go through any interface of the MN.
> Also, those addresses and corresponding sessions can migrate to other
> interfaces of the MN in the middle. The following diagram simply shows this
> situation:
> 	
> 	/------- MN --------\
> 	                        Session#1
> 	               Addr#1   Session#2                 CN#1
> 	        IF#1   Addr#2   Session#3   MAG#1         CN#2
> 	MN-ID   IF#2   Addr#3   ...         MAG#2   LMA   ...
> 	        ...    ...      ...         ...           ...
> 	        IF#J   ...      ...         MAG#M         CN#N
> 	               Addr#K   ...
> 	                        Session#L
> 	
> 	Is this the correct view that we are discussing now?
> 	
> 	Regards,
> 	--
> 	Hidetoshi
> 	
> 	Marco Liebsch wrote:
> 	> Hi,
> 	>
> 	> I agree that we should consider support of use cases where
> mulitple
> 	> interfaces of an MN get the same HNP assiged. One step further,
> the MN
> 	> must configure the same suffix to allow flow mobility and keep
> flow
> 	> distribution etc.
> 	> transparent
> 	> to a CN.
> 	>
> 	> Regarding Raj's comments: I fully agree that we need to specify
> the
> 	> scope of what we'll solve in NetExt and my opinion is that the
> focus
> 	> should be first on the definition of a set of target use cases, as
> too
> 	> many of them are treated under the umbrella of multihoming. Then
> let's
> 	> analyze where RFC5213 needs some more work to support them.
> 	>
> 	> Whereas I think that most of this work will be on the LMA to allow
> the
> 	> assignment of the same HNP to multiple interfaces and to support
> 	> inter-working with policy based forwarding, I do *not* think that
> 	> PMIPv6 signaling should be extended to support in-band
> configuration
> 	> of such policy routing at the LMA. Hence, we should thoroughly
> define
> 	> the scope of the solution space before.
> 	>
> 	> marco
> 	>
> 	>
> 	>
> 	> MELIA TELEMACO schrieb:
> 	>> Hello,
> 	>>
> 	>> In principle I am fine with the 4 points Raj proposed. In
> addition, I
> 	>> would stress scenarios where the same HNP (and same IP address)
> is
> 	>> configured across several interfaces. I believe these scenarios
> are
> 	>> very useful for flow mobility and flow distributions.
> 	>> Comments?
> 	>>
> 	>> telemaco
> 	>> -----Message d'origine-----
> 	>> De : netext-bounces at mail.mobileip.jp
> 	>> [mailto:netext-bounces at mail.mobileip.jp] De la part de
> 	>> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009
> 15:56 A`
> 	>> : netext at mail.mobileip.jp Cc : Basavaraj.Patil at nokia.com Objet :
> 	>> [Netext] Review of the Multihoming PS I-D
> 	>>
> 	>>
> 	>> Hello,
> 	>>
> 	>> I have reviewed the Netext Multihoming PS I-D
> 	>> <draft-jeyatharan-netext-multihoming-ps-00>. Thanks to Mohana for
> her
> 	>> efforts on getting this I-D ready.
> 	>>
> 	>> 1. My impression after reading the I-D is that it misses the key
> 	>>    problem of multihoming that we are trying to work on. Proxy
> MIP6 as
> 	>>    currently specified in RFC5213 has limited support for
> 	>>    multihoming. It was decided that multihoming should be dealt
> with
> 	>>    separately in Netlmm during the course discussions on this
> topic in
> 	>>    the past. While many of the issues mentioned in the I-D are
> 	>>    relevant I believe that Netext should be working on a more
> narrow
> 	>>    scope to enhance PMIP6 to support a few multihoming scenarios.
> 	>>
> 	>> 2. Sec 3 of the I-D which analyses multihoming issues in the case
> of
> 	>>    PMIP6/CMIP6 coexisting together is really misplaced here. I do
> not
> 	>>    believe we want to address this topic as part of the
> multihoming
> 	>>    work in Netext. This is simply out of scope.
> 	>>
> 	>> 3. The I-D focuses on the problem of multiplexing flows or having
> 	>>    flows traverse via one interface or another or the ability to
> move
> 	>>    a flow from one interface to another. While these are all
> valid
> 	>>    things to do in PMIP6, I am not convinced that these are
> 	>>    specifically related to multihoming.
> 	>>
> 	>> Rajeev and I had a discussion on the scope of multihoming and
> what we
> 	>> should really be focusing on. We came up with the following
> specific
> 	>> scenarios which we should address:
> 	>>
> 	>> a. The multihoming work in Netext should address the limitations
> of
> 	>> RFC5213
> 	>>    w.r.t multihoming. The issue of having a single BCE for an MN
> 	>>    identified by an MN-ID and attaching via multiple interfaces
> should
> 	>>    be resolved.
> 	>>
> 	>> b. The scenario where an MN is connected via a MAG to an LMA and
> the
> 	>>    ability to establish multiple sessions via the same MAG. This
> is
> 	>>    the case where the MN is attached via a specific access type
> and
> 	>>    establishes multiple IP sessions via the MAG.
> 	>>
> 	>> c. The scenario where an MN attaches via different interfaces
> which
> 	>>    are of differing access technologies via MAG1 and MAG2
> 	>>    simultaneously. The MAG1/MAG2 entities are attached to the
> same
> 	>>    LMA.
> 	>>
> 	>> d. A combination of the scenarios in (b) and (c), i.e having
> multiple
> 	>>    sessions via each access type while connected thru different
> MAGs
> 	>>    simultaneously.
> 	>>
> 	>> Lets see if we can build some consensus around the scope of the
> problem.
> 	>>
> 	>> -Raj
> 	>>
> 	>> _______________________________________________
> 	>> NetExt mailing list
> 	>> NetExt at mail.mobileip.jp
> 	>> http://www.mobileip.jp/mailman/listinfo/netext
> 	>>
> 	>> _______________________________________________
> 	>> NetExt mailing list
> 	>> NetExt at mail.mobileip.jp
> 	>> http://www.mobileip.jp/mailman/listinfo/netext
> 	>>  
> 	>
> 	>
> 	> _______________________________________________
> 	> NetExt mailing list
> 	> NetExt at mail.mobileip.jp
> 	> http://www.mobileip.jp/mailman/listinfo/netext
> 	>
> 	>
> 	>
> 	
> 	
> 
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 
> 
> 

From: yokota at kddilabs.jp (Hidetoshi Yokota)
Date: Tue, 17 Feb 2009 13:59:07 +0900
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]>	<[email-masked]> <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Marco,

My answer to your last comment was a bit off the mark. Regarding the
mesh-relationship between the interfaces and the assigned addresses,
this could happen as an extreme case if the same address can be assigned
to multiple interfaces and one interface can have multiple addresses
simultaneously. If you think this is too complex and impractical, we
should narrow down the scope. Do you have any condition to add to avoid
the mesh-relationship?

Regards,
-- 
Hidetoshi

Hidetoshi Yokota wrote:
> Hi Marco,
> 
> Marco Liebsch wrote:
>> Hi Hidetoshi,
>>
>> please find my comments in-line.
>>
>> Hidetoshi Yokota wrote:
>>> Hi Marco, Telemaco, Raj and all,
>>>
>>> This thread is interesting and important for the start. Let me clarify
>>> the problem that we are trying to solve. The MN has multiple interfaces
>>> and multiple addresses assigned by multiple MAGs and can setup multiple
>>> sessions with multiple CNs (either mobile or plain IPv6 hosts)
>>> simultaneously. However, the MN has only one MN-ID and only one LMA (in
>>> the scople of the multihoming problem we are discussing now).
>> So far I am ok.
>>>  The
>>> addresses assigned for the MN can be bound to any interface of the MN
>>> and the sessions associated with those addresses can go through any
>>> interface of the MN.
>> Well, here we should stick to the PMIP concept be clear: An MN's
>> interface cannot simply use any address, but should use the HNP,
>> which has been assigned to the interface during its registration.
>> And this is under control of the LMA (or the AAA behind). So, in
>> my opinion, an MN can use an HNP for an interface only if the
>> HNP has been assigned to this interface during the registration.
>> Maybe that's what you mean.
> 
> Yes, I meant that the MN should use the HNPs under the control of the
> LMA, but those HNPs, or I should say the whole addresses configured by
> those HNPs are not tightly bound to the interfaces or MAGs that are used
> at the initial attach. I think this is what we are talking about now.
> 
>>>  Also, those addresses and corresponding sessions
>>> can migrate to other interfaces of the MN in the middle. The following
>>> diagram simply shows this situation:
>>>   
>> Maybe I read the diagram in the wrong way, but there should not be
>> a 'mesh'-like relationship between all addresses (1-K) and all IFs (1-J).
> 
> Right. I think that a session is identified by one of the MN addresses
> and one of the CN addresses (more precisely, by 5-tuples, but simplified
> for now), so mesh-like relationship will not happen.
> 
> I should emphasize here that this is for the clarification of the
> problem. More discussion will be needed to decide how further the scope
> of the multihoming problem should cover.
> 
> Regards,

From: yokota at kddilabs.jp (Hidetoshi Yokota)
Date: Tue, 17 Feb 2009 13:41:52 +0900
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Mohana and all,

I think your scenario is viable, but we should probably more carefully 
clarify the difference between multihoming and handover. Assigning the 
same address to different interfaces on the MN for a sufficiently long 
time sounds like multihoming; however, if this situation holds only for 
a short period of time for MN's movement or fail over or for whatever 
reason, that sounds like handover. This difference would affect the 
behavior of the LMA and MAG(s).

In Section 2 of the Multihoming PS document, Issues related to handoff 
performance and those related to flow mobility during sudden 
disconnection appear to be categorized into handover. If all agree that 
these issues should also be included in multihoming, that's fine. I 
would just like to make sure of it first of all.

Regards,
-- 
Hidetoshi

Mohana Jeyatharan wrote:
> Hi Domagoj and All,
> 
> Yes, we too support this. For hosts that want flow mobility in PMIPv6 domain, may have to configure same address or at least be able to accept packets that are addressed to another interface.
> 
> Moreover, this is extending PMIPv6 for such hosts and it is not changing PMIPv6 in anyway. 
> 
> BR,
> Mohana
> 
> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Domagoj Premec
> Sent: Tuesday, February 17, 2009 6:45 AM
> To: 'ext MELIA TELEMACO'; 'Hidetoshi Yokota'; 'Marco Liebsch'
> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Re: [Netext] Review of the Multihoming PS I-D
> 
> Hi,
>  
> I share the opinion that having the same address assigned to different
> interfaces is a viable scenario in the context of flow mobility and I
> believe it should be included in the scope of the inter-tech work.
> 
> domagoj
> 
> 
> 
> ________________________________
> 
> 	From: netext-bounces at mail.mobileip.jp
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext MELIA TELEMACO
> 	Sent: 16. veljaca 2009 14:14
> 	To: Hidetoshi Yokota; Marco Liebsch
> 	Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> 	Subject: Re: [Netext] Review of the Multihoming PS I-D
> 	
> 	
> 
> 	Hi Hidetoshi,
> 	
> 	I took the liberty to edit your post according (I hope) to what
> Marco and I have been saying. Here it goes:
> 	
> 
> 	                            Session2_CN1
> 	                   Addr_1   Session1_CN1
> 	            IF#1                             MAG#1        CN#1
> 	                   Addr_2   Session1_CN2
> 
> 	    MN-ID                                            LMA
> 
> 	                   Addr_1
> 	            IF#2                             MAG#2         CN#2
> 	                   Addr_2   Session2_CN2
> 
> 	According to the pic the MN can a) request multiple addresses
> (depending on the service he might want to get) and b) configure the very
> same address on multiple interfaces to allow flow mobility (e.g.
> Session2_CN1 can be moved to IF#2 Addr_1). If you do not configure the same
> address I wonder how the LMA can route flows since the CN1 always send to
> the same HNP (Addr_1).
> 
> 	Marco this is your understanding as well?
> 
> 	 
> 
> 	thanks
> 
> 	telemaco
> 
> 	
> 	
> 	-----Message d'origine-----
> 	De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
> 	Envoy? : lundi 16 f?vrier 2009 13:15
> 	? : Marco Liebsch
> 	Cc : MELIA TELEMACO; netext at mail.mobileip.jp;
> Basavaraj.Patil at nokia.com
> 	Objet : Re: [Netext] Review of the Multihoming PS I-D
> 	
> 	Hi Marco, Telemaco, Raj and all,
> 	
> 	This thread is interesting and important for the start. Let me
> clarify the problem that we are trying to solve. The MN has multiple
> interfaces and multiple addresses assigned by multiple MAGs and can setup
> multiple sessions with multiple CNs (either mobile or plain IPv6 hosts)
> simultaneously. However, the MN has only one MN-ID and only one LMA (in the
> scople of the multihoming problem we are discussing now). The addresses
> assigned for the MN can be bound to any interface of the MN and the sessions
> associated with those addresses can go through any interface of the MN.
> Also, those addresses and corresponding sessions can migrate to other
> interfaces of the MN in the middle. The following diagram simply shows this
> situation:
> 	
> 	/------- MN --------\
> 	                        Session#1
> 	               Addr#1   Session#2                 CN#1
> 	        IF#1   Addr#2   Session#3   MAG#1         CN#2
> 	MN-ID   IF#2   Addr#3   ...         MAG#2   LMA   ...
> 	        ...    ...      ...         ...           ...
> 	        IF#J   ...      ...         MAG#M         CN#N
> 	               Addr#K   ...
> 	                        Session#L
> 	
> 	Is this the correct view that we are discussing now?
> 	
> 	Regards,
> 	--
> 	Hidetoshi
> 	
> 	Marco Liebsch wrote:
> 	> Hi,
> 	>
> 	> I agree that we should consider support of use cases where
> mulitple
> 	> interfaces of an MN get the same HNP assiged. One step further,
> the MN
> 	> must configure the same suffix to allow flow mobility and keep
> flow
> 	> distribution etc.
> 	> transparent
> 	> to a CN.
> 	>
> 	> Regarding Raj's comments: I fully agree that we need to specify
> the
> 	> scope of what we'll solve in NetExt and my opinion is that the
> focus
> 	> should be first on the definition of a set of target use cases, as
> too
> 	> many of them are treated under the umbrella of multihoming. Then
> let's
> 	> analyze where RFC5213 needs some more work to support them.
> 	>
> 	> Whereas I think that most of this work will be on the LMA to allow
> the
> 	> assignment of the same HNP to multiple interfaces and to support
> 	> inter-working with policy based forwarding, I do *not* think that
> 	> PMIPv6 signaling should be extended to support in-band
> configuration
> 	> of such policy routing at the LMA. Hence, we should thoroughly
> define
> 	> the scope of the solution space before.
> 	>
> 	> marco
> 	>
> 	>
> 	>
> 	> MELIA TELEMACO schrieb:
> 	>> Hello,
> 	>>
> 	>> In principle I am fine with the 4 points Raj proposed. In
> addition, I
> 	>> would stress scenarios where the same HNP (and same IP address)
> is
> 	>> configured across several interfaces. I believe these scenarios
> are
> 	>> very useful for flow mobility and flow distributions.
> 	>> Comments?
> 	>>
> 	>> telemaco
> 	>> -----Message d'origine-----
> 	>> De : netext-bounces at mail.mobileip.jp
> 	>> [mailto:netext-bounces at mail.mobileip.jp] De la part de
> 	>> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009
> 15:56 A`
> 	>> : netext at mail.mobileip.jp Cc : Basavaraj.Patil at nokia.com Objet :
> 	>> [Netext] Review of the Multihoming PS I-D
> 	>>
> 	>>
> 	>> Hello,
> 	>>
> 	>> I have reviewed the Netext Multihoming PS I-D
> 	>> <draft-jeyatharan-netext-multihoming-ps-00>. Thanks to Mohana for
> her
> 	>> efforts on getting this I-D ready.
> 	>>
> 	>> 1. My impression after reading the I-D is that it misses the key
> 	>>    problem of multihoming that we are trying to work on. Proxy
> MIP6 as
> 	>>    currently specified in RFC5213 has limited support for
> 	>>    multihoming. It was decided that multihoming should be dealt
> with
> 	>>    separately in Netlmm during the course discussions on this
> topic in
> 	>>    the past. While many of the issues mentioned in the I-D are
> 	>>    relevant I believe that Netext should be working on a more
> narrow
> 	>>    scope to enhance PMIP6 to support a few multihoming scenarios.
> 	>>
> 	>> 2. Sec 3 of the I-D which analyses multihoming issues in the case
> of
> 	>>    PMIP6/CMIP6 coexisting together is really misplaced here. I do
> not
> 	>>    believe we want to address this topic as part of the
> multihoming
> 	>>    work in Netext. This is simply out of scope.
> 	>>
> 	>> 3. The I-D focuses on the problem of multiplexing flows or having
> 	>>    flows traverse via one interface or another or the ability to
> move
> 	>>    a flow from one interface to another. While these are all
> valid
> 	>>    things to do in PMIP6, I am not convinced that these are
> 	>>    specifically related to multihoming.
> 	>>
> 	>> Rajeev and I had a discussion on the scope of multihoming and
> what we
> 	>> should really be focusing on. We came up with the following
> specific
> 	>> scenarios which we should address:
> 	>>
> 	>> a. The multihoming work in Netext should address the limitations
> of
> 	>> RFC5213
> 	>>    w.r.t multihoming. The issue of having a single BCE for an MN
> 	>>    identified by an MN-ID and attaching via multiple interfaces
> should
> 	>>    be resolved.
> 	>>
> 	>> b. The scenario where an MN is connected via a MAG to an LMA and
> the
> 	>>    ability to establish multiple sessions via the same MAG. This
> is
> 	>>    the case where the MN is attached via a specific access type
> and
> 	>>    establishes multiple IP sessions via the MAG.
> 	>>
> 	>> c. The scenario where an MN attaches via different interfaces
> which
> 	>>    are of differing access technologies via MAG1 and MAG2
> 	>>    simultaneously. The MAG1/MAG2 entities are attached to the
> same
> 	>>    LMA.
> 	>>
> 	>> d. A combination of the scenarios in (b) and (c), i.e having
> multiple
> 	>>    sessions via each access type while connected thru different
> MAGs
> 	>>    simultaneously.
> 	>>
> 	>> Lets see if we can build some consensus around the scope of the
> problem.
> 	>>
> 	>> -Raj
> 	>>
> 	>> _______________________________________________
> 	>> NetExt mailing list
> 	>> NetExt at mail.mobileip.jp
> 	>> http://www.mobileip.jp/mailman/listinfo/netext
> 	>>
> 	>> _______________________________________________
> 	>> NetExt mailing list
> 	>> NetExt at mail.mobileip.jp
> 	>> http://www.mobileip.jp/mailman/listinfo/netext
> 	>>  
> 	>
> 	>
> 	> _______________________________________________
> 	> NetExt mailing list
> 	> NetExt at mail.mobileip.jp
> 	> http://www.mobileip.jp/mailman/listinfo/netext
> 	>
> 	>
> 	>
> 	
> 	
> 
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 
> 
> 

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Tue, 17 Feb 2009 10:59:57 +0800
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Domagoj and All,

Yes, we too support this. For hosts that want flow mobility in PMIPv6 domain, may have to configure same address or at least be able to accept packets that are addressed to another interface.

Moreover, this is extending PMIPv6 for such hosts and it is not changing PMIPv6 in anyway. 

BR,
Mohana

-----Original Message-----
From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Domagoj Premec
Sent: Tuesday, February 17, 2009 6:45 AM
To: 'ext MELIA TELEMACO'; 'Hidetoshi Yokota'; 'Marco Liebsch'
Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
Subject: Re: [Netext] Review of the Multihoming PS I-D

Hi,
 
I share the opinion that having the same address assigned to different
interfaces is a viable scenario in the context of flow mobility and I
believe it should be included in the scope of the inter-tech work.

domagoj

________________________________

	From: netext-bounces at mail.mobileip.jp
[mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext MELIA TELEMACO
	Sent: 16. veljaca 2009 14:14
	To: Hidetoshi Yokota; Marco Liebsch
	Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
	Subject: Re: [Netext] Review of the Multihoming PS I-D

	Hi Hidetoshi,
	
	I took the liberty to edit your post according (I hope) to what
Marco and I have been saying. Here it goes:

	                            Session2_CN1
	                   Addr_1   Session1_CN1
	            IF#1                             MAG#1        CN#1
	                   Addr_2   Session1_CN2

	    MN-ID                                            LMA

	                   Addr_1
	            IF#2                             MAG#2         CN#2
	                   Addr_2   Session2_CN2

	According to the pic the MN can a) request multiple addresses
(depending on the service he might want to get) and b) configure the very
same address on multiple interfaces to allow flow mobility (e.g.
Session2_CN1 can be moved to IF#2 Addr_1). If you do not configure the same
address I wonder how the LMA can route flows since the CN1 always send to
the same HNP (Addr_1).

	Marco this is your understanding as well?

	thanks

	telemaco

	
	-----Message d'origine-----
	De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
	Envoy? : lundi 16 f?vrier 2009 13:15
	? : Marco Liebsch
	Cc : MELIA TELEMACO; netext at mail.mobileip.jp;
Basavaraj.Patil at nokia.com
	Objet : Re: [Netext] Review of the Multihoming PS I-D
	
	Hi Marco, Telemaco, Raj and all,
	
	This thread is interesting and important for the start. Let me
clarify the problem that we are trying to solve. The MN has multiple
interfaces and multiple addresses assigned by multiple MAGs and can setup
multiple sessions with multiple CNs (either mobile or plain IPv6 hosts)
simultaneously. However, the MN has only one MN-ID and only one LMA (in the
scople of the multihoming problem we are discussing now). The addresses
assigned for the MN can be bound to any interface of the MN and the sessions
associated with those addresses can go through any interface of the MN.
Also, those addresses and corresponding sessions can migrate to other
interfaces of the MN in the middle. The following diagram simply shows this
situation:
	
	/------- MN --------\
	                        Session#1
	               Addr#1   Session#2                 CN#1
	        IF#1   Addr#2   Session#3   MAG#1         CN#2
	MN-ID   IF#2   Addr#3   ...         MAG#2   LMA   ...
	        ...    ...      ...         ...           ...
	        IF#J   ...      ...         MAG#M         CN#N
	               Addr#K   ...
	                        Session#L
	
	Is this the correct view that we are discussing now?
	
	Regards,
	--
	Hidetoshi
	
	Marco Liebsch wrote:
	> Hi,
	>
	> I agree that we should consider support of use cases where
mulitple
	> interfaces of an MN get the same HNP assiged. One step further,
the MN
	> must configure the same suffix to allow flow mobility and keep
flow
	> distribution etc.
	> transparent
	> to a CN.
	>
	> Regarding Raj's comments: I fully agree that we need to specify
the
	> scope of what we'll solve in NetExt and my opinion is that the
focus
	> should be first on the definition of a set of target use cases, as
too
	> many of them are treated under the umbrella of multihoming. Then
let's
	> analyze where RFC5213 needs some more work to support them.
	>
	> Whereas I think that most of this work will be on the LMA to allow
the
	> assignment of the same HNP to multiple interfaces and to support
	> inter-working with policy based forwarding, I do *not* think that
	> PMIPv6 signaling should be extended to support in-band
configuration
	> of such policy routing at the LMA. Hence, we should thoroughly
define
	> the scope of the solution space before.
	>
	> marco
	>
	>
	>
	> MELIA TELEMACO schrieb:
	>> Hello,
	>>
	>> In principle I am fine with the 4 points Raj proposed. In
addition, I
	>> would stress scenarios where the same HNP (and same IP address)
is
	>> configured across several interfaces. I believe these scenarios
are
	>> very useful for flow mobility and flow distributions.
	>> Comments?
	>>
	>> telemaco
	>> -----Message d'origine-----
	>> De : netext-bounces at mail.mobileip.jp
	>> [mailto:netext-bounces at mail.mobileip.jp] De la part de
	>> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009
15:56 A`
	>> : netext at mail.mobileip.jp Cc : Basavaraj.Patil at nokia.com Objet :
	>> [Netext] Review of the Multihoming PS I-D
	>>
	>>
	>> Hello,
	>>
	>> I have reviewed the Netext Multihoming PS I-D
	>> <draft-jeyatharan-netext-multihoming-ps-00>. Thanks to Mohana for
her
	>> efforts on getting this I-D ready.
	>>
	>> 1. My impression after reading the I-D is that it misses the key
	>>    problem of multihoming that we are trying to work on. Proxy
MIP6 as
	>>    currently specified in RFC5213 has limited support for
	>>    multihoming. It was decided that multihoming should be dealt
with
	>>    separately in Netlmm during the course discussions on this
topic in
	>>    the past. While many of the issues mentioned in the I-D are
	>>    relevant I believe that Netext should be working on a more
narrow
	>>    scope to enhance PMIP6 to support a few multihoming scenarios.
	>>
	>> 2. Sec 3 of the I-D which analyses multihoming issues in the case
of
	>>    PMIP6/CMIP6 coexisting together is really misplaced here. I do
not
	>>    believe we want to address this topic as part of the
multihoming
	>>    work in Netext. This is simply out of scope.
	>>
	>> 3. The I-D focuses on the problem of multiplexing flows or having
	>>    flows traverse via one interface or another or the ability to
move
	>>    a flow from one interface to another. While these are all
valid
	>>    things to do in PMIP6, I am not convinced that these are
	>>    specifically related to multihoming.
	>>
	>> Rajeev and I had a discussion on the scope of multihoming and
what we
	>> should really be focusing on. We came up with the following
specific
	>> scenarios which we should address:
	>>
	>> a. The multihoming work in Netext should address the limitations
of
	>> RFC5213
	>>    w.r.t multihoming. The issue of having a single BCE for an MN
	>>    identified by an MN-ID and attaching via multiple interfaces
should
	>>    be resolved.
	>>
	>> b. The scenario where an MN is connected via a MAG to an LMA and
the
	>>    ability to establish multiple sessions via the same MAG. This
is
	>>    the case where the MN is attached via a specific access type
and
	>>    establishes multiple IP sessions via the MAG.
	>>
	>> c. The scenario where an MN attaches via different interfaces
which
	>>    are of differing access technologies via MAG1 and MAG2
	>>    simultaneously. The MAG1/MAG2 entities are attached to the
same
	>>    LMA.
	>>
	>> d. A combination of the scenarios in (b) and (c), i.e having
multiple
	>>    sessions via each access type while connected thru different
MAGs
	>>    simultaneously.
	>>
	>> Lets see if we can build some consensus around the scope of the
problem.
	>>
	>> -Raj
	>>
	>> _______________________________________________
	>> NetExt mailing list
	>> NetExt at mail.mobileip.jp
	>> http://www.mobileip.jp/mailman/listinfo/netext
	>>
	>> _______________________________________________
	>> NetExt mailing list
	>> NetExt at mail.mobileip.jp
	>> http://www.mobileip.jp/mailman/listinfo/netext
	>>  
	>
	>
	> _______________________________________________
	> NetExt mailing list
	> NetExt at mail.mobileip.jp
	> http://www.mobileip.jp/mailman/listinfo/netext
	>
	>
	>

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

From: yokota at kddilabs.jp (Hidetoshi Yokota)
Date: Tue, 17 Feb 2009 11:55:04 +0900
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Marco,

Marco Liebsch wrote:
> Hi Hidetoshi,
> 
> please find my comments in-line.
> 
> Hidetoshi Yokota wrote:
>> Hi Marco, Telemaco, Raj and all,
>>
>> This thread is interesting and important for the start. Let me clarify
>> the problem that we are trying to solve. The MN has multiple interfaces
>> and multiple addresses assigned by multiple MAGs and can setup multiple
>> sessions with multiple CNs (either mobile or plain IPv6 hosts)
>> simultaneously. However, the MN has only one MN-ID and only one LMA (in
>> the scople of the multihoming problem we are discussing now).
> So far I am ok.
>>  The
>> addresses assigned for the MN can be bound to any interface of the MN
>> and the sessions associated with those addresses can go through any
>> interface of the MN.
> Well, here we should stick to the PMIP concept be clear: An MN's
> interface cannot simply use any address, but should use the HNP,
> which has been assigned to the interface during its registration.
> And this is under control of the LMA (or the AAA behind). So, in
> my opinion, an MN can use an HNP for an interface only if the
> HNP has been assigned to this interface during the registration.
> Maybe that's what you mean.

Yes, I meant that the MN should use the HNPs under the control of the
LMA, but those HNPs, or I should say the whole addresses configured by
those HNPs are not tightly bound to the interfaces or MAGs that are used
at the initial attach. I think this is what we are talking about now.

>>  Also, those addresses and corresponding sessions
>> can migrate to other interfaces of the MN in the middle. The following
>> diagram simply shows this situation:
>>   
> Maybe I read the diagram in the wrong way, but there should not be
> a 'mesh'-like relationship between all addresses (1-K) and all IFs (1-J).

Right. I think that a session is identified by one of the MN addresses
and one of the CN addresses (more precisely, by 5-tuples, but simplified
for now), so mesh-like relationship will not happen.

I should emphasize here that this is for the clarification of the
problem. More discussion will be needed to decide how further the scope
of the multihoming problem should cover.

Regards,
-- 
Hidetoshi

> marco
> 
>> /------- MN --------\
>>                         Session#1
>>                Addr#1   Session#2                 CN#1
>>         IF#1   Addr#2   Session#3   MAG#1         CN#2
>> MN-ID   IF#2   Addr#3   ...         MAG#2   LMA   ...
>>         ...    ...      ...         ...           ...
>>         IF#J   ...      ...         MAG#M         CN#N
>>                Addr#K   ...
>>                         Session#L
>>
>> Is this the correct view that we are discussing now?
>>
>> Regards,
>>   
> 
> 
> 
> 

From: xiayangsong at huawei.com (Frank Xia)
Date: Mon, 16 Feb 2009 19:54:42 -0600
Subject: [Netext] Review of the Multihoming PS I-D
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Domagoj

I am fine with the motivation of the Netext.
However, I still think RFC5213 is the baseline for our work.

Conceptually, it looks strange to me when a host with
two different interfaces sharing one IP address.
It is a challenge for an application to select a proper
interface when sending a packet because IP address
is not tied to one special interface.

You will be appreciated  if  you can give me some current
practices to justify your opinion, e.g RFC, OS

BR
Frank

----- Original Message ----- 
From: "Domagoj Premec" <domagoj.premec.ext at nsn.com>
To: "'ext Frank Xia'" <xiayangsong at huawei.com>; "'ext MELIA TELEMACO'" 
<Telemaco.Melia at alcatel-lucent.com>; "'Hidetoshi Yokota'" 
<yokota at kddilabs.jp>; "'Marco Liebsch'" <marco.liebsch at nw.neclab.eu>
Cc: <netext at mail.mobileip.jp>; <Basavaraj.Patil at nokia.com>
Sent: Monday, February 16, 2009 5:18 PM
Subject: RE: [Netext] Review of the Multihoming PS I-D

Hi Frank,

Well... the netext is about extending the baseline PMIP6 functionality and
hence I don't see the RFC 5213 as a limiting factor when considering the
scenarios that can be addressed in the netext.

domagoj

> -----Original Message-----
> From: ext Frank Xia [mailto:xiayangsong at huawei.com]
> Sent: 17. veljaca 2009 00:06
> To: Domagoj Premec; 'ext MELIA TELEMACO'; 'Hidetoshi Yokota';
> 'Marco Liebsch'
> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Re: [Netext] Review of the Multihoming PS I-D
>
> Hi Domagoj
>
> I don't think so.
>
> Please check RFC5213
> "If the mobile node connects to the Proxy Mobile IPv6 domain through
>    multiple interfaces and over multiple access networks, the network
>    will allocate a unique set of home network prefixes for each of the
>    connected interfaces"
>
> BR
> Frank
>
>
> ----- Original Message -----
> From: "Domagoj Premec" <domagoj.premec.ext at nsn.com>
> To: "'ext MELIA TELEMACO'"
> <Telemaco.Melia at alcatel-lucent.com>; "'Hidetoshi Yokota'"
> <yokota at kddilabs.jp>; "'Marco Liebsch'"
> <marco.liebsch at nw.neclab.eu>
> Cc: <netext at mail.mobileip.jp>; <Basavaraj.Patil at nokia.com>
> Sent: Monday, February 16, 2009 4:45 PM
> Subject: Re: [Netext] Review of the Multihoming PS I-D
>
>
> Hi,
>
> I share the opinion that having the same address assigned to
> different interfaces is a viable scenario in the context of
> flow mobility and I believe it should be included in the
> scope of the inter-tech work.
>
> domagoj
>
>
>
> ________________________________
>
> From: netext-bounces at mail.mobileip.jp
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext
> MELIA TELEMACO
> Sent: 16. veljaca 2009 14:14
> To: Hidetoshi Yokota; Marco Liebsch
> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Re: [Netext] Review of the Multihoming PS I-D
>
>
>
> Hi Hidetoshi,
>
> I took the liberty to edit your post according (I hope) to
> what Marco and I have been saying. Here it goes:
>
>
>                             Session2_CN1
>                    Addr_1   Session1_CN1
>             IF#1                             MAG#1        CN#1
>                    Addr_2   Session1_CN2
>
>     MN-ID                                            LMA
>
>                    Addr_1
>             IF#2                             MAG#2         CN#2
>                    Addr_2   Session2_CN2
>
> According to the pic the MN can a) request multiple addresses
> (depending on the service he might want to get) and b)
> configure the very same address on multiple interfaces to
> allow flow mobility (e.g.
> Session2_CN1 can be moved to IF#2 Addr_1). If you do not
> configure the same address I wonder how the LMA can route
> flows since the CN1 always send to the same HNP (Addr_1).
>
> Marco this is your understanding as well?
>
>
>
> thanks
>
> telemaco
>
>
>
> -----Message d'origine-----
> De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp] Envoy? :
> lundi 16 f?vrier 2009 13:15 ? : Marco Liebsch Cc : MELIA
> TELEMACO; netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Objet : Re: [Netext] Review of the Multihoming PS I-D
>
> Hi Marco, Telemaco, Raj and all,
>
> This thread is interesting and important for the start. Let
> me clarify the problem that we are trying to solve. The MN
> has multiple interfaces and multiple addresses assigned by
> multiple MAGs and can setup multiple sessions with multiple
> CNs (either mobile or plain IPv6 hosts) simultaneously.
> However, the MN has only one MN-ID and only one LMA (in the
> scople of the multihoming problem we are discussing now). The
> addresses assigned for the MN can be bound to any interface
> of the MN and the sessions associated with those addresses
> can go through any interface of the MN.
> Also, those addresses and corresponding sessions can migrate
> to other interfaces of the MN in the middle. The following
> diagram simply shows this
> situation:
>
> /------- MN --------\
>                         Session#1
>                Addr#1   Session#2                 CN#1
>         IF#1   Addr#2   Session#3   MAG#1         CN#2
> MN-ID   IF#2   Addr#3   ...         MAG#2   LMA   ...
>         ...    ...      ...         ...           ...
>         IF#J   ...      ...         MAG#M         CN#N
>                Addr#K   ...
>                         Session#L
>
> Is this the correct view that we are discussing now?
>
> Regards,
> --
> Hidetoshi
>
> Marco Liebsch wrote:
> > Hi,
> >
> > I agree that we should consider support of use cases where
> mulitple
> > interfaces of an MN get the same HNP assiged. One step further,
> the MN
> > must configure the same suffix to allow flow mobility and keep
> flow
> > distribution etc.
> > transparent
> > to a CN.
> >
> > Regarding Raj's comments: I fully agree that we need to specify
> the
> > scope of what we'll solve in NetExt and my opinion is that the
> focus
> > should be first on the definition of a set of target use cases, as
> too
> > many of them are treated under the umbrella of multihoming. Then
> let's
> > analyze where RFC5213 needs some more work to support them.
> >
> > Whereas I think that most of this work will be on the LMA to allow
> the
> > assignment of the same HNP to multiple interfaces and to support
> > inter-working with policy based forwarding, I do *not* think that
> > PMIPv6 signaling should be extended to support in-band
> configuration
> > of such policy routing at the LMA. Hence, we should thoroughly
> define
> > the scope of the solution space before.
> >
> > marco
> >
> >
> >
> > MELIA TELEMACO schrieb:
> >> Hello,
> >>
> >> In principle I am fine with the 4 points Raj proposed. In
> addition, I
> >> would stress scenarios where the same HNP (and same IP address)
> is
> >> configured across several interfaces. I believe these scenarios
> are
> >> very useful for flow mobility and flow distributions.
> >> Comments?
> >>
> >> telemaco
> >> -----Message d'origine-----
> >> De : netext-bounces at mail.mobileip.jp
> >> [mailto:netext-bounces at mail.mobileip.jp] De la part de
> >> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009
> 15:56 A`
> >> : netext at mail.mobileip.jp Cc : Basavaraj.Patil at nokia.com Objet :
> >> [Netext] Review of the Multihoming PS I-D
> >>
> >>
> >> Hello,
> >>
> >> I have reviewed the Netext Multihoming PS I-D
> >> <draft-jeyatharan-netext-multihoming-ps-00>. Thanks to Mohana for
> her
> >> efforts on getting this I-D ready.
> >>
> >> 1. My impression after reading the I-D is that it misses the key
> >>    problem of multihoming that we are trying to work on. Proxy
> MIP6 as
> >>    currently specified in RFC5213 has limited support for
> >>    multihoming. It was decided that multihoming should be dealt
> with
> >>    separately in Netlmm during the course discussions on this
> topic in
> >>    the past. While many of the issues mentioned in the I-D are
> >>    relevant I believe that Netext should be working on a more
> narrow
> >>    scope to enhance PMIP6 to support a few multihoming scenarios.
> >>
> >> 2. Sec 3 of the I-D which analyses multihoming issues in the case
> of
> >>    PMIP6/CMIP6 coexisting together is really misplaced here. I do
> not
> >>    believe we want to address this topic as part of the
> multihoming
> >>    work in Netext. This is simply out of scope.
> >>
> >> 3. The I-D focuses on the problem of multiplexing flows or having
> >>    flows traverse via one interface or another or the ability to
> move
> >>    a flow from one interface to another. While these are all
> valid
> >>    things to do in PMIP6, I am not convinced that these are
> >>    specifically related to multihoming.
> >>
> >> Rajeev and I had a discussion on the scope of multihoming and
> what we
> >> should really be focusing on. We came up with the following
> specific
> >> scenarios which we should address:
> >>
> >> a. The multihoming work in Netext should address the limitations
> of
> >> RFC5213
> >>    w.r.t multihoming. The issue of having a single BCE for an MN
> >>    identified by an MN-ID and attaching via multiple interfaces
> should
> >>    be resolved.
> >>
> >> b. The scenario where an MN is connected via a MAG to an LMA and
> the
> >>    ability to establish multiple sessions via the same MAG. This
> is
> >>    the case where the MN is attached via a specific access type
> and
> >>    establishes multiple IP sessions via the MAG.
> >>
> >> c. The scenario where an MN attaches via different interfaces
> which
> >>    are of differing access technologies via MAG1 and MAG2
> >>    simultaneously. The MAG1/MAG2 entities are attached to the
> same
> >>    LMA.
> >>
> >> d. A combination of the scenarios in (b) and (c), i.e having
> multiple
> >>    sessions via each access type while connected thru different
> MAGs
> >>    simultaneously.
> >>
> >> Lets see if we can build some consensus around the scope of the
> problem.
> >>
> >> -Raj
> >>
> >> _______________________________________________
> >> NetExt mailing list
> >> NetExt at mail.mobileip.jp
> >> http://www.mobileip.jp/mailman/listinfo/netext
> >>
> >> _______________________________________________
> >> NetExt mailing list
> >> NetExt at mail.mobileip.jp
> >> http://www.mobileip.jp/mailman/listinfo/netext
> >>
> >
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> >
> >
> >
>
>
>
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>
>

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Tue, 17 Feb 2009 00:18:32 +0100
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Frank,

Well... the netext is about extending the baseline PMIP6 functionality and
hence I don't see the RFC 5213 as a limiting factor when considering the
scenarios that can be addressed in the netext.

domagoj

> -----Original Message-----
> From: ext Frank Xia [mailto:xiayangsong at huawei.com] 
> Sent: 17. veljaca 2009 00:06
> To: Domagoj Premec; 'ext MELIA TELEMACO'; 'Hidetoshi Yokota'; 
> 'Marco Liebsch'
> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Re: [Netext] Review of the Multihoming PS I-D
> 
> Hi Domagoj
> 
> I don't think so.
> 
> Please check RFC5213
> "If the mobile node connects to the Proxy Mobile IPv6 domain through
>    multiple interfaces and over multiple access networks, the network
>    will allocate a unique set of home network prefixes for each of the
>    connected interfaces"
> 
> BR
> Frank
> 
> 
> ----- Original Message -----
> From: "Domagoj Premec" <domagoj.premec.ext at nsn.com>
> To: "'ext MELIA TELEMACO'" 
> <Telemaco.Melia at alcatel-lucent.com>; "'Hidetoshi Yokota'" 
> <yokota at kddilabs.jp>; "'Marco Liebsch'" 
> <marco.liebsch at nw.neclab.eu>
> Cc: <netext at mail.mobileip.jp>; <Basavaraj.Patil at nokia.com>
> Sent: Monday, February 16, 2009 4:45 PM
> Subject: Re: [Netext] Review of the Multihoming PS I-D
> 
> 
> Hi,
> 
> I share the opinion that having the same address assigned to 
> different interfaces is a viable scenario in the context of 
> flow mobility and I believe it should be included in the 
> scope of the inter-tech work.
> 
> domagoj
> 
> 
> 
> ________________________________
> 
> From: netext-bounces at mail.mobileip.jp
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext 
> MELIA TELEMACO
> Sent: 16. veljaca 2009 14:14
> To: Hidetoshi Yokota; Marco Liebsch
> Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
> Subject: Re: [Netext] Review of the Multihoming PS I-D
> 
> 
> 
> Hi Hidetoshi,
> 
> I took the liberty to edit your post according (I hope) to 
> what Marco and I have been saying. Here it goes:
> 
> 
>                             Session2_CN1
>                    Addr_1   Session1_CN1
>             IF#1                             MAG#1        CN#1
>                    Addr_2   Session1_CN2
> 
>     MN-ID                                            LMA
> 
>                    Addr_1
>             IF#2                             MAG#2         CN#2
>                    Addr_2   Session2_CN2
> 
> According to the pic the MN can a) request multiple addresses 
> (depending on the service he might want to get) and b) 
> configure the very same address on multiple interfaces to 
> allow flow mobility (e.g.
> Session2_CN1 can be moved to IF#2 Addr_1). If you do not 
> configure the same address I wonder how the LMA can route 
> flows since the CN1 always send to the same HNP (Addr_1).
> 
> Marco this is your understanding as well?
> 
> 
> 
> thanks
> 
> telemaco
> 
> 
> 
> -----Message d'origine-----
> De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp] Envoy? : 
> lundi 16 f?vrier 2009 13:15 ? : Marco Liebsch Cc : MELIA 
> TELEMACO; netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com 
> Objet : Re: [Netext] Review of the Multihoming PS I-D
> 
> Hi Marco, Telemaco, Raj and all,
> 
> This thread is interesting and important for the start. Let 
> me clarify the problem that we are trying to solve. The MN 
> has multiple interfaces and multiple addresses assigned by 
> multiple MAGs and can setup multiple sessions with multiple 
> CNs (either mobile or plain IPv6 hosts) simultaneously. 
> However, the MN has only one MN-ID and only one LMA (in the 
> scople of the multihoming problem we are discussing now). The 
> addresses assigned for the MN can be bound to any interface 
> of the MN and the sessions associated with those addresses 
> can go through any interface of the MN.
> Also, those addresses and corresponding sessions can migrate 
> to other interfaces of the MN in the middle. The following 
> diagram simply shows this
> situation:
> 
> /------- MN --------\
>                         Session#1
>                Addr#1   Session#2                 CN#1
>         IF#1   Addr#2   Session#3   MAG#1         CN#2
> MN-ID   IF#2   Addr#3   ...         MAG#2   LMA   ...
>         ...    ...      ...         ...           ...
>         IF#J   ...      ...         MAG#M         CN#N
>                Addr#K   ...
>                         Session#L
> 
> Is this the correct view that we are discussing now?
> 
> Regards,
> --
> Hidetoshi
> 
> Marco Liebsch wrote:
> > Hi,
> >
> > I agree that we should consider support of use cases where
> mulitple
> > interfaces of an MN get the same HNP assiged. One step further,
> the MN
> > must configure the same suffix to allow flow mobility and keep
> flow
> > distribution etc.
> > transparent
> > to a CN.
> >
> > Regarding Raj's comments: I fully agree that we need to specify
> the
> > scope of what we'll solve in NetExt and my opinion is that the
> focus
> > should be first on the definition of a set of target use cases, as
> too
> > many of them are treated under the umbrella of multihoming. Then
> let's
> > analyze where RFC5213 needs some more work to support them.
> >
> > Whereas I think that most of this work will be on the LMA to allow
> the
> > assignment of the same HNP to multiple interfaces and to support 
> > inter-working with policy based forwarding, I do *not* think that
> > PMIPv6 signaling should be extended to support in-band
> configuration
> > of such policy routing at the LMA. Hence, we should thoroughly
> define
> > the scope of the solution space before.
> >
> > marco
> >
> >
> >
> > MELIA TELEMACO schrieb:
> >> Hello,
> >>
> >> In principle I am fine with the 4 points Raj proposed. In
> addition, I
> >> would stress scenarios where the same HNP (and same IP address)
> is
> >> configured across several interfaces. I believe these scenarios
> are
> >> very useful for flow mobility and flow distributions.
> >> Comments?
> >>
> >> telemaco
> >> -----Message d'origine-----
> >> De : netext-bounces at mail.mobileip.jp
> >> [mailto:netext-bounces at mail.mobileip.jp] De la part de 
> >> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009
> 15:56 A`
> >> : netext at mail.mobileip.jp Cc : Basavaraj.Patil at nokia.com Objet :
> >> [Netext] Review of the Multihoming PS I-D
> >>
> >>
> >> Hello,
> >>
> >> I have reviewed the Netext Multihoming PS I-D 
> >> <draft-jeyatharan-netext-multihoming-ps-00>. Thanks to Mohana for
> her
> >> efforts on getting this I-D ready.
> >>
> >> 1. My impression after reading the I-D is that it misses the key
> >>    problem of multihoming that we are trying to work on. Proxy
> MIP6 as
> >>    currently specified in RFC5213 has limited support for
> >>    multihoming. It was decided that multihoming should be dealt
> with
> >>    separately in Netlmm during the course discussions on this
> topic in
> >>    the past. While many of the issues mentioned in the I-D are
> >>    relevant I believe that Netext should be working on a more
> narrow
> >>    scope to enhance PMIP6 to support a few multihoming scenarios.
> >>
> >> 2. Sec 3 of the I-D which analyses multihoming issues in the case
> of
> >>    PMIP6/CMIP6 coexisting together is really misplaced here. I do
> not
> >>    believe we want to address this topic as part of the
> multihoming
> >>    work in Netext. This is simply out of scope.
> >>
> >> 3. The I-D focuses on the problem of multiplexing flows or having
> >>    flows traverse via one interface or another or the ability to
> move
> >>    a flow from one interface to another. While these are all
> valid
> >>    things to do in PMIP6, I am not convinced that these are
> >>    specifically related to multihoming.
> >>
> >> Rajeev and I had a discussion on the scope of multihoming and
> what we
> >> should really be focusing on. We came up with the following
> specific
> >> scenarios which we should address:
> >>
> >> a. The multihoming work in Netext should address the limitations
> of
> >> RFC5213
> >>    w.r.t multihoming. The issue of having a single BCE for an MN
> >>    identified by an MN-ID and attaching via multiple interfaces
> should
> >>    be resolved.
> >>
> >> b. The scenario where an MN is connected via a MAG to an LMA and
> the
> >>    ability to establish multiple sessions via the same MAG. This
> is
> >>    the case where the MN is attached via a specific access type
> and
> >>    establishes multiple IP sessions via the MAG.
> >>
> >> c. The scenario where an MN attaches via different interfaces
> which
> >>    are of differing access technologies via MAG1 and MAG2
> >>    simultaneously. The MAG1/MAG2 entities are attached to the
> same
> >>    LMA.
> >>
> >> d. A combination of the scenarios in (b) and (c), i.e having
> multiple
> >>    sessions via each access type while connected thru different
> MAGs
> >>    simultaneously.
> >>
> >> Lets see if we can build some consensus around the scope of the
> problem.
> >>
> >> -Raj
> >>
> >> _______________________________________________
> >> NetExt mailing list
> >> NetExt at mail.mobileip.jp
> >> http://www.mobileip.jp/mailman/listinfo/netext
> >>
> >> _______________________________________________
> >> NetExt mailing list
> >> NetExt at mail.mobileip.jp
> >> http://www.mobileip.jp/mailman/listinfo/netext
> >>
> >
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> >
> >
> >
> 
> 
> 
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext 
> 
> 

From: xiayangsong at huawei.com (Frank Xia)
Date: Mon, 16 Feb 2009 17:06:29 -0600
Subject: [Netext] Review of the Multihoming PS I-D
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Domagoj

I don't think so.

Please check RFC5213
"If the mobile node connects to the Proxy Mobile IPv6 domain through
   multiple interfaces and over multiple access networks, the network
   will allocate a unique set of home network prefixes for each of the
   connected interfaces"

BR
Frank

----- Original Message ----- 
From: "Domagoj Premec" <domagoj.premec.ext at nsn.com>
To: "'ext MELIA TELEMACO'" <Telemaco.Melia at alcatel-lucent.com>; "'Hidetoshi 
Yokota'" <yokota at kddilabs.jp>; "'Marco Liebsch'" 
<marco.liebsch at nw.neclab.eu>
Cc: <netext at mail.mobileip.jp>; <Basavaraj.Patil at nokia.com>
Sent: Monday, February 16, 2009 4:45 PM
Subject: Re: [Netext] Review of the Multihoming PS I-D

Hi,

I share the opinion that having the same address assigned to different
interfaces is a viable scenario in the context of flow mobility and I
believe it should be included in the scope of the inter-tech work.

domagoj

________________________________

From: netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext MELIA TELEMACO
Sent: Monday, February 16, 2009 2:14 PM
To: Hidetoshi Yokota; Marco Liebsch
Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
Subject: Re: [Netext] Review of the Multihoming PS I-D

Hi Hidetoshi,

I took the liberty to edit your post according (I hope) to what
Marco and I have been saying. Here it goes:

                            Session2_CN1
                   Addr_1   Session1_CN1
            IF#1                             MAG#1        CN#1
                   Addr_2   Session1_CN2

    MN-ID                                            LMA

                   Addr_1
            IF#2                             MAG#2         CN#2
                   Addr_2   Session2_CN2

According to the pic the MN can a) request multiple addresses
(depending on the service he might want to get) and b) configure the very
same address on multiple interfaces to allow flow mobility (e.g.
Session2_CN1 can be moved to IF#2 Addr_1). If you do not configure the same
address I wonder how the LMA can route flows since the CN1 always send to
the same HNP (Addr_1).

Marco this is your understanding as well?

thanks

telemaco

-----Message d'origine-----
De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
Envoy? : lundi 16 f?vrier 2009 13:15
? : Marco Liebsch
Cc : MELIA TELEMACO; netext at mail.mobileip.jp;
Basavaraj.Patil at nokia.com
Objet : Re: [Netext] Review of the Multihoming PS I-D

Hi Marco, Telemaco, Raj and all,

This thread is interesting and important for the start. Let me
clarify the problem that we are trying to solve. The MN has multiple
interfaces and multiple addresses assigned by multiple MAGs and can setup
multiple sessions with multiple CNs (either mobile or plain IPv6 hosts)
simultaneously. However, the MN has only one MN-ID and only one LMA (in the
scople of the multihoming problem we are discussing now). The addresses
assigned for the MN can be bound to any interface of the MN and the sessions
associated with those addresses can go through any interface of the MN.
Also, those addresses and corresponding sessions can migrate to other
interfaces of the MN in the middle. The following diagram simply shows this
situation:

/------- MN --------\
                        Session#1
               Addr#1   Session#2                 CN#1
        IF#1   Addr#2   Session#3   MAG#1         CN#2
MN-ID   IF#2   Addr#3   ...         MAG#2   LMA   ...
        ...    ...      ...         ...           ...
        IF#J   ...      ...         MAG#M         CN#N
               Addr#K   ...
                        Session#L

Is this the correct view that we are discussing now?

Regards,
--
Hidetoshi

Marco Liebsch wrote:
> Hi,
>
> I agree that we should consider support of use cases where
mulitple
> interfaces of an MN get the same HNP assiged. One step further,
the MN
> must configure the same suffix to allow flow mobility and keep
flow
> distribution etc.
> transparent
> to a CN.
>
> Regarding Raj's comments: I fully agree that we need to specify
the
> scope of what we'll solve in NetExt and my opinion is that the
focus
> should be first on the definition of a set of target use cases, as
too
> many of them are treated under the umbrella of multihoming. Then
let's
> analyze where RFC5213 needs some more work to support them.
>
> Whereas I think that most of this work will be on the LMA to allow
the
> assignment of the same HNP to multiple interfaces and to support
> inter-working with policy based forwarding, I do *not* think that
> PMIPv6 signaling should be extended to support in-band
configuration
> of such policy routing at the LMA. Hence, we should thoroughly
define
> the scope of the solution space before.
>
> marco
>
>
>
> MELIA TELEMACO schrieb:
>> Hello,
>>
>> In principle I am fine with the 4 points Raj proposed. In
addition, I
>> would stress scenarios where the same HNP (and same IP address)
is
>> configured across several interfaces. I believe these scenarios
are
>> very useful for flow mobility and flow distributions.
>> Comments?
>>
>> telemaco
>> -----Message d'origine-----
>> De : netext-bounces at mail.mobileip.jp
>> [mailto:netext-bounces at mail.mobileip.jp] De la part de
>> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009
15:56 A`
>> : netext at mail.mobileip.jp Cc : Basavaraj.Patil at nokia.com Objet :
>> [Netext] Review of the Multihoming PS I-D
>>
>>
>> Hello,
>>
>> I have reviewed the Netext Multihoming PS I-D
>> <draft-jeyatharan-netext-multihoming-ps-00>. Thanks to Mohana for
her
>> efforts on getting this I-D ready.
>>
>> 1. My impression after reading the I-D is that it misses the key
>>    problem of multihoming that we are trying to work on. Proxy
MIP6 as
>>    currently specified in RFC5213 has limited support for
>>    multihoming. It was decided that multihoming should be dealt
with
>>    separately in Netlmm during the course discussions on this
topic in
>>    the past. While many of the issues mentioned in the I-D are
>>    relevant I believe that Netext should be working on a more
narrow
>>    scope to enhance PMIP6 to support a few multihoming scenarios.
>>
>> 2. Sec 3 of the I-D which analyses multihoming issues in the case
of
>>    PMIP6/CMIP6 coexisting together is really misplaced here. I do
not
>>    believe we want to address this topic as part of the
multihoming
>>    work in Netext. This is simply out of scope.
>>
>> 3. The I-D focuses on the problem of multiplexing flows or having
>>    flows traverse via one interface or another or the ability to
move
>>    a flow from one interface to another. While these are all
valid
>>    things to do in PMIP6, I am not convinced that these are
>>    specifically related to multihoming.
>>
>> Rajeev and I had a discussion on the scope of multihoming and
what we
>> should really be focusing on. We came up with the following
specific
>> scenarios which we should address:
>>
>> a. The multihoming work in Netext should address the limitations
of
>> RFC5213
>>    w.r.t multihoming. The issue of having a single BCE for an MN
>>    identified by an MN-ID and attaching via multiple interfaces
should
>>    be resolved.
>>
>> b. The scenario where an MN is connected via a MAG to an LMA and
the
>>    ability to establish multiple sessions via the same MAG. This
is
>>    the case where the MN is attached via a specific access type
and
>>    establishes multiple IP sessions via the MAG.
>>
>> c. The scenario where an MN attaches via different interfaces
which
>>    are of differing access technologies via MAG1 and MAG2
>>    simultaneously. The MAG1/MAG2 entities are attached to the
same
>>    LMA.
>>
>> d. A combination of the scenarios in (b) and (c), i.e having
multiple
>>    sessions via each access type while connected thru different
MAGs
>>    simultaneously.
>>
>> Lets see if we can build some consensus around the scope of the
problem.
>>
>> -Raj
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>
>
>

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext 

From: domagoj.premec.ext at nsn.com (Domagoj Premec)
Date: Mon, 16 Feb 2009 23:45:02 +0100
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]><[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,
 
I share the opinion that having the same address assigned to different
interfaces is a viable scenario in the context of flow mobility and I
believe it should be included in the scope of the inter-tech work.

domagoj

________________________________

	From: netext-bounces at mail.mobileip.jp
[mailto:netext-bounces at mail.mobileip.jp] On Behalf Of ext MELIA TELEMACO
	Sent: 16. veljaca 2009 14:14
	To: Hidetoshi Yokota; Marco Liebsch
	Cc: netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
	Subject: Re: [Netext] Review of the Multihoming PS I-D

	Hi Hidetoshi,
	
	I took the liberty to edit your post according (I hope) to what
Marco and I have been saying. Here it goes:

	                            Session2_CN1
	                   Addr_1   Session1_CN1
	            IF#1                             MAG#1        CN#1
	                   Addr_2   Session1_CN2

	    MN-ID                                            LMA

	                   Addr_1
	            IF#2                             MAG#2         CN#2
	                   Addr_2   Session2_CN2

	According to the pic the MN can a) request multiple addresses
(depending on the service he might want to get) and b) configure the very
same address on multiple interfaces to allow flow mobility (e.g.
Session2_CN1 can be moved to IF#2 Addr_1). If you do not configure the same
address I wonder how the LMA can route flows since the CN1 always send to
the same HNP (Addr_1).

	Marco this is your understanding as well?

	thanks

	telemaco

	
	-----Message d'origine-----
	De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
	Envoy? : lundi 16 f?vrier 2009 13:15
	? : Marco Liebsch
	Cc : MELIA TELEMACO; netext at mail.mobileip.jp;
Basavaraj.Patil at nokia.com
	Objet : Re: [Netext] Review of the Multihoming PS I-D
	
	Hi Marco, Telemaco, Raj and all,
	
	This thread is interesting and important for the start. Let me
clarify the problem that we are trying to solve. The MN has multiple
interfaces and multiple addresses assigned by multiple MAGs and can setup
multiple sessions with multiple CNs (either mobile or plain IPv6 hosts)
simultaneously. However, the MN has only one MN-ID and only one LMA (in the
scople of the multihoming problem we are discussing now). The addresses
assigned for the MN can be bound to any interface of the MN and the sessions
associated with those addresses can go through any interface of the MN.
Also, those addresses and corresponding sessions can migrate to other
interfaces of the MN in the middle. The following diagram simply shows this
situation:
	
	/------- MN --------\
	                        Session#1
	               Addr#1   Session#2                 CN#1
	        IF#1   Addr#2   Session#3   MAG#1         CN#2
	MN-ID   IF#2   Addr#3   ...         MAG#2   LMA   ...
	        ...    ...      ...         ...           ...
	        IF#J   ...      ...         MAG#M         CN#N
	               Addr#K   ...
	                        Session#L
	
	Is this the correct view that we are discussing now?
	
	Regards,
	--
	Hidetoshi
	
	Marco Liebsch wrote:
	> Hi,
	>
	> I agree that we should consider support of use cases where
mulitple
	> interfaces of an MN get the same HNP assiged. One step further,
the MN
	> must configure the same suffix to allow flow mobility and keep
flow
	> distribution etc.
	> transparent
	> to a CN.
	>
	> Regarding Raj's comments: I fully agree that we need to specify
the
	> scope of what we'll solve in NetExt and my opinion is that the
focus
	> should be first on the definition of a set of target use cases, as
too
	> many of them are treated under the umbrella of multihoming. Then
let's
	> analyze where RFC5213 needs some more work to support them.
	>
	> Whereas I think that most of this work will be on the LMA to allow
the
	> assignment of the same HNP to multiple interfaces and to support
	> inter-working with policy based forwarding, I do *not* think that
	> PMIPv6 signaling should be extended to support in-band
configuration
	> of such policy routing at the LMA. Hence, we should thoroughly
define
	> the scope of the solution space before.
	>
	> marco
	>
	>
	>
	> MELIA TELEMACO schrieb:
	>> Hello,
	>>
	>> In principle I am fine with the 4 points Raj proposed. In
addition, I
	>> would stress scenarios where the same HNP (and same IP address)
is
	>> configured across several interfaces. I believe these scenarios
are
	>> very useful for flow mobility and flow distributions.
	>> Comments?
	>>
	>> telemaco
	>> -----Message d'origine-----
	>> De : netext-bounces at mail.mobileip.jp
	>> [mailto:netext-bounces at mail.mobileip.jp] De la part de
	>> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009
15:56 A`
	>> : netext at mail.mobileip.jp Cc : Basavaraj.Patil at nokia.com Objet :
	>> [Netext] Review of the Multihoming PS I-D
	>>
	>>
	>> Hello,
	>>
	>> I have reviewed the Netext Multihoming PS I-D
	>> <draft-jeyatharan-netext-multihoming-ps-00>. Thanks to Mohana for
her
	>> efforts on getting this I-D ready.
	>>
	>> 1. My impression after reading the I-D is that it misses the key
	>>    problem of multihoming that we are trying to work on. Proxy
MIP6 as
	>>    currently specified in RFC5213 has limited support for
	>>    multihoming. It was decided that multihoming should be dealt
with
	>>    separately in Netlmm during the course discussions on this
topic in
	>>    the past. While many of the issues mentioned in the I-D are
	>>    relevant I believe that Netext should be working on a more
narrow
	>>    scope to enhance PMIP6 to support a few multihoming scenarios.
	>>
	>> 2. Sec 3 of the I-D which analyses multihoming issues in the case
of
	>>    PMIP6/CMIP6 coexisting together is really misplaced here. I do
not
	>>    believe we want to address this topic as part of the
multihoming
	>>    work in Netext. This is simply out of scope.
	>>
	>> 3. The I-D focuses on the problem of multiplexing flows or having
	>>    flows traverse via one interface or another or the ability to
move
	>>    a flow from one interface to another. While these are all
valid
	>>    things to do in PMIP6, I am not convinced that these are
	>>    specifically related to multihoming.
	>>
	>> Rajeev and I had a discussion on the scope of multihoming and
what we
	>> should really be focusing on. We came up with the following
specific
	>> scenarios which we should address:
	>>
	>> a. The multihoming work in Netext should address the limitations
of
	>> RFC5213
	>>    w.r.t multihoming. The issue of having a single BCE for an MN
	>>    identified by an MN-ID and attaching via multiple interfaces
should
	>>    be resolved.
	>>
	>> b. The scenario where an MN is connected via a MAG to an LMA and
the
	>>    ability to establish multiple sessions via the same MAG. This
is
	>>    the case where the MN is attached via a specific access type
and
	>>    establishes multiple IP sessions via the MAG.
	>>
	>> c. The scenario where an MN attaches via different interfaces
which
	>>    are of differing access technologies via MAG1 and MAG2
	>>    simultaneously. The MAG1/MAG2 entities are attached to the
same
	>>    LMA.
	>>
	>> d. A combination of the scenarios in (b) and (c), i.e having
multiple
	>>    sessions via each access type while connected thru different
MAGs
	>>    simultaneously.
	>>
	>> Lets see if we can build some consensus around the scope of the
problem.
	>>
	>> -Raj
	>>
	>> _______________________________________________
	>> NetExt mailing list
	>> NetExt at mail.mobileip.jp
	>> http://www.mobileip.jp/mailman/listinfo/netext
	>>
	>> _______________________________________________
	>> NetExt mailing list
	>> NetExt at mail.mobileip.jp
	>> http://www.mobileip.jp/mailman/listinfo/netext
	>>  
	>
	>
	> _______________________________________________
	> NetExt mailing list
	> NetExt at mail.mobileip.jp
	> http://www.mobileip.jp/mailman/listinfo/netext
	>
	>
	>

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Mon, 16 Feb 2009 16:01:15 -0500
Subject: [Netext] First Problem Statement about LocalizedRoutingin	PMIPv6 submitted
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Marco,
 
> Rajeev, Carlos,
> 
> can we conclude from the discussion so far that
> a.) this is a reasonable and 'in-scope' use case?

What is a)? If you mean a node without PMIP6 support, I would say no. 
There is no way to distinguish nodes like that way, and we should be focussed on solving this for PMIP6 domain IMHO.

> b.) PMIPv6 CN vs. IPv6 CN may not be transparent to a MAG and
>   the NetExt solution for PMIPv6 RO?
> 

We should look at MNs which expect network-based mobility support.

Regards,

-Rajeev

> If both is a 'yes', I propose to add this case to the RO PS.
> If we don't see this as separate use case, we could also add 
> simply a short paragraph that 'this case may have issues, 
> which we must look at and take into account'.
> 
> What do you think?
> 
> marco
> 
> 
> 
> Koodli, Rajeev wrote:
> > Hi,
> >  
> >   
> >> I fully agree that the whole point of PMIP is make mobility 
> >> management transparent to the MN. However, as far as I understand 
> >> from my reading of RFC5213, a mobile node attached to a 
> PMIPv6 domain 
> >> might not be entitled to the network-based mobility management 
> >> service, and RFC5213 (section 6.14) still support this node to get 
> >> connectivity (regular
> >> access) from the MAG.
> >>     
> >
> > I need to look into this, but I have no idea how a MAG can 
> distinguish the two nodes..
> >
> >   
> >> Related to this, it is also my interpretation of RFC5213 (section
> >> 6.10.5) that the local routing support provided by the basic spec 
> >> (controlled with the EnableMAGLocalRouting flag) only applies to 
> >> communications between a PMIPv6 MN and a regular
> >> IPv6 host attached to the same MAG.
> >>     
> >
> > This sounds even more interesting because the "regular IPv6 
> host" gets better performance!
> > So, all you have to do is to declare that you are not a PMIP6 MN to 
> > get better VoIP quality :-)
> >
> > Regards,
> >
> > -Rajeev
> >
> >   
> >> This is just to try to clarify what RFC5213 provides 
> (actually, very
> >> little) and what does not in regards to local routing 
> support. Do you 
> >> see my point?
> >>
> >> Thanks!
> >>
> >> Carlos
> >>
> >>     
> >>>       
> >>>> 	- If my previous understanding is correct, then RFC5213
> >>>>         
> >> does not
> >>     
> >>>> only define any mechanism to perform local routing
> >>>>         
> >> between two MNs
> >>     
> >>>> connected to the same PMIPv6 domain (not even for the
> >>>>         
> >> case in which
> >>     
> >>>> both are attached to the same MAG).
> >>>> Then, IMHO it would be better to change the terminology 
> in the PS 
> >>>> and avoid using CN or coming up with different terms for
> >>>>         
> >> a CN that
> >>     
> >>>> is getting network-based mobility service from a CN that is not 
> >>>> (i.e. it is just a regular IPv6 node getting access from a MAG).
> >>>>         
> >>> See above.
> >>>
> >>>       
> >>>> 	- Currently, the PS only addresses the case of local routing 
> >>>> between two MNs connected to the same PMIPv6 domain.
> >>>> I think the scenario of optimising traffic between an MN and a 
> >>>> regular IPv6 host that is locally connected to a MAG
> >>>>         
> >> should also be
> >>     
> >>>> addressed. Not sure the implications on the potential
> >>>>         
> >> solutions, but
> >>     
> >>>> it might have an impact on the classification scheme that
> >>>>         
> >> is used in
> >>     
> >>>> the PS now (A[number of MAGs][number of LMAs]).
> >>>>
> >>>>         
> >>> Our focus should be on solving the problem for nodes
> >>>       
> >> attached to a PMIP6 domain.
> >>     
> >>> Thanks,
> >>>
> >>> -Rajeev
> >>>
> >>>
> >>>       
> >>>> 	Thanks,
> >>>>
> >>>> 	Carlos
> >>>>
> >>>> El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?:
> >>>>         
> >>>>> Hi all,
> >>>>>
> >>>>> please find the link to a first version of a Localized
> >>>>>           
> >>>> Routing Problem
> >>>>         
> >>>>> Statement below.
> >>>>> The abstract of the PS document is as follows:
> >>>>>
> >>>>> Abstract:
> >>>>>
> >>>>>    Proxy Mobile IPv6 is the IETF standard for network-based
> >>>>>           
> >>>> localized
> >>>>         
> >>>>>    mobility management.  In Proxy Mobile IPv6, mobile nodes are
> >>>>>    topologically anchored at a Local Mobility Anchor, which
> >>>>>           
> >>>> forwards all
> >>>>         
> >>>>>    data for registered mobile nodes.  The set up and support for
> >>>>>    localized routing, which allows forwarding of data
> >>>>>           
> >>>> packets between
> >>>>         
> >>>>>    mobile nodes and correspondent nodes directly without
> >>>>>           
> >>>> traversing an
> >>>>         
> >>>>>    LMA, is not considered.  This document describes the
> >>>>>           
> >>>> problem space of
> >>>>         
> >>>>>    localized routing in Proxy Mobile IPv6.
> >>>>>
> >>>>>
> >>>>> Any comments to this version of the problem statement
> >>>>>           
> >> are welcome.
> >>     
> >>>>>           
> >> 
> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps
> >>     
> >>>> -0
> >>>>         
> >>>>> 0.txt
> >>>>>
> >>>>> Best regards,
> >>>>> marco
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> NetExt mailing list
> >>>>> NetExt at mail.mobileip.jp
> >>>>> http://www.mobileip.jp/mailman/listinfo/netext
> >>>>>           
> >>>> -- 
> >>>>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> >>>>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> >>>>         Deployment Experiences on Vehicular networks
> >>>>                   http://www.weedev.org/
> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>
> >>>>         
> >>> This email and any attachments may contain legally
> >>>       
> >> privileged and/or confidential information of Starent 
> Networks, Corp. 
> >> and is intended only for the individual or entity named in the 
> >> message.  The information transmitted may not be used to create or 
> >> change any contractual obligations of Starent Networks, Corp.  Any 
> >> review, retransmission, dissemination or other use of, or 
> taking of 
> >> any action in reliance upon this e-mail and its attachments by 
> >> persons or entities other than the intended recipient is 
> prohibited. 
> >> If you are not the intended recipient, please notify the sender 
> >> immediately -- by replying to this message or by sending 
> an email to 
> >> postmaster at starentnetworks.com -- and destroy all copies of this 
> >> message and any attachments without reading or disclosing their 
> >> contents. Thank you.
> >> -- 
> >>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> >>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> >>         Deployment Experiences on Vehicular networks
> >>                   http://www.weedev.org/
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>
> >>     
> 
> 

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Mon, 16 Feb 2009 20:01:42 +0100
Subject: [Netext] Inter-technology handover PS
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <1234810902.5187.92.camel@localhost>

Hi Suresh,

	Thanks for the draft. I think it's short and clear. Some comments
below:

	- Section 2.1. Formation of interface identifier. The issue described
there only applies if SLAAC is used, right? If DHCP is used, the issue
is then on the network side, to ensure that the address provided to the
new interface of the MN is the same that it was (or is still) using on
the previous interface, right?

	- Section 2.2 Usage of the same address on multiple interfaces. Since
it seems that we cannot assume that is safe to use the same address on
multiple interfaces (without requiring changes on the MN side), this
implies that: a) if NETEXT work is restricted to work on solutions that
do not impose changes on the MN, use cases requiring the MN to use the
same address simultaneously are out of the scope of NETEXT, b) we allow
for changes on the MN side. Additionally, it might be good to analyse if
it is OK for the MN to receive (and send) traffic addressed to the IPv6
address of one interface through a different interface (weak end-system
model defined in RFC 1122 or draft-thaler-ip-model-evolution).

	- IMHO, it'd be good to explicitly describe what a "change on the MN"
within the scope of NETEXT. For example, is it fine assuming IEEE 802.21
support on the MN or is this "a change on the MN"?

	Thanks!

	Carlos

El lun, 09-02-2009 a las 17:27 -0500, Suresh Krishnan escribi?:
> Hi Folks,
>    We have submitted the initial version of the problem statement draft 
> describing issues with network based inter-technology handovers. Please 
> send us any comments or issues that you may have on the document.
> 
> Thanks
> Suresh
> 
> -------- Original Message --------
> Subject: I-D Action:draft-krishnan-netext-intertech-ps-00.txt
> Date: Mon,  9 Feb 2009 14:15:01 -0800 (PST)
> From: Internet-Drafts at ietf.org
> Reply-To: internet-drafts at ietf.org
> To: i-d-announce at ietf.org
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> 
> 	Title           : Issues with network based inter-technology handovers
> 	Author(s)       : S. Krishnan, et al.
> 	Filename        : draft-krishnan-netext-intertech-ps-00.txt
> 	Pages           : 9
> 	Date            : 2009-02-09
> 
> Proxy Mobile IPv6 (PMIPv6) is a network based mobility management
> protocol enables IP mobility for a host without requiring its
> participation in any mobility-related signaling.  While the PMIPv6
> protocol itself supports handover across interfaces and between
> access types, there are several issues with effectively performing
> inter-technology handovers with network based mobility protocols.
> This document aims to enumerate some known issues with such
> handovers.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-krishnan-netext-intertech-ps-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
-- 
 Carlos Jes?s Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090216/2f3d8d59/attachment.bin>

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Mon, 16 Feb 2009 19:32:15 +0100
Subject: [Netext] First Problem Statement about	LocalizedRoutingin	PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <1234809135.5187.77.camel@localhost>

Hi Marco,

	In my opinion, it is relevant to first identify whether basic RFC5213
provides a solution for the PMIPv6 MN - IPv6 CN case (when attached to
the same MAG). If so, since that solution would be basically a framework
(the use of the EnableMAGLocalRouting flag), it would be good for NETEXT
to detail the solution. In any case, I find useful to include the use
case of the IPv6 CN (either attached to the same MAG than the PMIPv6 MN
or to a different one). I'm not so sure about addressing the MIPv6 CN...
but I'm fine with including the short paragraph.

	I'm not sure if I replied to what you were asking, BTW :-)

	Thanks,

	Carlos

El lun, 16-02-2009 a las 17:57 +0100, Marco Liebsch escribi?:
> Rajeev, Carlos,
> 
> can we conclude from the discussion so far that
> a.) this is a reasonable and 'in-scope' use case?
> b.) PMIPv6 CN vs. IPv6 CN may not be transparent to a MAG and
>   the NetExt solution for PMIPv6 RO?
> 
> If both is a 'yes', I propose to add this case to the RO PS.
> If we don't see this as separate use case, we could also add
> simply a short paragraph that 'this case may have issues,
> which we must look at and take into account'.
> 
> What do you think?
> 
> marco
> 
> 
> 
> Koodli, Rajeev wrote:
> > Hi,
> >  
> >   
> >> I fully agree that the whole point of PMIP is make mobility 
> >> management transparent to the MN. However, as far as I 
> >> understand from my reading of RFC5213, a mobile node attached 
> >> to a PMIPv6 domain might not be entitled to the network-based 
> >> mobility management service, and RFC5213 (section 6.14) still 
> >> support this node to get connectivity (regular
> >> access) from the MAG.
> >>     
> >
> > I need to look into this, but I have no idea how a MAG can distinguish the two nodes..
> >
> >   
> >> Related to this, it is also my interpretation of RFC5213 (section
> >> 6.10.5) that the local routing support provided by the basic 
> >> spec (controlled with the EnableMAGLocalRouting flag) only 
> >> applies to communications between a PMIPv6 MN and a regular 
> >> IPv6 host attached to the same MAG.
> >>     
> >
> > This sounds even more interesting because the "regular IPv6 host" gets better performance!
> > So, all you have to do is to declare that you are not a PMIP6 MN to get better VoIP quality :-)
> >
> > Regards,
> >
> > -Rajeev
> >
> >   
> >> This is just to try to clarify what RFC5213 provides (actually, very
> >> little) and what does not in regards to local routing 
> >> support. Do you see my point?
> >>
> >> Thanks!
> >>
> >> Carlos
> >>
> >>     
> >>>       
> >>>> 	- If my previous understanding is correct, then RFC5213 
> >>>>         
> >> does not 
> >>     
> >>>> only define any mechanism to perform local routing 
> >>>>         
> >> between two MNs 
> >>     
> >>>> connected to the same PMIPv6 domain (not even for the 
> >>>>         
> >> case in which 
> >>     
> >>>> both are attached to the same MAG).
> >>>> Then, IMHO it would be better to change the terminology in the PS 
> >>>> and avoid using CN or coming up with different terms for 
> >>>>         
> >> a CN that 
> >>     
> >>>> is getting network-based mobility service from a CN that is not 
> >>>> (i.e. it is just a regular IPv6 node getting access from a MAG).
> >>>>         
> >>> See above.
> >>>
> >>>       
> >>>> 	- Currently, the PS only addresses the case of local routing 
> >>>> between two MNs connected to the same PMIPv6 domain.
> >>>> I think the scenario of optimising traffic between an MN and a 
> >>>> regular IPv6 host that is locally connected to a MAG 
> >>>>         
> >> should also be 
> >>     
> >>>> addressed. Not sure the implications on the potential 
> >>>>         
> >> solutions, but 
> >>     
> >>>> it might have an impact on the classification scheme that 
> >>>>         
> >> is used in 
> >>     
> >>>> the PS now (A[number of MAGs][number of LMAs]).
> >>>>
> >>>>         
> >>> Our focus should be on solving the problem for nodes 
> >>>       
> >> attached to a PMIP6 domain.
> >>     
> >>> Thanks,
> >>>
> >>> -Rajeev
> >>>
> >>>
> >>>       
> >>>> 	Thanks,
> >>>>
> >>>> 	Carlos
> >>>>
> >>>> El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?:
> >>>>         
> >>>>> Hi all,
> >>>>>
> >>>>> please find the link to a first version of a Localized
> >>>>>           
> >>>> Routing Problem
> >>>>         
> >>>>> Statement below.
> >>>>> The abstract of the PS document is as follows:
> >>>>>
> >>>>> Abstract:
> >>>>>
> >>>>>    Proxy Mobile IPv6 is the IETF standard for network-based
> >>>>>           
> >>>> localized
> >>>>         
> >>>>>    mobility management.  In Proxy Mobile IPv6, mobile nodes are
> >>>>>    topologically anchored at a Local Mobility Anchor, which
> >>>>>           
> >>>> forwards all
> >>>>         
> >>>>>    data for registered mobile nodes.  The set up and support for
> >>>>>    localized routing, which allows forwarding of data
> >>>>>           
> >>>> packets between
> >>>>         
> >>>>>    mobile nodes and correspondent nodes directly without
> >>>>>           
> >>>> traversing an
> >>>>         
> >>>>>    LMA, is not considered.  This document describes the
> >>>>>           
> >>>> problem space of
> >>>>         
> >>>>>    localized routing in Proxy Mobile IPv6.
> >>>>>
> >>>>>
> >>>>> Any comments to this version of the problem statement 
> >>>>>           
> >> are welcome.
> >>     
> >>>>>           
> >> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps
> >>     
> >>>> -0
> >>>>         
> >>>>> 0.txt
> >>>>>
> >>>>> Best regards,
> >>>>> marco
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> NetExt mailing list
> >>>>> NetExt at mail.mobileip.jp
> >>>>> http://www.mobileip.jp/mailman/listinfo/netext
> >>>>>           
> >>>> -- 
> >>>>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> >>>>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> >>>>         Deployment Experiences on Vehicular networks
> >>>>                   http://www.weedev.org/
> >>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>
> >>>>         
> >>> This email and any attachments may contain legally 
> >>>       
> >> privileged and/or confidential information of Starent 
> >> Networks, Corp. and is intended only for the individual or 
> >> entity named in the message.  The information transmitted may 
> >> not be used to create or change any contractual obligations 
> >> of Starent Networks, Corp.  Any review, retransmission, 
> >> dissemination or other use of, or taking of any action in 
> >> reliance upon this e-mail and its attachments by persons or 
> >> entities other than the intended recipient is prohibited. If 
> >> you are not the intended recipient, please notify the sender 
> >> immediately -- by replying to this message or by sending an 
> >> email to postmaster at starentnetworks.com -- and destroy all 
> >> copies of this message and any attachments without reading or 
> >> disclosing their contents. Thank you.
> >> -- 
> >>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> >>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> >>         Deployment Experiences on Vehicular networks
> >>                   http://www.weedev.org/
> >> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>
> >>     
> 
-- 
 Carlos Jes?s Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090216/910f403b/attachment.bin>

From: liebsch at nw.neclab.eu (Marco Liebsch)
Date: Mon, 16 Feb 2009 17:57:03 +0100
Subject: [Netext] First Problem Statement about LocalizedRoutingin	PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Rajeev, Carlos,

can we conclude from the discussion so far that
a.) this is a reasonable and 'in-scope' use case?
b.) PMIPv6 CN vs. IPv6 CN may not be transparent to a MAG and
  the NetExt solution for PMIPv6 RO?

If both is a 'yes', I propose to add this case to the RO PS.
If we don't see this as separate use case, we could also add
simply a short paragraph that 'this case may have issues,
which we must look at and take into account'.

What do you think?

marco

Koodli, Rajeev wrote:
> Hi,
>  
>   
>> I fully agree that the whole point of PMIP is make mobility 
>> management transparent to the MN. However, as far as I 
>> understand from my reading of RFC5213, a mobile node attached 
>> to a PMIPv6 domain might not be entitled to the network-based 
>> mobility management service, and RFC5213 (section 6.14) still 
>> support this node to get connectivity (regular
>> access) from the MAG.
>>     
>
> I need to look into this, but I have no idea how a MAG can distinguish the two nodes..
>
>   
>> Related to this, it is also my interpretation of RFC5213 (section
>> 6.10.5) that the local routing support provided by the basic 
>> spec (controlled with the EnableMAGLocalRouting flag) only 
>> applies to communications between a PMIPv6 MN and a regular 
>> IPv6 host attached to the same MAG.
>>     
>
> This sounds even more interesting because the "regular IPv6 host" gets better performance!
> So, all you have to do is to declare that you are not a PMIP6 MN to get better VoIP quality :-)
>
> Regards,
>
> -Rajeev
>
>   
>> This is just to try to clarify what RFC5213 provides (actually, very
>> little) and what does not in regards to local routing 
>> support. Do you see my point?
>>
>> Thanks!
>>
>> Carlos
>>
>>     
>>>       
>>>> 	- If my previous understanding is correct, then RFC5213 
>>>>         
>> does not 
>>     
>>>> only define any mechanism to perform local routing 
>>>>         
>> between two MNs 
>>     
>>>> connected to the same PMIPv6 domain (not even for the 
>>>>         
>> case in which 
>>     
>>>> both are attached to the same MAG).
>>>> Then, IMHO it would be better to change the terminology in the PS 
>>>> and avoid using CN or coming up with different terms for 
>>>>         
>> a CN that 
>>     
>>>> is getting network-based mobility service from a CN that is not 
>>>> (i.e. it is just a regular IPv6 node getting access from a MAG).
>>>>         
>>> See above.
>>>
>>>       
>>>> 	- Currently, the PS only addresses the case of local routing 
>>>> between two MNs connected to the same PMIPv6 domain.
>>>> I think the scenario of optimising traffic between an MN and a 
>>>> regular IPv6 host that is locally connected to a MAG 
>>>>         
>> should also be 
>>     
>>>> addressed. Not sure the implications on the potential 
>>>>         
>> solutions, but 
>>     
>>>> it might have an impact on the classification scheme that 
>>>>         
>> is used in 
>>     
>>>> the PS now (A[number of MAGs][number of LMAs]).
>>>>
>>>>         
>>> Our focus should be on solving the problem for nodes 
>>>       
>> attached to a PMIP6 domain.
>>     
>>> Thanks,
>>>
>>> -Rajeev
>>>
>>>
>>>       
>>>> 	Thanks,
>>>>
>>>> 	Carlos
>>>>
>>>> El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?:
>>>>         
>>>>> Hi all,
>>>>>
>>>>> please find the link to a first version of a Localized
>>>>>           
>>>> Routing Problem
>>>>         
>>>>> Statement below.
>>>>> The abstract of the PS document is as follows:
>>>>>
>>>>> Abstract:
>>>>>
>>>>>    Proxy Mobile IPv6 is the IETF standard for network-based
>>>>>           
>>>> localized
>>>>         
>>>>>    mobility management.  In Proxy Mobile IPv6, mobile nodes are
>>>>>    topologically anchored at a Local Mobility Anchor, which
>>>>>           
>>>> forwards all
>>>>         
>>>>>    data for registered mobile nodes.  The set up and support for
>>>>>    localized routing, which allows forwarding of data
>>>>>           
>>>> packets between
>>>>         
>>>>>    mobile nodes and correspondent nodes directly without
>>>>>           
>>>> traversing an
>>>>         
>>>>>    LMA, is not considered.  This document describes the
>>>>>           
>>>> problem space of
>>>>         
>>>>>    localized routing in Proxy Mobile IPv6.
>>>>>
>>>>>
>>>>> Any comments to this version of the problem statement 
>>>>>           
>> are welcome.
>>     
>>>>>           
>> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps
>>     
>>>> -0
>>>>         
>>>>> 0.txt
>>>>>
>>>>> Best regards,
>>>>> marco
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> NetExt mailing list
>>>>> NetExt at mail.mobileip.jp
>>>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>>>           
>>>> -- 
>>>>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
>>>>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
>>>>         Deployment Experiences on Vehicular networks
>>>>                   http://www.weedev.org/
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>>>
>>>>         
>>> This email and any attachments may contain legally 
>>>       
>> privileged and/or confidential information of Starent 
>> Networks, Corp. and is intended only for the individual or 
>> entity named in the message.  The information transmitted may 
>> not be used to create or change any contractual obligations 
>> of Starent Networks, Corp.  Any review, retransmission, 
>> dissemination or other use of, or taking of any action in 
>> reliance upon this e-mail and its attachments by persons or 
>> entities other than the intended recipient is prohibited. If 
>> you are not the intended recipient, please notify the sender 
>> immediately -- by replying to this message or by sending an 
>> email to postmaster at starentnetworks.com -- and destroy all 
>> copies of this message and any attachments without reading or 
>> disclosing their contents. Thank you.
>> -- 
>>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
>>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
>>         Deployment Experiences on Vehicular networks
>>                   http://www.weedev.org/
>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>
>>     

From: liebsch at nw.neclab.eu (Marco Liebsch)
Date: Mon, 16 Feb 2009 17:44:01 +0100
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Hidetoshi,

please find my comments in-line.

Hidetoshi Yokota wrote:
> Hi Marco, Telemaco, Raj and all,
>
> This thread is interesting and important for the start. Let me clarify
> the problem that we are trying to solve. The MN has multiple interfaces
> and multiple addresses assigned by multiple MAGs and can setup multiple
> sessions with multiple CNs (either mobile or plain IPv6 hosts)
> simultaneously. However, the MN has only one MN-ID and only one LMA (in
> the scople of the multihoming problem we are discussing now).
So far I am ok.
>  The
> addresses assigned for the MN can be bound to any interface of the MN
> and the sessions associated with those addresses can go through any
> interface of the MN.
Well, here we should stick to the PMIP concept be clear: An MN's
interface cannot simply use any address, but should use the HNP,
which has been assigned to the interface during its registration.
And this is under control of the LMA (or the AAA behind). So, in
my opinion, an MN can use an HNP for an interface only if the
HNP has been assigned to this interface during the registration.
Maybe that's what you mean.
>  Also, those addresses and corresponding sessions
> can migrate to other interfaces of the MN in the middle. The following
> diagram simply shows this situation:
>   
Maybe I read the diagram in the wrong way, but there should not be
a 'mesh'-like relationship between all addresses (1-K) and all IFs (1-J).

marco

> /------- MN --------\
>                         Session#1
>                Addr#1   Session#2                 CN#1
>         IF#1   Addr#2   Session#3   MAG#1         CN#2
> MN-ID   IF#2   Addr#3   ...         MAG#2   LMA   ...
>         ...    ...      ...         ...           ...
>         IF#J   ...      ...         MAG#M         CN#N
>                Addr#K   ...
>                         Session#L
>
> Is this the correct view that we are discussing now?
>
> Regards,
>   

From: Telemaco.Melia at alcatel-lucent.com (MELIA TELEMACO)
Date: Mon, 16 Feb 2009 14:14:18 +0100
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Hidetoshi,

I took the liberty to edit your post according (I hope) to what Marco and I have been saying. Here it goes:

                            Session2_CN1
                   Addr_1   Session1_CN1
            IF#1                             MAG#1        CN#1
                   Addr_2   Session1_CN2

    MN-ID                                            LMA

                   Addr_1
            IF#2                             MAG#2         CN#2
                   Addr_2   Session2_CN2

According to the pic the MN can a) request multiple addresses (depending on the service he might want to get) and b) configure the very same address on multiple interfaces to allow flow mobility (e.g. Session2_CN1 can be moved to IF#2 Addr_1). If you do not configure the same address I wonder how the LMA can route flows since the CN1 always send to the same HNP (Addr_1).

Marco this is your understanding as well?

thanks

telemaco

-----Message d'origine-----
De : Hidetoshi Yokota [mailto:yokota at kddilabs.jp]
Envoy? : lundi 16 f?vrier 2009 13:15
? : Marco Liebsch
Cc : MELIA TELEMACO; netext at mail.mobileip.jp; Basavaraj.Patil at nokia.com
Objet : Re: [Netext] Review of the Multihoming PS I-D

Hi Marco, Telemaco, Raj and all,

This thread is interesting and important for the start. Let me clarify the problem that we are trying to solve. The MN has multiple interfaces and multiple addresses assigned by multiple MAGs and can setup multiple sessions with multiple CNs (either mobile or plain IPv6 hosts) simultaneously. However, the MN has only one MN-ID and only one LMA (in the scople of the multihoming problem we are discussing now). The addresses assigned for the MN can be bound to any interface of the MN and the sessions associated with those addresses can go through any interface of the MN. Also, those addresses and corresponding sessions can migrate to other interfaces of the MN in the middle. The following diagram simply shows this situation:

/------- MN --------\
                        Session#1
               Addr#1   Session#2                 CN#1
        IF#1   Addr#2   Session#3   MAG#1         CN#2
MN-ID   IF#2   Addr#3   ...         MAG#2   LMA   ...
        ...    ...      ...         ...           ...
        IF#J   ...      ...         MAG#M         CN#N
               Addr#K   ...
                        Session#L

Is this the correct view that we are discussing now?

Regards,
--
Hidetoshi

Marco Liebsch wrote:
> Hi,
>
> I agree that we should consider support of use cases where mulitple
> interfaces of an MN get the same HNP assiged. One step further, the MN
> must configure the same suffix to allow flow mobility and keep flow
> distribution etc.
> transparent
> to a CN.
>
> Regarding Raj's comments: I fully agree that we need to specify the
> scope of what we'll solve in NetExt and my opinion is that the focus
> should be first on the definition of a set of target use cases, as too
> many of them are treated under the umbrella of multihoming. Then let's
> analyze where RFC5213 needs some more work to support them.
>
> Whereas I think that most of this work will be on the LMA to allow the
> assignment of the same HNP to multiple interfaces and to support
> inter-working with policy based forwarding, I do *not* think that
> PMIPv6 signaling should be extended to support in-band configuration
> of such policy routing at the LMA. Hence, we should thoroughly define
> the scope of the solution space before.
>
> marco
>
>
>
> MELIA TELEMACO schrieb:
>> Hello,
>>
>> In principle I am fine with the 4 points Raj proposed. In addition, I
>> would stress scenarios where the same HNP (and same IP address) is
>> configured across several interfaces. I believe these scenarios are
>> very useful for flow mobility and flow distributions.
>> Comments?
>>
>> telemaco
>> -----Message d'origine-----
>> De : netext-bounces at mail.mobileip.jp
>> [mailto:netext-bounces at mail.mobileip.jp] De la part de
>> Basavaraj.Patil at nokia.com Envoye' : mercredi 4 fe'vrier 2009 15:56 A`
>> : netext at mail.mobileip.jp Cc : Basavaraj.Patil at nokia.com Objet :
>> [Netext] Review of the Multihoming PS I-D
>>
>>
>> Hello,
>>
>> I have reviewed the Netext Multihoming PS I-D
>> <draft-jeyatharan-netext-multihoming-ps-00>. Thanks to Mohana for her
>> efforts on getting this I-D ready.
>>
>> 1. My impression after reading the I-D is that it misses the key
>>    problem of multihoming that we are trying to work on. Proxy MIP6 as
>>    currently specified in RFC5213 has limited support for
>>    multihoming. It was decided that multihoming should be dealt with
>>    separately in Netlmm during the course discussions on this topic in
>>    the past. While many of the issues mentioned in the I-D are
>>    relevant I believe that Netext should be working on a more narrow
>>    scope to enhance PMIP6 to support a few multihoming scenarios.
>>
>> 2. Sec 3 of the I-D which analyses multihoming issues in the case of
>>    PMIP6/CMIP6 coexisting together is really misplaced here. I do not
>>    believe we want to address this topic as part of the multihoming
>>    work in Netext. This is simply out of scope.
>>
>> 3. The I-D focuses on the problem of multiplexing flows or having
>>    flows traverse via one interface or another or the ability to move
>>    a flow from one interface to another. While these are all valid
>>    things to do in PMIP6, I am not convinced that these are
>>    specifically related to multihoming.
>>
>> Rajeev and I had a discussion on the scope of multihoming and what we
>> should really be focusing on. We came up with the following specific
>> scenarios which we should address:
>>
>> a. The multihoming work in Netext should address the limitations of
>> RFC5213
>>    w.r.t multihoming. The issue of having a single BCE for an MN
>>    identified by an MN-ID and attaching via multiple interfaces should
>>    be resolved.
>>
>> b. The scenario where an MN is connected via a MAG to an LMA and the
>>    ability to establish multiple sessions via the same MAG. This is
>>    the case where the MN is attached via a specific access type and
>>    establishes multiple IP sessions via the MAG.
>>
>> c. The scenario where an MN attaches via different interfaces which
>>    are of differing access technologies via MAG1 and MAG2
>>    simultaneously. The MAG1/MAG2 entities are attached to the same
>>    LMA.
>>
>> d. A combination of the scenarios in (b) and (c), i.e having multiple
>>    sessions via each access type while connected thru different MAGs
>>    simultaneously.
>>
>> Lets see if we can build some consensus around the scope of the problem.
>>
>> -Raj
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>  
>
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090216/26053090/attachment-0001.html>

From: yokota at kddilabs.jp (Hidetoshi Yokota)
Date: Mon, 16 Feb 2009 21:15:20 +0900
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]>	<[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Marco, Telemaco, Raj and all,

This thread is interesting and important for the start. Let me clarify
the problem that we are trying to solve. The MN has multiple interfaces
and multiple addresses assigned by multiple MAGs and can setup multiple
sessions with multiple CNs (either mobile or plain IPv6 hosts)
simultaneously. However, the MN has only one MN-ID and only one LMA (in
the scople of the multihoming problem we are discussing now). The
addresses assigned for the MN can be bound to any interface of the MN
and the sessions associated with those addresses can go through any
interface of the MN. Also, those addresses and corresponding sessions
can migrate to other interfaces of the MN in the middle. The following
diagram simply shows this situation:

/------- MN --------\
                        Session#1
               Addr#1   Session#2                 CN#1
        IF#1   Addr#2   Session#3   MAG#1         CN#2
MN-ID   IF#2   Addr#3   ...         MAG#2   LMA   ...
        ...    ...      ...         ...           ...
        IF#J   ...      ...         MAG#M         CN#N
               Addr#K   ...
                        Session#L

Is this the correct view that we are discussing now?

Regards,
-- 
Hidetoshi

Marco Liebsch wrote:
> Hi,
> 
> I agree that we should consider support of use cases where mulitple 
> interfaces
> of an MN get the same HNP assiged. One step further, the MN must configure
> the same suffix to allow flow mobility and keep flow distribution etc. 
> transparent
> to a CN.
> 
> Regarding Raj's comments: I fully agree that we need to specify the 
> scope of what
> we'll solve in NetExt and my opinion is that the focus should be first 
> on the definition of
> a set of target use cases, as too many of them are treated under the 
> umbrella of
> multihoming. Then let's analyze where RFC5213 needs some more work to 
> support them.
> 
> Whereas I think that most of this work will be on the LMA to allow the 
> assignment of
> the same HNP to multiple interfaces and to support inter-working with 
> policy based
> forwarding, I do *not* think that PMIPv6 signaling should be extended to 
> support
> in-band configuration of such policy routing at the LMA. Hence, we 
> should thoroughly
> define the scope of the solution space before.
> 
> marco
> 
> 
> 
> MELIA TELEMACO schrieb:
>> Hello,
>>
>> In principle I am fine with the 4 points Raj proposed. In addition, I 
>> would stress scenarios where the same HNP (and same IP address) is 
>> configured across several interfaces. I believe these scenarios are 
>> very useful for flow mobility and flow distributions.
>> Comments?
>>
>> telemaco
>> -----Message d'origine-----
>> De : netext-bounces at mail.mobileip.jp 
>> [mailto:netext-bounces at mail.mobileip.jp] De la part de 
>> Basavaraj.Patil at nokia.com
>> Envoye' : mercredi 4 fe'vrier 2009 15:56
>> A` : netext at mail.mobileip.jp
>> Cc : Basavaraj.Patil at nokia.com
>> Objet : [Netext] Review of the Multihoming PS I-D
>>
>>
>> Hello,
>>
>> I have reviewed the Netext Multihoming PS I-D 
>> <draft-jeyatharan-netext-multihoming-ps-00>. Thanks to Mohana for her 
>> efforts on getting this I-D ready.
>>
>> 1. My impression after reading the I-D is that it misses the key
>>    problem of multihoming that we are trying to work on. Proxy MIP6 as
>>    currently specified in RFC5213 has limited support for
>>    multihoming. It was decided that multihoming should be dealt with
>>    separately in Netlmm during the course discussions on this topic in
>>    the past. While many of the issues mentioned in the I-D are
>>    relevant I believe that Netext should be working on a more narrow
>>    scope to enhance PMIP6 to support a few multihoming scenarios.
>>
>> 2. Sec 3 of the I-D which analyses multihoming issues in the case of
>>    PMIP6/CMIP6 coexisting together is really misplaced here. I do not
>>    believe we want to address this topic as part of the multihoming
>>    work in Netext. This is simply out of scope.
>>
>> 3. The I-D focuses on the problem of multiplexing flows or having
>>    flows traverse via one interface or another or the ability to move
>>    a flow from one interface to another. While these are all valid
>>    things to do in PMIP6, I am not convinced that these are
>>    specifically related to multihoming.
>>
>> Rajeev and I had a discussion on the scope of multihoming and what we 
>> should really be focusing on. We came up with the following specific 
>> scenarios which we should address:
>>
>> a. The multihoming work in Netext should address the limitations of 
>> RFC5213
>>    w.r.t multihoming. The issue of having a single BCE for an MN
>>    identified by an MN-ID and attaching via multiple interfaces should
>>    be resolved.
>>
>> b. The scenario where an MN is connected via a MAG to an LMA and the
>>    ability to establish multiple sessions via the same MAG. This is
>>    the case where the MN is attached via a specific access type and
>>    establishes multiple IP sessions via the MAG.
>>
>> c. The scenario where an MN attaches via different interfaces which
>>    are of differing access technologies via MAG1 and MAG2
>>    simultaneously. The MAG1/MAG2 entities are attached to the same
>>    LMA.
>>
>> d. A combination of the scenarios in (b) and (c), i.e having multiple
>>    sessions via each access type while connected thru different MAGs
>>    simultaneously.
>>
>> Lets see if we can build some consensus around the scope of the problem.
>>
>> -Raj
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>   
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 
> 
> 

From: marco.liebsch at nw.neclab.eu (Marco Liebsch)
Date: Mon, 16 Feb 2009 12:16:48 +0100
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi,

I agree that we should consider support of use cases where mulitple 
interfaces
of an MN get the same HNP assiged. One step further, the MN must configure
the same suffix to allow flow mobility and keep flow distribution etc. 
transparent
to a CN.

Regarding Raj's comments: I fully agree that we need to specify the 
scope of what
we'll solve in NetExt and my opinion is that the focus should be first 
on the definition of
a set of target use cases, as too many of them are treated under the 
umbrella of
multihoming. Then let's analyze where RFC5213 needs some more work to 
support them.

Whereas I think that most of this work will be on the LMA to allow the 
assignment of
the same HNP to multiple interfaces and to support inter-working with 
policy based
forwarding, I do *not* think that PMIPv6 signaling should be extended to 
support
in-band configuration of such policy routing at the LMA. Hence, we 
should thoroughly
define the scope of the solution space before.

marco

MELIA TELEMACO schrieb:
> Hello,
>
> In principle I am fine with the 4 points Raj proposed. In addition, I would stress scenarios where the same HNP (and same IP address) is configured across several interfaces. I believe these scenarios are very useful for flow mobility and flow distributions. 
>
> Comments?
>
> telemaco 
>
> -----Message d'origine-----
> De : netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] De la part de Basavaraj.Patil at nokia.com
> Envoy? : mercredi 4 f?vrier 2009 15:56
> ? : netext at mail.mobileip.jp
> Cc : Basavaraj.Patil at nokia.com
> Objet : [Netext] Review of the Multihoming PS I-D
>
>
> Hello,
>
> I have reviewed the Netext Multihoming PS I-D <draft-jeyatharan-netext-multihoming-ps-00>. Thanks to Mohana for her efforts on getting this I-D ready.
>
> 1. My impression after reading the I-D is that it misses the key
>    problem of multihoming that we are trying to work on. Proxy MIP6 as
>    currently specified in RFC5213 has limited support for
>    multihoming. It was decided that multihoming should be dealt with
>    separately in Netlmm during the course discussions on this topic in
>    the past. While many of the issues mentioned in the I-D are
>    relevant I believe that Netext should be working on a more narrow
>    scope to enhance PMIP6 to support a few multihoming scenarios.
>
> 2. Sec 3 of the I-D which analyses multihoming issues in the case of
>    PMIP6/CMIP6 coexisting together is really misplaced here. I do not
>    believe we want to address this topic as part of the multihoming
>    work in Netext. This is simply out of scope.
>
> 3. The I-D focuses on the problem of multiplexing flows or having
>    flows traverse via one interface or another or the ability to move
>    a flow from one interface to another. While these are all valid
>    things to do in PMIP6, I am not convinced that these are
>    specifically related to multihoming.
>
> Rajeev and I had a discussion on the scope of multihoming and what we should really be focusing on. We came up with the following specific scenarios which we should address:
>
> a. The multihoming work in Netext should address the limitations of RFC5213
>    w.r.t multihoming. The issue of having a single BCE for an MN
>    identified by an MN-ID and attaching via multiple interfaces should
>    be resolved.
>
> b. The scenario where an MN is connected via a MAG to an LMA and the
>    ability to establish multiple sessions via the same MAG. This is
>    the case where the MN is attached via a specific access type and
>    establishes multiple IP sessions via the MAG.
>
> c. The scenario where an MN attaches via different interfaces which
>    are of differing access technologies via MAG1 and MAG2
>    simultaneously. The MAG1/MAG2 entities are attached to the same
>    LMA.
>
> d. A combination of the scenarios in (b) and (c), i.e having multiple
>    sessions via each access type while connected thru different MAGs
>    simultaneously.
>
> Lets see if we can build some consensus around the scope of the problem.
>
> -Raj
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>   

From: behcetsarikaya at yahoo.com (Behcet Sarikaya)
Date: Sun, 15 Feb 2009 12:18:06 -0800 (PST)
Subject: [Netext] Review of the Multihoming PS I-D
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Telemaco,

________________________________
From: MELIA TELEMACO <Telemaco.Melia at alcatel-lucent.com>
To: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
Sent: Friday, February 13, 2009 11:23:58 AM
Subject: Re: [Netext] Review of the Multihoming PS I-D

Hello,

In principle I am fine with the 4 points Raj proposed. In addition, I would stress scenarios where the same HNP (and same IP address) is configured across several interfaces. I believe these scenarios are very useful for flow mobility and flow distributions. 

[behcet] Why? Do you expect prefix run-out soon?

Regards,

Behcet

      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090215/42273a41/attachment.html>

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Fri, 13 Feb 2009 19:11:30 -0500
Subject: [Netext] First Problem Statement about LocalizedRoutingin	PMIPv6 submitted
In-Reply-To: <1234370715.5174.9.camel@localhost>
Message-ID: <[email-masked]>

Hi,
 
> I fully agree that the whole point of PMIP is make mobility 
> management transparent to the MN. However, as far as I 
> understand from my reading of RFC5213, a mobile node attached 
> to a PMIPv6 domain might not be entitled to the network-based 
> mobility management service, and RFC5213 (section 6.14) still 
> support this node to get connectivity (regular
> access) from the MAG.

I need to look into this, but I have no idea how a MAG can distinguish the two nodes..

> 
> Related to this, it is also my interpretation of RFC5213 (section
> 6.10.5) that the local routing support provided by the basic 
> spec (controlled with the EnableMAGLocalRouting flag) only 
> applies to communications between a PMIPv6 MN and a regular 
> IPv6 host attached to the same MAG.

This sounds even more interesting because the "regular IPv6 host" gets better performance!
So, all you have to do is to declare that you are not a PMIP6 MN to get better VoIP quality :-)

Regards,

-Rajeev

> 
> This is just to try to clarify what RFC5213 provides (actually, very
> little) and what does not in regards to local routing 
> support. Do you see my point?
> 
> Thanks!
> 
> Carlos
> 
> > 
> > 
> > > 
> > > 	- If my previous understanding is correct, then RFC5213 
> does not 
> > > only define any mechanism to perform local routing 
> between two MNs 
> > > connected to the same PMIPv6 domain (not even for the 
> case in which 
> > > both are attached to the same MAG).
> > > Then, IMHO it would be better to change the terminology in the PS 
> > > and avoid using CN or coming up with different terms for 
> a CN that 
> > > is getting network-based mobility service from a CN that is not 
> > > (i.e. it is just a regular IPv6 node getting access from a MAG).
> > 
> > See above.
> > 
> > > 
> > > 	- Currently, the PS only addresses the case of local routing 
> > > between two MNs connected to the same PMIPv6 domain.
> > > I think the scenario of optimising traffic between an MN and a 
> > > regular IPv6 host that is locally connected to a MAG 
> should also be 
> > > addressed. Not sure the implications on the potential 
> solutions, but 
> > > it might have an impact on the classification scheme that 
> is used in 
> > > the PS now (A[number of MAGs][number of LMAs]).
> > > 
> > 
> > Our focus should be on solving the problem for nodes 
> attached to a PMIP6 domain.
> > 
> > Thanks,
> > 
> > -Rajeev
> > 
> > 
> > > 	Thanks,
> > > 
> > > 	Carlos
> > > 
> > > El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?:
> > > > Hi all,
> > > > 
> > > > please find the link to a first version of a Localized
> > > Routing Problem
> > > > Statement below.
> > > > The abstract of the PS document is as follows:
> > > > 
> > > > Abstract:
> > > > 
> > > >    Proxy Mobile IPv6 is the IETF standard for network-based
> > > localized
> > > >    mobility management.  In Proxy Mobile IPv6, mobile nodes are
> > > >    topologically anchored at a Local Mobility Anchor, which
> > > forwards all
> > > >    data for registered mobile nodes.  The set up and support for
> > > >    localized routing, which allows forwarding of data
> > > packets between
> > > >    mobile nodes and correspondent nodes directly without
> > > traversing an
> > > >    LMA, is not considered.  This document describes the
> > > problem space of
> > > >    localized routing in Proxy Mobile IPv6.
> > > > 
> > > > 
> > > > Any comments to this version of the problem statement 
> are welcome.
> > > > 
> > > > 
> > > 
> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps
> > > -0
> > > > 0.txt
> > > > 
> > > > Best regards,
> > > > marco
> > > > 
> > > > 
> > > > _______________________________________________
> > > > NetExt mailing list
> > > > NetExt at mail.mobileip.jp
> > > > http://www.mobileip.jp/mailman/listinfo/netext
> > > -- 
> > >  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> > >  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > >   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> > >         Deployment Experiences on Vehicular networks
> > >                   http://www.weedev.org/
> > > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > > 
> > 
> > 
> > This email and any attachments may contain legally 
> privileged and/or confidential information of Starent 
> Networks, Corp. and is intended only for the individual or 
> entity named in the message.  The information transmitted may 
> not be used to create or change any contractual obligations 
> of Starent Networks, Corp.  Any review, retransmission, 
> dissemination or other use of, or taking of any action in 
> reliance upon this e-mail and its attachments by persons or 
> entities other than the intended recipient is prohibited. If 
> you are not the intended recipient, please notify the sender 
> immediately -- by replying to this message or by sending an 
> email to postmaster at starentnetworks.com -- and destroy all 
> copies of this message and any attachments without reading or 
> disclosing their contents. Thank you.
> -- 
>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
>         Deployment Experiences on Vehicular networks
>                   http://www.weedev.org/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 

From: Telemaco.Melia at alcatel-lucent.com (MELIA TELEMACO)
Date: Fri, 13 Feb 2009 18:23:58 +0100
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hello,

In principle I am fine with the 4 points Raj proposed. In addition, I would stress scenarios where the same HNP (and same IP address) is configured across several interfaces. I believe these scenarios are very useful for flow mobility and flow distributions. 

Comments?

telemaco 

-----Message d'origine-----
De : netext-bounces at mail.mobileip.jp [mailto:netext-bounces at mail.mobileip.jp] De la part de Basavaraj.Patil at nokia.com
Envoy? : mercredi 4 f?vrier 2009 15:56
? : netext at mail.mobileip.jp
Cc : Basavaraj.Patil at nokia.com
Objet : [Netext] Review of the Multihoming PS I-D

Hello,

I have reviewed the Netext Multihoming PS I-D <draft-jeyatharan-netext-multihoming-ps-00>. Thanks to Mohana for her efforts on getting this I-D ready.

1. My impression after reading the I-D is that it misses the key
   problem of multihoming that we are trying to work on. Proxy MIP6 as
   currently specified in RFC5213 has limited support for
   multihoming. It was decided that multihoming should be dealt with
   separately in Netlmm during the course discussions on this topic in
   the past. While many of the issues mentioned in the I-D are
   relevant I believe that Netext should be working on a more narrow
   scope to enhance PMIP6 to support a few multihoming scenarios.

2. Sec 3 of the I-D which analyses multihoming issues in the case of
   PMIP6/CMIP6 coexisting together is really misplaced here. I do not
   believe we want to address this topic as part of the multihoming
   work in Netext. This is simply out of scope.

3. The I-D focuses on the problem of multiplexing flows or having
   flows traverse via one interface or another or the ability to move
   a flow from one interface to another. While these are all valid
   things to do in PMIP6, I am not convinced that these are
   specifically related to multihoming.

Rajeev and I had a discussion on the scope of multihoming and what we should really be focusing on. We came up with the following specific scenarios which we should address:

a. The multihoming work in Netext should address the limitations of RFC5213
   w.r.t multihoming. The issue of having a single BCE for an MN
   identified by an MN-ID and attaching via multiple interfaces should
   be resolved.

b. The scenario where an MN is connected via a MAG to an LMA and the
   ability to establish multiple sessions via the same MAG. This is
   the case where the MN is attached via a specific access type and
   establishes multiple IP sessions via the MAG.

c. The scenario where an MN attaches via different interfaces which
   are of differing access technologies via MAG1 and MAG2
   simultaneously. The MAG1/MAG2 entities are attached to the same
   LMA.

d. A combination of the scenarios in (b) and (c), i.e having multiple
   sessions via each access type while connected thru different MAGs
   simultaneously.

Lets see if we can build some consensus around the scope of the problem.

-Raj

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

From: liebsch at nw.neclab.eu (Marco Liebsch)
Date: Thu, 12 Feb 2009 09:53:18 +0100
Subject: [Netext] First Problem Statement about Localized Routing	in	PMIPv6 submitted
In-Reply-To: <1234371603.5174.26.camel@localhost>
References: <[email-masked]>	 <1234339777.21602.198.camel@localhost> <[email-masked]> <1234371603.5174.26.camel@localhost>
Message-ID: <[email-masked]>

Hi Carlos,

Carlos Jes?s Bernardos Cano wrote:
> Hi Marco,
>
> El mi?, 11-02-2009 a las 10:24 +0100, Marco Liebsch escribi?: 
>   
>> Hi Carlos,
>>
>> thanks for the feedback!
>> Please find my view and answers to your comments below.
>>
>> Carlos Jes?s Bernardos Cano wrote:
>>     
>>> Hi Marco, all,
>>>
>>> 	I've just read your document. Thanks for writing it!
>>>
>>> 	I have some comments/questions:
>>>
>>> 	- Regarding EnableMAGLocalRouting flag: in addition to what has been
>>> already discussed in this list, I want to check whether my understanding
>>> of RFC5213 is right or not. As far as I understand it, the local routing
>>> mechanism that is slightly defined in PMIPv6 specs refers to the
>>> optimisation of data traffic between an MN and a regular IPv6 node (a
>>> node that is not getting network-based mobility service from the PMIPv6
>>> domain) that are both connected to the same MAG. This is what I
>>> understand from reading sections 6.10.5 and 6.14, though IMHO this is
>>> not clearly specified in RFC5213. Is this correct or am I missing
>>> something?
>>>   
>>>       
>> Well, I think both is intrinsically supported (maybe without
>> intention), a PMIPv6-attached CN or an IPv6 CN, that uses the
>> network component, which implements the MAG, as AR. In the
>> first case, the MAG has a BUL entry and an associated route
>> entry for the CN, in the latter case, the AR has a route
>> entry for the CN. So prefix routing should work in both cases.
>> The only thing you need to take care in the IPv6 case is that
>> the MAG allows deviations from a default route for the MN's
>> traffic, which should not go through the LMA then, but should be
>> forwarded according to the local routing table. However, all these
>> things are not described in RFC5213, for good reasons, as this
>> was not the focus.
>>     
>
> Yes, I agree both cases are not so different, but there are still
> differences. I'm not sure RFC5214 intrinsically supports both, since
> there are explicit references to "IPv6..." Besides the IPv6 address of a
> regular IPv6 host (IPv6 CN, as you called it) is anchored at the MAG,
> while the IPv6 prefix used by a PMIPv6 MN is anchored at the LMA, so
> there might be some subtle differences.
>   
Yes, I understand the difference.

>   
>>> 	- If my previous understanding is correct, then RFC5213 does not only
>>> define any mechanism to perform local routing between two MNs connected
>>> to the same PMIPv6 domain (not even for the case in which both are
>>> attached to the same MAG). Then, IMHO it would be better to change the
>>> terminology in the PS and avoid using CN or coming up with different
>>> terms for a CN that is getting network-based mobility service from a CN
>>> that is not (i.e. it is just a regular IPv6 node getting access from a
>>> MAG).
>>>   
>>>       
>> Ok, the idea was the following: MN and CN have been chosen to
>> distinguish the two mobile nodes. Now, as we thought about more
>> use cases before, such as for example setting up RO between a
>> PMIPv6 attached MN and a MIPv6 CN, the intention was to keep
>> MN and CN as terms, but to refer to a specific use case in addition.
>> So, if there is a discussion about a RO 'association' between an MN
>> and a CN, both are PMIPv6 attached, its for example a use case
>> according to A12. RO with a MIPv6 CN should be described as B
>> use cases (e.g. B12). We could introduce more uses cases to cover
>> RO with an IPv6 node, such as C2.
>>     
>
> Ummm, this is getting too complex. Maybe I didn't explain well in my
> previous e-mail. What I had in mind are two different scenarios:
>
> - PMIPv6 MNs: that is, MNs getting network-based mobility management
> - Regular IPv6 hosts (we can call them IPv6 CNs): that is, nodes locally
> attached to a MAG that don't benefit from a network-based mobility
> management (i.e., they configure their IPv6 address from a local
> "visited" prefix, not from a prefix managed by an LMA).
>   
Yes, I agree that we may look into such use case and see if there is
anything more to be done to support it.

> I didn't add the third variable of MIPv6 CNs 
No, but I did ;-)

> (i.e., nodes that support
> the CN functionality of MIPv6 RO). I'll leave that case out of the PS
> for the time being.
>
>   
>> Alternatively (or in addition) we could distinguish the mobile devices
>> by means of extensions (CN_IP6, CN_MIP6), but this does not cover
>> the use cases and all the variants of a particular use case yet.
>> More in this context below.
>>     
>
> OK, I see now. One thing is the scenario based on the attachment points
> of the end-points of the communication (MAGs) and the number of involved
> LMAs. A different thing is the type of node a PMIPv6 MN is communicating
> to (it may be a PMIPv6 MN, an IPv6 CN or a MIPv6 CN).
>   
Yes.

>   
>>> 	- Currently, the PS only addresses the case of local routing between
>>> two MNs connected to the same PMIPv6 domain. I think the scenario of
>>> optimising traffic between an MN and a regular IPv6 host that is locally
>>> connected to a MAG should also be addressed. Not sure the implications
>>> on the potential solutions, but it might have an impact on the
>>> classification scheme that is used in the PS now (A[number of
>>> MAGs][number of LMAs]).
>>>   
>>>       
>> I don't see an issue here, as we can differentiate the mobility
>> mode (if there is any) of both nodes by means of the use case
>> (A,B,C,...). Since the IPv6 CN will not have a mobility anchor,
>> we should indicate only the amount of involved ARs/MAGs (such as C2).
>>     
>
> I don't want to bring a new issue. I just tried to point out that it
> might be good to highlight that the type of node is also important. I'm
> fine with adding a new variable on the use cases to reflect that.
>   
Yes, independent of different types of nodes and how they are attached
to the network infrastructure we should agree on the scope of a future 
solution
and either keep it as it is or add one or the other use case to the PS 
doc accordingly.

>   
>> Ok, long story above. Fact is that the scope of the PS doc has been
>> cut to the current NetExt charter, which focuses in particular on RO
>> between two PMIPv6 attached MNs. Larger scope needs to be discussed
>> and agreed on. If we need more use cases, we could describe them as
>> proposed above or by other means.
>>     
>
> OK, if it is already clear and agreed that we just want to address the
> problem of RO between two PMIPv6 attached MNs, then I'm fine. The only
> point to clarify would be then the use of the intended use of the
> EnableMAGLocalRouting flag in RFC5213...
>   
As I said, the PS currently covers cases according to the NetExt scope.
Whether or not to add one or the other use case or CN type, that's something
we need to work out, so that we can update the PS doc accordingly.
If we stick to support of RO between two PMIPv6 attached nodes, fine,
then we probably have to go only through some editorial revision.

marco

> Thanks!
>
> Carlos
>
>   
>> marco
>>
>>     
>>> 	Thanks,
>>>
>>> 	Carlos
>>>
>>> El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?:
>>>   
>>>       
>>>> Hi all,
>>>>
>>>> please find the link to a first version of a Localized Routing Problem 
>>>> Statement below.
>>>> The abstract of the PS document is as follows:
>>>>
>>>> Abstract:
>>>>
>>>>    Proxy Mobile IPv6 is the IETF standard for network-based localized
>>>>    mobility management.  In Proxy Mobile IPv6, mobile nodes are
>>>>    topologically anchored at a Local Mobility Anchor, which forwards all
>>>>    data for registered mobile nodes.  The set up and support for
>>>>    localized routing, which allows forwarding of data packets between
>>>>    mobile nodes and correspondent nodes directly without traversing an
>>>>    LMA, is not considered.  This document describes the problem space of
>>>>    localized routing in Proxy Mobile IPv6.
>>>>
>>>>
>>>> Any comments to this version of the problem statement are welcome.
>>>>
>>>> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps-00.txt
>>>>
>>>> Best regards,
>>>> marco
>>>>
>>>>
>>>> _______________________________________________
>>>> NetExt mailing list
>>>> NetExt at mail.mobileip.jp
>>>> http://www.mobileip.jp/mailman/listinfo/netext
>>>>     
>>>>         

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Wed, 11 Feb 2009 18:00:03 +0100
Subject: [Netext] First Problem Statement about Localized Routing	in	PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]> <1234339777.21602.198.camel@localhost> <[email-masked]>
Message-ID: <1234371603.5174.26.camel@localhost>

Hi Marco,

El mi?, 11-02-2009 a las 10:24 +0100, Marco Liebsch escribi?: 
> Hi Carlos,
> 
> thanks for the feedback!
> Please find my view and answers to your comments below.
> 
> Carlos Jes?s Bernardos Cano wrote:
> > Hi Marco, all,
> >
> > 	I've just read your document. Thanks for writing it!
> >
> > 	I have some comments/questions:
> >
> > 	- Regarding EnableMAGLocalRouting flag: in addition to what has been
> > already discussed in this list, I want to check whether my understanding
> > of RFC5213 is right or not. As far as I understand it, the local routing
> > mechanism that is slightly defined in PMIPv6 specs refers to the
> > optimisation of data traffic between an MN and a regular IPv6 node (a
> > node that is not getting network-based mobility service from the PMIPv6
> > domain) that are both connected to the same MAG. This is what I
> > understand from reading sections 6.10.5 and 6.14, though IMHO this is
> > not clearly specified in RFC5213. Is this correct or am I missing
> > something?
> >   
> Well, I think both is intrinsically supported (maybe without
> intention), a PMIPv6-attached CN or an IPv6 CN, that uses the
> network component, which implements the MAG, as AR. In the
> first case, the MAG has a BUL entry and an associated route
> entry for the CN, in the latter case, the AR has a route
> entry for the CN. So prefix routing should work in both cases.
> The only thing you need to take care in the IPv6 case is that
> the MAG allows deviations from a default route for the MN's
> traffic, which should not go through the LMA then, but should be
> forwarded according to the local routing table. However, all these
> things are not described in RFC5213, for good reasons, as this
> was not the focus.

Yes, I agree both cases are not so different, but there are still
differences. I'm not sure RFC5214 intrinsically supports both, since
there are explicit references to "IPv6..." Besides the IPv6 address of a
regular IPv6 host (IPv6 CN, as you called it) is anchored at the MAG,
while the IPv6 prefix used by a PMIPv6 MN is anchored at the LMA, so
there might be some subtle differences.

> > 	- If my previous understanding is correct, then RFC5213 does not only
> > define any mechanism to perform local routing between two MNs connected
> > to the same PMIPv6 domain (not even for the case in which both are
> > attached to the same MAG). Then, IMHO it would be better to change the
> > terminology in the PS and avoid using CN or coming up with different
> > terms for a CN that is getting network-based mobility service from a CN
> > that is not (i.e. it is just a regular IPv6 node getting access from a
> > MAG).
> >   
> Ok, the idea was the following: MN and CN have been chosen to
> distinguish the two mobile nodes. Now, as we thought about more
> use cases before, such as for example setting up RO between a
> PMIPv6 attached MN and a MIPv6 CN, the intention was to keep
> MN and CN as terms, but to refer to a specific use case in addition.
> So, if there is a discussion about a RO 'association' between an MN
> and a CN, both are PMIPv6 attached, its for example a use case
> according to A12. RO with a MIPv6 CN should be described as B
> use cases (e.g. B12). We could introduce more uses cases to cover
> RO with an IPv6 node, such as C2.

Ummm, this is getting too complex. Maybe I didn't explain well in my
previous e-mail. What I had in mind are two different scenarios:

- PMIPv6 MNs: that is, MNs getting network-based mobility management
- Regular IPv6 hosts (we can call them IPv6 CNs): that is, nodes locally
attached to a MAG that don't benefit from a network-based mobility
management (i.e., they configure their IPv6 address from a local
"visited" prefix, not from a prefix managed by an LMA).

I didn't add the third variable of MIPv6 CNs (i.e., nodes that support
the CN functionality of MIPv6 RO). I'll leave that case out of the PS
for the time being.

> 
> Alternatively (or in addition) we could distinguish the mobile devices
> by means of extensions (CN_IP6, CN_MIP6), but this does not cover
> the use cases and all the variants of a particular use case yet.
> More in this context below.

OK, I see now. One thing is the scenario based on the attachment points
of the end-points of the communication (MAGs) and the number of involved
LMAs. A different thing is the type of node a PMIPv6 MN is communicating
to (it may be a PMIPv6 MN, an IPv6 CN or a MIPv6 CN).

> > 	- Currently, the PS only addresses the case of local routing between
> > two MNs connected to the same PMIPv6 domain. I think the scenario of
> > optimising traffic between an MN and a regular IPv6 host that is locally
> > connected to a MAG should also be addressed. Not sure the implications
> > on the potential solutions, but it might have an impact on the
> > classification scheme that is used in the PS now (A[number of
> > MAGs][number of LMAs]).
> >   
> I don't see an issue here, as we can differentiate the mobility
> mode (if there is any) of both nodes by means of the use case
> (A,B,C,...). Since the IPv6 CN will not have a mobility anchor,
> we should indicate only the amount of involved ARs/MAGs (such as C2).

I don't want to bring a new issue. I just tried to point out that it
might be good to highlight that the type of node is also important. I'm
fine with adding a new variable on the use cases to reflect that.

> 
> Ok, long story above. Fact is that the scope of the PS doc has been
> cut to the current NetExt charter, which focuses in particular on RO
> between two PMIPv6 attached MNs. Larger scope needs to be discussed
> and agreed on. If we need more use cases, we could describe them as
> proposed above or by other means.

OK, if it is already clear and agreed that we just want to address the
problem of RO between two PMIPv6 attached MNs, then I'm fine. The only
point to clarify would be then the use of the intended use of the
EnableMAGLocalRouting flag in RFC5213...

Thanks!

Carlos

> 
> marco
> 
> > 	Thanks,
> >
> > 	Carlos
> >
> > El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?:
> >   
> >> Hi all,
> >>
> >> please find the link to a first version of a Localized Routing Problem 
> >> Statement below.
> >> The abstract of the PS document is as follows:
> >>
> >> Abstract:
> >>
> >>    Proxy Mobile IPv6 is the IETF standard for network-based localized
> >>    mobility management.  In Proxy Mobile IPv6, mobile nodes are
> >>    topologically anchored at a Local Mobility Anchor, which forwards all
> >>    data for registered mobile nodes.  The set up and support for
> >>    localized routing, which allows forwarding of data packets between
> >>    mobile nodes and correspondent nodes directly without traversing an
> >>    LMA, is not considered.  This document describes the problem space of
> >>    localized routing in Proxy Mobile IPv6.
> >>
> >>
> >> Any comments to this version of the problem statement are welcome.
> >>
> >> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps-00.txt
> >>
> >> Best regards,
> >> marco
> >>
> >>
> >> _______________________________________________
> >> NetExt mailing list
> >> NetExt at mail.mobileip.jp
> >> http://www.mobileip.jp/mailman/listinfo/netext
> >>     
> 
-- 
 Carlos Jes?s Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090211/61e7c2fa/attachment.bin>

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Wed, 11 Feb 2009 17:45:15 +0100
Subject: [Netext] First Problem Statement about Localized	Routingin	PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <1234370715.5174.9.camel@localhost>

Hi Rajeev,

El mi?, 11-02-2009 a las 09:47 -0500, Koodli, Rajeev escribi?:
> Hi Carlos,
>  
> 
> > 	- Regarding EnableMAGLocalRouting flag: in addition to 
> > what has been already discussed in this list, I want to check 
> > whether my understanding of RFC5213 is right or not. As far 
> > as I understand it, the local routing mechanism that is 
> > slightly defined in PMIPv6 specs refers to the optimisation 
> > of data traffic between an MN and a regular IPv6 node (a node 
> > that is not getting network-based mobility service from the PMIPv6
> > domain) that are both connected to the same MAG. This is what 
> > I understand from reading sections 6.10.5 and 6.14, though 
> > IMHO this is not clearly specified in RFC5213. Is this 
> > correct or am I missing something?
> 
> What does it mean to say it is not getting network-based mobility support? 
> Isn't the whole point of PMIP to make mobility transparent to the MN?

I fully agree that the whole point of PMIP is make mobility management
transparent to the MN. However, as far as I understand from my reading
of RFC5213, a mobile node attached to a PMIPv6 domain might not be
entitled to the network-based mobility management service, and RFC5213
(section 6.14) still support this node to get connectivity (regular
access) from the MAG.

Related to this, it is also my interpretation of RFC5213 (section
6.10.5) that the local routing support provided by the basic spec
(controlled with the EnableMAGLocalRouting flag) only applies to
communications between a PMIPv6 MN and a regular IPv6 host attached to
the same MAG.

This is just to try to clarify what RFC5213 provides (actually, very
little) and what does not in regards to local routing support. Do you
see my point?

Thanks!

Carlos

> 
> 
> > 
> > 	- If my previous understanding is correct, then RFC5213 
> > does not only define any mechanism to perform local routing 
> > between two MNs connected to the same PMIPv6 domain (not even 
> > for the case in which both are attached to the same MAG). 
> > Then, IMHO it would be better to change the terminology in 
> > the PS and avoid using CN or coming up with different terms 
> > for a CN that is getting network-based mobility service from 
> > a CN that is not (i.e. it is just a regular IPv6 node getting 
> > access from a MAG).
> 
> See above.
> 
> > 
> > 	- Currently, the PS only addresses the case of local 
> > routing between two MNs connected to the same PMIPv6 domain. 
> > I think the scenario of optimising traffic between an MN and 
> > a regular IPv6 host that is locally connected to a MAG should 
> > also be addressed. Not sure the implications on the potential 
> > solutions, but it might have an impact on the classification 
> > scheme that is used in the PS now (A[number of MAGs][number of LMAs]).
> > 
> 
> Our focus should be on solving the problem for nodes attached to a PMIP6 domain.
> 
> Thanks,
> 
> -Rajeev
> 
> 
> > 	Thanks,
> > 
> > 	Carlos
> > 
> > El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?:
> > > Hi all,
> > > 
> > > please find the link to a first version of a Localized 
> > Routing Problem 
> > > Statement below.
> > > The abstract of the PS document is as follows:
> > > 
> > > Abstract:
> > > 
> > >    Proxy Mobile IPv6 is the IETF standard for network-based 
> > localized
> > >    mobility management.  In Proxy Mobile IPv6, mobile nodes are
> > >    topologically anchored at a Local Mobility Anchor, which 
> > forwards all
> > >    data for registered mobile nodes.  The set up and support for
> > >    localized routing, which allows forwarding of data 
> > packets between
> > >    mobile nodes and correspondent nodes directly without 
> > traversing an
> > >    LMA, is not considered.  This document describes the 
> > problem space of
> > >    localized routing in Proxy Mobile IPv6.
> > > 
> > > 
> > > Any comments to this version of the problem statement are welcome.
> > > 
> > > 
> > http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps-0
> > > 0.txt
> > > 
> > > Best regards,
> > > marco
> > > 
> > > 
> > > _______________________________________________
> > > NetExt mailing list
> > > NetExt at mail.mobileip.jp
> > > http://www.mobileip.jp/mailman/listinfo/netext
> > -- 
> >  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
> >  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
> >         Deployment Experiences on Vehicular networks
> >                   http://www.weedev.org/
> > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> > 
> 
> 
> This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.
-- 
 Carlos Jes?s Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090211/a9fb09df/attachment-0001.bin>

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Wed, 11 Feb 2009 09:47:07 -0500
Subject: [Netext] First Problem Statement about Localized Routingin	PMIPv6 submitted
In-Reply-To: <1234339777.21602.198.camel@localhost>
Message-ID: <[email-masked]>

Hi Carlos,

> 	- Regarding EnableMAGLocalRouting flag: in addition to 
> what has been already discussed in this list, I want to check 
> whether my understanding of RFC5213 is right or not. As far 
> as I understand it, the local routing mechanism that is 
> slightly defined in PMIPv6 specs refers to the optimisation 
> of data traffic between an MN and a regular IPv6 node (a node 
> that is not getting network-based mobility service from the PMIPv6
> domain) that are both connected to the same MAG. This is what 
> I understand from reading sections 6.10.5 and 6.14, though 
> IMHO this is not clearly specified in RFC5213. Is this 
> correct or am I missing something?

What does it mean to say it is not getting network-based mobility support? 
Isn't the whole point of PMIP to make mobility transparent to the MN?

> 
> 	- If my previous understanding is correct, then RFC5213 
> does not only define any mechanism to perform local routing 
> between two MNs connected to the same PMIPv6 domain (not even 
> for the case in which both are attached to the same MAG). 
> Then, IMHO it would be better to change the terminology in 
> the PS and avoid using CN or coming up with different terms 
> for a CN that is getting network-based mobility service from 
> a CN that is not (i.e. it is just a regular IPv6 node getting 
> access from a MAG).

See above.

> 
> 	- Currently, the PS only addresses the case of local 
> routing between two MNs connected to the same PMIPv6 domain. 
> I think the scenario of optimising traffic between an MN and 
> a regular IPv6 host that is locally connected to a MAG should 
> also be addressed. Not sure the implications on the potential 
> solutions, but it might have an impact on the classification 
> scheme that is used in the PS now (A[number of MAGs][number of LMAs]).
> 

Our focus should be on solving the problem for nodes attached to a PMIP6 domain.

Thanks,

-Rajeev

> 	Thanks,
> 
> 	Carlos
> 
> El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?:
> > Hi all,
> > 
> > please find the link to a first version of a Localized 
> Routing Problem 
> > Statement below.
> > The abstract of the PS document is as follows:
> > 
> > Abstract:
> > 
> >    Proxy Mobile IPv6 is the IETF standard for network-based 
> localized
> >    mobility management.  In Proxy Mobile IPv6, mobile nodes are
> >    topologically anchored at a Local Mobility Anchor, which 
> forwards all
> >    data for registered mobile nodes.  The set up and support for
> >    localized routing, which allows forwarding of data 
> packets between
> >    mobile nodes and correspondent nodes directly without 
> traversing an
> >    LMA, is not considered.  This document describes the 
> problem space of
> >    localized routing in Proxy Mobile IPv6.
> > 
> > 
> > Any comments to this version of the problem statement are welcome.
> > 
> > 
> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps-0
> > 0.txt
> > 
> > Best regards,
> > marco
> > 
> > 
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> -- 
>  Carlos Jes?s Bernardos Cano     http://www.netcoms.net
>  GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>   WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
>         Deployment Experiences on Vehicular networks
>                   http://www.weedev.org/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 

This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.

From: liebsch at nw.neclab.eu (Marco Liebsch)
Date: Wed, 11 Feb 2009 15:39:29 +0100
Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Ashutosh Dutta wrote:
> Marco, nothing much, do you think putting a word such as  "However" 
> before the third sentence will make the abstract little bit more clear 
> in terms of what this document is trying to address?
Well, not really. But if folks want it, I can add it.

marco
>
> Regards
> Ashutosh
>
> Marco Liebsch wrote:
>> Hi Ashutosh,
>>
>> Ashutosh Dutta schrieb:
>>> Marco,
>>>       Is it possible to make the abstract little bit clear? The 
>>> third sentence refers to the fact that localized routing is not 
>>> considered in RFC5213, right?
>> Sure, it's possible. But I don't see the point point where the 
>> abstract is not clear.
>> Do you think the abstract should say that RFC5213 considers the 
>> EnableMAGLocalRouting
>> flag, but does not provide a full specification for localized 
>> routing? I prefer to keep the
>> abstract concise and the message clear. Details about what is 
>> supported by the base PMIP
>> spec, where are the limitations and where are open issues, I think 
>> this is something
>> the document core should describe rather than the abstract.
>>
>> But if you have a specific proposal how to make the abstract clearer, 
>> just let me know.
>>
>> Best regards,
>> marco
>>
>>>
>>> I will look at the rest.
>>>
>>> Thanks
>>> Ashutosh
>>>
>>> Marco Liebsch wrote:
>>>> Hi all,
>>>>
>>>> please find the link to a first version of a Localized Routing 
>>>> Problem Statement below.
>>>> The abstract of the PS document is as follows:
>>>>
>>>> Abstract:
>>>>
>>>>   Proxy Mobile IPv6 is the IETF standard for network-based localized
>>>>   mobility management.  In Proxy Mobile IPv6, mobile nodes are
>>>>   topologically anchored at a Local Mobility Anchor, which forwards 
>>>> all
>>>>   data for registered mobile nodes.  The set up and support for
>>>>   localized routing, which allows forwarding of data packets between
>>>>   mobile nodes and correspondent nodes directly without traversing an
>>>>   LMA, is not considered.  This document describes the problem 
>>>> space of
>>>>   localized routing in Proxy Mobile IPv6.
>>>>
>>>>
>>>> Any comments to this version of the problem statement are welcome.
>>>>
>>>> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps-00.txt 
>>>>
>>>>
>>>> Best regards,
>>>> marco
>>>>
>>>>
>>>> _______________________________________________
>>>> NetExt mailing list
>>>> NetExt at mail.mobileip.jp
>>>> http://www.mobileip.jp/mailman/listinfo/netext
>>
>>

From: liebsch at nw.neclab.eu (Marco Liebsch)
Date: Wed, 11 Feb 2009 10:24:36 +0100
Subject: [Netext] First Problem Statement about Localized Routing in	PMIPv6 submitted
In-Reply-To: <1234339777.21602.198.camel@localhost>
References: <[email-masked]> <1234339777.21602.198.camel@localhost>
Message-ID: <[email-masked]>

Hi Carlos,

thanks for the feedback!
Please find my view and answers to your comments below.

Carlos Jes?s Bernardos Cano wrote:
> Hi Marco, all,
>
> 	I've just read your document. Thanks for writing it!
>
> 	I have some comments/questions:
>
> 	- Regarding EnableMAGLocalRouting flag: in addition to what has been
> already discussed in this list, I want to check whether my understanding
> of RFC5213 is right or not. As far as I understand it, the local routing
> mechanism that is slightly defined in PMIPv6 specs refers to the
> optimisation of data traffic between an MN and a regular IPv6 node (a
> node that is not getting network-based mobility service from the PMIPv6
> domain) that are both connected to the same MAG. This is what I
> understand from reading sections 6.10.5 and 6.14, though IMHO this is
> not clearly specified in RFC5213. Is this correct or am I missing
> something?
>   
Well, I think both is intrinsically supported (maybe without
intention), a PMIPv6-attached CN or an IPv6 CN, that uses the
network component, which implements the MAG, as AR. In the
first case, the MAG has a BUL entry and an associated route
entry for the CN, in the latter case, the AR has a route
entry for the CN. So prefix routing should work in both cases.
The only thing you need to take care in the IPv6 case is that
the MAG allows deviations from a default route for the MN's
traffic, which should not go through the LMA then, but should be
forwarded according to the local routing table. However, all these
things are not described in RFC5213, for good reasons, as this
was not the focus.
> 	- If my previous understanding is correct, then RFC5213 does not only
> define any mechanism to perform local routing between two MNs connected
> to the same PMIPv6 domain (not even for the case in which both are
> attached to the same MAG). Then, IMHO it would be better to change the
> terminology in the PS and avoid using CN or coming up with different
> terms for a CN that is getting network-based mobility service from a CN
> that is not (i.e. it is just a regular IPv6 node getting access from a
> MAG).
>   
Ok, the idea was the following: MN and CN have been chosen to
distinguish the two mobile nodes. Now, as we thought about more
use cases before, such as for example setting up RO between a
PMIPv6 attached MN and a MIPv6 CN, the intention was to keep
MN and CN as terms, but to refer to a specific use case in addition.
So, if there is a discussion about a RO 'association' between an MN
and a CN, both are PMIPv6 attached, its for example a use case
according to A12. RO with a MIPv6 CN should be described as B
use cases (e.g. B12). We could introduce more uses cases to cover
RO with an IPv6 node, such as C2.

Alternatively (or in addition) we could distinguish the mobile devices
by means of extensions (CN_IP6, CN_MIP6), but this does not cover
the use cases and all the variants of a particular use case yet.
More in this context below.
> 	- Currently, the PS only addresses the case of local routing between
> two MNs connected to the same PMIPv6 domain. I think the scenario of
> optimising traffic between an MN and a regular IPv6 host that is locally
> connected to a MAG should also be addressed. Not sure the implications
> on the potential solutions, but it might have an impact on the
> classification scheme that is used in the PS now (A[number of
> MAGs][number of LMAs]).
>   
I don't see an issue here, as we can differentiate the mobility
mode (if there is any) of both nodes by means of the use case
(A,B,C,...). Since the IPv6 CN will not have a mobility anchor,
we should indicate only the amount of involved ARs/MAGs (such as C2).

Ok, long story above. Fact is that the scope of the PS doc has been
cut to the current NetExt charter, which focuses in particular on RO
between two PMIPv6 attached MNs. Larger scope needs to be discussed
and agreed on. If we need more use cases, we could describe them as
proposed above or by other means.

marco

> 	Thanks,
>
> 	Carlos
>
> El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?:
>   
>> Hi all,
>>
>> please find the link to a first version of a Localized Routing Problem 
>> Statement below.
>> The abstract of the PS document is as follows:
>>
>> Abstract:
>>
>>    Proxy Mobile IPv6 is the IETF standard for network-based localized
>>    mobility management.  In Proxy Mobile IPv6, mobile nodes are
>>    topologically anchored at a Local Mobility Anchor, which forwards all
>>    data for registered mobile nodes.  The set up and support for
>>    localized routing, which allows forwarding of data packets between
>>    mobile nodes and correspondent nodes directly without traversing an
>>    LMA, is not considered.  This document describes the problem space of
>>    localized routing in Proxy Mobile IPv6.
>>
>>
>> Any comments to this version of the problem statement are welcome.
>>
>> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps-00.txt
>>
>> Best regards,
>> marco
>>
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>     

From: cjbc at it.uc3m.es (Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano)
Date: Wed, 11 Feb 2009 09:09:37 +0100
Subject: [Netext] First Problem Statement about Localized Routing in	PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <1234339777.21602.198.camel@localhost>

Hi Marco, all,

	I've just read your document. Thanks for writing it!

	I have some comments/questions:

	- Regarding EnableMAGLocalRouting flag: in addition to what has been
already discussed in this list, I want to check whether my understanding
of RFC5213 is right or not. As far as I understand it, the local routing
mechanism that is slightly defined in PMIPv6 specs refers to the
optimisation of data traffic between an MN and a regular IPv6 node (a
node that is not getting network-based mobility service from the PMIPv6
domain) that are both connected to the same MAG. This is what I
understand from reading sections 6.10.5 and 6.14, though IMHO this is
not clearly specified in RFC5213. Is this correct or am I missing
something?

	- If my previous understanding is correct, then RFC5213 does not only
define any mechanism to perform local routing between two MNs connected
to the same PMIPv6 domain (not even for the case in which both are
attached to the same MAG). Then, IMHO it would be better to change the
terminology in the PS and avoid using CN or coming up with different
terms for a CN that is getting network-based mobility service from a CN
that is not (i.e. it is just a regular IPv6 node getting access from a
MAG).

	- Currently, the PS only addresses the case of local routing between
two MNs connected to the same PMIPv6 domain. I think the scenario of
optimising traffic between an MN and a regular IPv6 host that is locally
connected to a MAG should also be addressed. Not sure the implications
on the potential solutions, but it might have an impact on the
classification scheme that is used in the PS now (A[number of
MAGs][number of LMAs]).

	Thanks,

	Carlos

El jue, 05-02-2009 a las 15:33 +0100, Marco Liebsch escribi?:
> Hi all,
> 
> please find the link to a first version of a Localized Routing Problem 
> Statement below.
> The abstract of the PS document is as follows:
> 
> Abstract:
> 
>    Proxy Mobile IPv6 is the IETF standard for network-based localized
>    mobility management.  In Proxy Mobile IPv6, mobile nodes are
>    topologically anchored at a Local Mobility Anchor, which forwards all
>    data for registered mobile nodes.  The set up and support for
>    localized routing, which allows forwarding of data packets between
>    mobile nodes and correspondent nodes directly without traversing an
>    LMA, is not considered.  This document describes the problem space of
>    localized routing in Proxy Mobile IPv6.
> 
> 
> Any comments to this version of the problem statement are welcome.
> 
> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps-00.txt
> 
> Best regards,
> marco
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
-- 
 Carlos Jes?s Bernardos Cano     http://www.netcoms.net
 GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
  WEEDEV 2009: 2nd Workshop on Experimental Evaluation and
        Deployment Experiences on Vehicular networks
                  http://www.weedev.org/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090211/f738e902/attachment.bin>

From: jari.arkko at piuha.net (Jari Arkko)
Date: Tue, 10 Feb 2009 15:05:06 +0200
Subject: [Netext] BOF situation
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Basavaraj,

> We are trying to limit the MN involvement in any of the enhancements that
> are in the scope of Netext. However we would like to at least not be bounded
> by the kind of mandate that Netlmm has (i.e no changes to host). Effort
> should be to develop solutions which does not require any host involvement.
> However if the WG feels that there is no alternative to solving a problem or
> if the preferred approach would be to involve the MN, then I do think that
> Netext should have the liberty to proceed with such a design.
>
> But we recognize the challenges of developing any solution which involve the
> host, given the installed base. And will resist the need to involve the host
> if you believe this will be controversial (are you implying that this is
> controversial from the point of any such approaches being no different from
> host based Mobile IP? Or something else?).
>   
My main concerns personally were (a) the effects to deploying this when 
host changes are needed, and (b) the argument that I foresee about proxy 
vs. client mobility.

How about this: you figure out what exactly can and cannot be done 
without host changes, and then we can have a more sensible discussion? 
For the BOF, I would recommend trying to get at least the 
non-host-changing parts agreed.

Jari

From: adutta at research.telcordia.com (Ashutosh Dutta)
Date: Tue, 10 Feb 2009 07:20:12 -0500
Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Marco, nothing much, do you think putting a word such as  "However" 
before the third sentence will make the abstract little bit more clear 
in terms of what this document is trying to address?

Regards
Ashutosh

Marco Liebsch wrote:
> Hi Ashutosh,
> 
> Ashutosh Dutta schrieb:
>> Marco,
>>       Is it possible to make the abstract little bit clear? The third 
>> sentence refers to the fact that localized routing is not considered 
>> in RFC5213, right?
> Sure, it's possible. But I don't see the point point where the abstract 
> is not clear.
> Do you think the abstract should say that RFC5213 considers the 
> EnableMAGLocalRouting
> flag, but does not provide a full specification for localized routing? I 
> prefer to keep the
> abstract concise and the message clear. Details about what is supported 
> by the base PMIP
> spec, where are the limitations and where are open issues, I think this 
> is something
> the document core should describe rather than the abstract.
> 
> But if you have a specific proposal how to make the abstract clearer, 
> just let me know.
> 
> Best regards,
> marco
> 
>>
>> I will look at the rest.
>>
>> Thanks
>> Ashutosh
>>
>> Marco Liebsch wrote:
>>> Hi all,
>>>
>>> please find the link to a first version of a Localized Routing 
>>> Problem Statement below.
>>> The abstract of the PS document is as follows:
>>>
>>> Abstract:
>>>
>>>   Proxy Mobile IPv6 is the IETF standard for network-based localized
>>>   mobility management.  In Proxy Mobile IPv6, mobile nodes are
>>>   topologically anchored at a Local Mobility Anchor, which forwards all
>>>   data for registered mobile nodes.  The set up and support for
>>>   localized routing, which allows forwarding of data packets between
>>>   mobile nodes and correspondent nodes directly without traversing an
>>>   LMA, is not considered.  This document describes the problem space of
>>>   localized routing in Proxy Mobile IPv6.
>>>
>>>
>>> Any comments to this version of the problem statement are welcome.
>>>
>>> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps-00.txt 
>>>
>>>
>>> Best regards,
>>> marco
>>>
>>>
>>> _______________________________________________
>>> NetExt mailing list
>>> NetExt at mail.mobileip.jp
>>> http://www.mobileip.jp/mailman/listinfo/netext
> 
> 

From: suresh.krishnan at ericsson.com (Suresh Krishnan)
Date: Mon, 09 Feb 2009 17:27:58 -0500
Subject: [Netext] Inter-technology handover PS
Message-ID: <[email-masked]>

Hi Folks,
   We have submitted the initial version of the problem statement draft 
describing issues with network based inter-technology handovers. Please 
send us any comments or issues that you may have on the document.

Thanks
Suresh

-------- Original Message --------
Subject: I-D Action:draft-krishnan-netext-intertech-ps-00.txt
Date: Mon,  9 Feb 2009 14:15:01 -0800 (PST)
From: Internet-Drafts at ietf.org
Reply-To: internet-drafts at ietf.org
To: i-d-announce at ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.

	Title           : Issues with network based inter-technology handovers
	Author(s)       : S. Krishnan, et al.
	Filename        : draft-krishnan-netext-intertech-ps-00.txt
	Pages           : 9
	Date            : 2009-02-09

Proxy Mobile IPv6 (PMIPv6) is a network based mobility management
protocol enables IP mobility for a host without requiring its
participation in any mobility-related signaling.  While the PMIPv6
protocol itself supports handover across interfaces and between
access types, there are several issues with effectively performing
inter-technology handovers with network based mobility protocols.
This document aims to enumerate some known issues with such
handovers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-krishnan-netext-intertech-ps-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Mon, 9 Feb 2009 21:10:11 +0100
Subject: [Netext] BOF situation
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari,

Thanks for approving the BoF.

We are trying to limit the MN involvement in any of the enhancements that
are in the scope of Netext. However we would like to at least not be bounded
by the kind of mandate that Netlmm has (i.e no changes to host). Effort
should be to develop solutions which does not require any host involvement.
However if the WG feels that there is no alternative to solving a problem or
if the preferred approach would be to involve the MN, then I do think that
Netext should have the liberty to proceed with such a design.

But we recognize the challenges of developing any solution which involve the
host, given the installed base. And will resist the need to involve the host
if you believe this will be controversial (are you implying that this is
controversial from the point of any such approaches being no different from
host based Mobile IP? Or something else?).

-Raj

On 2/9/09 5:03 AM, "ext Jari Arkko" <jari.arkko at piuha.net> wrote:

> Hi all,
>
> I have approved the BOF request.
>
> However, one worry that has come up relates to the architectural
> direction. Some of the work items relate to the involvement of the
> mobile host. This is a deviation from the original concept of proxy
> mobility and the current protocols -- which work or at least fail safely
> even if the host is unaware that proxy mobility is happening on an
> interface. The ability to work with the very slowly changing installed
> base of hosts (laptops attached to a cellular modem etc) suggests that
> it would be useful to employ mechanisms that have no such requirements.
> Also, requiring further host involvement is likely going to be
> controversial.
>
> Based on this, I would like the group to spend the next few weeks
> talking about whether its work can be scoped down to optimizations and
> enhancements that do NOT require additional host involvement.
>
> Jari
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>

From: jouni.nospam at gmail.com (jouni korhonen)
Date: Mon, 9 Feb 2009 14:43:11 +0200
Subject: [Netext] Fwd: New Version Notification for draft-korhonen-netext-redirect-ps-00
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi All,

I wrote a small discussion paper on PMIPv6 redirection functionality.  
The aim is to
come up with a good redirection support for the base protocol. Obvious  
use cases
are load balancing, signaling reduction within a PMIPv6 Domain and  
eventually reduced
latencies during mobility session setup. The problem area falls under  
the improvements
and/or deployment considerations in the current proposed charter.

The I-D can be found here:
http://www.ietf.org/internet-drafts/draft-korhonen-netext-redirect-ps-00.txt

Comments are welcome!

Cheers,
	Jouni

Begin forwarded message:

> From: IETF I-D Submission Tool <idsubmission at ietf.org>
> Date: February 9, 2009 2:30:00 PM GMT+02:00
> To: jouni.nospam at gmail.com
> Subject: New Version Notification for  draft-korhonen-netext- 
> redirect-ps-00
>
>
> A new version of I-D, draft-korhonen-netext-redirect-ps-00.txt has  
> been successfuly submitted by Jouni Korhonen and posted to the IETF  
> repository.
>
> Filename:	 draft-korhonen-netext-redirect-ps
> Revision:	 00
> Title:		 Proxy Mobile IPv6 Mobility Session Redirection Problem  
> Statement
> Creation_date:	 2009-02-09
> WG ID:		 Independent Submission
> Number_of_pages: 7
>
> Abstract:
> This document discusses a Proxy Mobile IPv6 mobility session
> redirection functionality at the Proxy Mobile IPv6 base protocol
> level.  The redirection functionality would allow a Local Mobility
> Anchor to redirect the Mobile Access Gateway during the Proxy Binding
> Update and Acknowledgement exchange to an alternative Local Mobility
> Anchor.  The benefit of redirection at the protocol level is that it
> removes the dependence on having such functionality provided by the
> Authentication, Authorization and, Accounting elements or the Domain
> Name System in a Proxy Mobile IPv6 Domain.  Furthermore, doing the
> redirection at the base protocol level reduces the amount of
> signaling, unnecessary costly setup of mobility sessions and
> unnecessary costly interactions with backend systems.
>
>
>
> The IETF Secretariat.
>
>

From: jari.arkko at piuha.net (Jari Arkko)
Date: Mon, 09 Feb 2009 13:03:06 +0200
Subject: [Netext] BOF situation
Message-ID: <[email-masked]>

Hi all,

I have approved the BOF request.

However, one worry that has come up relates to the architectural 
direction. Some of the work items relate to the involvement of the 
mobile host. This is a deviation from the original concept of proxy 
mobility and the current protocols -- which work or at least fail safely 
even if the host is unaware that proxy mobility is happening on an 
interface. The ability to work with the very slowly changing installed 
base of hosts (laptops attached to a cellular modem etc) suggests that 
it would be useful to employ mechanisms that have no such requirements. 
Also, requiring further host involvement is likely going to be 
controversial.

Based on this, I would like the group to spend the next few weeks 
talking about whether its work can be scoped down to optimizations and 
enhancements that do NOT require additional host involvement.

Jari

From: yokota at kddilabs.jp (Hidetoshi Yokota)
Date: Mon, 09 Feb 2009 19:50:10 +0900
Subject: [Netext] First Problem Statement about Localized Routing in	PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Marco and Rajeev,

Koodli, Rajeev wrote:
> Hi,
>  
> 
>>> But, has there been a established way to do that already? 
>> If the LMA 
>>> enforces it, can it be done by the PBU? It seems to be in 
>> the opposite 
>>> direction.
>>>   
>> Yes, very good point. RFC5213 sais that localized routing on 
>> a MAG should be based on the MAG's policy but enforced by the 
>> LMA. The statement about the indication in the PBU should be 
>> taken out from the PS, in particular since the 
>> EnableMAGLocalRouting flag is a configuration flag, not a 
>> protocol message flag. This paragraph is simply to refer to 
>> existing mechanisms for local routing, whereas I think the 
>> text in RFC5213 is more a guideline, not a protocol solution 
>> (of course only the text about localized routing..).
>> So, regarding your question:
>> No, there is no established way yet to do this. And we cannot 
>> assume a CN remains always attached to the same MAG as the 
>> MN. If it hands over to a different MAG, we need a common 
>> solution to handle this also in a larger scope. Hence,I am 
>> not sure about the role of the EnableMAGLocalRouting flag in 
>> the NetExt solution for localized routing.
> 
> I would also just treat the flag as a reference to what exists today.
> We need a protocol for localized routing.

I agree.

>>> I thinks it should also include the "termination" of the path like:
>>>
>>> "o  Control in setting up, maintaining (e.g. during handover) and 
>>> termination the localized routing path."
>>>   
>> Maybe we can go even one step further and add 'termination' 
>> of a localized routing path to a separate bullet, as this 
>> function may be performed by a different network component 
>> than the controlling function. What do you think?
> 
> I think the proposal to simply add "termination" as in the above bullet
> sounds good.
> I don't think that we need to consider entities other than MAG and LMA
> for the protocol.
> It is possible that the trigger may arrive from other nodes, but those
> are outside the scope of the protocol we are interested here.

The reason why I pointed it out is that the clean-up of the old
localized routing path does not happen automatically. It should be well
defined as the protocol specification. The functional entity could
reside in the MAG, LMA or both or another node. It will be ok without
mentioning it in the PS. We will figure it out in the course of solution
discussions (I honestly don't have a specific solution in mind).

Regards,
-- 
Hidetoshi

> -Rajeev
> 
> 
> 
>>> Other than the above, the document is very well written.
>>>   
>> Thanks,
>> marco
>>
>>
>>> Regards,
>>>   
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>
> 
> 
> This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 
> 
> 

From: marco.liebsch at nw.neclab.eu (Marco Liebsch)
Date: Mon, 09 Feb 2009 10:23:52 +0100
Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Ashutosh,

Ashutosh Dutta schrieb:
> Marco,
>       Is it possible to make the abstract little bit clear? The third 
> sentence refers to the fact that localized routing is not considered 
> in RFC5213, right?
Sure, it's possible. But I don't see the point point where the abstract 
is not clear.
Do you think the abstract should say that RFC5213 considers the 
EnableMAGLocalRouting
flag, but does not provide a full specification for localized routing? I 
prefer to keep the
abstract concise and the message clear. Details about what is supported 
by the base PMIP
spec, where are the limitations and where are open issues, I think this 
is something
the document core should describe rather than the abstract.

But if you have a specific proposal how to make the abstract clearer, 
just let me know.

Best regards,
marco

>
> I will look at the rest.
>
> Thanks
> Ashutosh
>
> Marco Liebsch wrote:
>> Hi all,
>>
>> please find the link to a first version of a Localized Routing 
>> Problem Statement below.
>> The abstract of the PS document is as follows:
>>
>> Abstract:
>>
>>   Proxy Mobile IPv6 is the IETF standard for network-based localized
>>   mobility management.  In Proxy Mobile IPv6, mobile nodes are
>>   topologically anchored at a Local Mobility Anchor, which forwards all
>>   data for registered mobile nodes.  The set up and support for
>>   localized routing, which allows forwarding of data packets between
>>   mobile nodes and correspondent nodes directly without traversing an
>>   LMA, is not considered.  This document describes the problem space of
>>   localized routing in Proxy Mobile IPv6.
>>
>>
>> Any comments to this version of the problem statement are welcome.
>>
>> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps-00.txt 
>>
>>
>> Best regards,
>> marco
>>
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext

From: marco.liebsch at nw.neclab.eu (Marco Liebsch)
Date: Mon, 09 Feb 2009 10:16:19 +0100
Subject: [Netext] First Problem Statement about Localized Routing in	PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Rajeev,

please see my comments in-line.

Koodli, Rajeev schrieb:
> Hi,
>  
>
>   
>>> But, has there been a established way to do that already? 
>>>       
>> If the LMA 
>>     
>>> enforces it, can it be done by the PBU? It seems to be in 
>>>       
>> the opposite 
>>     
>>> direction.
>>>   
>>>       
>> Yes, very good point. RFC5213 sais that localized routing on 
>> a MAG should be based on the MAG's policy but enforced by the 
>> LMA. The statement about the indication in the PBU should be 
>> taken out from the PS, in particular since the 
>> EnableMAGLocalRouting flag is a configuration flag, not a 
>> protocol message flag. This paragraph is simply to refer to 
>> existing mechanisms for local routing, whereas I think the 
>> text in RFC5213 is more a guideline, not a protocol solution 
>> (of course only the text about localized routing..).
>> So, regarding your question:
>> No, there is no established way yet to do this. And we cannot 
>> assume a CN remains always attached to the same MAG as the 
>> MN. If it hands over to a different MAG, we need a common 
>> solution to handle this also in a larger scope. Hence,I am 
>> not sure about the role of the EnableMAGLocalRouting flag in 
>> the NetExt solution for localized routing.
>>     
>
> I would also just treat the flag as a reference to what exists today.
> We need a protocol for localized routing.
>
>
>   
>>> I thinks it should also include the "termination" of the path like:
>>>
>>> "o  Control in setting up, maintaining (e.g. during handover) and 
>>> termination the localized routing path."
>>>   
>>>       
>> Maybe we can go even one step further and add 'termination' 
>> of a localized routing path to a separate bullet, as this 
>> function may be performed by a different network component 
>> than the controlling function. What do you think?
>>     
>
> I think the proposal to simply add "termination" as in the above bullet
> sounds good.
> I don't think that we need to consider entities other than MAG and LMA
> for the protocol.
>   
That's actually not what I meant. I still considered PMIP functional 
entities.
In an A22 scenario, there are 4 entities involved, 2 LMAs and 2 MAGs. I 
simply
meant that signaling for termination of RO states may be initiated by an 
entity,
which is different from the entity that controls the setup. But I am ok with
incorporating the termination aspect into the existing bullet as proposed by
Hidetoshi.

> It is possible that the trigger may arrive from other nodes, but those
> are outside the scope of the protocol we are interested here.
>   
Agree, that the trigger may come from non-PMIP entities. Still I think 
the PMIP
RO protocol we'll specify needs to signal termination of RO states, even 
though
the trigger comes from outside.
Will add this to the action list and see for further comments.

Thanks,
marco

> -Rajeev
>
>
>
>   
>>> Other than the above, the document is very well written.
>>>   
>>>       
>> Thanks,
>> marco
>>
>>
>>     
>>> Regards,
>>>   
>>>       
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>>
>>     
>
>
> This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
>   

From: adutta at research.telcordia.com (Ashutosh Dutta)
Date: Mon, 09 Feb 2009 00:46:58 -0500
Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Marco,
       Is it possible to make the abstract little bit clear? The third 
sentence refers to the fact that localized routing is not considered in 
RFC5213, right?

I will look at the rest.

Thanks
Ashutosh

Marco Liebsch wrote:
> Hi all,
> 
> please find the link to a first version of a Localized Routing Problem 
> Statement below.
> The abstract of the PS document is as follows:
> 
> Abstract:
> 
>   Proxy Mobile IPv6 is the IETF standard for network-based localized
>   mobility management.  In Proxy Mobile IPv6, mobile nodes are
>   topologically anchored at a Local Mobility Anchor, which forwards all
>   data for registered mobile nodes.  The set up and support for
>   localized routing, which allows forwarding of data packets between
>   mobile nodes and correspondent nodes directly without traversing an
>   LMA, is not considered.  This document describes the problem space of
>   localized routing in Proxy Mobile IPv6.
> 
> 
> Any comments to this version of the problem statement are welcome.
> 
> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps-00.txt
> 
> Best regards,
> marco
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Fri, 6 Feb 2009 14:22:44 -0500
Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi,

> > But, has there been a established way to do that already? 
> If the LMA 
> > enforces it, can it be done by the PBU? It seems to be in 
> the opposite 
> > direction.
> >   
> Yes, very good point. RFC5213 sais that localized routing on 
> a MAG should be based on the MAG's policy but enforced by the 
> LMA. The statement about the indication in the PBU should be 
> taken out from the PS, in particular since the 
> EnableMAGLocalRouting flag is a configuration flag, not a 
> protocol message flag. This paragraph is simply to refer to 
> existing mechanisms for local routing, whereas I think the 
> text in RFC5213 is more a guideline, not a protocol solution 
> (of course only the text about localized routing..).
> So, regarding your question:
> No, there is no established way yet to do this. And we cannot 
> assume a CN remains always attached to the same MAG as the 
> MN. If it hands over to a different MAG, we need a common 
> solution to handle this also in a larger scope. Hence,I am 
> not sure about the role of the EnableMAGLocalRouting flag in 
> the NetExt solution for localized routing.

I would also just treat the flag as a reference to what exists today.
We need a protocol for localized routing.

> > I thinks it should also include the "termination" of the path like:
> >
> > "o  Control in setting up, maintaining (e.g. during handover) and 
> > termination the localized routing path."
> >   
> Maybe we can go even one step further and add 'termination' 
> of a localized routing path to a separate bullet, as this 
> function may be performed by a different network component 
> than the controlling function. What do you think?

I think the proposal to simply add "termination" as in the above bullet
sounds good.
I don't think that we need to consider entities other than MAG and LMA
for the protocol.
It is possible that the trigger may arrive from other nodes, but those
are outside the scope of the protocol we are interested here.

-Rajeev

> > Other than the above, the document is very well written.
> >   
> Thanks,
> marco
> 
> 
> > Regards,
> >   
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.

From: marco.liebsch at nw.neclab.eu (Marco Liebsch)
Date: Fri, 06 Feb 2009 10:32:09 +0100
Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Hidetoshi,

thanks for your comments. Please find my answers below.

Hidetoshi Yokota schrieb:
> Hi Marco,
>
> Thanks for creating the PS for localized routing, which I think covers
> enough scenarios and problem space. I have one small question and comment:
>
> [Q] On p.6, The paragraph of the use case for A11 has:
>
> "According to [RFC5213], such operation should be enforced by the LMA
> and signaled in the PBU by means of the EnableMAGLocalRouting flag."
>
> But, has there been a established way to do that already? If the LMA
> enforces it, can it be done by the PBU? It seems to be in the opposite
> direction.
>   
Yes, very good point. RFC5213 sais that localized routing on a MAG
should be based on the
MAG's policy but enforced by the LMA. The statement about the indication
in the PBU
should be taken out from the PS, in particular since the
EnableMAGLocalRouting flag is a
configuration flag, not a protocol message flag. This paragraph is
simply to refer to existing
mechanisms for local routing, whereas I think the text in RFC5213 is
more a guideline, not a
protocol solution (of course only the text about localized routing..).
So, regarding your question:
No, there is no established way yet to do this. And we cannot assume a
CN remains always
attached to the same MAG as the MN. If it hands over to a different MAG,
we need a common
solution to handle this also in a larger scope. Hence,I am not sure
about the role of the
EnableMAGLocalRouting flag in the NetExt solution for localized routing.

> [C] In the last bullet of the key functions on p.6:
>
> "o  Control in setting up and maintaining (e.g. during handover) the
> localized routing path."
>
> I thinks it should also include the "termination" of the path like:
>
> "o  Control in setting up, maintaining (e.g. during handover) and
> termination the localized routing path."
>   
Maybe we can go even one step further and add 'termination' of a
localized routing path
to a separate bullet, as this function may be performed by a different
network component
than the controlling function. What do you think?
> Other than the above, the document is very well written.
>   
Thanks,
marco

> Regards,
>   

From: yokota at kddilabs.jp (Hidetoshi Yokota)
Date: Fri, 06 Feb 2009 17:01:57 +0900
Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hi Marco,

Thanks for creating the PS for localized routing, which I think covers
enough scenarios and problem space. I have one small question and comment:

[Q] On p.6, The paragraph of the use case for A11 has:

"According to [RFC5213], such operation should be enforced by the LMA
and signaled in the PBU by means of the EnableMAGLocalRouting flag."

But, has there been a established way to do that already? If the LMA
enforces it, can it be done by the PBU? It seems to be in the opposite
direction.

[C] In the last bullet of the key functions on p.6:

"o  Control in setting up and maintaining (e.g. during handover) the
localized routing path."

I thinks it should also include the "termination" of the path like:

"o  Control in setting up, maintaining (e.g. during handover) and
termination the localized routing path."

Other than the above, the document is very well written.

Regards,
-- 
Hidetoshi

Marco Liebsch wrote:
> Hi all,
> 
> please find the link to a first version of a Localized Routing Problem 
> Statement below.
> The abstract of the PS document is as follows:
> 
> Abstract:
> 
>   Proxy Mobile IPv6 is the IETF standard for network-based localized
>   mobility management.  In Proxy Mobile IPv6, mobile nodes are
>   topologically anchored at a Local Mobility Anchor, which forwards all
>   data for registered mobile nodes.  The set up and support for
>   localized routing, which allows forwarding of data packets between
>   mobile nodes and correspondent nodes directly without traversing an
>   LMA, is not considered.  This document describes the problem space of
>   localized routing in Proxy Mobile IPv6.
> 
> 
> Any comments to this version of the problem statement are welcome.
> 
> http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps-00.txt
> 
> Best regards,
> marco
> 
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 
> 
> 

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Fri, 6 Feb 2009 09:12:39 +0800
Subject: [Netext] Revised BoF charter
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Rajeev, Raj and All,

I saw the updated charter items. Thanks so much for the updated charter
goals and the reviews on the multihoming-PS-ID.
When I was looking at multihoming in the revised charter I found these,
and I want to be clear on this.

a. improve the support for multiple IP mobility sessions via the same
MAG 
          simultaneously using a single access technology type, so that
individual
          mobility sessions can be instantiated dynamically

[Mohana] This Ok, understand one may need mobility sessions setup
dynamically for multiple home network prefixes at different times. Looks
very much tied to 3GPP and I agree that it is important work.
 
      b.  support for selectively sharing Home Network Prefixes across
access 
          technology types so that, for instance, packet streams
belonging to the
          same HNP could traverse different MAGs 

[Mohana] This is more of the multihoming (as in multihoming PS ID) such
as simultaneous usage of same prefix via both interfaces. Or flows
associated with a prefix to traverse via particular interface like flow
based routing. 
      
c.  Support for multiple IP mobility sessions for an MN attached
      	  via different interfaces (access technologies) but thru a
      	  single MAG (special case of a. and b.) 
[Mohana] This is a combination of a and b, but the scenario is
different.

[Mohana]I have just two more questions to Rajeev and Raj:
Why partial handoff of prefixes from one interface to a new interface is
not considered. Is it because of the narrowed scope. I think this is
also an extension to the current PMIPv6 protocol. Hope you can
re-consider this. It is described in P-ID. It is an important scenario,
because all the flows can be transferred to a new interface by such
partial handoff.

[Mohana]Also, the PMIPv6 and CMIPv6 interaction case is not considered.
Again is it because of CMIPv6 interaction? It has to be considered by
some group. NetExt may be the ideal. 

{PS} I saw the local routing PS. Will look into it as well.
Thanks again.

BR,
Mohana
-----Original Message-----
From: netext-bounces at mail.mobileip.jp
[mailto:netext-bounces at mail.mobileip.jp] On Behalf Of
Basavaraj.Patil at nokia.com
Sent: Friday, February 06, 2009 7:34 AM
To: netext at mail.mobileip.jp
Subject: [Netext] Revised BoF charter

Hello,

The updated BoF charter has been posted. Please refer to the Netext BoF
in
the IETF tools wiki page:

http://trac.tools.ietf.org/bof/trac/wiki/WikiStart

-Basavaraj

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Fri, 6 Feb 2009 00:34:27 +0100
Subject: [Netext] Revised BoF charter
Message-ID: <[email-masked]>

Hello,

The updated BoF charter has been posted. Please refer to the Netext BoF in
the IETF tools wiki page:

http://trac.tools.ietf.org/bof/trac/wiki/WikiStart

-Basavaraj

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Thu, 5 Feb 2009 23:52:54 +0100
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Comments inline:

On 2/4/09 8:53 PM, "ext Yungui Wang" <w52006 at huawei.com> wrote:

> Hello Raj,
>
> Propose below two scenarios which have been defined in CMIPv6
> to be considered in scope of multihoming as well.
> 1, Flow binding and flow mobility

Why do you believe flow binding and flow mobility need to be dealt with in
the context of multihoming? At least IMO the flow binding/flow mobility
aspects should be dealt with as a separate topic. I view the current scope
of specifying multihoming as simply the capability to establish multiple IP
mobility sessions either via the same interface or via multiple interfaces
to an LMA. I guess aspects of flow mobility can be considered especially if
we view the ability to move an HNP from one interface to another in the case
of multihoming.

> 2, Issues of Supported Home Network Prefix Models
> In current PMIPv6 base, it is not allowed that one HNP traverses
> multiple interfaces of MN. This limitation may defense
> a mobility session (or part of mobility session) moves from one
> interface to another to achieve load sharing, etc.

Okay. Agree about the part where an HNP may be across interfaces. We should
discusss the need for this further.

> More details of this scenario (/issue) were illustrated in
> ref.1 [draft-jeyatharan-netext-multihoming-ps-00.txt], and
> ref.2 [draft-muhanna-netlmm-multihoming-support-00.txt], etc.
>
> Please see more comments inline...
>
> B.R.
> Yungui
>
>>
>> a. The multihoming work in Netext should address the limitations of
>> RFC5213
>>   w.r.t multihoming. The issue of having a single BCE for an MN
>>   identified by an MN-ID and attaching via multiple interfaces should
>>   be resolved.
>
> [Yungui] In my understanding, this scenario (and c.) has been covered by
> PMIPv6 spec, Section 5.4.
> "
>    This specification allows mobile nodes to connect to a Proxy Mobile
>    IPv6 domain through multiple interfaces for simultaneous access.  The
>    following are the key aspects of this multihoming support.
>    o  When a mobile node connects to a Proxy Mobile IPv6 domain through
>       multiple interfaces for simultaneous access, the local mobility
>       anchor MUST allocate a mobility session for each of the attached
>       interfaces.  Each mobility session should be managed under a
>       separate Binding Cache entry and with its own lifetime.
> "

The point here is that the current PMIP6 spec says " Each mobility session
should be managed under a separate Binding Cache entry and with its own
lifetime". Why this limitation? The same BCE associated with an MN can be
used to establish multiple IP sessions. This would be the enhancement.

>
>>
>> b. The scenario where an MN is connected via a MAG to an LMA and the
>>   ability to establish multiple sessions via the same MAG. This is
>>   the case where the MN is attached via a specific access type and
>>   establishes multiple IP sessions via the MAG.
>>
> [Yungui] What's the difference from that multiple HNP for a given
> interface managed as one mobility session?
> "
>    o  The local mobility anchor MAY allocate more than one home network
>       prefix for a given interface of the mobile node.  However, all the
>       prefixes associated with a given interface MUST be managed as part
>       of one mobility session, associated with that interface.
>
> "

Okay.

>
>> c. The scenario where an MN attaches via different interfaces which
>>   are of differing access technologies via MAG1 and MAG2
>>   simultaneously. The MAG1/MAG2 entities are attached to the same
>>   LMA.
>>
> [Yungui] Please see the same comments as (a).
>

Fine. But with the caveat that you have a single BCE the MN in such a
scenario.

Thanks for your input.

-Raj

>> d. A combination of the scenarios in (b) and (c), i.e having multiple
>>   sessions via each access type while connected thru different MAGs
>>   simultaneously.
>>
>> Lets see if we can build some consensus around the scope of the
>> problem.
>>
>> -Raj
>>
>> _______________________________________________
>> NetExt mailing list
>> NetExt at mail.mobileip.jp
>> http://www.mobileip.jp/mailman/listinfo/netext
>
>

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Thu, 5 Feb 2009 16:27:05 -0500
Subject: [Netext] Review of the Multihoming PS I-D
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Yungui,

Good input. Please see some replies to your comments first.

> -----Original Message-----
> From: netext-bounces at mail.mobileip.jp 
> [mailto:netext-bounces at mail.mobileip.jp] On Behalf Of Yungui Wang
> Sent: Wednesday, February 04, 2009 6:53 PM
> To: Basavaraj.Patil at nokia.com; netext at mail.mobileip.jp
> Cc: gongxiaoyu; Basavaraj.Patil at nokia.com
> Subject: Re: [Netext] Review of the Multihoming PS I-D
> 
> Hello Raj,
> 
> Propose below two scenarios which have been defined in CMIPv6 
> to be considered in scope of multihoming as well.
> 1, Flow binding and flow mobility
> 2, Issues of Supported Home Network Prefix Models In current 
> PMIPv6 base, it is not allowed that one HNP traverses 
> multiple interfaces of MN. This limitation may defense a 
> mobility session (or part of mobility session) moves from one 
> interface to another to achieve load sharing, etc. 
> More details of this scenario (/issue) were illustrated in
> ref.1 [draft-jeyatharan-netext-multihoming-ps-00.txt], and
> ref.2 [draft-muhanna-netlmm-multihoming-support-00.txt], etc. 
> 
> Please see more comments inline...
> 
> B.R.
> Yungui
> 
> >
> > a. The multihoming work in Netext should address the limitations of
> > RFC5213
> >   w.r.t multihoming. The issue of having a single BCE for an MN
> >   identified by an MN-ID and attaching via multiple 
> interfaces should
> >   be resolved.
> 
> [Yungui] In my understanding, this scenario (and c.) has been 
> covered by
> PMIPv6 spec, Section 5.4.
> "
>    This specification allows mobile nodes to connect to a Proxy Mobile
>    IPv6 domain through multiple interfaces for simultaneous 
> access.  The
>    following are the key aspects of this multihoming support.
>    o  When a mobile node connects to a Proxy Mobile IPv6 
> domain through
>       multiple interfaces for simultaneous access, the local mobility
>       anchor MUST allocate a mobility session for each of the attached
>       interfaces.  Each mobility session should be managed under a
>       separate Binding Cache entry and with its own lifetime.
> "

Okay.

> 
> >
> > b. The scenario where an MN is connected via a MAG to an LMA and the
> >   ability to establish multiple sessions via the same MAG. This is
> >   the case where the MN is attached via a specific access type and
> >   establishes multiple IP sessions via the MAG.
> >
> [Yungui] What's the difference from that multiple HNP for a 
> given interface managed as one mobility session?
>    o  The local mobility anchor MAY allocate more than one 
> home network
>       prefix for a given interface of the mobile node.  
> However, all the
>       prefixes associated with a given interface MUST be 
> managed as part
>       of one mobility session, associated with that interface.
> 
> "
> 

Each mobility session may be instantiated dynamically at any time, and
not necessarily as a request for multiple HNPs within a single PBU.
Besides, why is there a requirement to manage multiple HNPs as part of
the same mobility session? A deployment may want to treat each mobility
session independently for a variety of reasons (e.g., QoS, Policy,
charging etc.).

> > c. The scenario where an MN attaches via different interfaces which
> >   are of differing access technologies via MAG1 and MAG2
> >   simultaneously. The MAG1/MAG2 entities are attached to the same
> >   LMA.
> >
> [Yungui] Please see the same comments as (a).

This needs to be drawn out further. Here, we should be able to support
the same HNP across MAG1 and MAG2.
I think this is referring to your item 2) above.

What do you mean by Flow binding here?

Regards,

-Rajeev

> 
> > d. A combination of the scenarios in (b) and (c), i.e 
> having multiple
> >   sessions via each access type while connected thru different MAGs
> >   simultaneously.
> >
> > Lets see if we can build some consensus around the scope of the 
> > problem.
> >
> > -Raj
> >
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.

From: rkoodli at starentnetworks.com (Koodli, Rajeev)
Date: Thu, 5 Feb 2009 13:31:11 -0500
Subject: [Netext] charter comments
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Jari,

Thanks for taking a look. Please see some comments below:
 
> I am looking at
> 
>    http://www.arkko.com/ietf/ietf-74/netext/bof.txt
> 
> is there a newer version of the charter text? Perhaps I 
> missed it, but this one seems include certain things also 
> outside the three topics that the chairs had told me they 
> were going to focus on (multihoming, intertechnology 
> handover, localized routing).

Yes, the version we sent you sometime ago needs to be updated. I logged
onto the WiKi few days ago, but could not update the items. Anyway, we
need to update the charter.

> 
> > Proxy MIP6, which is the IETF Network-based Mobility Protocol 
> > specified in RFC 5213, has been incorporated into the evolved 
> > architecture of Long-Term Evolution (LTE) and Wimax networks. The 
> > respective standards organizations are in the process of specifying 
> > the Proxy MIP6 protocol for their current requirements and 
> outlining 
> > the
> >   
> 
> the use of the Proxy ...

Okay.

> 
> > enhancements for subsequent releases of these networks. In light of 
> > the above, the following observations can be made:
> >
> > o as the trials and deployments of 4G networks are expected to begin
> >   in 2009, their evolution to support features such multihoming,
> >   inter-access technology handovers and localized routing
> >   continues
> >   
> 
> To be exact, the basics are being trialed and deployed 
> starting 2009 and then to a larger degree in 2010. The 
> extensions may not be on that same timeline. However, 3GPP 
> has a deadline December 2009 for their "Release 9" which 
> might include some of this functionality.

Yes. Perhaps the extensions may not be rolled out in 2009, but we would
like to have the protocols ready in time as the trials begin. 

> 
> > o while the base PMIPv6 protocol is completed, improvements are
> >   necessary in some areas, most notably multihoming and 
> >   inter-access technology handovers
> >
> > o certain deployment considerations, including localized routing and
> >   bulk refresh of lifetime are already emerging
> >
> > In summary, improvements, deficiencies and deployment 
> considerations 
> > are identified to extend the network-based mobility (i.e., 
> PMIPv6) to 
> > better meet the evolution of 4G mobile networks.
> >   
> 
> Yes.
> 
> > Proposed Work:
> > -------------
> >
> > The proposed NetExt Working Group will focus on the 
> following topics 
> > relevant for network-based mobility:
> >
> >  Improvements:
> >
> >    o Multihoming: a specification including the target scenarios,
> >    preservation of IP sessions and load balancing (Proposed 
> Standard)
> >   
> >    o Inter-access Technology handovers: a specification for 
> IP session
> >    preservation when changing access technologies (PS)
> >   
> 
> Both of these are very vaguely defined; hopefully there is 
> more detail in the documents. However, even at the BOF 
> proposal and charter level I would like to see this more 
> precisely. What type of multihoming do you intend to support? 

The details are expected in the PS documents. We could add little more
text here, but it is not possible to go through all the details.

> MN with multiple interfaces? MAG with multiple interfaces? 
> Also, in both cases there is some (albeit very basic) support 
> in RFC 5213. Please specify more of the delta you intend to 
> apply here. Finally, do the above require changes to mobile 
> nodes? I would expect that MN with multiple interfaces to use 
> the same IP address would require host changes. This should 
> be explicitly called out. (If the interfaces use different 
> addresses then RFC 5213 should work fine.)

There is discussion going on the topic. The main scenarios are:

1. Use of multiple IP mobility sessions over a single ATT (and single
MAG).
2. Use of multiple IP mobility sessions over respective ATTs (and
multiple MAGs)
   - how to use the same HNP across different interfaces
   - how to use the same HNP across different interfaces at the flow
granularity
3. Use of multiple IP mobility sessions over respective ATTs over a
single MAG

> 
> >  Deployment Considerations:
> >
> >    o Localized Routing: a specification for constraining routing to
> >    the MAG(s) without involving the LMA within a single PMIPv6
> >    domain (PS)
> >   
> 
> Again, there is limited functionality in RFC 5213, within a 
> single MAG.

There is no protocol specification on how to do this. It defines a flag,
which if set, can have localized routing.

> 
> State the intended optimization model in more detail. Packets 
> can flow directly between the MAGs, guided by some policy 
> that enables this functionality on a per host/per flow basis?
> 

In the PS document. Perhaps we will reference the PS docs against the
items.

> >    o Bulk Refresh: specification of improving the signaling load for
> >    binding lifetime refresh (PS)
> >
> >  Deficiencies:
> >
> >    o MN involvement: documentation of scenarios where MN involvement
> >    may be seen as beneficial (Informational)
> >   
> 
> How is this related to the other work items?

We probably don't want to take this up now to focus on the other topics.

> 
> > The BoF proposes to discuss the above items and gauge interest in 
> > forming a working Group. There is already work in progress 
> addressing 
> > the identified problems, which is expected to be the starting point 
> > for the deliverables.
> >
> > The proposed activity will be complementary to the existing IETF 
> > Working Groups, notably the NETLMM and MEXT WGs.
> >
> > Approximate Timeline for Deliverables:
> > -------------------------------------
> >
> > March 2009  WG approved by IESG
> >   
> April by the earliest, March is over when IETF-74 is over...
> 
> > 2Q09  	       Problem statements for multihoming, 
> localized routing
> > 	       and inter-access HO agreed upon in the WG
> > 2H09           Submit Inter-access Tech Handover, Localized Routing
> >                and Multihoming I-Ds to IESG  
> > 4Q09           Submit the I-D on MN Involvement to IESG 
> > 1Q10           Submit Bulk Refresh I-D to IESG 
> > 2H10           Recharter or close WG
> >   
> I would suggest breaking up WG document adoption and sending 
> to the IESG separately. Are the problem statements sent to 
> the IESG at all? Are the documents in the second step problem 
> statements or solutions? If the latter, its too aggressive schedule.

Okay, we will think over the schedule again (this is from last
November).

Thanks,

-Rajeev

> 
> Jari
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext
> 

This email and any attachments may contain legally privileged and/or confidential information of Starent Networks, Corp. and is intended only for the individual or entity named in the message.  The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster at starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you.

From: liebsch at nw.neclab.eu (Marco Liebsch)
Date: Thu, 05 Feb 2009 15:33:21 +0100
Subject: [Netext] First Problem Statement about Localized Routing in PMIPv6 submitted
Message-ID: <[email-masked]>

Hi all,

please find the link to a first version of a Localized Routing Problem 
Statement below.
The abstract of the PS document is as follows:

Abstract:

   Proxy Mobile IPv6 is the IETF standard for network-based localized
   mobility management.  In Proxy Mobile IPv6, mobile nodes are
   topologically anchored at a Local Mobility Anchor, which forwards all
   data for registered mobile nodes.  The set up and support for
   localized routing, which allows forwarding of data packets between
   mobile nodes and correspondent nodes directly without traversing an
   LMA, is not considered.  This document describes the problem space of
   localized routing in Proxy Mobile IPv6.

Any comments to this version of the problem statement are welcome.

http://www.ietf.org/internet-drafts/draft-liebsch-netext-pmip6-ro-ps-00.txt

Best regards,
marco

From: jari.arkko at piuha.net (Jari Arkko)
Date: Thu, 05 Feb 2009 14:57:00 +0200
Subject: [Netext] charter comments
Message-ID: <[email-masked]>

I am looking at

   http://www.arkko.com/ietf/ietf-74/netext/bof.txt

is there a newer version of the charter text? Perhaps I missed it, but 
this one seems include certain things also outside the three topics that 
the chairs had told me they were going to focus on (multihoming, 
intertechnology handover, localized routing).

> Proxy MIP6, which is the IETF Network-based Mobility Protocol
> specified in RFC 5213, has been incorporated into the evolved
> architecture of Long-Term Evolution (LTE) and Wimax networks. The
> respective standards organizations are in the process of specifying
> the Proxy MIP6 protocol for their current requirements and outlining the
>   

the use of the Proxy ...

> enhancements for subsequent releases of these networks. In light of
> the above, the following observations can be made: 
>
> o as the trials and deployments of 4G networks are expected to begin
>   in 2009, their evolution to support features such multihoming,
>   inter-access technology handovers and localized routing
>   continues
>   

To be exact, the basics are being trialed and deployed starting 2009 and 
then to a larger degree in 2010. The extensions may not be on that same 
timeline. However, 3GPP has a deadline December 2009 for their "Release 
9" which might include some of this functionality.

> o while the base PMIPv6 protocol is completed, improvements are
>   necessary in some areas, most notably multihoming and 
>   inter-access technology handovers 
>
> o certain deployment considerations, including localized routing and
>   bulk refresh of lifetime are already emerging
>
> In summary, improvements, deficiencies and deployment considerations
> are identified to extend the network-based mobility (i.e., PMIPv6) to
> better meet the evolution of 4G mobile networks. 
>   

Yes.

> Proposed Work:
> -------------
>
> The proposed NetExt Working Group will focus on the following topics
> relevant for network-based mobility:
>
>  Improvements:
>
>    o Multihoming: a specification including the target scenarios,
>    preservation of IP sessions and load balancing (Proposed Standard)
>   
>    o Inter-access Technology handovers: a specification for IP session
>    preservation when changing access technologies (PS)
>   

Both of these are very vaguely defined; hopefully there is more detail 
in the documents. However, even at the BOF proposal and charter level I 
would like to see this more precisely. What type of multihoming do you 
intend to support? MN with multiple interfaces? MAG with multiple 
interfaces? Also, in both cases there is some (albeit very basic) 
support in RFC 5213. Please specify more of the delta you intend to 
apply here. Finally, do the above require changes to mobile nodes? I 
would expect that MN with multiple interfaces to use the same IP address 
would require host changes. This should be explicitly called out. (If 
the interfaces use different addresses then RFC 5213 should work fine.)

>  Deployment Considerations:
>
>    o Localized Routing: a specification for constraining routing to
>    the MAG(s) without involving the LMA within a single PMIPv6
>    domain (PS)
>   

Again, there is limited functionality in RFC 5213, within a single MAG.

State the intended optimization model in more detail. Packets can flow 
directly between the MAGs, guided by some policy that enables this 
functionality on a per host/per flow basis?

>    o Bulk Refresh: specification of improving the signaling load for
>    binding lifetime refresh (PS)
>
>  Deficiencies:
>
>    o MN involvement: documentation of scenarios where MN involvement
>    may be seen as beneficial (Informational)
>   

How is this related to the other work items?

> The BoF proposes to discuss the above items and gauge interest in
> forming a working Group. There is already work in progress addressing
> the identified problems, which is expected to be the starting point
> for the deliverables. 
>
> The proposed activity will be complementary to the existing IETF
> Working Groups, notably the NETLMM and MEXT WGs. 
>
> Approximate Timeline for Deliverables:
> -------------------------------------
>
> March 2009  WG approved by IESG 
>   
April by the earliest, March is over when IETF-74 is over...

> 2Q09  	       Problem statements for multihoming, localized routing
> 	       and inter-access HO agreed upon in the WG
> 2H09           Submit Inter-access Tech Handover, Localized Routing
>                and Multihoming I-Ds to IESG  
> 4Q09           Submit the I-D on MN Involvement to IESG 
> 1Q10           Submit Bulk Refresh I-D to IESG 
> 2H10           Recharter or close WG
>   
I would suggest breaking up WG document adoption and sending to the IESG 
separately. Are the problem statements sent to the IESG at all? Are the 
documents in the second step problem statements or solutions? If the 
latter, its too aggressive schedule.

Jari

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Thu, 5 Feb 2009 14:20:45 +0800
Subject: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt
In-Reply-To: <[email-masked]>
Message-ID: <[email-masked]>

Hi Yungui,

Please see in-line.

BR,

Mohana

-----Original Message-----
From: Yungui Wang [mailto:w52006 at huawei.com] 
Sent: Wednesday, February 04, 2009 10:47 AM
To: Mohana Jeyatharan
Cc: netext at mail.mobileip.jp
Subject: Re: [Netext] FW:
I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt

Hello Mohana

Thanks for you clarification. Please see below comments...

[Mohana] Flow based routing is not a solution and we have not described

it as a solution in the PS-ID. It is just mentioned such mechanism may

need to be supported by PMIPv6 extensions. The PMIPv6 protocol does not

support it. At this point, I like to re emphasize what we mean by flow

based routing. It is routing all P1 flows via p2 interface and all P2

flows via P1 interface. basiaclly, it is swapping of the prefixes. This

flow based routing overides the normal prefix based routing of PMIPv6.

That is all. Hope this helps.

[Yungui] Although you don't described it as a solution, it seems you

had potentially done.  For example, 'basiaclly, it is swapping of the

prefixes.' is your assumed solution to flow based routing. That's not an

issue related to flow based routing for PMIPv6.

[Mohana] Ok, what you are saying is right. Rather than setting filters
for each flow, such swapping of prefixes makes a combined action.
However, I just classified based on possible states and divisions of
multihoming. I agree it is solution to a certain problem. But to
activate this scenario (of swapping of prefixes), certain detail
protocol operations have to be configured in the system.

Thus it is not a full solution. Why we classified it as a scenario is
because it is a state on multihoming. An MN may want

This kind of deployment. Why it wants is the problem you are thinking
of.

I agree that 'It is routing all P1 flows via p2 interface and all

P2 flows via P1 interface.' is a scenario of flow based routing,
however,

whose problem we had discussed is 'one prefix can't tranverse multiple

interfaces'. In my mind, maybe there is a certain solution to flow based

routing can make consistent with prefix based routing of PMIPv6.

[Mohana] I am not sure what you mean by "flow based routing made
consistent with routing based on PMIPv6". 

Flow based routing is just high level. The actual routing will be
performed using routing based on PMIPv6 even in the case of swapping of
prefixes (flow based routing that is described in the draft)

 

[Mohana]In the sub-section <issues related to Simultaneous usage of

interfaces> there are three issues highligted. Let me highlight the

principle of the issues. The first one is, flow based routing associated

with certain flows associated with a prefix. If a flow does not match

the filters, then the flows will be routed by using the routing rules of

PMIPv6. The second and third issues are simultaneous usage for a single

or multiple prefixes. The main motive for such division is that to

understand the levels of multihoming that we can achieve in the base

PMIPv6 protocol. What we mean by simulatneous usage for a single or

multiple prefixes is mainly like a simulatneous usage of one or more.

Now, what I said about prioritize the prefixes, is sometimes the network

may not provide such services for all the prefixes(simulatneous usage).

Then the Mn based on some decsion criteria may need to prioritze. We did

not explain this in the draft. Howveer, such divisions are highlighted

because there are many levels of multihoming that can be achieved.

 

[Yungui] Sorry for I can't get your logic. If network can not provide
such

services for all the prefixes(simulatneous usage), why does it allocate

multiple prefixes to MN? 

[Mohana] Yungui, this is just an example. Anyway allocating multiple
prefixes to an interface and enabling routing for those multiple
prefixes via all interfaces may be more core network signaling. Again if
we go into this we are more or less touching on the solution space. But,
We need to identify a scenario where simultaneous usage for a single or
multiple prefixes. It depends on the nature of flows. For example for
real-time flows one would not want such simultaneous usage. However for
non-time critical flows, perhaps one would want such simultaneous usage
services.

On the other side, even if it is reasonable, maybe

it can directly stated as an issue, e.g. prefix selection. However,
proirity 

or

MN's preference, network's policy, etc total can be considered as
solution

for further study.

[Mohana] Yes, I was thinking more towards these lines....

In addition, the draft seems mostly being described as 'scenario -
assumed

solution - solution related issues (impact to PMIP6 basis)'. That means,
I

am not sure I have gotten the actual multihoming problems from this ps

ID.

[Mohana] I think we wrote the draft in such a way that multihoming
scenarios are there tied to multiple prefixes model of PMIPv6 (different
prefixes via its interfaces). Each of these in a very high level can be
considered as a solution. But, it is more like an effect of the final
solutions. Thus, whenever such high level solutions are not supported we
classified it as an issue. Because as explained in the draft, there is a
reason for such high level solutions to be supported. These are
explained in the draft. Whenever. these high level solutions are not
supported it is considered as a problem. High level solutions are not
solution. Detail signaling and solution operation is needed.

 

Thanks Yungui. 

 

B.R.

Yungui

----- Original Message ----- 
From: "Mohana Jeyatharan" <Mohana.Jeyatharan at sg.panasonic.com>

To: "Yungui Wang" <w52006 at huawei.com>

Cc: <netext at mail.mobileip.jp>

Sent: Wednesday, February 04, 2009 8:47 AM

Subject: RE: [Netext] FW: 

I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt

 

Hi Yungui,

Please see reply in-line.

BR,

Mohana

 

  _____

From: Yungui Wang [mailto:w52006 at huawei.com]
Sent: Tuesday, February 03, 2009 11:44 AM
To: Mohana Jeyatharan
Cc: netext at mail.mobileip.jp
Subject: Re: [Netext] FW:
I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt

 

Hello Mohana,

Please see inline...

B.R.

Yungui

----- Original Message ----- 
From: Mohana Jeyatharan <mailto:Mohana.Jeyatharan at sg.panasonic.com>

To: Yungui Wang <mailto:w52006 at huawei.com>

Cc: netext at mail.mobileip.jp

Sent: Monday, February 02, 2009 6:11 PM

Subject: RE: [Netext] FW:

I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt

Hi Yungui,

Thanks for reading. Please see reply in-line.

BR,

Mohana

 

  _____

From: Yungui Wang [mailto:w52006 at huawei.com]
Sent: Monday, February 02, 2009 5:19 PM
To: Mohana Jeyatharan
Cc: netext at mail.mobileip.jp
Subject: Re: [Netext] FW:
I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt

 

Hello Mohana

Thanks for your hard works. There are my several comments.

1, In section 2, issue related to simultaneous usage of interfaces.

Here are three sub-issues illustrated within following three scenarios

respectively. Regarding of the first sub-issue, it can be educed that

one IP address can't traverse multiple interfaces of MN.

[Mohana] Yes, it can be considered that some IP address cannot traverse

the other interface or an IP connection that can be characterised by

some parameters cannot traverse another interface. The first issue is

that, MN wants certain flows associated with a prefix to traverse via a

certain interface. It is different from the issue, Flow based routing

given in the ID. Flow based routing issue is complete swapping of

prefixes, where all P1 flows sent via P2 interface and all P2 flows sent

via P1 interface.

[Yungui] What's you mentioned flow based routing in the PMIP6 domain? I

don't see this solution until now.

[Mohana] Flow based routing is not a solution and we have not described

it as a solution in the PS-ID. It is just mentioned such mechanism may

need to be supported by PMIPv6 extensions. The PMIPv6 protocol does not

support it. At this point, I like to re emphasize what we mean by flow

based routing. It is routing all P1 flows via p2 interface and all P2

flows via P1 interface. basiaclly, it is swapping of the prefixes. This

flow based routing overides the normal prefix based routing of PMIPv6.

That is all. Hope this helps.

 

Regarding of the second and third sub-issue, what's their difference? In

my understanding, they both seems to say the same issue that one Prefix

can't traverse multiple interfaces of MN.

[Mohana] I agree from operation or solution point of view one prefix or

multiple prefixes the same. Whether one wants to give one prefix such

simultaneous usage or multiple prefixes such simulatneous usage is the

difference. Since multiple prefixes are obtained in PMIPv6 via multiple

interfaces, such differences are essentail to consider. because, in some

cases, the network may not support this and the Mn may need to

prioritize the prefixes.

[Yungui] From the third scenario described in the draft, in my

understanding, load balancing feature may bring P1 flows moving from IF1

to IF2.  Do you mean it is necessary to prioritize multiple prefixes (P1

and P2) via one interface (IF2) of MN? If so, I don't think this

priority issue is related to multihoming/multiple-interface. However, I

agree with the third scenario although it is a certain similar as the

second.

[Mohana]In the sub-section <issues related to Simultaneous usage of

interfaces> there are three issues highligted. Let me highlight the

principle of the issues. The first one is, flow based routing associated

with certain flows associated with a prefix. If a flow does not match

the filters, then the flows will be routed by using the routing rules of

PMIPv6. The second and third issues are simultaneous usage for a single

or multiple prefixes. The main motive for such division is that to

understand the levels of multihoming that we can achieve in the base

PMIPv6 protocol. What we mean by simulatneous usage for a single or

multiple prefixes is mainly like a simulatneous usage of one or more.

Now, what I said about prioritize the prefixes, is sometimes the network

may not provide such services for all the prefixes(simulatneous usage).

Then the Mn based on some decsion criteria may need to prioritze. We did

not explain this in the draft. Howveer, such divisions are highlighted

because there are many levels of multihoming that can be achieved.

2, In section 2, issue related to Flow based Routing

Maybe you are proposing flow based solution? This scenario may have been

contained in the first issue and it scenarios (like the first

sub-issue).

[Mohana] As I explained, it is quite different. Here (flow based

routing) all the flows associated with a prefix may need to be

transferred via another interface. It is how you define the filters. In

the first case (certain flows of a prefix sent via another interface),

filters are defined for flows where as for the Flow based routing case,

flows defined for prefixes.

[Yungui] Please see the 1st comments.

 3, In section 2, issue related to Flow Mobility during Sudden

Disconnection

It may be a general reliability issue associated with Multiple Interface

capable node, not related to flow mobility.

[Mohana]It is in a way flow mobility. If there is disconnection and if

appropriate vertical handoff triggers are not sent, then flows

associated with a prefix is lost. It is beneficial to get these flows

via a connected interface during the diconnection period. So, it is flow

mobility but happening in a disconnection scenario.

[Yungui] When one link is disconnected, something over it may be is an

application, a IP seesion, a flow, or nothing. I wonder if it is

specially for flow mobility. Maybe this scenario can be outlined as

'Issues Related to Sudden Disconnection'.

[Mohana] Ok.... Will reconsider about the wording. I understand your

concern. Flow mobility is transfering of a flow .When all the flows are

transferred due to disconnection, then perhaps we may need to

re-consider a better term. Thanks..

4, In section 3 Multihoming Issues in PMIPv6/CMIPv6 mixed Scenario

These issues may depend on the basis issues described in PMIPv6/CMIPv6

interaction [draft-giaretta-netlmm-mip-interactions-02.txt]. I am not

sure whether these issues exsit. For example, if two spearate BCEs are

created with different indexes (e.g. HoA for MIP, HNP/MN-ID for PMIP,

etc.) in LMA/HA for PMIPv6/CMIPv6 domain respectively, it may be not

necessary to do that synchronization.

[Mohana] The PMIPv6/CMIPv6 interaction draft

[draft-giaretta-netlmm-mip-interactions-02.txt] was specifically

designed for a single interface case. There it is considered that the

MIPv6 binidng takes precedence over the PMIPv6 binding, so I am not sure

why you are comparing this to PMIP/CMIP draft. Even if we follow the

logic used in that draft, according to that draft only one of the

bindings are valid at any point in time. Thus there is no mechanism that

describes simulatneous reachability using PMIPv6 and CMIPv6 bindings.

Thus we need to look at this as a special problem that is related to

Multiplke Interfaces and look at how to solve the issue.

[Yungui] Get it. Maybe it is necessary to be done next step.

[Mohana] Ok.

5, In addition, there is a typo error in the Figure 2. In the text

description, CMIP6 is used via the MN.IF1. Thus, here is AR1, not

MAG1(AGW) in the Figure 2.

[Mohana] well, we considered a 3GPP specific scenario. I agree in CMIPv6

case there is no MAG but it is explained in the text that a prefix for

care-of address is obtained from AGW which happens to be a MAG. Anyway

please highlight whether we have made a mistake here (please point to

the correct text). thanks.

[Yungui] Here I was just confused that the entity MAG1 located in the

CMIP6 domain. Do you mean an AR (within AGW) can't allocate a prefix for

configuring a CoA?

[Mohana] i agree, that IF1's mobility is managed by CMIPv6. However, the

architecture can support PMIPv6 as well. That is why the AGW/MAG1 term

is used in figure 2. In CMIPv6 mode, The AGW does not function as a MAG

to the MN. It only provides a prefix and acts as a normal AR.

 

B.R.

Yungui

 

----- Original Message ----- 
From: Mohana Jeyatharan <mailto:Mohana.Jeyatharan at sg.panasonic.com>

To: netext at mail.mobileip.jp

Sent: Friday, January 23, 2009 12:20 PM

Subject: [Netext] FW: I-D

Action:draft-jeyatharan-netext-multihoming-ps-00.txt

 

Hello All,

We have drafted the problem stated ID, which highlights multihoming

related issues in PMIPv6 and the need for further work. Please have a

look and we can start some discussion on scenarios and issues.

Thanks.

BR,

Mohana

-----Original Message-----
From: i-d-announce-bounces at ietf.org

[mailto:i-d-announce-bounces at ietf.org] On Behalf Of

Internet-Drafts at ietf.org

Sent: Friday, January 23, 2009 12:15 PM

To: i-d-announce at ietf.org

Subject: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts

directories.

Title           : Multihoming Problem Statement in NetLMM

Author(s)       : M. Jeyatharan, C. Ng

Filename        : draft-jeyatharan-netext-multihoming-ps-00.txt

Pages           : 12

Date            : 2009-01-22

The base PMIPv6 protocol does not have adequate mechanisms to support

advanced multihoming such as simultaneous usage of all interfaces of a

mobile node (MN) to receive and transmit data packets associated with a

given prefix allocated to MN, and allow flow based routing according to

preference, rules, and policies set by the MN or network entity.  This

memo highlights such advanced multihoming related issues when mobility

of the multiple interfaced mobile node (MuIF MN) is purely managed by

PMIPv6 mechanism.  It also highlights the issue of lack of simultaneous

attachment support when the mobility of the MuIF MN is managed by PMIPv6

and CMIPv6 mechanisms.

A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-jeyatharan-netext-multihoming-

ps-00.txt

Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader

implementation to automatically retrieve the ASCII version of the

Internet-Draft.

 

 

  _____

 

 

_______________________________________________

NetExt mailing list

NetExt at mail.mobileip.jp

http://www.mobileip.jp/mailman/listinfo/netext

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090205/0ec610d8/attachment-0001.html>

From: w52006 at huawei.com (Yungui Wang)
Date: Thu, 05 Feb 2009 10:53:13 +0800
Subject: [Netext] Review of the Multihoming PS I-D
References: <[email-masked]>
Message-ID: <[email-masked]>

Hello Raj,

Propose below two scenarios which have been defined in CMIPv6 
to be considered in scope of multihoming as well.
1, Flow binding and flow mobility 
2, Issues of Supported Home Network Prefix Models
In current PMIPv6 base, it is not allowed that one HNP traverses 
multiple interfaces of MN. This limitation may defense
a mobility session (or part of mobility session) moves from one 
interface to another to achieve load sharing, etc. 
More details of this scenario (/issue) were illustrated in
ref.1 [draft-jeyatharan-netext-multihoming-ps-00.txt], and
ref.2 [draft-muhanna-netlmm-multihoming-support-00.txt], etc. 

Please see more comments inline...

B.R.
Yungui

>
> a. The multihoming work in Netext should address the limitations of 
> RFC5213
>   w.r.t multihoming. The issue of having a single BCE for an MN
>   identified by an MN-ID and attaching via multiple interfaces should
>   be resolved.

[Yungui] In my understanding, this scenario (and c.) has been covered by
PMIPv6 spec, Section 5.4.
"
   This specification allows mobile nodes to connect to a Proxy Mobile
   IPv6 domain through multiple interfaces for simultaneous access.  The
   following are the key aspects of this multihoming support.
   o  When a mobile node connects to a Proxy Mobile IPv6 domain through
      multiple interfaces for simultaneous access, the local mobility
      anchor MUST allocate a mobility session for each of the attached
      interfaces.  Each mobility session should be managed under a
      separate Binding Cache entry and with its own lifetime.
"

>
> b. The scenario where an MN is connected via a MAG to an LMA and the
>   ability to establish multiple sessions via the same MAG. This is
>   the case where the MN is attached via a specific access type and
>   establishes multiple IP sessions via the MAG.
>
[Yungui] What's the difference from that multiple HNP for a given 
interface managed as one mobility session?
"
   o  The local mobility anchor MAY allocate more than one home network
      prefix for a given interface of the mobile node.  However, all the
      prefixes associated with a given interface MUST be managed as part
      of one mobility session, associated with that interface.

"

> c. The scenario where an MN attaches via different interfaces which
>   are of differing access technologies via MAG1 and MAG2
>   simultaneously. The MAG1/MAG2 entities are attached to the same
>   LMA.
>
[Yungui] Please see the same comments as (a).

> d. A combination of the scenarios in (b) and (c), i.e having multiple
>   sessions via each access type while connected thru different MAGs
>   simultaneously.
>
> Lets see if we can build some consensus around the scope of the
> problem.
>
> -Raj
>
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext 

From: Basavaraj.Patil at nokia.com (Basavaraj.Patil at nokia.com)
Date: Wed, 4 Feb 2009 15:55:59 +0100
Subject: [Netext] Review of the Multihoming PS I-D
Message-ID: <[email-masked]>

Hello,

I have reviewed the Netext Multihoming PS I-D
<draft-jeyatharan-netext-multihoming-ps-00>. Thanks to Mohana for her
efforts on getting this I-D ready.

1. My impression after reading the I-D is that it misses the key
   problem of multihoming that we are trying to work on. Proxy MIP6 as
   currently specified in RFC5213 has limited support for
   multihoming. It was decided that multihoming should be dealt with
   separately in Netlmm during the course discussions on this topic in
   the past. While many of the issues mentioned in the I-D are
   relevant I believe that Netext should be working on a more narrow
   scope to enhance PMIP6 to support a few multihoming scenarios.

2. Sec 3 of the I-D which analyses multihoming issues in the case of
   PMIP6/CMIP6 coexisting together is really misplaced here. I do not
   believe we want to address this topic as part of the multihoming
   work in Netext. This is simply out of scope.

3. The I-D focuses on the problem of multiplexing flows or having
   flows traverse via one interface or another or the ability to move
   a flow from one interface to another. While these are all valid
   things to do in PMIP6, I am not convinced that these are
   specifically related to multihoming.

Rajeev and I had a discussion on the scope of multihoming and what we
should really be focusing on. We came up with the following specific
scenarios which we should address:

a. The multihoming work in Netext should address the limitations of RFC5213
   w.r.t multihoming. The issue of having a single BCE for an MN
   identified by an MN-ID and attaching via multiple interfaces should
   be resolved.

b. The scenario where an MN is connected via a MAG to an LMA and the
   ability to establish multiple sessions via the same MAG. This is
   the case where the MN is attached via a specific access type and
   establishes multiple IP sessions via the MAG.

c. The scenario where an MN attaches via different interfaces which
   are of differing access technologies via MAG1 and MAG2
   simultaneously. The MAG1/MAG2 entities are attached to the same
   LMA.

d. A combination of the scenarios in (b) and (c), i.e having multiple
   sessions via each access type while connected thru different MAGs
   simultaneously.

Lets see if we can build some consensus around the scope of the
problem.

-Raj

From: w52006 at huawei.com (Yungui Wang)
Date: Wed, 04 Feb 2009 10:47:15 +0800
Subject: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello Mohana

Thanks for you clarification. Please see below comments...

[Mohana] Flow based routing is not a solution and we have not described
it as a solution in the PS-ID. It is just mentioned such mechanism may
need to be supported by PMIPv6 extensions. The PMIPv6 protocol does not
support it. At this point, I like to re emphasize what we mean by flow
based routing. It is routing all P1 flows via p2 interface and all P2
flows via P1 interface. basiaclly, it is swapping of the prefixes. This
flow based routing overides the normal prefix based routing of PMIPv6.
That is all. Hope this helps.
[Yungui] Although you don't described it as a solution, it seems you
had potentially done.  For example, 'basiaclly, it is swapping of the
prefixes.' is your assumed solution to flow based routing. That's not an
issue related to flow based routing for PMIPv6.
I agree that 'It is routing all P1 flows via p2 interface and all
P2 flows via P1 interface.' is a scenario of flow based routing, however,
whose problem we had discussed is 'one prefix can't tranverse multiple
interfaces'. In my mind, maybe there is a certain solution to flow based
routing can make consistent with prefix based routing of PMIPv6.

[Mohana]In the sub-section <issues related to Simultaneous usage of
interfaces> there are three issues highligted. Let me highlight the
principle of the issues. The first one is, flow based routing associated
with certain flows associated with a prefix. If a flow does not match
the filters, then the flows will be routed by using the routing rules of
PMIPv6. The second and third issues are simultaneous usage for a single
or multiple prefixes. The main motive for such division is that to
understand the levels of multihoming that we can achieve in the base
PMIPv6 protocol. What we mean by simulatneous usage for a single or
multiple prefixes is mainly like a simulatneous usage of one or more.

Now, what I said about prioritize the prefixes, is sometimes the network
may not provide such services for all the prefixes(simulatneous usage).
Then the Mn based on some decsion criteria may need to prioritze. We did
not explain this in the draft. Howveer, such divisions are highlighted
because there are many levels of multihoming that can be achieved.

[Yungui] Sorry for I can't get your logic. If network can not provide such
services for all the prefixes(simulatneous usage), why does it allocate
multiple prefixes to MN? On the other side, even if it is reasonable, maybe
it can directly stated as an issue, e.g. prefix selection. However, proirity 
or
MN's preference, network's policy, etc total can be considered as solution
for further study.
In addition, the draft seems mostly being described as 'scenario - assumed
solution - solution related issues (impact to PMIP6 basis)'. That means, I
am not sure I have gotten the actual multihoming problems from this ps
ID.

B.R.
Yungui

----- Original Message ----- 
From: "Mohana Jeyatharan" <Mohana.Jeyatharan at sg.panasonic.com>
To: "Yungui Wang" <w52006 at huawei.com>
Cc: <netext at mail.mobileip.jp>
Sent: Wednesday, February 04, 2009 8:47 AM
Subject: RE: [Netext] FW: 
I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt

Hi Yungui,

Please see reply in-line.

BR,
Mohana

  _____

From: Yungui Wang [mailto:w52006 at huawei.com]
Sent: Tuesday, February 03, 2009 11:44 AM
To: Mohana Jeyatharan
Cc: netext at mail.mobileip.jp
Subject: Re: [Netext] FW:
I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt

Hello Mohana,

Please see inline...

B.R.
Yungui

----- Original Message ----- 
From: Mohana Jeyatharan <mailto:Mohana.Jeyatharan at sg.panasonic.com>
To: Yungui Wang <mailto:w52006 at huawei.com>
Cc: netext at mail.mobileip.jp
Sent: Monday, February 02, 2009 6:11 PM
Subject: RE: [Netext] FW:
I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt

Hi Yungui,

Thanks for reading. Please see reply in-line.
BR,
Mohana

  _____

From: Yungui Wang [mailto:w52006 at huawei.com]
Sent: Monday, February 02, 2009 5:19 PM
To: Mohana Jeyatharan
Cc: netext at mail.mobileip.jp
Subject: Re: [Netext] FW:
I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt

Hello Mohana

Thanks for your hard works. There are my several comments.

1, In section 2, issue related to simultaneous usage of interfaces.
Here are three sub-issues illustrated within following three scenarios
respectively. Regarding of the first sub-issue, it can be educed that
one IP address can't traverse multiple interfaces of MN.
[Mohana] Yes, it can be considered that some IP address cannot traverse
the other interface or an IP connection that can be characterised by
some parameters cannot traverse another interface. The first issue is
that, MN wants certain flows associated with a prefix to traverse via a
certain interface. It is different from the issue, Flow based routing
given in the ID. Flow based routing issue is complete swapping of
prefixes, where all P1 flows sent via P2 interface and all P2 flows sent
via P1 interface.
[Yungui] What's you mentioned flow based routing in the PMIP6 domain? I
don't see this solution until now.
[Mohana] Flow based routing is not a solution and we have not described
it as a solution in the PS-ID. It is just mentioned such mechanism may
need to be supported by PMIPv6 extensions. The PMIPv6 protocol does not
support it. At this point, I like to re emphasize what we mean by flow
based routing. It is routing all P1 flows via p2 interface and all P2
flows via P1 interface. basiaclly, it is swapping of the prefixes. This
flow based routing overides the normal prefix based routing of PMIPv6.
That is all. Hope this helps.

Regarding of the second and third sub-issue, what's their difference? In
my understanding, they both seems to say the same issue that one Prefix
can't traverse multiple interfaces of MN.
[Mohana] I agree from operation or solution point of view one prefix or
multiple prefixes the same. Whether one wants to give one prefix such
simultaneous usage or multiple prefixes such simulatneous usage is the
difference. Since multiple prefixes are obtained in PMIPv6 via multiple
interfaces, such differences are essentail to consider. because, in some
cases, the network may not support this and the Mn may need to
prioritize the prefixes.
[Yungui] From the third scenario described in the draft, in my
understanding, load balancing feature may bring P1 flows moving from IF1
to IF2.  Do you mean it is necessary to prioritize multiple prefixes (P1
and P2) via one interface (IF2) of MN? If so, I don't think this
priority issue is related to multihoming/multiple-interface. However, I
agree with the third scenario although it is a certain similar as the
second.
[Mohana]In the sub-section <issues related to Simultaneous usage of
interfaces> there are three issues highligted. Let me highlight the
principle of the issues. The first one is, flow based routing associated
with certain flows associated with a prefix. If a flow does not match
the filters, then the flows will be routed by using the routing rules of
PMIPv6. The second and third issues are simultaneous usage for a single
or multiple prefixes. The main motive for such division is that to
understand the levels of multihoming that we can achieve in the base
PMIPv6 protocol. What we mean by simulatneous usage for a single or
multiple prefixes is mainly like a simulatneous usage of one or more.

Now, what I said about prioritize the prefixes, is sometimes the network
may not provide such services for all the prefixes(simulatneous usage).
Then the Mn based on some decsion criteria may need to prioritze. We did
not explain this in the draft. Howveer, such divisions are highlighted
because there are many levels of multihoming that can be achieved.
2, In section 2, issue related to Flow based Routing
Maybe you are proposing flow based solution? This scenario may have been
contained in the first issue and it scenarios (like the first
sub-issue).
[Mohana] As I explained, it is quite different. Here (flow based
routing) all the flows associated with a prefix may need to be
transferred via another interface. It is how you define the filters. In
the first case (certain flows of a prefix sent via another interface),
filters are defined for flows where as for the Flow based routing case,
flows defined for prefixes.
[Yungui] Please see the 1st comments.

 3, In section 2, issue related to Flow Mobility during Sudden
Disconnection
It may be a general reliability issue associated with Multiple Interface
capable node, not related to flow mobility.
[Mohana]It is in a way flow mobility. If there is disconnection and if
appropriate vertical handoff triggers are not sent, then flows
associated with a prefix is lost. It is beneficial to get these flows
via a connected interface during the diconnection period. So, it is flow
mobility but happening in a disconnection scenario.
[Yungui] When one link is disconnected, something over it may be is an
application, a IP seesion, a flow, or nothing. I wonder if it is
specially for flow mobility. Maybe this scenario can be outlined as
'Issues Related to Sudden Disconnection'.
[Mohana] Ok.... Will reconsider about the wording. I understand your
concern. Flow mobility is transfering of a flow .When all the flows are
transferred due to disconnection, then perhaps we may need to
re-consider a better term. Thanks..

4, In section 3 Multihoming Issues in PMIPv6/CMIPv6 mixed Scenario
These issues may depend on the basis issues described in PMIPv6/CMIPv6
interaction [draft-giaretta-netlmm-mip-interactions-02.txt]. I am not
sure whether these issues exsit. For example, if two spearate BCEs are
created with different indexes (e.g. HoA for MIP, HNP/MN-ID for PMIP,
etc.) in LMA/HA for PMIPv6/CMIPv6 domain respectively, it may be not
necessary to do that synchronization.
[Mohana] The PMIPv6/CMIPv6 interaction draft
[draft-giaretta-netlmm-mip-interactions-02.txt] was specifically
designed for a single interface case. There it is considered that the
MIPv6 binidng takes precedence over the PMIPv6 binding, so I am not sure
why you are comparing this to PMIP/CMIP draft. Even if we follow the
logic used in that draft, according to that draft only one of the
bindings are valid at any point in time. Thus there is no mechanism that
describes simulatneous reachability using PMIPv6 and CMIPv6 bindings.
Thus we need to look at this as a special problem that is related to
Multiplke Interfaces and look at how to solve the issue.
[Yungui] Get it. Maybe it is necessary to be done next step.
[Mohana] Ok.

5, In addition, there is a typo error in the Figure 2. In the text
description, CMIP6 is used via the MN.IF1. Thus, here is AR1, not
MAG1(AGW) in the Figure 2.
[Mohana] well, we considered a 3GPP specific scenario. I agree in CMIPv6
case there is no MAG but it is explained in the text that a prefix for
care-of address is obtained from AGW which happens to be a MAG. Anyway
please highlight whether we have made a mistake here (please point to
the correct text). thanks.
[Yungui] Here I was just confused that the entity MAG1 located in the
CMIP6 domain. Do you mean an AR (within AGW) can't allocate a prefix for
configuring a CoA?
[Mohana] i agree, that IF1's mobility is managed by CMIPv6. However, the
architecture can support PMIPv6 as well. That is why the AGW/MAG1 term
is used in figure 2. In CMIPv6 mode, The AGW does not function as a MAG
to the MN. It only provides a prefix and acts as a normal AR.

B.R.
Yungui

----- Original Message ----- 
From: Mohana Jeyatharan <mailto:Mohana.Jeyatharan at sg.panasonic.com>
To: netext at mail.mobileip.jp
Sent: Friday, January 23, 2009 12:20 PM
Subject: [Netext] FW: I-D
Action:draft-jeyatharan-netext-multihoming-ps-00.txt

Hello All,

We have drafted the problem stated ID, which highlights multihoming
related issues in PMIPv6 and the need for further work. Please have a
look and we can start some discussion on scenarios and issues.
Thanks.

BR,
Mohana
-----Original Message-----
From: i-d-announce-bounces at ietf.org
[mailto:i-d-announce-bounces at ietf.org] On Behalf Of
Internet-Drafts at ietf.org
Sent: Friday, January 23, 2009 12:15 PM
To: i-d-announce at ietf.org
Subject: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

Title           : Multihoming Problem Statement in NetLMM
Author(s)       : M. Jeyatharan, C. Ng
Filename        : draft-jeyatharan-netext-multihoming-ps-00.txt
Pages           : 12
Date            : 2009-01-22

The base PMIPv6 protocol does not have adequate mechanisms to support
advanced multihoming such as simultaneous usage of all interfaces of a
mobile node (MN) to receive and transmit data packets associated with a
given prefix allocated to MN, and allow flow based routing according to
preference, rules, and policies set by the MN or network entity.  This
memo highlights such advanced multihoming related issues when mobility
of the multiple interfaced mobile node (MuIF MN) is purely managed by
PMIPv6 mechanism.  It also highlights the issue of lack of simultaneous
attachment support when the mobility of the MuIF MN is managed by PMIPv6
and CMIPv6 mechanisms.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jeyatharan-netext-multihoming-
ps-00.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

  _____

_______________________________________________
NetExt mailing list
NetExt at mail.mobileip.jp
http://www.mobileip.jp/mailman/listinfo/netext

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Wed, 4 Feb 2009 09:12:22 +0800
Subject: [Netext] PMIPv6 Multihoming problem statemnt draft Notification
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Niklas,

Thank for your comments. Please see reply in-line.
BR,
Mohana 

> -----Original Message-----
> From: Niklas Neumann [mailto:niklas.neumann at cs.uni-goettingen.de] 
> Sent: Tuesday, February 03, 2009 7:35 PM
> To: Mohana Jeyatharan
> Cc: netext at mail.mobileip.jp
> Subject: Re: [Netext] PMIPv6 Multihoming problem statemnt 
> draft Notification
> 
> Hey Mohana,
> 
> thank you for submitting the draft. I have a couple of questions:
> 
> 1) Can you please help me to understand what the PMIP 
> relation of those issues is? To me everything you outlined in 
> Section 2 sounds like the general problems associated with 
> multi-path routing. As a matter of fact as far as I 
> understand, if all those problems were solved as proposed in 
> the draft we wouldn't need PMIP anymore because a MN would 
> have the means to delegate any flow to any available 
> interface no matter of the prefix. I am not saying all those 
> points in the draft are not valid issues, I just need some 
> help to understand the relationship to PMIP.

[Mohana] First of all I was surprised to see you saying if MN 
can achieve multihoming with some support from network, we don't 
Need PMIPv6. I really don't think so. But, I agree, that some of the 
Multihoming scenarios and flow based routing and so on overides the
PMIPv6
Base operation. However, PMIPv6 is definitely important because these
Are extensions to the protocol. PMIPv6 is the base to set up the
routing.
All these extensions (I am talking about solution) will need to use 
Base PMIPv6 mechanisms. Thus, these are extensions. At this juncture I
would 
like to quote the draft ::draft-koodli-flow-handover-00.txt. If you look
at it,
it can be seen that base PMIPv6 is running, but the solution is using
some new
Messages to achieve flow based routing. This draft matches the first
issue 
which we have stated in our draft of achieving a flow associated with a
prefix 
via a certain interface 

I can quote you an anology. MIPv6 is the base protocol and MCoA(MONAMI6)
is an
Extension to MIPv6 to achieve multihoming to MNs that want and can
support
Multihoming. When extensions are proposed, the Mn and HA needs to be
chnaged. 
The same principle here.... Multihoming extensions are mobility
protocols. 
> 2) Regarding Section 3, if the home domain offers two 
> mobility solutions (PMIP and CMIP), isn't it a deployment 
> error to mix the BCs of the two solutions? I am not clear how 
> a PMIP PBU can otherwise invalidate a CMIP BCE.

[Mohana]Yes, if a home domain offers both PMIPv6 and CMIPv6 mechanisms
for its interfaces, then it needs to have mechanisms to clearly
Separate the caches. All we are saying is that, if the caches need to
separated
Proper cache separation parameters needs to be there and thus a
Standardized Solution needs to be there. In the PS-ID we have touched 
A little bit on the solution space. If you see, some extensions
Are required to achieve this cache separation.

> 3) I understand that most of the issues outlined by the draft 
> would require active participation and determinations by the 
> MN. Is that correct? I don't want to anticipate any 
> solutions. I am just trying to understand the relation to the 
> network-based paradigm of PMIP and how much host-based 
> problems are involved here.
> 
[Mohana] Still nothing changes as far as PMIPv6 is concerned. 
The mobility or the routing path for the prefix is setup using PMIPv6. 
We are only highlighting some involvement for MN to achieve some
Better services such as multihoming in PMIPv6 domain. If the MN does 
not want any, fine,
All these are extensions to the base PMIPv6 protocol... The core is
PMIPv6
and all these are extensions.

> Again, thank you for your effort,
{mohana] Thanks Niklas for reading. 
> best regards
>    Niklas
> 
> 
> Mohana Jeyatharan wrote:
> > Hello All,
> > 
> > We have drafted the problem stated ID, which highlights multihoming 
> > related issues in PMIPv6 and the need for further work. 
> Please have a 
> > look and we can start some discussion on scenarios and issues.
> > This ID has been already published and it is called:
> > 
> > draft-jeyatharan-netext-multihoming-ps-00
> > Thanks.
> > 
> > BR,
> > Mohana
> > 
> > _______________________________________________
> > NetExt mailing list
> > NetExt at mail.mobileip.jp
> > http://www.mobileip.jp/mailman/listinfo/netext
> 
> 
> 
> --
> Niklas Neumann - University of Goettingen, Institute of 
> Computer Science http://user.informatik.uni-goettingen.de/~nneuman1/
> Tel: +49 551 39-172053
> 

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Wed, 4 Feb 2009 08:47:19 +0800
Subject: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Yungui,
 
Please see reply in-line.
 
BR,
Mohana

________________________________

	From: Yungui Wang [mailto:w52006 at huawei.com] 
	Sent: Tuesday, February 03, 2009 11:44 AM
	To: Mohana Jeyatharan
	Cc: netext at mail.mobileip.jp
	Subject: Re: [Netext] FW:
I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt

	Hello Mohana,
	 
	Please see inline...
	 
	B.R.
	Yungui

		----- Original Message ----- 
		From: Mohana Jeyatharan
<mailto:Mohana.Jeyatharan at sg.panasonic.com>  
		To: Yungui Wang <mailto:w52006 at huawei.com>  
		Cc: netext at mail.mobileip.jp 
		Sent: Monday, February 02, 2009 6:11 PM
		Subject: RE: [Netext] FW:
I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt

		Hi Yungui,
		 
		Thanks for reading. Please see reply in-line.
		BR,
		Mohana

________________________________

			From: Yungui Wang [mailto:w52006 at huawei.com] 
			Sent: Monday, February 02, 2009 5:19 PM
			To: Mohana Jeyatharan
			Cc: netext at mail.mobileip.jp
			Subject: Re: [Netext] FW:
I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt

			Hello Mohana
			 
			Thanks for your hard works. There are my several
comments.
			 
			1, In section 2, issue related to simultaneous
usage of interfaces.
			Here are three sub-issues illustrated within
following three scenarios respectively. Regarding of the first
sub-issue, it can be educed that one IP address can't traverse multiple
interfaces of MN.  
			[Mohana] Yes, it can be considered that some IP
address cannot traverse the other interface or an IP connection that can
be characterised by some parameters cannot traverse another interface.
The first issue is that, MN wants certain flows associated with a prefix
to traverse via a certain interface. It is different from the issue,
Flow based routing given in the ID. Flow based routing issue is complete
swapping of prefixes, where all P1 flows sent via P2 interface and all
P2 flows sent via P1 interface.
			[Yungui] What's you mentioned flow based routing
in the PMIP6 domain? I don't see this solution until now. 
			[Mohana] Flow based routing is not a solution
and we have not described it as a solution in the PS-ID. It is just
mentioned such mechanism may need to be supported by PMIPv6 extensions.
The PMIPv6 protocol does not support it. At this point, I like to re
emphasize what we mean by flow based routing. It is routing all P1 flows
via p2 interface and all P2 flows via P1 interface. basiaclly, it is
swapping of the prefixes. This flow based routing overides the normal
prefix based routing of PMIPv6. That is all. Hope this helps.

			Regarding of the second and third sub-issue,
what's their difference? In my understanding, they both seems to say the
same issue that one Prefix can't traverse multiple interfaces of MN.
			[Mohana] I agree from operation or solution
point of view one prefix or multiple prefixes the same. Whether one
wants to give one prefix such simultaneous usage or multiple prefixes
such simulatneous usage is the difference. Since multiple prefixes are
obtained in PMIPv6 via multiple interfaces, such differences are
essentail to consider. because, in some cases, the network may not
support this and the Mn may need to prioritize the prefixes. 
			[Yungui] From the third scenario described in
the draft, in my understanding, load balancing feature may bring P1
flows moving from IF1 to IF2.  Do you mean it is necessary to prioritize
multiple prefixes (P1 and P2) via one interface (IF2) of MN? If so, I
don't think this priority issue is related to
multihoming/multiple-interface. However, I agree with the third scenario
although it is a certain similar as the second. 
			[Mohana]In the sub-section <issues related to
Simultaneous usage of interfaces> there are three issues highligted. Let
me highlight the principle of the issues. The first one is, flow based
routing associated with certain flows associated with a prefix. If a
flow does not match the filters, then the flows will be routed by using
the routing rules of PMIPv6. The second and third issues are
simultaneous usage for a single or multiple prefixes. The main motive
for such division is that to understand the levels of multihoming that
we can achieve in the base PMIPv6 protocol. What we mean by simulatneous
usage for a single or multiple prefixes is mainly like a simulatneous
usage of one or more. 
			 
			Now, what I said about prioritize the prefixes,
is sometimes the network may not provide such services for all the
prefixes(simulatneous usage). Then the Mn based on some decsion criteria
may need to prioritze. We did not explain this in the draft. Howveer,
such divisions are highlighted because there are many levels of
multihoming that can be achieved. 
			2, In section 2, issue related to Flow based
Routing
			Maybe you are proposing flow based solution?
This scenario may have been contained in the first issue and it
scenarios (like the first sub-issue).
			[Mohana] As I explained, it is quite different.
Here (flow based routing) all the flows associated with a prefix may
need to be transferred via another interface. It is how you define the
filters. In the first case (certain flows of a prefix sent via another
interface), filters are defined for flows where as for the Flow based
routing case, flows defined for prefixes.
			[Yungui] Please see the 1st comments. 
			 
			 3, In section 2, issue related to Flow Mobility
during Sudden Disconnection
			It may be a general reliability issue associated
with Multiple Interface capable node, not related to flow mobility. 
			[Mohana]It is in a way flow mobility. If there
is disconnection and if appropriate vertical handoff triggers are not
sent, then flows associated with a prefix is lost. It is beneficial to
get these flows via a connected interface during the diconnection
period. So, it is flow mobility but happening in a disconnection
scenario. 
			[Yungui] When one link is disconnected,
something over it may be is an application, a IP seesion, a flow, or
nothing. I wonder if it is specially for flow mobility. Maybe this
scenario can be outlined as 'Issues Related to Sudden Disconnection'. 
			[Mohana] Ok.... Will reconsider about the
wording. I understand your concern. Flow mobility is transfering of a
flow .When all the flows are transferred due to disconnection, then
perhaps we may need to re-consider a better term. Thanks..
			 
			4, In section 3 Multihoming Issues in
PMIPv6/CMIPv6 mixed Scenario
			These issues may depend on the basis issues
described in PMIPv6/CMIPv6 interaction
[draft-giaretta-netlmm-mip-interactions-02.txt]. I am not sure whether
these issues exsit. For example, if two spearate BCEs are created with
different indexes (e.g. HoA for MIP, HNP/MN-ID for PMIP, etc.) in LMA/HA
for PMIPv6/CMIPv6 domain respectively, it may be not necessary to do
that synchronization. 
			[Mohana] The PMIPv6/CMIPv6 interaction draft
[draft-giaretta-netlmm-mip-interactions-02.txt] was specifically
designed for a single interface case. There it is considered that the
MIPv6 binidng takes precedence over the PMIPv6 binding, so I am not sure
why you are comparing this to PMIP/CMIP draft. Even if we follow the
logic used in that draft, according to that draft only one of the
bindings are valid at any point in time. Thus there is no mechanism that
describes simulatneous reachability using PMIPv6 and CMIPv6 bindings.
Thus we need to look at this as a special problem that is related to
Multiplke Interfaces and look at how to solve the issue. 
			[Yungui] Get it. Maybe it is necessary to be
done next step. 
			[Mohana] Ok.
			 
			5, In addition, there is a typo error in the
Figure 2. In the text description, CMIP6 is used via the MN.IF1. Thus,
here is AR1, not MAG1(AGW) in the Figure 2. 
			[Mohana] well, we considered a 3GPP specific
scenario. I agree in CMIPv6 case there is no MAG but it is explained in
the text that a prefix for care-of address is obtained from AGW which
happens to be a MAG. Anyway please highlight whether we have made a
mistake here (please point to the correct text). thanks. 
			[Yungui] Here I was just confused that the
entity MAG1 located in the CMIP6 domain. Do you mean an AR (within AGW)
can't allocate a prefix for configuring a CoA? 
			[Mohana] i agree, that IF1's mobility is managed
by CMIPv6. However, the architecture can support PMIPv6 as well. That is
why the AGW/MAG1 term is used in figure 2. In CMIPv6 mode, The AGW does
not function as a MAG to the MN. It only provides a prefix and acts as a
normal AR.

			B.R.
			Yungui

				----- Original Message ----- 
				From: Mohana Jeyatharan
<mailto:Mohana.Jeyatharan at sg.panasonic.com>  
				To: netext at mail.mobileip.jp 
				Sent: Friday, January 23, 2009 12:20 PM
				Subject: [Netext] FW: I-D
Action:draft-jeyatharan-netext-multihoming-ps-00.txt

				Hello All,
				
				We have drafted the problem stated ID,
which highlights multihoming
				related issues in PMIPv6 and the need
for further work. Please have a
				look and we can start some discussion on
scenarios and issues.
				Thanks.
				
				BR,
				Mohana
				-----Original Message-----
				From: i-d-announce-bounces at ietf.org
				[mailto:i-d-announce-bounces at ietf.org]
On Behalf Of
				Internet-Drafts at ietf.org
				Sent: Friday, January 23, 2009 12:15 PM
				To: i-d-announce at ietf.org
				Subject: I-D
Action:draft-jeyatharan-netext-multihoming-ps-00.txt 
				
				A New Internet-Draft is available from
the on-line Internet-Drafts
				directories.
				
				Title           : Multihoming Problem
Statement in NetLMM
				Author(s)       : M. Jeyatharan, C. Ng
				Filename        :
draft-jeyatharan-netext-multihoming-ps-00.txt
				Pages           : 12
				Date            : 2009-01-22
				
				The base PMIPv6 protocol does not have
adequate mechanisms to support
				advanced multihoming such as
simultaneous usage of all interfaces of a
				mobile node (MN) to receive and transmit
data packets associated with a
				given prefix allocated to MN, and allow
flow based routing according to
				preference, rules, and policies set by
the MN or network entity.  This
				memo highlights such advanced
multihoming related issues when mobility
				of the multiple interfaced mobile node
(MuIF MN) is purely managed by
				PMIPv6 mechanism.  It also highlights
the issue of lack of simultaneous
				attachment support when the mobility of
the MuIF MN is managed by PMIPv6
				and CMIPv6 mechanisms.
				
				A URL for this Internet-Draft is:
	
http://www.ietf.org/internet-drafts/draft-jeyatharan-netext-multihoming-
				ps-00.txt
				
				Internet-Drafts are also available by
anonymous FTP at:
				ftp://ftp.ietf.org/internet-drafts/
				
				Below is the data which will enable a
MIME compliant mail reader
				implementation to automatically retrieve
the ASCII version of the
				Internet-Draft.

				
________________________________

				

_______________________________________________
				NetExt mailing list
				NetExt at mail.mobileip.jp
	
http://www.mobileip.jp/mailman/listinfo/netext

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090204/653113db/attachment-0001.html>

From: niklas.neumann at cs.uni-goettingen.de (Niklas Neumann)
Date: Tue, 03 Feb 2009 12:35:04 +0100
Subject: [Netext] PMIPv6 Multihoming problem statemnt draft Notification
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

Hey Mohana,

thank you for submitting the draft. I have a couple of questions:

1) Can you please help me to understand what the PMIP relation of those 
issues is? To me everything you outlined in Section 2 sounds like the 
general problems associated with multi-path routing. As a matter of fact 
as far as I understand, if all those problems were solved as proposed in 
the draft we wouldn't need PMIP anymore because a MN would have the 
means to delegate any flow to any available interface no matter of the 
prefix. I am not saying all those points in the draft are not valid 
issues, I just need some help to understand the relationship to PMIP.

2) Regarding Section 3, if the home domain offers two mobility solutions 
(PMIP and CMIP), isn't it a deployment error to mix the BCs of the two 
solutions? I am not clear how a PMIP PBU can otherwise invalidate a CMIP 
BCE.

3) I understand that most of the issues outlined by the draft would 
require active participation and determinations by the MN. Is that 
correct? I don't want to anticipate any solutions. I am just trying to 
understand the relation to the network-based paradigm of PMIP and how 
much host-based problems are involved here.

Again, thank you for your effort,
best regards
   Niklas

Mohana Jeyatharan wrote:
> Hello All,
> 
> We have drafted the problem stated ID, which highlights multihoming
> related issues in PMIPv6 and the need for further work. Please have a
> look and we can start some discussion on scenarios and issues.
> This ID has been already published and it is called:
> 
> draft-jeyatharan-netext-multihoming-ps-00 
> Thanks.
> 
> BR,
> Mohana
> 
> _______________________________________________
> NetExt mailing list
> NetExt at mail.mobileip.jp
> http://www.mobileip.jp/mailman/listinfo/netext

-- 
Niklas Neumann - University of Goettingen, Institute of Computer Science
http://user.informatik.uni-goettingen.de/~nneuman1/
Tel: +49 551 39-172053

From: w52006 at huawei.com (Yungui Wang)
Date: Tue, 03 Feb 2009 11:44:21 +0800
Subject: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt
References: <[email-masked]> <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hello Mohana,

Please see inline...

B.R.
Yungui
  ----- Original Message ----- 
  From: Mohana Jeyatharan 
  To: Yungui Wang 
  Cc: netext at mail.mobileip.jp 
  Sent: Monday, February 02, 2009 6:11 PM
  Subject: RE: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt

  Hi Yungui,

  Thanks for reading. Please see reply in-line.
  BR,
  Mohana

----------------------------------------------------------------------------
    From: Yungui Wang [mailto:w52006 at huawei.com] 
    Sent: Monday, February 02, 2009 5:19 PM
    To: Mohana Jeyatharan
    Cc: netext at mail.mobileip.jp
    Subject: Re: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt

    Hello Mohana

    Thanks for your hard works. There are my several comments.

    1, In section 2, issue related to simultaneous usage of interfaces.
    Here are three sub-issues illustrated within following three scenarios respectively. Regarding of the first sub-issue, it can be educed that one IP address can't traverse multiple interfaces of MN.  
    [Mohana] Yes, it can be considered that some IP address cannot traverse the other interface or an IP connection that can be characterised by some parameters cannot traverse another interface. The first issue is that, MN wants certain flows associated with a prefix to traverse via a certain interface. It is different from the issue, Flow based routing given in the ID. Flow based routing issue is complete swapping of prefixes, where all P1 flows sent via P2 interface and all P2 flows sent via P1 interface.
    [Yungui] What's you mentioned flow based routing in the PMIP6 domain? I don't see this solution until now. 

    Regarding of the second and third sub-issue, what's their difference? In my understanding, they both seems to say the same issue that one Prefix can't traverse multiple interfaces of MN.
    [Mohana] I agree from operation or solution point of view one prefix or multiple prefixes the same. Whether one wants to give one prefix such simultaneous usage or multiple prefixes such simulatneous usage is the difference. Since multiple prefixes are obtained in PMIPv6 via multiple interfaces, such differences are essentail to consider. because, in some cases, the network may not support this and the Mn may need to prioritize the prefixes. 
    [Yungui] From the third scenario described in the draft, in my understanding, load balancing feature may bring P1 flows moving from IF1 to IF2.  Do you mean it is necessary to prioritize multiple prefixes (P1 and P2) via one interface (IF2) of MN? If so, I don't think this priority issue is related to multihoming/multiple-interface. However, I agree with the third scenario although it is a certain similar as the second. 

    2, In section 2, issue related to Flow based Routing
    Maybe you are proposing flow based solution? This scenario may have been contained in the first issue and it scenarios (like the first sub-issue).
    [Mohana] As I explained, it is quite different. Here (flow based routing) all the flows associated with a prefix may need to be transferred via another interface. It is how you define the filters. In the first case (certain flows of a prefix sent via another interface), filters are defined for flows where as for the Flow based routing case, flows defined for prefixes.
    [Yungui] Please see the 1st comments. 

     3, In section 2, issue related to Flow Mobility during Sudden Disconnection
    It may be a general reliability issue associated with Multiple Interface capable node, not related to flow mobility. 
    [Mohana]It is in a way flow mobility. If there is disconnection and if appropriate vertical handoff triggers are not sent, then flows associated with a prefix is lost. It is beneficial to get these flows via a connected interface during the diconnection period. So, it is flow mobility but happening in a disconnection scenario. 
    [Yungui] When one link is disconnected, something over it may be is an application, a IP seesion, a flow, or nothing. I wonder if it is specially for flow mobility. Maybe this scenario can be outlined as 'Issues Related to Sudden Disconnection'.

    4, In section 3 Multihoming Issues in PMIPv6/CMIPv6 mixed Scenario
    These issues may depend on the basis issues described in PMIPv6/CMIPv6 interaction [draft-giaretta-netlmm-mip-interactions-02.txt]. I am not sure whether these issues exsit. For example, if two spearate BCEs are created with different indexes (e.g. HoA for MIP, HNP/MN-ID for PMIP, etc.) in LMA/HA for PMIPv6/CMIPv6 domain respectively, it may be not necessary to do that synchronization. 
    [Mohana] The PMIPv6/CMIPv6 interaction draft [draft-giaretta-netlmm-mip-interactions-02.txt] was specifically designed for a single interface case. There it is considered that the MIPv6 binidng takes precedence over the PMIPv6 binding, so I am not sure why you are comparing this to PMIP/CMIP draft. Even if we follow the logic used in that draft, according to that draft only one of the bindings are valid at any point in time. Thus there is no mechanism that describes simulatneous reachability using PMIPv6 and CMIPv6 bindings. Thus we need to look at this as a special problem that is related to Multiplke Interfaces and look at how to solve the issue. 
    [Yungui] Get it. Maybe it is necessary to be done next step.

    5, In addition, there is a typo error in the Figure 2. In the text description, CMIP6 is used via the MN.IF1. Thus, here is AR1, not MAG1(AGW) in the Figure 2. 
    [Mohana] well, we considered a 3GPP specific scenario. I agree in CMIPv6 case there is no MAG but it is explained in the text that a prefix for care-of address is obtained from AGW which happens to be a MAG. Anyway please highlight whether we have made a mistake here (please point to the correct text). thanks. 
    [Yungui] Here I was just confused that the entity MAG1 located in the CMIP6 domain. Do you mean an AR (within AGW) can't allocate a prefix for configuring a CoA?

    B.R.
    Yungui

      ----- Original Message ----- 
      From: Mohana Jeyatharan 
      To: netext at mail.mobileip.jp 
      Sent: Friday, January 23, 2009 12:20 PM
      Subject: [Netext] FW: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.txt

      Hello All,

      We have drafted the problem stated ID, which highlights multihoming
      related issues in PMIPv6 and the need for further work. Please have a
      look and we can start some discussion on scenarios and issues.
      Thanks.

      BR,
      Mohana
      -----Original Message-----
      From: i-d-announce-bounces at ietf.org
      [mailto:i-d-announce-bounces at ietf.org] On Behalf Of
      Internet-Drafts at ietf.org
      Sent: Friday, January 23, 2009 12:15 PM
      To: i-d-announce at ietf.org
      Subject: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.txt 

      A New Internet-Draft is available from the on-line Internet-Drafts
      directories.

      Title           : Multihoming Problem Statement in NetLMM
      Author(s)       : M. Jeyatharan, C. Ng
      Filename        : draft-jeyatharan-netext-multihoming-ps-00.txt
      Pages           : 12
      Date            : 2009-01-22

      The base PMIPv6 protocol does not have adequate mechanisms to support
      advanced multihoming such as simultaneous usage of all interfaces of a
      mobile node (MN) to receive and transmit data packets associated with a
      given prefix allocated to MN, and allow flow based routing according to
      preference, rules, and policies set by the MN or network entity.  This
      memo highlights such advanced multihoming related issues when mobility
      of the multiple interfaced mobile node (MuIF MN) is purely managed by
      PMIPv6 mechanism.  It also highlights the issue of lack of simultaneous
      attachment support when the mobility of the MuIF MN is managed by PMIPv6
      and CMIPv6 mechanisms.

      A URL for this Internet-Draft is:
      http://www.ietf.org/internet-drafts/draft-jeyatharan-netext-multihoming-
      ps-00.txt

      Internet-Drafts are also available by anonymous FTP at:
      ftp://ftp.ietf.org/internet-drafts/

      Below is the data which will enable a MIME compliant mail reader
      implementation to automatically retrieve the ASCII version of the
      Internet-Draft.

--------------------------------------------------------------------------

      _______________________________________________
      NetExt mailing list
      NetExt at mail.mobileip.jp
      http://www.mobileip.jp/mailman/listinfo/netext
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090203/2f16f8c6/attachment.html>

From: Mohana.Jeyatharan at sg.panasonic.com (Mohana Jeyatharan)
Date: Mon, 2 Feb 2009 18:11:32 +0800
Subject: [Netext] FW: I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt
In-Reply-To: <[email-masked]>
References: <[email-masked]> <[email-masked]>
Message-ID: <[email-masked]>

Hi Yungui,
 
Thanks for reading. Please see reply in-line.
BR,
Mohana

________________________________

	From: Yungui Wang [mailto:w52006 at huawei.com] 
	Sent: Monday, February 02, 2009 5:19 PM
	To: Mohana Jeyatharan
	Cc: netext at mail.mobileip.jp
	Subject: Re: [Netext] FW:
I-DAction:draft-jeyatharan-netext-multihoming-ps-00.txt

	Hello Mohana
	 
	Thanks for your hard works. There are my several comments.
	 
	1, In section 2, issue related to simultaneous usage of
interfaces.
	Here are three sub-issues illustrated within following three
scenarios respectively. Regarding of the first sub-issue, it can be
educed that one IP address can't traverse multiple interfaces of MN.  
	[Mohana] Yes, it can be considered that some IP address cannot
traverse the other interface or an IP connection that can be
characterised by some parameters cannot traverse another interface. The
first issue is that, MN wants certain flows associated with a prefix to
traverse via a certain interface. It is different from the issue, Flow
based routing given in the ID. Flow based routing issue is complete
swapping of prefixes, where all P1 flows sent via P2 interface and all
P2 flows sent via P1 interface.
	 Regarding of the second and third sub-issue, what's their
difference? In my understanding, they both seems to say the same issue
that one Prefix can't traverse multiple interfaces of MN.
	[Mohana] I agree from operation or solution point of view one
prefix or multiple prefixes the same. Whether one wants to give one
prefix such simultaneous usage or multiple prefixes such simulatneous
usage is the difference. Since multiple prefixes are obtained in PMIPv6
via multiple interfaces, such differences are essentail to consider.
because, in some cases, the network may not support this and the Mn may
need to prioritize the prefixes. 
	 
	2, In section 2, issue related to Flow based Routing
	Maybe you are proposing flow based solution? This scenario may
have been contained in the first issue and it scenarios (like the first
sub-issue).
	[Mohana] As I explained, it is quite different. Here (flow based
routing) all the flows associated with a prefix may need to be
transferred via another interface. It is how you define the filters. In
the first case (certain flows of a prefix sent via another interface),
filters are defined for flows where as for the Flow based routing case,
flows defined for prefixes.
	 
	 3, In section 2, issue related to Flow Mobility during Sudden
Disconnection
	It may be a general reliability issue associated with Multiple
Interface capable node, not related to flow mobility. 
	[Mohana]It is in a way flow mobility. If there is disconnection
and if appropriate vertical handoff triggers are not sent, then flows
associated with a prefix is lost. It is beneficial to get these flows
via a connected interface during the diconnection period. So, it is flow
mobility but happening in a disconnection scenario. 
	 
	4, In section 3 Multihoming Issues in PMIPv6/CMIPv6 mixed
Scenario
	These issues may depend on the basis issues described in
PMIPv6/CMIPv6 interaction
[draft-giaretta-netlmm-mip-interactions-02.txt]. I am not sure whether
these issues exsit. For example, if two spearate BCEs are created with
different indexes (e.g. HoA for MIP, HNP/MN-ID for PMIP, etc.) in LMA/HA
for PMIPv6/CMIPv6 domain respectively, it may be not necessary to do
that synchronization. 
	[Mohana] The PMIPv6/CMIPv6 interaction draft
[draft-giaretta-netlmm-mip-interactions-02.txt] was specifically
designed for a single interface case. There it is considered that the
MIPv6 binidng takes precedence over the PMIPv6 binding, so I am not sure
why you are comparing this to PMIP/CMIP draft. Even if we follow the
logic used in that draft, according to that draft only one of the
bindings are valid at any point in time. Thus there is no mechanism that
describes simulatneous reachability using PMIPv6 and CMIPv6 bindings.
Thus we need to look at this as a special problem that is related to
Multiplke Interfaces and look at how to solve the issue. 
	 
	5, In addition, there is a typo error in the Figure 2. In the
text description, CMIP6 is used via the MN.IF1. Thus, here is AR1, not
MAG1(AGW) in the Figure 2. 
	[Mohana] well, we considered a 3GPP specific scenario. I agree
in CMIPv6 case there is no MAG but it is explained in the text that a
prefix for care-of address is obtained from AGW which happens to be a
MAG. Anyway please highlight whether we have made a mistake here (please
point to the correct text). thanks. 

	B.R.
	Yungui

		----- Original Message ----- 
		From: Mohana Jeyatharan
<mailto:Mohana.Jeyatharan at sg.panasonic.com>  
		To: netext at mail.mobileip.jp 
		Sent: Friday, January 23, 2009 12:20 PM
		Subject: [Netext] FW: I-D
Action:draft-jeyatharan-netext-multihoming-ps-00.txt

		Hello All,
		
		We have drafted the problem stated ID, which highlights
multihoming
		related issues in PMIPv6 and the need for further work.
Please have a
		look and we can start some discussion on scenarios and
issues.
		Thanks.
		
		BR,
		Mohana
		-----Original Message-----
		From: i-d-announce-bounces at ietf.org
		[mailto:i-d-announce-bounces at ietf.org] On Behalf Of
		Internet-Drafts at ietf.org
		Sent: Friday, January 23, 2009 12:15 PM
		To: i-d-announce at ietf.org
		Subject: I-D
Action:draft-jeyatharan-netext-multihoming-ps-00.txt 
		
		A New Internet-Draft is available from the on-line
Internet-Drafts
		directories.
		
		Title           : Multihoming Problem Statement in
NetLMM
		Author(s)       : M. Jeyatharan, C. Ng
		Filename        :
draft-jeyatharan-netext-multihoming-ps-00.txt
		Pages           : 12
		Date            : 2009-01-22
		
		The base PMIPv6 protocol does not have adequate
mechanisms to support
		advanced multihoming such as simultaneous usage of all
interfaces of a
		mobile node (MN) to receive and transmit data packets
associated with a
		given prefix allocated to MN, and allow flow based
routing according to
		preference, rules, and policies set by the MN or network
entity.  This
		memo highlights such advanced multihoming related issues
when mobility
		of the multiple interfaced mobile node (MuIF MN) is
purely managed by
		PMIPv6 mechanism.  It also highlights the issue of lack
of simultaneous
		attachment support when the mobility of the MuIF MN is
managed by PMIPv6
		and CMIPv6 mechanisms.
		
		A URL for this Internet-Draft is:
	
http://www.ietf.org/internet-drafts/draft-jeyatharan-netext-multihoming-
		ps-00.txt
		
		Internet-Drafts are also available by anonymous FTP at:
		ftp://ftp.ietf.org/internet-drafts/
		
		Below is the data which will enable a MIME compliant
mail reader
		implementation to automatically retrieve the ASCII
version of the
		Internet-Draft.

		
________________________________

		

		_______________________________________________
		NetExt mailing list
		NetExt at mail.mobileip.jp
		http://www.mobileip.jp/mailman/listinfo/netext

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090202/fbc3b3f0/attachment-0001.html>

From: w52006 at huawei.com (Yungui Wang)
Date: Mon, 02 Feb 2009 17:18:34 +0800
Subject: [Netext] FW: I-D	Action:draft-jeyatharan-netext-multihoming-ps-00.txt
References: <[email-masked]>
Message-ID: <[email-masked]>

Hello Mohana

Thanks for your hard works. There are my several comments.

1, In section 2, issue related to simultaneous usage of interfaces.
Here are three sub-issues illustrated within following three scenarios respectively. Regarding of the first sub-issue, it can be educed that one IP address can't traverse multiple interfaces of MN. Regarding of the second and third sub-issue, what's their difference? In my understanding, they both seems to say the same issue that one Prefix can't traverse multiple interfaces of MN.

2, In section 2, issue related to Flow based Routing
Maybe you are proposing flow based solution? This scenario may have been contained in the first issue and it scenarios (like the first sub-issue).

3, In section 2, issue related to Flow Mobility during Sudden Disconnection
It may be a general reliability issue associated with Multiple Interface capable node, not related to flow mobility.

4, In section 3 Multihoming Issues in PMIPv6/CMIPv6 mixed Scenario
These issues may depend on the basis issues described in PMIPv6/CMIPv6 interaction [draft-giaretta-netlmm-mip-interactions-02.txt]. I am not sure whether these issues exsit. For example, if two spearate BCEs are created with different indexes (e.g. HoA for MIP, HNP/MN-ID for PMIP, etc.) in LMA/HA for PMIPv6/CMIPv6 domain respectively, it may be not necessary to do that synchronization.

5, In addition, there is a typo error in the Figure 2. In the text description, CMIP6 is used via the MN.IF1. Thus, here is AR1, not MAG1(AGW) in the Figure 2.

B.R.
Yungui

  ----- Original Message ----- 
  From: Mohana Jeyatharan 
  To: netext at mail.mobileip.jp 
  Sent: Friday, January 23, 2009 12:20 PM
  Subject: [Netext] FW: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.txt

  Hello All,

  We have drafted the problem stated ID, which highlights multihoming
  related issues in PMIPv6 and the need for further work. Please have a
  look and we can start some discussion on scenarios and issues.
  Thanks.

  BR,
  Mohana
  -----Original Message-----
  From: i-d-announce-bounces at ietf.org
  [mailto:i-d-announce-bounces at ietf.org] On Behalf Of
  Internet-Drafts at ietf.org
  Sent: Friday, January 23, 2009 12:15 PM
  To: i-d-announce at ietf.org
  Subject: I-D Action:draft-jeyatharan-netext-multihoming-ps-00.txt 

  A New Internet-Draft is available from the on-line Internet-Drafts
  directories.

  Title           : Multihoming Problem Statement in NetLMM
  Author(s)       : M. Jeyatharan, C. Ng
  Filename        : draft-jeyatharan-netext-multihoming-ps-00.txt
  Pages           : 12
  Date            : 2009-01-22

  The base PMIPv6 protocol does not have adequate mechanisms to support
  advanced multihoming such as simultaneous usage of all interfaces of a
  mobile node (MN) to receive and transmit data packets associated with a
  given prefix allocated to MN, and allow flow based routing according to
  preference, rules, and policies set by the MN or network entity.  This
  memo highlights such advanced multihoming related issues when mobility
  of the multiple interfaced mobile node (MuIF MN) is purely managed by
  PMIPv6 mechanism.  It also highlights the issue of lack of simultaneous
  attachment support when the mobility of the MuIF MN is managed by PMIPv6
  and CMIPv6 mechanisms.

  A URL for this Internet-Draft is:
  http://www.ietf.org/internet-drafts/draft-jeyatharan-netext-multihoming-
  ps-00.txt

  Internet-Drafts are also available by anonymous FTP at:
  ftp://ftp.ietf.org/internet-drafts/

  Below is the data which will enable a MIME compliant mail reader
  implementation to automatically retrieve the ASCII version of the
  Internet-Draft.

------------------------------------------------------------------------------

  _______________________________________________
  NetExt mailing list
  NetExt at mail.mobileip.jp
  http://www.mobileip.jp/mailman/listinfo/netext
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mobileip.jp/pipermail/netext/attachments/20090202/9b7592b2/attachment.html>