Re: [DMM] Éric Vyncke's Discuss on draft-ietf-dmm-pmipv6-dlif-05: (with DISCUSS and COMMENT)
CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Sun, 08 March 2020 12:09 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 875913A041E for <dmm@ietfa.amsl.com>; Sun, 8 Mar 2020 05:09:39 -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, 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 W7xOPiS963ZO for <dmm@ietfa.amsl.com>; Sun, 8 Mar 2020 05:09:35 -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 B40DA3A044F for <dmm@ietf.org>; Sun, 8 Mar 2020 05:09:34 -0700 (PDT)
Received: by mail-ed1-x52a.google.com with SMTP id b23so555742edx.4 for <dmm@ietf.org>; Sun, 08 Mar 2020 05:09:34 -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=m3AHJXOsd4q2p/q2bdzgGHEKM16dqWxYE6Vlq2qcm9Y=; b=Da3WhOSwTuTX8etpfozCkm/T+HR5XZ3wuQmYOaMTIQ6iLl0IcLU9cCy6HC9aT81n3p L3uMDjkvyKbc10QBJtsRwX8In4tPWWaHFEP5iBtifIOAJoL/NQs5T3XRY0QCF+hA8qWy kQEwOsLN8Cmo1Kz77o4jS1Qv1U4FcdkpjleYO8wqOwDxwVuEJqNi8dnhBGwuePWHSx7G Pfn7bRuLdpYSsI+20mJEAm7TzF+xX9hxwLUfMu3vQIzxvFfYuqypbA+ffqhlJ7A6PIPl a7befyI0fvRBbIZg5F65XF3CMV5Pjs/pV/oSM7SCuGWXBStYF1S3axOZAYxMmIMjs+28 rqXA==
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=m3AHJXOsd4q2p/q2bdzgGHEKM16dqWxYE6Vlq2qcm9Y=; b=FW2N5vUkDj+H5ng1aAUVnDeCrxNGuSKDiGDX82l25y4AetvoylJmCv3zB35+CNEsnR TdSjg6m9MUUsataemyzckHyRfsagBIo6+3LPm74PS56TPCX8QoFEX1XKGXqtnrmAXO7y l3Zz09s75YOOCKsdjujWIzyVsUEyeXlv8IJ5ZrtBsV2iRl9tjhLlxLFv9zL0fmqDnybx Q2y6RbS1LtwJdEyWqieo0/USwNREHiSjEfW99Iw8LRULdeQBHZ0mRvH0xby6zYfVr/NZ E3hcPaWLNvC9s9jsd7kUFP1SuMcBZ62WTcr0Cxk1GZ75199D56mu+6Vvyk7MBPT4Ur8R 9FRg==
X-Gm-Message-State: ANhLgQ23kjI0CvUX1E2Kvmx+MByUXunuMQpqoUwOs5zX25BzjXUg0s9z 8A7P7yMsF1PcdJjBRwXjkfwiZ+KKQ9YK7LhYMH4qhA==
X-Google-Smtp-Source: ADFU+vtKUKu2BOVZyCNvCTLdAsDwMRJIj7kAKAQ3ixYZcq/I2meD+KdYaqs2s5WuHvxofpQpUx6LKN0EIfXMlbD0Drw=
X-Received: by 2002:aa7:dd1a:: with SMTP id i26mr12314205edv.321.1583669372810; Sun, 08 Mar 2020 05:09:32 -0700 (PDT)
MIME-Version: 1.0
References: <158318249840.27483.9051628354202166127@ietfa.amsl.com>
In-Reply-To: <158318249840.27483.9051628354202166127@ietfa.amsl.com>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Sun, 08 Mar 2020 13:09:16 +0100
Message-ID: <CALypLp_E4PHkPTTj8vN3jEFAcD1Yhk4EVpsnW7e9xd=OP1Dbww@mail.gmail.com>
To: Éric Vyncke <evyncke@cisco.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dmm-pmipv6-dlif@ietf.org, dmm-chairs <dmm-chairs@ietf.org>, dmm <dmm@ietf.org>, Dapeng Liu <max.ldp@alibaba-inc.com>, Carlos Pignataro <cpignata@cisco.com>
Content-Type: multipart/alternative; boundary="00000000000068a1e505a056c212"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/R2uR-Ra7g-JrNbe9M4pbEqLE_0M>
Subject: Re: [DMM] Éric Vyncke's Discuss on draft-ietf-dmm-pmipv6-dlif-05: (with DISCUSS and COMMENT)
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: Sun, 08 Mar 2020 12:09:40 -0000
Hi Éric, Thanks a lot for your review. Please see inline below my comments. On Mon, Mar 2, 2020 at 9:55 PM Éric Vyncke via Datatracker <noreply@ietf.org> wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-dmm-pmipv6-dlif-05: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dmm-pmipv6-dlif/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > Thank you for the work put into this document. And congratulations for the > many > advanced ASCII art ! Except for section 3.6, the text is really easy to > read. > > I have a block DISCUSS below but it should be trivial to fix. > > Please also address the points raised by Carlos during the INT directorate > review. Thank you again Carlos ! > > https://datatracker.ietf.org/doc/review-ietf-dmm-pmipv6-dlif-05-intdir-telechat-pignataro-2020-02-28/ > > I hope that this helps to improve the document, > [CB] Thanks. I've addressed the comments from Carlos in version -06 (to be submitted soon). > > Regards, > > -éric > > == DISCUSS == > > -- Section 4.3 & 4.4 & 4.5 -- > Probably trivial to fix but is "Prefix Length" expressed in bits (/64) or > in > bytes (8 bytes). If the latter, then how can we have a prefix of /57 ? The > definition of the "Prefix length" field should be specific about the unit > (bits/bytes) and be aligned with the definition of "Anchored prefix" (as > this > one seems to assert that the prefix length must be a multiple of 8). > > [CB] The prefix length is expressed in bits. I've clarified this in the text. I've also fixed this in the "Anchored prefix" definition. > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > == COMMENTS == > > A generic question, can a MN be attached to multiple MAAR at the same time? > I.e., once over WiFi and once of 3GPP ? There seems to be only one S-MAAR > at > any time. > [CB] The document assumes only S-MAAR at a time. Adding support for multiple S-MAARs at the same time could be feasible, but it'd add complexity. IMHO it's better to see the potential adoption of this solution and gain from implementation experience before going into adding support for multiple S-MAARs. > > -- Section 3.1 -- > Should the length of the prefix assigned to the MN be specified? Adding a > /64 > would make things clearer without using too much of text. > [CB] I agree it could be added and be helpful, but since the message options defined could support other prefix lengths (though I agree /64 would be one most of the times), using /64 in Section 3.1 could lead to assume that only that prefix length is valid. But if you think it's better to add it, I can do it (I don't have a strong opinion against). > For my own curiosity, the text is about "IPv6 global prefix", but, would > ULA > also work ? > [CB] I think it would as well. I always tend to think that mobility solutions only make sense in global scenarios, but there is nothing preventing it to use the mechanisms with ULA. I also tried to follow as much as possible RFC 5213 terminology and there "global" is used. I've kept the "global" for the time being, but it can be removed. > -- Section 3.6 -- > This section is so different than the previous ones in section 3, that I > would > have created a section on its own. > [CB] I agree section 3.6 (which is section 3.7 in version -06) is different from the other 3.x, but it is about PMIPv6 DMM extensions, and that's why I believe it belongs to Section 3. Creating a section on its own would probably give it too much focus. > This section also uses EUI-64 for the link-local address; and, this is no > more > advised for privacy reason. Not really important in the DMM context though. > [CB] Yes, I agree. Since the exemplary addresses are not that important, I've removed them by rewriting the text as follows: OLD: [...] router with a specific MAC (e.g., 00:11:22:33:01:01) and IPv6 addresses (e.g., prefA::MAAR1/64 and fe80:211:22ff:fe33:101/64) using [...] NEW: [...] router with a specific MAC and IPv6 addresses (e.g., prefA::MAAR1/64 and fe80::MAAR1/64) using [...] > Important thing to fix, s/fe80:211:22ff:fe33:101/fe80::211:22ff:fe33:101/ > ;-) > [CB] Right! Fixed in my new proposed text above (fe80::MAAR1/64). > > The text of this section is really difficult to parse. After 2 readings I > am > not even sure that I got it... I was about to open a DISCUSS for the point > 2) > but I am unsure whether I am reading the text correctly. > > 1) If the MAC and LLA for the 'virtual router' mn1mar2 are different than > the > one for mn1mar2, why is there a need for different interface? Multiple > routers > can exist on the same link. > [CB] Since mn1mar1 and mn1mar2 have different MAC addresses, we need to have a different "logical" interface over the same physical interface (as one interface can only have one MAC address). They actually co-exist on the same link, as the distributed logical interface is just a mechanism to hide the change of anchors from the mobile node. The mobile node actually "sees" multiple routers on the same link, even though the anchors (MAARs) are not actually on that same link. > 2) For packets sourced by MN1 with prefix1 how can we ensure that they are > sent > to mn1mar1 and not to mn1mar? PvD could help there and should be mentionned > draft-ietf-intarea-provisioning-domains. > [CB] The MN, for each CN it is communicates, uses the source address that was selected when the communication was initiated with that CN. At each given time, only one (global) IPv6 address is not deprecated, and therefore when the MN is attached to MAARX, only the address allocated from the prefix anchored at MAARX (e.g. PrefX::MN) is non-deprecated. If the MN visited before other MAARs (e.g., MAARY) and has an active communication with a CN that was established while MN was attached to MAARY (e.g., PrefY::MN), then that communication will continue using the deprecated address (PrefY::MN). Deprecated addresses can be used while there are ongoing communications using them, but for new communications a non-deprecated address is preferred (according to RFC 6724). Then, according to RFC 2461, next-hop determination is not performed on every packet that is sent, but the results of next-hop determination computations are saved in the Destination Cache (which will contain the right mn1marX for the used source address in a given communication). > -- Section 4.2 -- > Bit 31 is not described, it is probably reserved but you should really > described it. > [CB] Yes, it is reserved and that's why we didn't describe it. Since there is a bit 'R' defined in RFC 3963, and there is only one bit left reserved I was not sure how to refer to it in the message format. Other mobility RFCs defining new flags just describe the new ones and refer to RFC 6275, but I agree that when there are multiple reserved bits and the message format figure shows "Reser" or something like that it is much easier to understand that these are not yet assigned and you don't need text to explain it. Any advice on how to do this in this case in which only one bit is left reserved? > > With this PBA packet format, all flags / bits are used and assigned for an > experimental document. Isn't it a waste of bits? I will really appreciate > an > answer on this question. > [CB] Well, this is a good question. I'm not aware of any policy about how to assign flags to protocols. I can only say that there are other experimental protocols using flags of the Binding Update / Binding Acknowledgement messages registered by the IANA. I think the use of the 'D' flag is well justified, but I'm of course biased here :) > > == NITS == > > -- Section 3 (and possibly others) -- > The CMD and MAAR acronyms are expanded multiple times. This makes the > reading > easier for newcomers of course. > [CB] I've removed some of the duplicated expansions. I still kept two because I think it makes the reading easier. It is probably not very relevant, but I think one of the reasons we expand the terms several times is because we got a request in some of the reviews at the WG to do so, but I'm 100% sure about that. Thanks a lot for your comments! Carlos
- [DMM] Éric Vyncke's Discuss on draft-ietf-dmm-pmi… Éric Vyncke via Datatracker
- Re: [DMM] Éric Vyncke's Discuss on draft-ietf-dmm… CARLOS JESUS BERNARDOS CANO
- Re: [DMM] Éric Vyncke's Discuss on draft-ietf-dmm… Eric Vyncke (evyncke)
- Re: [DMM] Éric Vyncke's Discuss on draft-ietf-dmm… CARLOS JESUS BERNARDOS CANO