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

CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Fri, 01 November 2019 12:06 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 5371D120118 for <dmm@ietfa.amsl.com>; Fri, 1 Nov 2019 05:06:12 -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 yAeiaFVjzWGe for <dmm@ietfa.amsl.com>; Fri, 1 Nov 2019 05:06:08 -0700 (PDT)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 F3F53120853 for <dmm@ietf.org>; Fri, 1 Nov 2019 05:06:07 -0700 (PDT)
Received: by mail-ed1-x533.google.com with SMTP id y7so7353228edo.12 for <dmm@ietf.org>; Fri, 01 Nov 2019 05:06:07 -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=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; d=1e100.net; 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: <157103982375.24746.491736148532050112@ietfa.amsl.com> <CALypLp-7wcYB1j6qU_CawTCgU2m2EU-XJTONO3f3KF=r4_tozg@mail.gmail.com> <CAAK044T+7wjgmK=G8SVndoEny8EWsDkKq9V+rJPhAYp_adxaLg@mail.gmail.com>
In-Reply-To: <CAAK044T+7wjgmK=G8SVndoEny8EWsDkKq9V+rJPhAYp_adxaLg@mail.gmail.com>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Fri, 1 Nov 2019 13:05:49 +0100
Message-ID: <CALypLp_qK4GJW9f4_KAOiZPZ3X2jaS1UqzwiYgSbmJ1AwzXMTQ@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="00000000000067f7a2059647ca59"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/UeNskZMke3TQ6Q7YQQEVNQ_KWZ0>
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, 01 Nov 2019 12:06:12 -0000

Dear Yoshi,

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

Thanks!

Carlos

On Thu, Oct 24, 2019 at 9:38 AM Yoshifumi Nishida <nsd.ietf@gmail.com>
wrote:

> 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 <
> cjbc@it.uc3m.es> 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 <
>> 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.
>>
>
> 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":
https://www.mdpi.com/journal/electronics/special_issues/beyond_5g