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

CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Fri, 18 October 2019 11:20 UTC

Return-Path: <cjbc@it.uc3m.es>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57908120C0D for <dmm@ietfa.amsl.com>; Fri, 18 Oct 2019 04:20:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it.uc3m.es
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5K6WyVweW2oG for <dmm@ietfa.amsl.com>; Fri, 18 Oct 2019 04:20:28 -0700 (PDT)
Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD09120C10 for <dmm@ietf.org>; Fri, 18 Oct 2019 04:20:28 -0700 (PDT)
Received: by mail-ed1-x532.google.com with SMTP id y91so4262659ede.9 for <dmm@ietf.org>; Fri, 18 Oct 2019 04:20:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it.uc3m.es; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=errjep6A5mhg8VfAXms1IP9gUaY68Fwk/aOdD6Zd2sA=; b=q0cFeLY5bxTOnFzqKt9udBYbnorNsilZ6p3Q6kW9eDTlvZC3B1pYh81vmCT2clLji2 SgpxzViR6z7mDTINwgmhxo1bxFcYCmtPFIGnYw0RSEq/q46g3av5psfkkgC5f5UZPl14 RMyYKZjPrUmRvo0q9uHJIgm60ddDGEhn44eqLaj0W01jAjt2fbT9kEgBL7lttwUdNXvj vcU2hLEAT1l+BD+0rX8ATuogGhvXac1Au23ijxk+NaZBpRYew12yWxjicj+0j3A7fNnO iFco2pC+Aaq4FRtrIiQy0TK+RSEGca8nave8taTq6bLCKf07s4+mHYwQnfXOhse3nUnF JDFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=errjep6A5mhg8VfAXms1IP9gUaY68Fwk/aOdD6Zd2sA=; b=jz/beXuO9Pa+5yOIWW6CocAnRlUH5NEanmXULfqLBo6L2iOrYF82l02RPfybbgYHyl l2Mzjlxmbd6ZD7p+XSrwrsWv1A0qL1zDf4Fw0RLpTIkxK2+FT7PjEonbucvlSV2aiCZV m4cRW7xX3dB1k36FqSVfK5AN9hoCUHT6ULDw8fUNeEmIjGYaYCSbmVPB3wsqAG5Pfmg2 mcs7uLYS+TqLv92UruLN0zxtxx022CpmeaOf5SFdyApDFZqLcEV0bL/DM/VMlQBLSHp9 ZAnGRv9oERqJ5IS6R2YTVwX//lU4Dir8Oyug+IXaqHiUxbXbYGMmDPYi+cRey6+BUKKo /v0A==
X-Gm-Message-State: APjAAAVUk6orAsgWN/RfhEoZjJ7snSYtHmo8d2hXg/CM8dxS3p5TJb9g UmGn5hoZ3r4gx4M2fjHVg9NTTllYUyXNW34f/5b/9Q==
X-Google-Smtp-Source: APXvYqxUyQdg2WLSQhcAcj38ckVUWfKoptybjolg56+fYcNNfJwdMDqCCeWFzN1g0XcFvo4UnWuYPSTeZcOK9gcOrT0=
X-Received: by 2002:a17:906:6ad7:: with SMTP id q23mr7842379ejs.214.1571397626615; Fri, 18 Oct 2019 04:20:26 -0700 (PDT)
MIME-Version: 1.0
References: <157103982375.24746.491736148532050112@ietfa.amsl.com>
In-Reply-To: <157103982375.24746.491736148532050112@ietfa.amsl.com>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Fri, 18 Oct 2019 13:20:10 +0200
Message-ID: <CALypLp-7wcYB1j6qU_CawTCgU2m2EU-XJTONO3f3KF=r4_tozg@mail.gmail.com>
To: Yoshifumi Nishida <nsd.ietf@gmail.com>
Cc: tsv-art@ietf.org, draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, ietf@ietf.org, dmm <dmm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000055f83105952d85b3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/eq8OO0u7kHTLILJlGNsdX0MpkiQ>
Subject: Re: [DMM] Tsvart last call review of draft-ietf-dmm-distributed-mobility-anchoring-13
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Oct 2019 11:20:32 -0000

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 <
noreply@ietf.org>; 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
> 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?
>

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


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


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

Thanks!

Carlos

>
> Thanks,
> --
> Yoshi
>
>

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