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

Yoshifumi Nishida <> Thu, 24 October 2019 07:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 937D2120814; Thu, 24 Oct 2019 00:38:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4DPlcYKPFPCn; Thu, 24 Oct 2019 00:38:10 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02B2612000F; Thu, 24 Oct 2019 00:38:10 -0700 (PDT)
Received: by with SMTP id q13so19864143wrs.12; Thu, 24 Oct 2019 00:38:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZMQwa5zJlipdg8k9JZGDkAa59NFyxE0t7LMUO5fUODo=; b=TmEi1zVw29zd6wY/HHVoflcSxGjrgwQxWfYbhNf6wtZeD+f2D3cFAqvblMZRYT65Bm Cq8NVmlPk9ThHM3P5OQPJZUJWSnhUwgwUOg0XAGboUF/eGq7R813NbzoRInPDD25p9YH Jtu4w6I5twFCEOIVipPXwHpIPvqM9Ye06w14FER1Z/TLSwbbV5419B2tt2hrbO4ZahbW jOJNECRFfCZQp3w/y/rylpA7+HtV2mNG5QQwfXp6wmfNnJqZPgjeRzR4ttyuGCyATRCx wNTqIIWmQEoliImOCA2fwmwP+0rgKo03o73XNQLt/jC82bkGJ5FlvE8XtuHPeLNfaiAF XUUQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZMQwa5zJlipdg8k9JZGDkAa59NFyxE0t7LMUO5fUODo=; b=sTXhbL3mJwRFMjn5bm6Psks+WQtwUWZWwOHfoBo0SCECQfv8/Yt406RgrTupohL2M1 l6Nw6PmbzGNV9AbeFsQ3RG4e2QVTiwOSqZvXilu43g3Nzrd2ojPJdhu9wgv4js2zvzA9 th0pUmDswnE+MkS+sMmOCL8JmlkoHX6bbiLGrpSAodfedDGFcITkrKtoKn9HeCUMaC9U diQFTmdlrKB+4C1K0xrvMrIAv+Q/hX1vV+ZoI8NWlqUl8DXMDmiZNdXfwMaC0uESLvyI qXOIIbWGKAyRlMyFestLKlZm13YnLg9q9xQljiHDUgR0Epi7NVugsGtCahqL+DcD9QsC Gi7A==
X-Gm-Message-State: APjAAAWlnzX0FAKnXpGnzVcm3eweUVd+vOb6XYoT4eeyHGI/+GT3+HSH 60HJggAbk0z8mk0oZaxygDQ32HN2gY6WSpYC3U8=
X-Google-Smtp-Source: APXvYqyPvRctkF52zdwAN+Dqlv+jg4jXZTXN2jJS589ErgP8aQZylRlaWdFzkd9EywFHU73bGyi/DeABGNHIlK7neWQ=
X-Received: by 2002:a5d:4705:: with SMTP id y5mr1816269wrq.364.1571902688457; Thu, 24 Oct 2019 00:38:08 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Yoshifumi Nishida <>
Date: Thu, 24 Oct 2019 00:37:56 -0700
Message-ID: <>
Cc:,,, dmm <>
Content-Type: multipart/alternative; boundary="0000000000005dfbb30595a31d8b"
Archived-At: <>
Subject: Re: [DMM] Tsvart last call review of draft-ietf-dmm-distributed-mobility-anchoring-13
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Distributed Mobility Management Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Oct 2019 07:38:12 -0000

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

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