From nobody Wed Oct 2 08:40:18 2019 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4538012088D; Wed, 2 Oct 2019 08:40:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Qin Wu via Datatracker To: Cc: draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, ietf@ietf.org, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.104.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Qin Wu Message-ID: <157003081719.8945.440750359268316955@ietfa.amsl.com> Date: Wed, 02 Oct 2019 08:40:17 -0700 Archived-At: Subject: [DMM] Opsdir last call review of draft-ietf-dmm-distributed-mobility-anchoring-13 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 15:40:17 -0000 Reviewer: Qin Wu Review result: Has Issues I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This draft discusses how distributed mobility anchoring functions work in both network based mobility solution and host based mobility solution. I think this draft lacks clarity on terminoloy definition and IP mobility support in different use cases. Major issue: Not found Minor issue: 1. Good to see anchor definition in the terminology section, however when we say anchor of IP prefix, how it is related to control plane anchor and data plane anchor? It will be nice to define CPA and DPA in the terminology section as well and clarify their relationship. 2. LM and FM functions are two terms defined in terminology section, however it is not clear to me how LM and FM functions related to 3GPP mobility components? How they are related to anchor defined in this document? Clarify this in ther terminology section will be helpful. Add 3GGP reference will be good. 3.Section 4.1 Not sure IP session continuity is needed in this nomadic case. If IP session continuity is supported, how is it different from two mobility cases? I think normadic case only supports application layer session continuity rather than IP session continuity. Would it be great to clarify the difference between IP session continuity, higher layer session continuity and IP mobility support in the terminology section 4. Section 4.1. I see in most cases IP mobiity support is equivalent to IP session continuity support, but in this draft, I see some difference between IP mobility and IP session continuity, e.g., IP mobility may not support IP session continuity, if the answer is yes, please clarify in the terminology section and redefine IP mobility. 5. Section 4.1, Figuer 4. In figuer 4, it is not clear to me how does CN know new address of MN, i.e.,IP2? Do we need any communication between CPA and DPA or CPA in the home network and CPA in new visited network? Control plane channel or data plane channel or Do we rely on LM and FM function to make CN know new IP address of MN when MN moves to new network? Please clarify. 6. Section 4.2, Not sure the case (ii) always enable optimized routes, it seems not consistent with what was said in section 4.3 since section 4.3 supports two cases, one is keeping anchoring to IP address of flow in the home networ, the other is switch the IP prefix/address anchoring to the new network. 7. Section 4.3 Also it is not clear to me why traffic redirection mobility case described in section 4.2 and anchor relocation mobility case described in section 4.3 should be breifly discussed in section 4.2. 8. How work flow in traffic redirection mobility case in section 4.2 is different from anchor relocation mobility case described in section 4.3? Why some piece of work flow for anchor relocation should be described in figure 5. From nobody Sun Oct 13 15:26:00 2019 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F0112006D; Sun, 13 Oct 2019 15:25:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey via Datatracker To: Cc: draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, iesg@ietf.org, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Joseph Salowey Message-ID: <157100555733.20750.5488529297693995498@ietfa.amsl.com> Date: Sun, 13 Oct 2019 15:25:57 -0700 Archived-At: Subject: [DMM] Secdir last call review of draft-ietf-dmm-distributed-mobility-anchoring-13 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Oct 2019 22:25:58 -0000 Reviewer: Joseph Salowey Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is the document has issues with the security considerations section. The security consideration section is extremely light. It mainly contains text from RFC 7333. It seems that there should be more discussion of security as it relates to the different configurations and different cases. Do each of these cases have the same security properties and require the same types of security controls? Are the IPSEC recommendations mentioned in the security considerations of draft-ietf-dmm-deployment-models-04 applicable for all the cases? Should these be pointed out in the security considerations section? From nobody Mon Oct 14 00:57:06 2019 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC510120121; Mon, 14 Oct 2019 00:57:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoshifumi Nishida via Datatracker To: Cc: draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, ietf@ietf.org, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yoshifumi Nishida Message-ID: <157103982375.24746.491736148532050112@ietfa.amsl.com> Date: Mon, 14 Oct 2019 00:57:03 -0700 Archived-At: Subject: [DMM] Tsvart last call review of draft-ietf-dmm-distributed-mobility-anchoring-13 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 07:57:04 -0000 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? 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 From nobody Mon Oct 14 13:21:22 2019 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1B11200F7; Mon, 14 Oct 2019 13:21:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Ines Robles via Datatracker To: Cc: draft-ietf-dmm-pmipv6-dlif.all@ietf.org, ietf@ietf.org, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Ines Robles Message-ID: <157108446243.24779.12043209679040887677@ietfa.amsl.com> Date: Mon, 14 Oct 2019 13:21:02 -0700 Archived-At: Subject: [DMM] Genart last call review of draft-ietf-dmm-pmipv6-dlif-04 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 20:21:08 -0000 Reviewer: Ines Robles Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-dmm-pmipv6-dlif-04 Reviewer: Ines Robles Review Date: 2019-10-14 IETF LC End Date: 2019-10-14 IESG Telechat date: Not scheduled for a telechat Summary: I believe the draft is technically good. This document is well written. The document proposes Distributed Mobility Management for Proxy Mobile IPv6 in which mobility sessions are anchored at the last IP hop router called MAAR (mobility anchor and access router). The document focuses on the required extensions to effectively support simultaneously anchoring several flows at different distributed gateways. I have a minor concern detailed in Nits section. Major issues:Not Issues found Minor issues: Not Issues found Nits/editorial comments: It would be nice to specify IANA Section with more details, such as indicating the registry which the option type belong, etc. [rfc8126] Thank you for this document, Ines. From nobody Mon Oct 14 13:49:29 2019 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C72120888; Mon, 14 Oct 2019 13:49:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joerg Ott via Datatracker To: Cc: draft-ietf-dmm-pmipv6-dlif.all@ietf.org, ietf@ietf.org, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.105.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Joerg Ott Message-ID: <157108615425.24656.12786623966649135975@ietfa.amsl.com> Date: Mon, 14 Oct 2019 13:49:14 -0700 Archived-At: Subject: [DMM] Tsvart last call review of draft-ietf-dmm-pmipv6-dlif-04 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 20:49:15 -0000 Reviewer: Joerg Ott Review result: Ready with Issues Hi, 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. The draft defines extensions to Proxy Mobile IPv6 to support a more distributed variant of mobility management. In essence, as a mobile node moves from one point of attachment (Mobility Anchor and Access Router, MAAR) to the next, its routing prefix with the previous MAAR(s) remain(s) and ongoing transport layer connections remain active and routed indirectly via the previous MAAR, while new ones will use the present MAAR. The interactions of MAARs are managed via a Central Mobility Database (CMD). The draft is well written and good to follow, describing the protocols and extensions clearly. I just have two transport-specific concern and two general operational issues that require further clarification in the draft. The transport issues: T1. Section 3.2. When the CMD acts as a relay for Proxy Binding Updates (PBUs) and Proxy Binding Acts (PBAs), the CMD may act as a relay of a single PBU to multiple previous MAARs. If multiple previous MAARs exist, say k, (and there may be numerous in case of many fast handovers, e.g., with vehicular networks), the CMD creates k outgoing packets from a single incoming packet. This bears a certain amplification risk (which may also need to be addressed in the security considerations section) but it also may lead to packet bursts originated from the CMD, albeit to different targets. Other protocols start introducing pacing to avoid bursts on the outgoing link, even if the packets do take different paths in the end. This may be worthwhile considering. T2. Also in section 3.2, when relaying PBAs, the CMD serves as a transport or application endpoint and should have a way to deal with missing responses (after all, this is a connectionless protocol on top of an unreliable Internet). A timeout is only mentioned for aggregation, but even there there the timeout is not specified, nor is a reference to, e.g., RFC 5213 or so to infer a timeout used elsewhere. General issues: G1. Section 3.2 (again) specifies that responses are aggregated on p.10. How does response aggregation work? How is error handling done? Moreover, also on p.10, further below the draft states that if a timer expires, the requests already received are forwarded. The missing ones come later. This seems to contradict aggregation because the originator (the currently server MAAR) does not expect more than a single response if it sent out a single update. This may thus require updated processing in the MAAR. G2. Sect. 3.3 suggests that PBAs could be sent straight from the previous MAAR to the current MAAR. How does this work if security associations are supposed to be applied? It would seem that, when following the security considerations, such cases are not covered. At least, this would warrant further explanation as in this case we suddenly have three involved security associations, which would also need to be established. G3. Sect 3.5 discusses deregistration and suggests that this can only be done by timeout; I understand the rationale but can any risks arise on continued resource consumption (DoS attacks)? G4. Sect. 6.: As alluded to above, the security considerations may need expanding. Nits: p.12: "information are" -> "information is" p.12: "influence on" -> "influence" From nobody Fri Oct 18 04:12:50 2019 Return-Path: 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 293B5120142 for ; Fri, 18 Oct 2019 04:12:43 -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 0F7PmFq2kFvR for ; Fri, 18 Oct 2019 04:12:40 -0700 (PDT) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (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 3FF36120110 for ; Fri, 18 Oct 2019 04:12:40 -0700 (PDT) Received: by mail-ed1-x52a.google.com with SMTP id f20so4254652edv.8 for ; Fri, 18 Oct 2019 04:12:40 -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=kFke+xMnACHK4gRyehapddZVAaZLJqvaDBZc8OohRMo=; b=sFqsMhqjDOFzOwhutj4blbpv5Wpt2PKOxwO8R18G+Gdov9q14qewEcwXr0daBrCxzm /81019CyIj9i15biclbrddbSCCzMabYw3nSuX3d7qnXXjF9v7YTwjOPNZJLHncIMGvVj FqUWFWBZlJYuflqq9nUDZSOkQ1abnstrjQXVoMlmWirVTMbSTOM15WCAhNAwdg2lDis7 Sc1xrD9HaECPNCmZOIHqffbq5KfkqizCo3maIbCga+oJ4FcJfrVwQYdIvvstsJmoxcF1 NLdxdwB23CacT0HA+klLCDmHgKOC+UdTPL0YgNugHyfi0OCzNcLqs4+RJMsHIa4f/HDO uMQA== 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=kFke+xMnACHK4gRyehapddZVAaZLJqvaDBZc8OohRMo=; b=iqZ1q+Fnu2t/h3TlezOXOKDIFqtG/VdzBuCN53qrnxR5uUxxytAwKne+GLfwf+Vbwv rJwAEOuJk7+GEVSunVY009rSG7snXsv8z9nufsd5I9FyHTiCsw08Lyy2OuVv9fwIJyoH vs0SakEHwKoQxpKSFEUdUZ4bAycGoxYZCqzgRszFiMKzIgw1NG6fzBVpIoJ7SdOtCPGG /Lk4IEGRLgnddCg4+U+1HiDGtxWki/9utxuIxtZoU+HSnsM0dH85DB3mQdRbd67aJxa+ bpppTB8khDkOUaN2eW3yFX5NUPxf9ttcOEIbnIRkIjE9oE23ZDAHaNal7AYwBPsKag2W pXQA== X-Gm-Message-State: APjAAAUIgGVeOVL5YJVSLT2BPyenZyhhGx1M00avM7vWENmT4MqMWERC QMg5AmHxE82lu5iNBokhSAUvCM8/WZVqkF6fpTHj4g== X-Google-Smtp-Source: APXvYqwrQ1Tsllc6ZguvIHVqe8uZVx+viVXd8gBuxAoRdrnXz8kEtu/P6bOyC5lJphtRaug2hhqImhx05DoIwP5p2WA= X-Received: by 2002:a17:906:6ad7:: with SMTP id q23mr7813041ejs.214.1571397158408; Fri, 18 Oct 2019 04:12:38 -0700 (PDT) MIME-Version: 1.0 References: <157100555733.20750.5488529297693995498@ietfa.amsl.com> In-Reply-To: <157100555733.20750.5488529297693995498@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Fri, 18 Oct 2019 13:12:22 +0200 Message-ID: To: Joseph Salowey Cc: secdir@ietf.org, draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, The IESG , dmm Content-Type: multipart/alternative; boundary="0000000000006db02105952d69ef" Archived-At: Subject: Re: [DMM] Secdir 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 11:12:43 -0000 --0000000000006db02105952d69ef Content-Type: text/plain; charset="UTF-8" Dear Joseph, Thanks a lot for the review. We will improve the security consideration section by including also some of the considerations mentioned in draft-ietf -dmm-deployment-models-04, and also by better scoping current text. We believe we don't need much more in terms of text, as the document is informational, and the actual security mechanisms for a distributed anchoring solution would depend on the specifics of that solution. We can also better reflect that rational in the text. Thanks, Carlos On Mon, Oct 14, 2019 at 12:25 AM Joseph Salowey via Datatracker < noreply@ietf.org> wrote: > Reviewer: Joseph Salowey > Review result: Has Issues > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > The summary of the review is the document has issues with the security > considerations section. > > The security consideration section is extremely light. It mainly contains > text > from RFC 7333. It seems that there should be more discussion of security > as it > relates to the different configurations and different cases. Do each of > these > cases have the same security properties and require the same types of > security > controls? > > Are the IPSEC recommendations mentioned in the security considerations of > draft-ietf-dmm-deployment-models-04 applicable for all the cases? Should > these be pointed out in the security considerations section? > > > -- Special Issue "Beyond 5G Evolution": https://www.mdpi.com/journal/electronics/special_issues/beyond_5g --0000000000006db02105952d69ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Joseph,

Thanks a lot for the revie= w. We will improve the security consideration section by including also som= e of the considerations mentioned in=C2=A0draft-ietf-dmm-deployment-models-04, and also by better scoping current text. We believ= e we don't need much more in terms of text, as the document is informat= ional, and the actual security mechanisms for a distributed anchoring solut= ion would depend on the specifics of that solution. We can also better refl= ect that rational in the text.

Thanks,
<= br>
Carlos

On Mon, Oct 14, 2019 at 12:25 AM Joseph Salowey v= ia Datatracker <noreply@ietf.org= > wrote:
Revi= ewer: Joseph Salowey
Review result: Has Issues

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.=C2=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and WG chairs should treat<= br> these comments just like any other last call comments.

The summary of the review is the document has issues with the security
considerations section.

The security consideration section is extremely light.=C2=A0 It mainly cont= ains text
from RFC 7333.=C2=A0 It seems that there should be more discussion of secur= ity as it
relates to the different configurations and different cases.=C2=A0 =C2=A0Do= each of these
cases have the same security properties and require the same types of secur= ity
controls?

Are the IPSEC recommendations mentioned in the security considerations of draft-ietf-dmm-deployment-models-04 applicable for all the cases?=C2=A0 =C2= =A0Should
these be pointed out in the security considerations section?




--
--0000000000006db02105952d69ef-- From nobody Fri Oct 18 04:20:43 2019 Return-Path: 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 ; 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 ; 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 ; Fri, 18 Oct 2019 04:20:28 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id y91so4262659ede.9 for ; 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 Date: Fri, 18 Oct 2019 13:20:10 +0200 Message-ID: To: Yoshifumi Nishida Cc: tsv-art@ietf.org, draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, ietf@ietf.org, dmm Content-Type: multipart/alternative; boundary="00000000000055f83105952d85b3" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2019 11:20:32 -0000 --00000000000055f83105952d85b3 Content-Type: text/plain; charset="UTF-8" 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 --00000000000055f83105952d85b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear=C2=A0Yoshifumi,

T= hanks a lot for the review. Please check inline below for some comments fro= m my side.

On Mon, Oct 14, 2019 at 9:57 AM Yoshifumi Nishida via Datat= racker <noreply@ietf.org> wro= te:
Reviewer: Yo= shifumi Nishida
Review result: Almost Ready

This document has been reviewed as part of the transport area review team&#= 39;s
ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document&= #39;s
authors and WG to allow them to address any issues raised and also to the I= ETF
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.
=C2=A0 =C2=A0For examples, in the figure 3 case, the flow is somehow termin= ated before
=C2=A0 =C2=A0the MN moves and is re-initiated after the movement has finish= ed. However, I
=C2=A0 =C2=A0believe there should be the cases where applications don't= aware of network
=C2=A0 =C2=A0changes and transmit data while migrating, which may cause pac= ket drops,
=C2=A0 =C2=A0delays and timeouts, etc. I think this draft should clarify th= e treatments
=C2=A0 =C2=A0of these cases. Is it out of scope of the draft? Or, do some c= omponents
=C2=A0 =C2=A0generate ICMP messages to give some hints to the applications,= or provide
=C2=A0 =C2=A0buffering features to mitigate the side effects?

[Carlos] I guess you mean Figure 4, right? In that f= igure, we try to explain what would happen if there is no actual mobility s= upport, meaning that a communication flow does not need such mobility suppo= rt. 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 i= tself (no mobility at the IP layer). We don't explicitly mention that s= econd case because it is not in the scope of the draft (IP mobility). We ca= n better clarify the scope in the text.
=C2=A0

2: Page 8:
=C2=A0 =C2=A0"A MN will need to choose which IP prefix/address to use = for each flow
=C2=A0 =C2=A0 according to whether it needs IP mobility support or not.&quo= t;

=C2=A0 =C2=A0 =C2=A0-> It seems to me that the draft implicitly suggests= the use of
=C2=A0 =C2=A0 =C2=A0draft-ietf-dmm-ondemand-mobility here.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If so, I think it would be better to state more= explicitly. Or, do we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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 h= ave another option in mind, but we can leave it open.

<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">
3: Page 10:
=C2=A0 =C2=A0 "the initial anchor remains the anchor and forwards traf= fic"

=C2=A0 =C2=A0 =C2=A0-> could be "anchor remains and the anchor..&qu= ot;?

[Carlos] Maybe "mobility anch= or remains playing that role and forwards traffic"?

Thanks!

Carlos

Thanks,
--
Yoshi



--
--00000000000055f83105952d85b3-- From nobody Fri Oct 18 04:21:43 2019 Return-Path: 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 5211B120C11 for ; Fri, 18 Oct 2019 04:21:42 -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=ham 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 yKFA3O99pXxD for ; Fri, 18 Oct 2019 04:21:40 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 0CDA4120C08 for ; Fri, 18 Oct 2019 04:21:40 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id a15so4276242edt.6 for ; Fri, 18 Oct 2019 04:21:39 -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=ZaVVMeFSJe1J5445EjNGmnL8hEi2+jyaPNF7a8dpk/I=; b=d5wb8QjF+r3NzMF9lL3V6e0bnWEnNuxQwRBFHnetNI2WVHm5POO3YTn3uh4PBj5dO3 Pdzaod0GtyHF7+jA32fev/MWcYFS0Ytq32Od99SQspsfPrtyNBhA0AurU/g+WitUlqx5 DCIU3r1ArVkbAMCXTaPY00BT5mXXS+TPmS4LQSZVKmqJ2AGtSlSwJnE4cJBG10cGX3Fh ZcW7JlWXC8aZXryZVeMcntEK/L8Gqw3AcrY9c3+bUZONI7mJQvTNYYeVyCculUFqif33 i5uO7EzeK5Yu3CFXmWtZ2xRm+HRDqZsXtL2QItt81gbOtS8EjErpy4bubsgqPc874gnL 5zZQ== 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=ZaVVMeFSJe1J5445EjNGmnL8hEi2+jyaPNF7a8dpk/I=; b=RX7MtZzE1+9HWyvJQSoHV1wubE+HAP6XYQB51RlFa/S15WFYm3KaGPDlbwPn6X0qyN QAun3mESnk5QIrtm7NTMcQdsK5/Dfv9KMXTqJNRZicnLpaPoOXmry22gvjiTosuBBT3a F1JN/2jrzdCq3g5RufuonKY4zk0Nx5mAmc+/nf3p06EToMRlXChaXRd3khTSEpwgcSa8 sO83NjjGGFsA1QDwlRIM6ggRuelFNHF3zSmnESS5VO7QoZQh0+LiTKOLT9GgmDqWPvIw szZe+sqhznL3j5N9u+5e38uRR2GqiSeA0Rx8LkvwNhyut5MrLfmKVynbzKa2Ww280/ws ud2w== X-Gm-Message-State: APjAAAUgokZxKyWDr8L5/mK2hBbFDgk6M7Q1mp2/DSW5x60Biz/BY85z Ll6UZafD94jxryMejw/x7K5hYhKZFFWSZKrx7IM7WQ== X-Google-Smtp-Source: APXvYqypRwuExWbepeDreqryOjcsilfV3mwiCWn2/0FR9+BaIzFIHDrQ7+9LYYIsccn9XGMhdvqwDI8rU+6VR0lKbRI= X-Received: by 2002:a50:8f03:: with SMTP id 3mr9208920edy.195.1571397698287; Fri, 18 Oct 2019 04:21:38 -0700 (PDT) MIME-Version: 1.0 References: <157108446243.24779.12043209679040887677@ietfa.amsl.com> In-Reply-To: <157108446243.24779.12043209679040887677@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Fri, 18 Oct 2019 13:21:22 +0200 Message-ID: To: Ines Robles Cc: General Area Review Team , draft-ietf-dmm-pmipv6-dlif.all@ietf.org, ietf@ietf.org, dmm Content-Type: multipart/alternative; boundary="0000000000009b9a1605952d892a" Archived-At: Subject: Re: [DMM] Genart last call review of draft-ietf-dmm-pmipv6-dlif-04 X-BeenThere: dmm@ietf.org 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, 18 Oct 2019 11:21:42 -0000 --0000000000009b9a1605952d892a Content-Type: text/plain; charset="UTF-8" Hi Ines, Thanks for the review. We'll check with IANA folks about how to add more details (whether they do it or we do). Thanks, Carlos On Mon, Oct 14, 2019 at 10:21 PM Ines Robles via Datatracker < noreply@ietf.org> wrote: > Reviewer: Ines Robles > Review result: Ready with Nits > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please treat these comments just > like any other last call comments. > > For more information, please see the FAQ at > > . > > Document: draft-ietf-dmm-pmipv6-dlif-04 > Reviewer: Ines Robles > Review Date: 2019-10-14 > IETF LC End Date: 2019-10-14 > IESG Telechat date: Not scheduled for a telechat > > Summary: > > I believe the draft is technically good. This document is well written. > > The document proposes Distributed Mobility Management for Proxy Mobile > IPv6 in > which mobility sessions are anchored at the last IP hop router called MAAR > (mobility anchor and access router). The document focuses on the required > extensions to effectively support simultaneously anchoring several flows at > different distributed gateways. > > I have a minor concern detailed in Nits section. > > Major issues:Not Issues found > > Minor issues: Not Issues found > > Nits/editorial comments: > > It would be nice to specify IANA Section with more details, such as > indicating > the registry which the option type belong, etc. [rfc8126] > > Thank you for this document, > > Ines. > > > -- Special Issue "Beyond 5G Evolution": https://www.mdpi.com/journal/electronics/special_issues/beyond_5g --0000000000009b9a1605952d892a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ines,

Thanks for the review. We'= ll check with IANA folks about how to add more details (whether they do it = or we do).

Thanks,

Carlos=

On Mon, Oct 14, 2019 at 10:21 PM Ines Robles via Datatracker <noreply@ietf.org> wrote:
Reviewer: Ines Robles
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.=C2=A0 Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq&g= t;.

Document: draft-ietf-dmm-pmipv6-dlif-04
Reviewer: Ines Robles
Review Date: 2019-10-14
IETF LC End Date: 2019-10-14
IESG Telechat date: Not scheduled for a telechat

Summary:

I believe the draft is technically good. This document is well written.

The document proposes Distributed Mobility Management for Proxy Mobile IPv6= in
which mobility sessions are anchored at the last IP hop router called MAAR<= br> (mobility anchor and access router). The document focuses on the required extensions to effectively support simultaneously anchoring several flows at=
different distributed gateways.

I have a minor concern detailed in Nits section.

Major issues:Not Issues found

Minor issues: Not Issues found

Nits/editorial comments:

It would be nice to specify IANA Section with more details, such as indicat= ing
the registry which the option type belong, etc. [rfc8126]

Thank you for this document,

Ines.




--
--0000000000009b9a1605952d892a-- From nobody Fri Oct 18 04:24:43 2019 Return-Path: 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 D012E120BE6 for ; Fri, 18 Oct 2019 04:24:30 -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 DGElgii2ifB1 for ; Fri, 18 Oct 2019 04:24:26 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 100C2120C0D for ; Fri, 18 Oct 2019 04:24:26 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id f20so4278085edv.8 for ; Fri, 18 Oct 2019 04:24:25 -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=D6dfZgRiPvICC3k64jiOVzv8fCBiufwvTQmJ1mkvIoA=; b=rn/aSsPbw8lokV8avqlDNWwipUmhCCNhHs9EnzgTlZMz8qeSy4EZp/pW6ZeDJlSqTA a0BcTtd0RBxwRwP+pqysbaK8Il5t75sUNAKF3mTFLhX4CnFF8DcYpgopkY7N/fT2K08E L8tpFXdGtl4d92g1u56zxofbCJcfP30PR0gT/UowGXtLZ1rAPUwjnorsKkj9gq5D2JBf eo6BnJX8m0s3Y07kFk12CPgl4uGo8izArpTXyBobJ7oybRbZ7OY9N0m+S/NeLWiKhj39 YQ6moPQFbLr3rE1hj+v38D5BMmvC6WuUL+4OXnzJs5rUX6eEDRJxr0rgOEzT7rFJlL/I 2uMA== 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=D6dfZgRiPvICC3k64jiOVzv8fCBiufwvTQmJ1mkvIoA=; b=oTaxT17NRaqKWvAcpv7ZgFbJ75awV9jlPXvXvVU5k3scnCzBtjJvy/XJ2I+yG8Uhl1 MDnbUsGxpyttc8+tNpDqoGZ8ndW0SIPKyqeujvgVd5mMVxwLfiXuZF1ZE2O6Nh2yq7Na 5+1CJ0HoxCqN1LzfRbCq0wsD6hXPejWYcuVRLWI52QDI0tg0p8COu5VMG57/p8iftns7 iIrhi56PooEb8wTKvn1or4ThWRhzVzkWN2yueFfQaJU+9bRDz6/2p3oekWUzKApyR6Lz N2GdPhrLb14fIhZYl/UxD2E8fUftBrJXSSJ0BPWd/0Td4GWtU6k6sEF7ClhwrfpqyxtL trGw== X-Gm-Message-State: APjAAAWFt7PP8j5nQhbOenmftS4H6eNqv9XbHr9NjcGArUv85IACykkV u5NZpU+UXhpP9DsBUTCousuM/Rpm57aYDP06W1dnGg== X-Google-Smtp-Source: APXvYqxPjeeCXe6famlnxfBUyyPuBypgPWbzWQ5bPJ+Lpm0CSr257meya8cDnOs1n72vctD1qHfbmzYP29hg/N3ocqI= X-Received: by 2002:a17:906:8308:: with SMTP id j8mr8191530ejx.29.1571397864293; Fri, 18 Oct 2019 04:24:24 -0700 (PDT) MIME-Version: 1.0 References: <157108615425.24656.12786623966649135975@ietfa.amsl.com> In-Reply-To: <157108615425.24656.12786623966649135975@ietfa.amsl.com> From: CARLOS JESUS BERNARDOS CANO Date: Fri, 18 Oct 2019 13:24:08 +0200 Message-ID: To: Joerg Ott Cc: tsv-art@ietf.org, draft-ietf-dmm-pmipv6-dlif.all@ietf.org, ietf@ietf.org, dmm Content-Type: multipart/alternative; boundary="000000000000809ff305952d93bf" Archived-At: Subject: Re: [DMM] Tsvart last call review of draft-ietf-dmm-pmipv6-dlif-04 X-BeenThere: dmm@ietf.org 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, 18 Oct 2019 11:24:31 -0000 --000000000000809ff305952d93bf Content-Type: text/plain; charset="UTF-8" Thanks a lot Joerg for your very comprehensive review. We will carefully look at your comments and provide responses (with proposals of text changes) in the next few days. I prefer to take some time to properly address all your points. Thanks! Carlos On Mon, Oct 14, 2019 at 10:49 PM Joerg Ott via Datatracker wrote: > Reviewer: Joerg Ott > Review result: Ready with Issues > > Hi, > > 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. > > The draft defines extensions to Proxy Mobile IPv6 to support a more > distributed > variant of mobility management. In essence, as a mobile node moves from one > point of attachment (Mobility Anchor and Access Router, MAAR) to the next, > its routing prefix with the previous MAAR(s) remain(s) and ongoing > transport > layer connections remain active and routed indirectly via the previous > MAAR, > while new ones will use the present MAAR. The interactions of MAARs are > managed via a Central Mobility Database (CMD). > > The draft is well written and good to follow, describing the protocols and > extensions clearly. I just have two transport-specific concern and two > general > operational issues that require further clarification in the draft. > > The transport issues: > > T1. Section 3.2. When the CMD acts as a relay for Proxy Binding Updates > (PBUs) > and Proxy Binding Acts (PBAs), the CMD may act as a relay of a single PBU > to > multiple previous MAARs. If multiple previous MAARs exist, say k, (and > there > may be numerous in case of many fast handovers, e.g., with vehicular > networks), > the CMD creates k outgoing packets from a single incoming packet. This > bears > a certain amplification risk (which may also need to be addressed in the > security > considerations section) but it also may lead to packet bursts originated > from the > CMD, albeit to different targets. Other protocols start introducing pacing > to avoid > bursts on the outgoing link, even if the packets do take different paths > in the end. > This may be worthwhile considering. > > T2. Also in section 3.2, when relaying PBAs, the CMD serves as a transport > or > application endpoint and should have a way to deal with missing responses > (after all, this is a connectionless protocol on top of an unreliable > Internet). > A timeout is only mentioned for aggregation, but even there there the > timeout > is not specified, nor is a reference to, e.g., RFC 5213 or so to infer a > timeout > used elsewhere. > > General issues: > > G1. Section 3.2 (again) specifies that responses are aggregated on p.10. > How > does response aggregation work? How is error handling done? > > Moreover, also on p.10, further below the draft states that if a timer > expires, > the requests already received are forwarded. The missing ones come later. > This seems to contradict aggregation because the originator (the currently > server MAAR) does not expect more than a single response if it sent out a > single update. This may thus require updated processing in the MAAR. > > G2. Sect. 3.3 suggests that PBAs could be sent straight from the previous > MAAR > to the current MAAR. How does this work if security associations are > supposed > to be applied? It would seem that, when following the security > considerations, > such cases are not covered. At least, this would warrant further > explanation as > in this case we suddenly have three involved security associations, which > would > also need to be established. > > G3. Sect 3.5 discusses deregistration and suggests that this can only be > done by > timeout; I understand the rationale but can any risks arise on continued > resource > consumption (DoS attacks)? > > G4. Sect. 6.: As alluded to above, the security considerations may need > expanding. > > Nits: > p.12: "information are" -> "information is" > p.12: "influence on" -> "influence" > > -- Special Issue "Beyond 5G Evolution": https://www.mdpi.com/journal/electronics/special_issues/beyond_5g --000000000000809ff305952d93bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks a lot Joerg for your very comprehensive review.
We will carefully look at your comments and provide respons= es (with proposals of text changes) in the next few days. I prefer to take = some time to properly address all your points.

Tha= nks!

Carlos

On Mon, Oct 14, 2019 at 10:49 PM = Joerg Ott via Datatracker <noreply@i= etf.org> wrote:
Reviewer: Joerg Ott
Review result: Ready with Issues

Hi,

this document has been reviewed as part of the transport area review team&#= 39;s
ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document&= #39;s
authors and WG to allow them to address any issues raised and also to the I= ETF
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.

The draft defines extensions to Proxy Mobile IPv6 to support a more distrib= uted
variant of mobility management. In essence, as a mobile node moves from one=
point of attachment (Mobility Anchor and Access Router, MAAR) to the next,<= br> its routing prefix with the previous MAAR(s) remain(s) and ongoing transpor= t
layer connections remain active and routed indirectly via the previous MAAR= ,
while new ones will use the present MAAR. The interactions of MAARs are
managed via a Central Mobility Database (CMD).

The draft is well written and good to follow, describing the protocols and<= br> extensions clearly. I just have two transport-specific concern and two gene= ral
operational issues that require further clarification in the draft.

The transport issues:

T1. Section 3.2. When the CMD acts as a relay for Proxy Binding Updates (PB= Us)
and Proxy Binding Acts (PBAs), the CMD may act as a relay of a single PBU t= o
multiple previous MAARs. If multiple previous MAARs exist, say k, (and ther= e
may be numerous in case of many fast handovers, e.g., with vehicular networ= ks),
the CMD creates k outgoing packets from a single incoming packet. This bear= s
a certain amplification risk (which may also need to be addressed in the se= curity
considerations section) but it also may lead to packet bursts originated fr= om the
CMD, albeit to different targets. Other protocols start introducing pacing = to avoid
bursts on the outgoing link, even if the packets do take different paths in= the end.
This may be worthwhile considering.

T2. Also in section 3.2, when relaying PBAs, the CMD serves as a transport = or
application endpoint and should have a way to deal with missing responses (after all, this is a connectionless protocol on top of an unreliable Inter= net).
A timeout is only mentioned for aggregation, but even there there the timeo= ut
is not specified, nor is a reference to, e.g., RFC 5213 or so to infer a ti= meout
used elsewhere.

General issues:

G1. Section 3.2 (again) specifies that responses are aggregated on p.10. Ho= w
does response aggregation work? How is error handling done?

Moreover, also on p.10, further below the draft states that if a timer expi= res,
the requests already received are forwarded. The missing ones come later. This seems to contradict aggregation because the originator (the currently<= br> server MAAR) does not expect more than a single response if it sent out a single update. This may thus require updated processing in the MAAR.

G2. Sect. 3.3 suggests that PBAs could be sent straight from the previous M= AAR
to the current MAAR. How does this work if security associations are suppos= ed
to be applied? It would seem that, when following the security consideratio= ns,
such cases are not covered. At least, this would warrant further explanatio= n as
in this case we suddenly have three involved security associations, which w= ould
also need to be established.

G3. Sect 3.5 discusses deregistration and suggests that this can only be do= ne by
timeout; I understand the rationale but can any risks arise on continued re= source
consumption (DoS attacks)?

G4. Sect. 6.: As alluded to above, the security considerations may need exp= anding.

Nits:
p.12: "information are" -> "information is"
p.12: "influence on" -> "influence"



--
--000000000000809ff305952d93bf-- From nobody Mon Oct 21 05:47:09 2019 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BFE12013B; Mon, 21 Oct 2019 05:47:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Vincent Roca via Datatracker To: Cc: draft-ietf-dmm-pmipv6-dlif.all@ietf.org, ietf@ietf.org, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.106.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Vincent Roca Message-ID: <157166202760.31949.6972305880517491481@ietfa.amsl.com> Date: Mon, 21 Oct 2019 05:47:07 -0700 Archived-At: Subject: [DMM] Secdir last call review of draft-ietf-dmm-pmipv6-dlif-04 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2019 12:47:08 -0000 Reviewer: Vincent Roca Review result: Has Nits Hello, I have reviewed this document as part of the security directorate’s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: Almost ready / has nits RFC4832 is a nice document that explains in detail security threats for the class of mobility management protocol PMIPv6 belongs to. It is referenced by RFC5213 which itself is referenced by the current document. Therefore I think that an interested reader can find the requiered information. However, the small text of section 6 that refers to RFC5213 and updates a few sentences to apply RFC5213 recommendations to MAARs, is misleading in my opinion. It suggests there is a single threat, the impersonation of a MAAR, and since using IPsec eliminates this threat, a reader can easily conclude there's nothing else. But what about the other benefits of using IPsec? Is the use of IPsec only for endpoint authentication (what I understand)? What about anti-replay, integrity, confidentiality? Is it meaningless in the present context? By the way, what is the attacker model? The subject is too complex, the risks are too varied, and I don't like this way of presenting things that overly simplifies the problems. Clarification on a different topic: This is a detail, but the document refers to the S-MAAR's global address or P-MAAR's global address as if there was a necessarily a single address. What happens if a MAAR has multiple global addresses? It may happen with a router that is multiply connected to the Internet. Cheers. Vincent From nobody Mon Oct 21 20:07:43 2019 Return-Path: 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 575E812004F for ; Mon, 21 Oct 2019 20:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 R8IPFQaJspK7 for ; Mon, 21 Oct 2019 20:07:40 -0700 (PDT) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 6DDA612000F for ; Mon, 21 Oct 2019 20:07:40 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id y5so9701015pfo.4 for ; Mon, 21 Oct 2019 20:07:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=content-transfer-encoding:from:mime-version:subject:message-id:date :to; bh=L4xxw+uXBx6j8V8uAdyjN/W+x/s42u/pPOtAJ87FF+k=; b=G4ijmyYhII/NCC/g0cFAam+BobY8wbEuAllX48cegyZIYhlCSCeTruGPfh/ynA5muQ kN2V5ccP77qfCKmMJ8479IilgyxKQXpOkuNPLiAQBp6Y/g71wmLRoM0MruVvTu2Gi8yR ObPZPkn0rvMi4d2gB+OEyLd/L3bCWTPqMTRVEhtg21D4tfDWkRsM33A0giOFxc75y4M0 FaMH7F9UVwrmVHg9UEhR7cSHZQ9OT7Dxz638gReYs5lsOVY+/a16mAzl9qhh5m1vhxMG 2i3p2OV3/aY+Phqj46i8kXHZjNwvn2qiUFcX4AV+psctyQg4uffvt4j5dvY+GNn67Ab4 iynA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:message-id:date:to; bh=L4xxw+uXBx6j8V8uAdyjN/W+x/s42u/pPOtAJ87FF+k=; b=O1lipf5v5enKW2BUGaciXdp/ZGIsA54qbdZGGbz9CZgW1eAh9VmkHYSLA6JpuE6LSA szRwoqiuMg0bqy4BzV50FuerTo9QhSPv4//IvUUJ5STZWKd1Xcfej7Yo1sK0alK3sJIG hx7nOoaJyjkCpdBDq2DYbC+1FeSz7DGrnNaNFXl5CLWQJbM3X8GQNFFVsMxvCD7ouz6b DS1iEaBwpj8M2/Uboz5bTqystq6/kuj813BtUVMmqWK/oXVE5IaAQN6m2iWkPFgAmnhq dc2fdt18ZVtk53etky0o6GHc8VbFUWDEGz4JMmUYMndtyFHqzlvdH/wLv/lkXK992NSr +F5w== X-Gm-Message-State: APjAAAWPx9yT8mspw5gZ7CBa3nhjPlO1DhRPavENtjpIS5ndlKrvA0lu HVYWRm+cun9AJPD3L+kNB0f3nUPK X-Google-Smtp-Source: APXvYqywsNODnQHm9FO7kmvHDXwA2jpKZn9vudvr4GhxpoBV/RPruvglCu5oH5XStzHBTXHpBKY64g== X-Received: by 2002:aa7:8a84:: with SMTP id a4mr81964pfc.99.1571713659320; Mon, 21 Oct 2019 20:07:39 -0700 (PDT) Received: from ?IPv6:2400:2411:8900:0:956b:7f8f:c17:2365? ([2400:2411:8900:0:956b:7f8f:c17:2365]) by smtp.gmail.com with ESMTPSA id y9sm15851888pgq.11.2019.10.21.20.07.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 21 Oct 2019 20:07:38 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-35E49C61-7AC1-4442-B69D-07C2C5ED6689 Content-Transfer-Encoding: 7bit From: Satoru Matsushima Mime-Version: 1.0 (1.0) Message-Id: <49BD327C-5377-4166-BC7C-9F5FBA7FD4E3@gmail.com> Date: Tue, 22 Oct 2019 12:07:37 +0900 To: dmm X-Mailer: iPad Mail (17A878) Archived-At: Subject: [DMM] IETF106 - Call for Agenda Items X-BeenThere: dmm@ietf.org 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: Tue, 22 Oct 2019 03:07:42 -0000 --Apple-Mail-35E49C61-7AC1-4442-B69D-07C2C5ED6689 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Folks, The DMM chairs are planning the dmm meeting in Singapore at IETF106: 18th November, Monday Afternoon Session II (15:50-17:50) If you have a draft or any topics you would like to discuss, please send you= r request for agenda time to the dmm chairs. Please include the information i= n the request as following: The title of the presentation: Presenter name: Time you need: Draft reference:=20 Please have agenda items to us by 2019-11-04 (November 4th). Reminder: The draft cut-off date: 14th November UTC 23:59 (2 weeks before the meeting)= . Dapeng & Sri & Satoru --Apple-Mail-35E49C61-7AC1-4442-B69D-07C2C5ED6689 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Folks,

<= span style=3D"-webkit-text-size-adjust: auto;">The DMM chairs are planning t= he dmm meeting in Singapore at IETF106:

18th November, Monday Afternoon Session II (15:50-17:50)=

If you have a draft or any topics you would like to disc= uss, please send your request for agenda time to the dmm chairs. Please incl= ude the information in the request as following:

The title of the prese= ntation:
Presenter name:
Time you need:
Draft reference: 

Please have agend= a items to us by 2019-11-04 (November 4th).

Reminder:
The draft cut-off date: 14th November UTC 23:59 (2 weeks before the meeting).

Dapeng & Sri & Satoru
= --Apple-Mail-35E49C61-7AC1-4442-B69D-07C2C5ED6689-- From nobody Tue Oct 22 19:49:19 2019 Return-Path: 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 2E59E12006D for ; Tue, 22 Oct 2019 19:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 bqc5GJTlvBnf for ; Tue, 22 Oct 2019 19:49:16 -0700 (PDT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 AAD2B120048 for ; Tue, 22 Oct 2019 19:49:16 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id q7so11920402pfh.8 for ; Tue, 22 Oct 2019 19:49:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=aOBhkW0g+te4ux/p5C42XRrWU03BQLMLHQdkrcawuTo=; b=c5h2MePLF2vZnelNNuEpLi1Rwb6ByTt+Ybx4OjZPTKFKyaA+8HFgK+W/uBmZG/uy8h 4XJCBAXPfUqYzJRz5c+HjhU5ZyGM7Wp3bXGRxfObOycQeTrhfNHvPgLrJn5X6MsmmWz8 5y3XeVZXhe7SozPcXyu0UA4Kw2fvTXZsNlrYrWmZy4U6ZDOHdX66ULdqi1mawWnLhuR5 UBw4aCsPcQBAT+C0hM6ivi5dViX0leln6FKXgFgmNLwYxAMnT0v1/U8koE+KHbkW8sFk /QuliMXZmS3Gahu0RxqYxVMQJsTJpz7y3PQ5yAWCtuG9PEDsrOLSIlUUcRIjX+E1WXfA U8jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=aOBhkW0g+te4ux/p5C42XRrWU03BQLMLHQdkrcawuTo=; b=HNud0rWZZi8UzgvBLQUdeFxJaWzUEN103L189foQfmJCWlNQ33IuI6/dA18QEVfgGk DOaUF7HFJrFknfmkWSljamW5YHp3dNrU0iSv+bewZKgaYNvyRtVSUgSqr+0Y+aJSkVn1 c+zCxrzvtyDF0RqeybE0S8zGIP3aI75ngHr78Ing6s9HIQq6mfv9cTRWeRPhilr8QU98 s0nHW3MpLTUdK8E7y4KNsA8k1H2drxVK0KfeJ2hJKrHHyqNbf20UXDV+iGBHR0+kwTVP fyyZBXA6PpF7fZyPwb0Wvx64HINbfKnnCuuteb/F020m8LVAHlchy8NTqK52rDNJOAwg k8iA== X-Gm-Message-State: APjAAAUxSVvVllElW2kYs+GEUeSMKgbf+QPpNJiqhPx0KjkpZv0g6KJw /8YIMZyA8mmYWWcbvyBYfiGQaiYT X-Google-Smtp-Source: APXvYqzSXyUVxa9CaPp8WM9DphFzeo9zkoOEoTUIoAo2ZgL0ZE7KdhIorH7Pq3SYw8SsbA8HIk0Pdw== X-Received: by 2002:a62:ae0d:: with SMTP id q13mr7951615pff.53.1571798955468; Tue, 22 Oct 2019 19:49:15 -0700 (PDT) Received: from [10.207.114.61] ([202.45.12.164]) by smtp.gmail.com with ESMTPSA id g187sm13482194pgc.12.2019.10.22.19.49.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Oct 2019 19:49:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3594.4.19\)) From: Satoru Matsushima In-Reply-To: <49BD327C-5377-4166-BC7C-9F5FBA7FD4E3@gmail.com> Date: Wed, 23 Oct 2019 11:49:12 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <602C6C0B-B325-440D-BFA1-609B9A7F6EF1@gmail.com> References: <49BD327C-5377-4166-BC7C-9F5FBA7FD4E3@gmail.com> To: dmm X-Mailer: Apple Mail (2.3594.4.19) Archived-At: Subject: Re: [DMM] IETF106 - Call for Agenda Items X-BeenThere: dmm@ietf.org 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: Wed, 23 Oct 2019 02:49:18 -0000 One correction for a typo: > Reminder: > The draft cut-off date: 4th November UTC 23:59 (2 weeks before the = meeting). Regards, --satoru > 2019/10/22 12:07=E3=80=81Satoru Matsushima = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB: >=20 > Folks, >=20 > The DMM chairs are planning the dmm meeting in Singapore at IETF106: >=20 > 18th November, Monday Afternoon Session II (15:50-17:50) >=20 > If you have a draft or any topics you would like to discuss, please = send your request for agenda time to the dmm chairs. Please include the = information in the request as following: >=20 > The title of the presentation: > Presenter name: > Time you need: > Draft reference:=20 >=20 > Please have agenda items to us by 2019-11-04 (November 4th). >=20 > Reminder: > The draft cut-off date: 14th November UTC 23:59 (2 weeks before the = meeting). >=20 > Dapeng & Sri & Satoru From nobody Thu Oct 24 00:38:15 2019 Return-Path: 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 937D2120814; Thu, 24 Oct 2019 00:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: 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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4DPlcYKPFPCn; Thu, 24 Oct 2019 00:38:10 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 02B2612000F; Thu, 24 Oct 2019 00:38:10 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id q13so19864143wrs.12; Thu, 24 Oct 2019 00:38:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <157103982375.24746.491736148532050112@ietfa.amsl.com> In-Reply-To: From: Yoshifumi Nishida Date: Thu, 24 Oct 2019 00:37:56 -0700 Message-ID: To: CARLOS JESUS BERNARDOS CANO Cc: tsv-art@ietf.org, draft-ietf-dmm-distributed-mobility-anchoring.all@ietf.org, ietf@ietf.org, 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-BeenThere: dmm@ietf.org 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 --0000000000005dfbb30595a31d8b Content-Type: text/plain; charset="UTF-8" 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 < > 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 --0000000000005dfbb30595a31d8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Carlos,=C2=A0
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=C2=A0Yoshifu= mi,

Thanks a lot for the review. Please check inline bel= ow for some comments from my side.

On Mon, Oct 14, 2019 at 9:57 AM Yos= hifumi 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&#= 39;s
ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document&= #39;s
authors and WG to allow them to address any issues raised and also to the I= ETF
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.
=C2=A0 =C2=A0For examples, in the figure 3 case, the flow is somehow termin= ated before
=C2=A0 =C2=A0the MN moves and is re-initiated after the movement has finish= ed. However, I
=C2=A0 =C2=A0believe there should be the cases where applications don't= aware of network
=C2=A0 =C2=A0changes and transmit data while migrating, which may cause pac= ket drops,
=C2=A0 =C2=A0delays and timeouts, etc. I think this draft should clarify th= e treatments
=C2=A0 =C2=A0of these cases. Is it out of scope of the draft? Or, do some c= omponents
=C2=A0 =C2=A0generate ICMP messages to give some hints to the applications,= or provide
=C2=A0 =C2=A0buffering features to mitigate the side effects?

[Carlos] I guess you mean Figure 4, right? In that f= igure, we try to explain what would happen if there is no actual mobility s= upport, meaning that a communication flow does not need such mobility suppo= rt. 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 i= tself (no mobility at the IP layer). We don't explicitly mention that s= econd case because it is not in the scope of the draft (IP mobility). We ca= n better clarify the scope in the text.
=
Sorry for confusion. Yes, t= he data flow is explained in Figure 4.=C2=A0
What I wanted to mention was how the flow can stop it w= ithout 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 tha= t in some cases, the flow may not able to stop before the movement.=C2=A0
I am guessing this case wo= uld be a major case than the case described in the draft.
= Or, is there any available approach here?<= /font>
=C2=A0

2: Page 8:
=C2=A0 =C2=A0"A MN will need to choose which IP prefix/address to use = for each flow
=C2=A0 =C2=A0 according to whether it needs IP mobility support or not.&quo= t;

=C2=A0 =C2=A0 =C2=A0-> It seems to me that the draft implicitly suggests= the use of
=C2=A0 =C2=A0 =C2=A0draft-ietf-dmm-ondemand-mobility here.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 If so, I think it would be better to state more= explicitly. Or, do we
=C2=A0 =C2=A0 =C2=A0 =C2=A0 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 h= ave another option in mind, but we can leave it open.

Yes, referring as an example is fine. I just t= hought if this approach can be used, then it might be better to explain it = explicitly. =C2=A0
<= div dir=3D"ltr">


3: Page 10:
=C2=A0 =C2=A0 "the initial anchor remains the anchor and forwards traf= fic"

=C2=A0 =C2=A0 =C2=A0-> could be "anchor remains and the anchor..&qu= ot;?

[Carlos] Maybe "mobility anch= or remains playing that role and forwards traffic"?
<= /blockquote>

Works for me. Thanks!
--
Yoshi=C2=A0
--0000000000005dfbb30595a31d8b-- From nobody Fri Oct 25 14:18:05 2019 Return-Path: X-Original-To: dmm@ietf.org Delivered-To: dmm@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61568120A40; Fri, 25 Oct 2019 14:12:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: suresh@kaloom.com, dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.108.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157203793438.2724.6757222191405052130.idtracker@ietfa.amsl.com> Date: Fri, 25 Oct 2019 14:12:14 -0700 Archived-At: Subject: [DMM] dmm - Requested session has been scheduled for IETF 106 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.29 List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Oct 2019 21:13:11 -0000 Dear Sri Gundavelli, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dmm Session 1 (2:00 requested) Monday, 18 November 2019, Afternoon Session II 1550-1750 Room Name: VIP A size: 100 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/106/sessions/dmm.ics Request Information: --------------------------------------------------------- Working Group Name: Distributed Mobility Management Area Name: Internet Area Session Requester: Sri Gundavelli Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 45 Conflicts to Avoid: Chair Conflict: ipwave People who must be present: Sri Gundavelli Suresh Krishnan Dapeng Liu Satoru Matsushima Resources Requested: Special Requests: Prefer Monday session, or earliest possible day in the week. --------------------------------------------------------- From nobody Thu Oct 31 21:39:40 2019 Return-Path: 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 E8EA41208A5; Thu, 31 Oct 2019 21:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 WRsIvkxIICWU; Thu, 31 Oct 2019 21:39:32 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43C812085A; Thu, 31 Oct 2019 21:39:32 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8F4ACF406D7; Thu, 31 Oct 2019 21:39:22 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, dmm@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20191101043922.8F4ACF406D7@rfc-editor.org> Date: Thu, 31 Oct 2019 21:39:22 -0700 (PDT) Archived-At: Subject: [DMM] =?utf-8?q?RFC_8653_on_On-Demand_Mobility_Management?= X-BeenThere: dmm@ietf.org 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 04:39:38 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8653 Title: On-Demand Mobility Management Author: A. Yegin, D. Moses, S. Jeon Status: Informational Stream: IETF Date: October 2019 Mailbox: alper.yegin@actility.com, danny.moses@intel.com, seiljeon.ietf@gmail.com Pages: 12 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dmm-ondemand-mobility-18.txt URL: https://www.rfc-editor.org/info/rfc8653 DOI: 10.17487/RFC8653 Applications differ with respect to whether they need session continuity and/or IP address reachability. The network providing the same type of service to any mobile host and any application running on the host yields inefficiencies, as described in RFC 7333. This document defines a new concept of enabling applications to influence the network's mobility services (session continuity and/or IP address reachability) on a per-socket basis, and suggests extensions to the networking stack's API to accommodate this concept. This document is a product of the Distributed Mobility Management Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC