Re: [netext] Update on flow mobility following discussion with ADs

[Sri Gundavelli <[e-mail]>]

Raj:

Thanks for the meeting minutes.

Can you comment on the AD inputs w.r.t bundling every flow mobility feature
in a single spec, vs multiple document deliverables. Specifically, the scope
of the current work and if it must be in a single document.


Thanks
Sri


On 3/2/11 9:04 AM, "[e-mail]" <[e-mail]>
wrote:

>  
> Just wanted to provide an update regarding the ongoing work on flow
> mobility for PMIP6 and my discussion with our ADs (Jari and Ralph) on
> March 1st:
>  
> I have apprised our ADs about the state of the ongoing discussion on
> flow mobility. One of the concerns about the ongoing work on flow
> mobility was related to the logical interface feature. Flow mobility
> depends on the existence of a logical interface on the host. The WG
> has not addressed the concerns related to the logical interface I-D,
> that were raised at the previous WG meetings. Emphasised that we
> should get the logical interface spec done soon since it is a
> fundamental dependency for flow mobility.
>  
> Regarding the current scope of the flow mobility work and the I-D
> which is now in consensus call, there are a few issues that need to be
> resolved. A few points below:
>  
> 1. Flow mobility in the context of Proxy MIP6 is not analogous to the
>    solution that has been developed for host based MIP6. The
>    featureset and capabilities developed in Netext does not have to
>    mirror, parallel or be equivalent to that of RFCs 6088/9.
>  
> 2. There is no plan or expectation that there would be a way for the
>    MN/host to do signaling related to flow mobility with a MAG at
>    layer 3. Layer 2 is an option but obviously this requires such
>    enhancements to be done in other SDOs. The preference is to develop
>    a flow mobility solution that works with policies and signaling
>    that is network centric (i.e MAG/LMA entities).
>  
> 3. One of the major concerns raised on the mailing list is related to
>    how flow mobility would work when an MN attaches to a wifi access
>    and the LMA switches a flow(s) to the MAG serving the MN via that
>    wifi. The MN has no way of indicating to the LMA if the wifi access
>    is congested or for the MAG to indicate to the LMA about the state
>    of the MNs attachment to the AP. Packets forwarded by the LMA to
>    the MN via the wifi-MAG could be sent into a void.
>    Without a solution for the above scenario, flow mobility would not
>    be robust. Some clear answers are needed here.
>  
>    One option is that flow mobility for PMIP6 is applicable only in
>    those access networks wherein the access network elements are aware
>    of the state of the MNs connection and congestion state. The MAG
>    can use this information to signal to an LMA attachment state and
>    potentially cause flows to be switched to an alternative MAG. It
>    may be okay to have specific statements about the limitations of
>    flow mobility for PMIP6 documented as a sort of disclaimer.
>    
>    Other options?
>  
> 4. The WG is free to extend the PMIP6 signaling between MAG/LMA to
>    accomplish flow mobility.
>  
> 5. And lastly the question about who is the customer for this work at
>    this time is irrelevant. We have had this discussion during the
>    chartering phase and there is no reason to revisit it.
>  
> If I have missed any other significant (show-stopper) concern
> regarding the flow mobility feature, please do raise them.
>  
> -Raj
> 
> 
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext