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

CARLOS JESUS BERNARDOS CANO <> Fri, 01 November 2019 12:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5371D120118 for <>; Fri, 1 Nov 2019 05:06:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yAeiaFVjzWGe for <>; Fri, 1 Nov 2019 05:06:08 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F3F53120853 for <>; Fri, 1 Nov 2019 05:06:07 -0700 (PDT)
Received: by with SMTP id y7so7353228edo.12 for <>; Fri, 01 Nov 2019 05:06:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=otQ2qta23d5CE2J5ryVSg7VFYG92+EYt+USCS+/NA8I=; b=cpNHU0BP+HGEA0Y1LNfuZdjb0WwqWCptgrk23avvNTsw2aWq6mYmsU4HDdQXek0RNG cDww3zbGVIZIKxofE63weMp0EFwzq9CmXIt5jnxX/q8dCuIDzIqD8jnE5T10xk15xA2n hTBoeaRW5T504rRtuvKA/hm0e3TxDeV10tyn/0Rvxjw0ct97NwLk7FQzFioHt3tw1Mfn OHczmBeeIgSFQ9bOQOI8i0vlNsGfpXdyjZTbLv2o90+Bjvq2ym43XDKfTXq81wwRDBAP BYYFgj1hQiL5ty99VYrt0mG+0Si5tJ2d5ltecKpSG9oxnJKtA6WCJGfvEG/Xty+rZG1H bgzg==
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=otQ2qta23d5CE2J5ryVSg7VFYG92+EYt+USCS+/NA8I=; b=cBeruHw29bKrsPnNJcmcIBUhpQIWnW8ViQZUoyncGYbnIcxEKB5qxGtnGveqeZWg23 18VUaqyVDFO8H5YwNxrW27IRyxBTznf2fwr0S9Q0kuJ0R54Pghib+9V0rm9KRiZZ2Gu7 eZxx0bAFXXDHpX69ovTtpNkt68U4kUGb3LkprLSVfRn1vVbvGEgARCxt7u6MV/ihLPlp MeYn4t4Yh9UtaiPQtbNrEfQHINqxK1v83iZyDMiYi5DE+c7v58ZKn1CYyyxjTtBOeiHF Hk4+c4MKGSyGyevjlI8hcoSTW1gBppHdj4zDxAfOhy3gPfiLNRkyiTGZv73SlMWVMLfe kMFQ==
X-Gm-Message-State: APjAAAXIZ2yOX5b4VtGXYpGscKHw5zG+p8f217iml2f7impFQbL3ri7l WasHYKUKhOAtLPzl1enWPKhNR84oYDkav2SMMRJi/Q==
X-Google-Smtp-Source: APXvYqxkRLMpQuBtOOTQYHg6T5NpbGP5D5lUxldQuLofiB1b87hPfnNA6audNVw75cakpSVEf4Qs+t+XgAMxaqyn9fQ=
X-Received: by 2002:a17:906:c9d9:: with SMTP id hk25mr9461852ejb.74.1572609966195; Fri, 01 Nov 2019 05:06:06 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Date: Fri, 1 Nov 2019 13:05:49 +0100
Message-ID: <>
To: Yoshifumi Nishida <>
Cc:,,, dmm <>
Content-Type: multipart/alternative; boundary="00000000000067f7a2059647ca59"
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: Fri, 01 Nov 2019 12:06:12 -0000

Dear Yoshi,

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



On Thu, Oct 24, 2019 at 9:38 AM Yoshifumi Nishida <>

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