Re: [netext] Scope of Prefixes in Flow Mobility

["Laganier, Julien" <[e-mail]>]

Hi Sri,

Some comments below -

Sri Gundavelli wrote: 
> 
> > The LMA will be receiving a PBU with the necessary information and can
> > take the decision on whether to assign multiple prefixes or the same
> > across different access networks.
> 
> (Couple of slides attached)
> 
> The above approach will always will result in a single prefix
> allocation across interfaces, which is not desirable. If the feature is
> active, we start with one prefix on a interface and start sharing on
> the other interface. Couple of points:
> 
> 1.) For each new interface attachment, always allocate a new prefix, or
> set of prefixes, just as in 5213.
> 2.) However, if the flow policy requires an existing active flow on a
> different interface to be relocated to the new interface, the approach
> of prefix sharing across interfaces can be considered.
> 
> As I said yesterday (please see the attached slides), we have 4
> scenarios.
> Scenario-1 and Scenario-2 are covered in 5213. Now, we have scenario-3,
> moving all the flows associated with a prefix (i.e. Using the source
> address from the same prefix) i.e. Mohana's draft, to a new interface.
> This is almost like Sceanario-1, we have proper indicators.
> 
> The other scenario, which I never liked is scenario-4, requiring shared
> prefixes across interfaces. But, scenario-4 and scenario-2 should not
> be seen as mutually exclusive. In other words, its not always
> multihoming vs prefix sharing, but rather its always multihoming, but
> some flows that had to moved to different interface (determined by
> policy), even if they are using a prefix from the prev interface, we
> need to share so those flows can be relocated. Assuming new flows will
> pick up the right source address/interface selection and eventually
> keeping the prefixes to the respective interfaces.

If you have, as you put it, "some flows that had to moved to different interface, even if they are using a prefix from the prev interface", it means that a prefix is no longer bound to a unique interface since flows from/to that prefix can show up on a difference interface.

Thus it is the case that prefixes are decorrelated from interfaces, which naturally lead to a per-MN prefix set that are equally available on all accesses/interfaces.

That does not preclude being able to assign additional prefixes when additional accesses are brought up, although I'd like to understand better the motivation behind such a feature. As I said this was primarily introduced to avoid issues involved with an unmodified host being multihomed, but we do no longer have to care about this since the host is isolated from the issues thanks to a below-IP logical interface.

--julien

> On 8/5/10 2:09 AM, "MELIA, TELEMACO (TELEMACO)"
> <[e-mail]> wrote:
> 
> > Hi all,
> >
> > Let me share few thoughts with you.
> >
> > I think that the flow mobility feature can be regarded as a service
> to
> > which mobile customers subscribe.
> > This can be a flag in  the mobile node's profile (section 6.2 of RFC
> > 5213). I suggest to extend the mandatory fields by adding the flow
> mobility service.
> > The LMA will be receiving a PBU with the necessary information and
> can
> > take the decision on whether to assign multiple prefixes or the same
> > across different access networks. The presence of the flow mobility
> > bit implicitely triggers the extended prefix assignment algorithm.
> > The LMA will not be aware of the logical interface but knows that the
> > MN can handle flow mobility.
> >
> > Now, about filters vs. prefix only configured in the MAG for flow
> > mobility. I think we should be flexible and allow both to be
> > transferred to the MAG. This allows the MAG to understand flows if
> > required (else routing is only possible via IP addreses).
> >
> > telemaco
> > ________________________________________
> > From: [e-mail] [[e-mail]] On Behalf Of
> > Sri Gundavelli [[e-mail]]
> > Sent: Thursday, August 05, 2010 5:18 AM
> > To: Tran Minh Trung
> > Cc: [e-mail]
> > Subject: Re: [netext] Scope of Prefixes in Flow Mobility
> >
> > Tran:
> >
> >>> However, the LMA may choose to assign the same prefix(es) as well
> as
> >>> new
> >>> prefix(es) if it so chooses based on the ATT field. This would be
> >>> scenario 3 below.
> >>>
> >
> > Right. We assume the network provides the handover hints. We do not
> > have the MN-AR interface at this point. When we were writing the base
> > spec, the MN-AR interface was factored into the design. Julien was
> > working on this and some where we lost track of this critical
> interface.
> >
> > http://tools.ietf.org/html/draft-ietf-netlmm-mn-ar-if-03
> >
> > We need to revive this at some point. I was hoping
> > Telemaco/Carlos/Juan Carlos will revive this in for different SDO
> > architectures, at least that was our understanding.
> >
> > http://ietfreport.isoc.org/idref/draft-melia-netext-3gpp-mn-ar-if/
> >
> > Ideally, the handover hints will come from that interface. If we
> build
> > this interface, eventually, the mobile node can express the handover
> > preferences and flow-path preference. This will allow us to cleanly
> > support the shared prefix scenario.
> >
> >
> >
> > Sri
> >
> >
> >
> >
> >
> >
> >
> >
> > On 8/4/10 7:09 PM, "Tran Minh Trung" <[e-mail]> wrote:
> >
> >> Hi Rajeev,
> >>
> >> Please see my comments inline:
> >>
> >> On Thu, Aug 5, 2010 at 2:39 AM, Rajeev Koodli <[e-mail]>
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I am still trying to understand what will not work if we don't make
> >>> this assumption..
> >>>
> >>> There are two parts here, which I outlined as 2) & 3) below.
> >>>
> >>> Signaling extension in Binding Update to inform the LMA to support
> >>> same prefix assignment. This can be another value assignment for
> the HI field.
> >>> When this value is set, the LMA knows that it can assign the same
> >>> prefix(es). This is scenario 2 below.
> >>>
> >>
> >> How can we set the value of HI exactly?.  Without signaling from the
> >> MN, I think it is not easy.
> >> Let's assume that we can set the value of HI exactly. Then if the MN
> >> uses 2 logical interfaces to hide two different sub-interface paths,
> >> how can LMA differentiate them by just depending on HI?
> >>
> >>> However, the LMA may choose to assign the same prefix(es) as well
> as
> >>> new
> >>> prefix(es) if it so chooses based on the ATT field. This would be
> >>> scenario 3 below.
> >>>
> >>
> >> I think just ATT is not enough. The MN can be equipped with 2
> >> interfaces using the same ATT and they can be hidden by different
> >> logical interface.
> >>
> >>> So, why do we need to know anything more than this?
> >>>
> >>> Thanks,
> >>>
> >>> -Rajeev
> >>>
> >>
> >> PS: I can not find the scenario 2,3 that you mentioned. Are they the
> >> scenarios in your previous email?
> >>
> >> Regards,
> >> TrungTM
> >>
> >>
> >>>
> >>> On 8/3/10 11:38 PM, "Tran Minh Trung" <[e-mail]> wrote:
> >>>
> >>>> Dear Rajeev,
> >>>>
> >>>> Should we assume that the LMA is aware of the logical interface at
> the MN?.
> >>>> If not, how LMA can differentiate which physical interfaces are
> >>>> hidden by the same logical interface?
> >>>> If LMA can not recognize which physical interfaces are hidden by
> >>>> the same logical interface then it is impossible to assign
> >>>> prefix(es) exactly to different attachments.
> >>>>
> >>>> In case we assume that the LMA is aware of the logical interface
> at
> >>>> the MN, then it is easy to enable LMA to assign the same
> prefix(es)
> >>>> to all attachments of the logical interface.
> >>>>
> >>>> Thank you very much for making it more clear.
> >>>> Regards,
> >>>> TrungTM
> >>>>
> >>>>
> >>>> On Wed, Aug 4, 2010 at 2:37 AM, Rajeev Koodli <[e-mail]>
> wrote:
> >>>>>
> >>>>> Hello Carlos, All,
> >>>>>
> >>>>> We had some good discussion on the prefix model for the flow
> >>>>> mobility work.
> >>>>> I have tried to capture the scenarios in the following text.
> Let¹s
> >>>>> work towards incorporating this into the draft.
> >>>>>
> >>>>>
> >>>>> X. Prefix Model
> >>>>>
> >>>>> Flow mobility assumes simultaneous access to more than one
> >>>>> network, in a contrast to a typical handover where connectivity
> to
> >>>>> a physical medium is relinquished, and is re-established with
> another.
> >>>>> There are multiple prefix models under which a flow mobility
> >>>>> protocol needs to work:
> >>>>>
> >>>>> 1. At the time of a new attachment, the MN obtains a new prefix
> or
> >>>>> a new set of prefixes. This is the default behavior with RFC 5213.
> >>>>>
> >>>>> 2. At the time of a new attachment, the MN obtains the same
> prefix
> >>>>> or the same set of prefixes as already assigned to an existing
> >>>>> session.  This is not the default behavior in RFC 5213, and the
> >>>>> LMA needs to be able to provide the same assignment even for the
> >>>>> simultaneous attachment (as opposed to the handover scenario
> only).
> >>>>>
> >>>>> 3. At the time of a new attachment, the MN obtains a combination
> >>>>> of
> >>>>> prefix(es) in use and new prefix(es). This is a hybrid of the
> >>>>> above two scenarios. The local policy determines whether the new
> >>>>> prefix is exclusive to the new attachment or it can be assigned
> to
> >>>>> an existing attachment as well.
> >>>>>
> >>>>> Among the above, scenario 2 needs extensions to RFC 5213
> signaling
> >>>>> at the time of a new attachment. Subsequently, no further
> >>>>> signaling may be necessary between the LMA and the MAG. The
> >>>>> scenario 1 requires flow mobility signaling whenever the LMA
> >>>>> determines the need for relocating flows between the different
> >>>>> attachments. The scenario 3 requires flow mobility signaling
> >>>>> whenever the LMA determines the need for relocating flows for the
> >>>>> new prefix(es) which are not shared across attachments.
> >>>>> In all the scenarios, a prefix has to  be valid on the concerned
> >>>>> MAGs in order for flow mobility to work. Furthermore, each MAG
> >>>>> MUST advertise to the MN the all the prefixes received from the
> LMA.
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> netext mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/netext
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> netext mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/netext
> >>>
> >>
> >>
> >
> > _______________________________________________
> > netext mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netext