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

Julien,

Capability discovery can be achieved by layer-2, 3 or even 7. The
current charter restriction is specifically about no MN-ntwk PMIP
signalling, and layer-2 signalling is outside the scope.

Hence, I think it is fair to design a PMIP flow mobility solution with
the following assumptions:

1) MN capabilities are known,
2) possible existence of layer-2 signalling to provide hints (HI=Flow
Mobility),
3) and possible non-existence of layer-2 signalling to provide hints
(HI=Unknown)

Cheers,

Juan Carlos

> -----Original Message-----
> From: netext-bounces@ietf.org [mailto:netext-bounces@ietf.org] On
> Behalf Of Julien Laganier
> Sent: March 4, 2011 2:30 PM
> To: Rajeev Koodli
> Cc: netext@ietf.org; Basavaraj.Patil@nokia.com
> Subject: Re: [netext] Update on flow mobility following discussion
with
> ADs
> 
> Hi Rajeev,
> 
> I've been under the impression that correctness is only achievable to
> the extent that the network offers flow-mobility / inter-access
> handoffs only to the MN that indicates their support for the feature
> (e.g., via the logical interface construct, or any other.) If that
> holds, since the MN can' t indicate this at layer 3, this has to be
> done at layer 2, thus you need this extended L2 signaling in all
> cases.
> 
> Am I missing something?
> 
> --julien
> 
> On Thu, Mar 3, 2011 at 9:40 PM, Rajeev Koodli <rkoodli@cisco.com>
> wrote:
> >
> > Hi Julien,
> >
> > I don't believe I suggested sacrificing correctness and robustness;
> in fact,
> > I suggested robustness of protocol operation to cover all cases.
> >
> > More to the point, I think relying _only_ on extended L2 signaling
is
> one of
> > the cases the protocol needs to cover. We need to include the case
> when
> > either new L2 signaling is unavailable or is not considered
reliable.
> >
> > I am proposing an inclusive approach for providing flow mobility
when
> the
> > desired aspects of L2 signaling are available (HI=Flow Mobility)
> _and_
> > consider the case when we they are not available (HI=Unknown). I
> should be
> > able to move flows across interfaces regardless of whether the LMA
> maintains
> > a single session or multiple sessions (all created according to the
> baseline
> > PMIP6 model).
> >
> > Making use of 3GPP as a customer is great, but I do not want to be
> limited
> > only to it.
> >
> > Thanks,
> >
> > -Rajeev
> >
> >
> >
> > On 3/3/11 11:44 AM, "Julien Laganier" <julien.ietf@gmail.com> wrote:
> >
> >> Hi Rajeev,
> >>
> >> On Wed, Mar 2, 2011 at 12:39 PM, Rajeev Koodli <rkoodli@cisco.com>
> wrote:
> >>>
> >>>
> >>> On 3/2/11 11:49 AM, "Jari Arkko" <jari.arkko@piuha.net> wrote:
> >>>
> >>>> Sri:
> >>>>
> >>>> What Basavaraj said. I don't think the number of specifications
is
> a big
> >>>> concern either now or later. Split the documents the way you
like.
> Lets
> >>>> discuss functionality, robustness, assumptions instead -- those
> are
> >>>> important.
> >>>
> >>>
> >>> I agree that the spec should be robust, and should work under
> conditions
> >>> assuming existing & new L2 signaling, as well as under conditions
> when new
> >>> L2 signaling is unavailable.
> >>
> >> I have expressed doubts about the feasibility of a robust flow
> >> mobility / inter-access handover solution that relies on existing,
> >> unmodified L2 signaling (this is discussed in a different thread.)
> We
> >> should not sacrifice correctness and robustness for the sake of
> >> working around unmodified L2 signaling. As I've said earlier, one
of
> >> the potential customer for this (3GPP) owns two L2 that are used to
> >> access their system (PMIP based S5 for 3GPP accesses, and PMIP
based
> >> S2b for no-3GPP accesses.)
> >>
> >>> It's a question of whether we agree that LMA-MAG signaling could
> also be
> >>> used in addition to relying only on L2 signaling for flow
mobility.
> >>
> >> At this stage the question is rather, is it possible to provide a
> >> correct and robust system without modified L2 signaling. If it is,
> >> then we can go ahead with the question you laid above. Would you
> >> agree?
> >>
> >>>> (And of course, splitting to different specifications should not
> be
> >>>> misused to hide a technical omission or a problem.)
> >>>
> >>> I would focus on getting a protocol that works under different
> cases and not
> >>> just under continued reliance on (existing and new) L2 signaling.
> (I am not
> >>> referring to new IP signaling between MN and MAG).
> >>
> >> See above. The focus you propose is only appropriate insofar we've
> >> come up with a positive answer to the question I asked above, and
> that
> >> we' re discussing with Carlos, Hesham, et al.
> >>
> >> --julien
> >
> >
> _______________________________________________
> netext mailing list
> netext@ietf.org
> https://www.ietf.org/mailman/listinfo/netext