Subject: [Tsv-art] Tsvart last call review of draft-ietf-dmm-distributed-mobility-anchoring-13

From: Yoshifumi Nishida via Datatracker <[email-masked]>
Date: Mon, 14 Oct 2019 00:57:03 -0700

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
[email-masked] 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?

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?

3: Page 10:
    "the initial anchor remains the anchor and forwards traffic"

     -> could be "anchor remains and the anchor.."?

Thanks,
--
Yoshi

---

From: CARLOS JESUS BERNARDOS CANO <[email-masked]>
Date: Fri, 18 Oct 2019 13:20:10 +0200

Dear Yoshifumi,

Thanks a lot for the review. Please check inline below for some comments
from my side.

>    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.

>         If so, I think it would be better to state more explicitly. Or, do

[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.

>      -> could be "anchor remains and the anchor.."?

[Carlos] Maybe "mobility anchor remains playing that role and forwards
traffic"?

Thanks!

Carlos

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

---

From: Yoshifumi Nishida <[email-masked]>
Date: Thu, 24 Oct 2019 00:37:56 -0700

Hi Carlos,
Thanks for the response. I put my comments in lines.

> 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?

> 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.

> [Carlos] Maybe "mobility anchor remains playing that role and forwards

Works for me. Thanks!
--
Yoshi