Re: [netext] Comments & Questions on the I-D:draft-bernardos-netext-pmipv6-flowmob-00

[Carlos Jesús Bernardos Cano <[e-mail]>]

Dear Pierrick,

I agree with your comments.

Thanks,

Carlos

On Wed, 2010-07-21 at 15:51 +0200, [e-mail]
wrote:
> Hi Tran Minh and Carlos,
> 
> Please let me jump into this interesting discussion.
> 
> Tran Minh, You're right, theoretically both the LMA and the MN should
> also be able to make decision about the path to use for a given IP
> flow. In addition to handover triggers at the MN side that you are
> suggesting, it may be not desirable that the LMA enforces its decision
> to the MN despite of the user preferences. 
> 
> However, a MN driven decision in a network based mobility management
> solution is quite tricky without MN signalling (and we definitely want
> to avoid such a signalling, I don't want to reopen the debate :-)).
> For example, you wrote:
> 
> "The MAG can be aware of this movement by analyzing the packets
> received from the MN and inform the LMA."
> 
> I don't think such a simple solution could be sufficient, since there
> are some cases where the MN does not use the uplink very often, e.g.
> RTP streaming. 
> 
> So, trying to support the MN driven routing decision would bring
> additional complexity and delay in the design of a solution. So, for
> the sake of pragmatism, it makes sense to focus, in a first step, on a
> routing decision driven by the LMA where the MN just updates its
> uplink path according to where packets are received.
> 
> Then we need to clarify the requirement for handover triggers to be
> processed at the MN side only. If so, we could think about extension
> to the base solution as drafted in draft-bernardos.
> 
> Regards,
> Pierrick
> 
> > -----Message d'origine-----
> > De : [e-mail] [mailto:[e-mail]] De la part
> > de Tran Minh Trung
> > Envoyé : mercredi 21 juillet 2010 12:17
> > À : [e-mail]
> > Cc : [e-mail]
> > Objet : Re: [netext] Comments & Questions on the I-D:draft-bernardos-
> > netext-pmipv6-flowmob-00
> > 
> > Hi Bernardos,
> > 
> > Thank you for your reply.
> > Pls. see my replies inline.
> > 
> > 2010/7/21 Carlos Jesús Bernardos Cano <[e-mail]>:
> > > Hi Tran Minh,
> > >
> > > On Tue, 2010-07-20 at 17:44 +0900, Tran Minh Trung wrote:
> > >> Hi Bernardos and all,
> > >>
> > >> I have some comments and questions on the I-D
> > >> draft-bernardos-netext-pmipv6-flowmob-00 as follows:
> > >
> > > Thanks a lot for the feedback. Please see some comments inline below.
> > >
> > >>
> > >> 1) I think the LMA can decide to move down-link flows only. The
> > >> up-link flows should be moved by the MN (eg. the MN is aware of the
> > >> attachment status via each IF and decide which IF is better for
> > >> sending up-link flows). The MAG should be aware of the movement of
> > >
> > > Our assumption is that the MN does implement the logical interface (as
> > > explained in draft-melia-netext-logical-interface-support-01). The LMA
> > > has of course the direct control of how downlink flows are routed, but
> > > an MN implementing the logical interface will just mirror that behavior
> > > with the uplink packets. Therefore, the LMA is the only entity
> > > controlling flow mobility both in downlink and uplink directions.
> > >
> > 
> > 
> > >> up-link flows and inform the LMA to update information.
> > >
> > > In the current draft, the MAG is informed about flow mobility operations
> > > by the LMA. There is signaling defined for that purpose.
> > >
> > 
> > Let's consider the case that the MN performs a handoff. I think it is
> > a special case of flow mobility when all flows are moved from an
> > interface to another. The MAG is aware of that event and informs the
> > LMA by using handoff indicator. So I think that we may consider the
> > same for the case that flows are moved by the MN. The MAG can be aware
> > of this movement by analyzing the packets received from the MN and
> > inform the LMA.
> > 
> > In real network both operator (the LMA) and user (the MN) can set and
> > perform the rules to select the best interface (access technologies)
> > for serving a specific service flow. So we may better support for both
> > of them.
> > 
> > 
> > >>
> > >> 2) It is necessary to discuss about the flow mobility triggers. The
> > >> signaling procedure between MAG/LMA depends on trigger. With different
> > >> kind of trigger we have to use different signaling procedure.
> > >
> > > The trigger is out of the scope of the solution draft. Any kind of
> > > trigger could be supported. For example a central policy entity can make
> > > the decisions based on the overall state of the network and trigger the
> > > LMA. IMHO, which entity triggers the LMA can be left out of the scope,
> > > as it does not have an impact on the protocol (with current design).
> > >
> > 
> > I agree that it is not necessary to discuss detail about trigger in
> > the solution draft.
> > However, we have to mention about where do triggers come from?. Basing
> > on the source of trigger we have to use different signaling procedure.
> > 
> > For examples:
> > 
> > - The MN performs new attachment -> The MAG is aware of that event and
> > informs the LMA about new attachment and asks the LMA whether to move
> > some exiting flows to new attachment.
> > - The MAG receives new flows from an interface of the MN -> The MAG
> > informs and asks LMA to check whether this flow is a new flow or just
> > a flow moved from another interface of the MN.
> > - The LMA sees some changes in the network conditions or service
> > profile of the MN -> The LMA decides to move some flows to get better
> > services and inform MAGs.
> > 
> > 
> > >>
> > >> 3) The proposed solution requires new signaling messages and new
> > >> caching table. It makes more complicated for implementing and
> > >> combining with the existing standard than just extending the current
> > >> PBU/PBA messages as well as BCE and BULE caching table.
> > >
> > 
> > > Well, this was a design decision (there might be of course others). We
> > > preferred not to overload existing signaling. Regarding the data
> > > structures, they are just logical ones, they could also even be
> > > implemented by extending BCE and BUL.
> > >
> > >>
> > >> 4) What are the necessary requirements of the logical interface to
> > >> support flow mobility?
> > >
> > > This should be covered by
> > > draft-melia-netext-logical-interface-support-01.
> > >
> > 
> > I get some confuses about the logical interface described in the I-D
> > "draft-melia-netext-logical-interface-support-" and the logical
> > interface used in the I-D "01draft-bernardos-netext-pmipv6-flowmob-00"
> > 
> > IMHO, when we use logical interface, the (set of) prefix(es) is
> > assigned to the logical interface only, not to physical interface. The
> > LMA, at layer 3, may see only the logical interface.
> > 
> > From this point, I think the 'Unique prefix per physical interface'
> > scenario is not necessary.
> > 
> > However if we consider this scenario, then we can justify why we need
> > it as Julien suggested. And also we can discuss to make clear that why
> > we use the logical interface to hide the physical interfaces but we
> > still separate prefix(es) assignment basing on physical interfaces.
> > 
> > ---
> > Tran Minh Trung
> > 
> > >>
> > >> I hope that we can have more discussion on these issues before making
> > >> it as a WG document.
> > >
> > > Sure, useful discussion as this is very very welcome. Thanks!
> > >
> > > Kind Regards,
> > >
> > > Carlos
> > >
> > >>
> > >> Regards,
> > >> Tran Minh Trung
> > >>
> > >
> > > --
> > > Carlos Jesús Bernardos Cano     http://www.netcoms.net
> > > GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67
> > >
> > 
> > 
> > 
> > --
> > Ph.D., Senior Member
> > Electronics and Telecommunications Research Institute
> > Standards Research Center
> > 161 Gajeong-Dong, Yuseong-Gu, Daejeon, 305-350, KOREA
> > Tel : [phone],   Fax : [phone]
> > _______________________________________________
> > netext mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/netext

-- 
Carlos Jesús Bernardos Cano     http://www.netcoms.net
GPG FP: D29B 0A6A 639A A561 93CA  4D55 35DC BA4D D170 4F67