Re: Tsvart last call review of draft-ietf-dmm-distributed-mobility-anchoring-13

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

Dear Yoshi,

We've just posted a new revision (-14) addressing all your comments.

Thanks!

Carlos

On Thu, Oct 24, 2019 at 9:38 AM Yoshifumi Nishida <[e-mail]>
wrote:

> Hi Carlos,
> Thanks for the response. I put my comments in lines.
>
> On Fri, Oct 18, 2019 at 4:20 AM CARLOS JESUS BERNARDOS CANO <
> [e-mail]> wrote:
>
>> Dear Yoshifumi,
>>
>> Thanks a lot for the review. Please check inline below for some comments
>> from my side.
>>
>> On Mon, Oct 14, 2019 at 9:57 AM Yoshifumi Nishida via Datatracker <
>> [e-mail]> wrote:
>>
>>> Reviewer: Yoshifumi Nishida
>>> Review result: Almost Ready
>>>
>>> This document has been reviewed as part of the transport area review
>>> team's
>>> ongoing effort to review key IETF documents. These comments were written
>>> primarily for the transport area directors, but are copied to the
>>> document's
>>> authors and WG to allow them to address any issues raised and also to
>>> the IETF
>>> discussion list for information.
>>>
>>> When done at the time of IETF Last Call, the authors should consider this
>>> review as part of the last-call comments they receive. Please always CC
>>> [e-mail] if you reply to or forward this review.
>>>
>>> Summary: This document is almost ready for publication as an
>>> informational RFC,
>>> but it will be better to clarify the following points.
>>>
>>> 1: The examples shown in the draft look behave conveniently.
>>>    For examples, in the figure 3 case, the flow is somehow terminated
>>> before
>>>    the MN moves and is re-initiated after the movement has finished.
>>> However, I
>>>    believe there should be the cases where applications don't aware of
>>> network
>>>    changes and transmit data while migrating, which may cause packet
>>> drops,
>>>    delays and timeouts, etc. I think this draft should clarify the
>>> treatments
>>>    of these cases. Is it out of scope of the draft? Or, do some
>>> components
>>>    generate ICMP messages to give some hints to the applications, or
>>> provide
>>>    buffering features to mitigate the side effects?
>>>
>>
>> [Carlos] I guess you mean Figure 4, right? In that figure, we try to
>> explain what would happen if there is no actual mobility support, meaning
>> that a communication flow does not need such mobility support. This might
>> happen because the flow stops before the movement (as shown in the figure)
>> or also because the application can deal with the mobility itself (no
>> mobility at the IP layer). We don't explicitly mention that second case
>> because it is not in the scope of the draft (IP mobility). We can better
>> clarify the scope in the text.
>>
>
> Sorry for confusion. Yes, the data flow is explained in Figure 4.
> What I wanted to mention was how the flow can stop it without mobility
> support. If there's no mobility support, the app should not be able to know
> when network change will happen. So, I am thinking that in some cases, the
> flow may not able to stop before the movement.
> I am guessing this case would be a major case than the case described in
> the draft.
> Or, is there any available approach here?
>
>>
>>
>>>
>>> 2: Page 8:
>>>    "A MN will need to choose which IP prefix/address to use for each flow
>>>     according to whether it needs IP mobility support or not."
>>>
>>>      -> It seems to me that the draft implicitly suggests the use of
>>>      draft-ietf-dmm-ondemand-mobility here.
>>>         If so, I think it would be better to state more explicitly. Or,
>>> do we
>>>         have other options?
>>>
>>
>> [Carlos] We can definitely add an explicit reference to
>> draft-ietf-dmm-ondemand-mobility, but I'd mention it as an example. I don't
>> have another option in mind, but we can leave it open.
>>
>
> Yes, referring as an example is fine. I just thought if this approach can
> be used, then it might be better to explain it explicitly.
>
>>
>>
>>> 3: Page 10:
>>>     "the initial anchor remains the anchor and forwards traffic"
>>>
>>>      -> could be "anchor remains and the anchor.."?
>>>
>>
>> [Carlos] Maybe "mobility anchor remains playing that role and forwards
>> traffic"?
>>
>
> Works for me. Thanks!
> --
> Yoshi
>


-- 
Special Issue "Beyond 5G Evolution":
https://www.mdpi.com/journal/electronics/special_issues/beyond_5g