Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt]

[Hidetoshi Yokota <[e-mail]>]

Hi Carlos,

Thanks for your response and the discussion is getting more active 
towards the WGLC!

Please see inline:

(2014/06/20 2:36), Carlos Jesús Bernardos Cano wrote:
> Hi Hidetoshi,
>
> Thanks for your comments. Please see inline below.
>
> On Thu, 2014-06-19 at 13:40 +0900, Hidetoshi Yokota wrote:
>> Hello Carlos,
>>
>> Thanks for updating the draft.
>> I have a couple of questions and comments:
>>
>> o In Section 3.2.1, which is the shared prefix case, there is no
>> message exchange between the LMA and MAG, so there is no flow
>> information on the MAG side. It should work in the sense of routing,
>> but if, for example, each flow has a specific QoS, the MAG should also
>> need to know which flow should go on which QoS path especially for
>> upstream traffic towards the LMA. Or, the MAG may want to send a
>> trigger for flow mobility to the MN (the exact mechanism is out of
>> scope).  Some mobility signaling should be there, too.
> [Carlos] There was a discussion on this in the past (don't remember
> exactly when, but I recall that Rajeev was one of the drivers) and the
> group decision was to make the signaling at the prefix level, not at
> flow level. If the group think there is value on supporting
> flow-granularity signaling, we could add it.

Flow movement at the prefix level is ok, but the new MAG needs to know 
which flow(s) is/are coming within that prefix to link it/them to proper 
QoS path(s) and optionally to inform the MN about it. Actual use cases 
would require more than just routing.

>> o In Section 3.3, FMI/FMA are revived considering the case where UPN
>> is not supported, but they convey very little information. There is no
>> special information that cannot be conveyed by the existing messages.
>> Since RFC7077 is now a proposed standard, I cannot think of a
>> situation where the UPN/UPA are not supported, nevertheless FMI/FMA
>> are supported. It rather seems more natural to mandate the support of
>> RFC7077 or to mandate FMI/FMA for all flow mobility operations.
>> Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to
>> convey different set of parameters in Figure 7. Could you clarify it a
>> little bit more please?
>>
> [Carlos] As Pierrick has already replied to you, there was discussion in
> London about supporting both mechanisms. I think this deserves another
> thread on the mailing list devoted to that discussion. As I expressed in
> a previous e-mail, my personal opinion as WG member is that we should go
> for just one signaling mechanism (being UPN/UPA my preference), but here
> I'm acting as the editor of the document and I just updated the document
> to reflect the consensus of the room in London.

I see, but Sri has a different view on it. Let's discuss it on the ML. I 
also prefer to stick to one set of signaling messages.

>> o In Section 3.3, just above Figure 7, there is a description: "...,
>> and the type of flow mobility operation (add flow)", but does RFC6089
>> define such an operation code? This kind of operation should also be
>> defined in the draft.
> [Carlos] By "add", a lifetime higher than 0 is meant (as 0 means
> "remove"). I agree this should be clarified in the document. Thanks for
> the comment.

Not only clarifying the text, but also more explicit mobility operation 
commands such as "add" or "remove" should be defined rather than using 
the lifetime value. This would be more true if the flow movement is at 
the prefix level; you don't want to lose all flows with the same prefix 
by setting the lifetime value to zero for removing just one flow. Please 
take it into consideration.

Regards,

-- 
Hidetoshi Yokota

KDDI R&D Laboratories, Inc.
e-mail:[e-mail]


> Once again, thanks for your comments!
>
> Carlos
>
>> Regards,
>> -- 
>> Hidetoshi Yokota
>>
>> KDDI R&D Laboratories, Inc.
>> e-mail:[e-mail]
>>
>>
>> (2014/06/14 2:16), Carlos Jesús Bernardos Cano wrote:
>>
>>> Hi,
>>>
>>> As agreed in London, I've updated the flow mobility draft to include
>>> also the FMI/FMA signaling option (in addition to the use of Update
>>> Notifications). The draft also includes a mechanism to allow selecting
>>> which one of the two signaling mechanisms to use.
>>>
>>> In my personal opinion, it'd be much cleaner and simpler to just specify
>>> one signaling mechanism, but this is up to the WG to decide.
>>>
>>> Comments, reviews and discussion on this new revision would be welcome.
>>> Hopefully we could get at least a new revision before Toronto.
>>>
>>> Thanks,
>>>
>>> Carlos
>>>
>>>
>>> _______________________________________________
>>> netext mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netext
>> _______________________________________________
>> netext mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/netext
>
>
>
>