Last Call Review of draft-ietf-dmm-distributed-mobility-anchoring-13
review-ietf-dmm-distributed-mobility-anchoring-13-tsvart-lc-nishida-2019-10-14-00

Request Review of draft-ietf-dmm-distributed-mobility-anchoring
Requested rev. no specific revision (document currently at 14)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2019-10-14
Requested 2019-09-30
Authors Anthony Chan, Xinpeng Wei, Jong-Hyouk Lee, Seil Jeon, Carlos Bernardos
Draft last updated 2019-10-14
Completed reviews Tsvart Last Call review of -13 by Yoshifumi Nishida (diff)
Opsdir Last Call review of -13 by Qin Wu (diff)
Secdir Last Call review of -13 by Joseph Salowey (diff)
Genart Last Call review of -13 by Paul Kyzivat (diff)
Assignment Reviewer Yoshifumi Nishida
State Completed
Review review-ietf-dmm-distributed-mobility-anchoring-13-tsvart-lc-nishida-2019-10-14
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/etDhwuZZHa1UFFPM_D6LBOrh0XE
Reviewed rev. 13 (document currently at 14)
Review result Almost Ready
Review completed: 2019-10-14

Review
review-ietf-dmm-distributed-mobility-anchoring-13-tsvart-lc-nishida-2019-10-14

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
tsv-art@ietf.org 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