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

[Tran Minh Trung <[e-mail]>]

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]