Re: [netlmm] PMIP6-MIP6 Interactions - Take 2

["Giaretta, Gerardo" <[e-mail]>]

Hi Kilian,

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Kilian Weniger
> Sent: Thursday, October 30, 2008 8:46 AM
> To: Suresh Krishnan; Christian Vogt
> Cc: Mohana Jeyatharan; NETLMM Mailing List
> Subject: Re: [netlmm] PMIP6-MIP6 Interactions - Take 2
> 
> Hi Suresh,
> 
> generally, scenarios where the MN has multiple interfaces up
> simultaneously and wants to move the traffic to a specific interface
> without newly attaching with this interface are out of scope of this
> discussion IMHO. Such scenarios are also not (yet) supported by PMIP, so
> why should we support them now in PMIP/MIP interaction scenarios?
>

I think this is exactly the point why people don't agree in my view. 

This cannot be out of scope of the discussion. This scenario is possible when MIP is used if the home link is not a PMIP domain. It must be possible in the same way also in case the home link is a PMIP domain as the intent of that is to hide some movements to the IP stack of the MN. The fact that the home link is a PMIP domain must not put any limitations of scenarios which can be enabled by MIP. 

I think this is the main point and the solution you propose does not satisfy that requirement. 

Gerardo
 
> With PMIP multihoming and flow filtering, I guess we will support such
> scenarios for PMIP. Then, they are automatically supported for MIP/PMIP
> interaction (if we keep MIP interactions in mind during design), no
> matter whether we choose approach "a) always use the MIP6 BCE and only
> use the PMIP6 BCE when there is no MIP6 BCE" vs. "b) forward using the
> most recently updated BCE."
> 
> Cheers,
> 
> Kilian
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Suresh Krishnan
> > Sent: Donnerstag, 30. Oktober 2008 15:00
> > To: Christian Vogt
> > Cc: NETLMM Mailing List; Mohana Jeyatharan
> > Subject: Re: [netlmm] PMIP6-MIP6 Interactions - Take 2
> >
> > Hi Christian,
> >    I agree and this is described in section 5.3 of the draft
> > George and
> > I wrote
> >
> > http://tools.ietf.org/html/draft-tsirtsis-logically-separate-lmaha-00
> >
> > Cheers
> > Suresh
> >
> > Christian Vogt wrote:
> > > On Oct 30, 2008, Mohana Jeyatharan wrote:
> > >
> > >> I agree with Rajeev. For multihoming case we need both
> > BCEs(PMIP and
> > >> MIP) to be present at LMA/HA and moreover both should be valid.
> > >
> > >
> > > Mohana and Rajeev,
> > >
> > > a general comment:  The simultaneous use of two mobility protocols
> > > without coordination is bound to be problematic if you
> > don't define a
> > > clear precedence of one mobility protocol over the other.
> > >
> > > This directly applies to the specific case of MIP/P-MIP
> > co-existence:
> > > Both mobility protocols run simultaneously, yet there is no
> > coordination
> > > between the entities who initiate mobility signaling, i.e.,
> > mobile hosts
> > > and MAGs.
> > >
> > > You don't need two BCEs to see why lack of precedences for
> > the mobility
> > > protocols could be a problem for multi-homing:  As a simple example,
> > > consider a host with 3G and WLAN interfaces, of which only the 3G
> > > interface has a home address with mobility support.  The
> > host may create
> > > a MIP binding to redirect traffic for its home address from
> > 3G to WLAN.
> > > In that case, the host certainly wouldn't want the network to remove
> > > that binding due to subsequent movements of the 3G interface.
> > >
> > > Overall, I would recommend that, if two protocols for the
> > same purpose
> > > (such as mobility) operate simultaneously, it should be clear which
> > > protocol takes precedence over the other.  In the specific case of
> > > MIP/P-MIP co-existence, that could mean that P-MIP pauses
> > as long as a
> > > MIP binding is active.  Without such precedences, the two
> > protocols will
> > > end up fighting each other (namely, over BCEs), and you
> > will likely end
> > > up with undesired side effects.
> > >
> > > - Christian
> > >
> > >
> > > _______________________________________________
> > > netlmm mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netlmm
> >
> > _______________________________________________
> > netlmm mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netlmm
> >
> >
> 
> 
> Panasonic R&D Center Germany GmbH
> 63225 Langen, Hessen, Germany
> Reg: AG Offenbach (Hessen) HRB 33974
> Managing Director: Thomas Micke
> 
> 
> _______________________________________________
> netlmm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netlmm
_______________________________________________
netlmm mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netlmm