Re: [DMM] [Last-Call] Intdir telechat review of draft-ietf-dmm-pmipv6-dlif -05

CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Thu, 12 March 2020 08:56 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 A77913A13A5 for <dmm@ietfa.amsl.com>; Thu, 12 Mar 2020 01:56: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, 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 gqgyTMB0OHIG for <dmm@ietfa.amsl.com>; Thu, 12 Mar 2020 01:56:27 -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 495083A13A1 for <dmm@ietf.org>; Thu, 12 Mar 2020 01:56:27 -0700 (PDT)
Received: by mail-ed1-x536.google.com with SMTP id m25so6418248edq.8 for <dmm@ietf.org>; Thu, 12 Mar 2020 01:56:26 -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=CNhpAK02/ITEu69vpMVr7/RIDtwfyS6eNsOQWQollgI=; b=XnFU3yhkhHyA6PLJ3JB7BTG1cDaUSVMmrm2mB4y4NdhiE3FHVLnswRTxHKBmyU4dEE Wzp15WewNYehsZQGLzX8foZR6dzfi23Pqx4QrAInom/uh+2n4j1nXRSRyX/Z/5HKSVN3 dMdB460iiVVjNvHrZi2w8gyRORU31EwNoShJLi978jcBx4v7TQfZG9VVCdaV7rhONm7T UE6zUylS1NZdTL96EVBDgGripOe7/Croyov7VJ2hwH3QGqDxW65yzWfcKzI2ZGOFqOGs kD0MXHxAcM/3nf56SLOvDmNqKpUuAcYuYGF8CMFSPg5I3KvpOP5CQgmvwiHUaYWHh1pS 3TBQ==
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=CNhpAK02/ITEu69vpMVr7/RIDtwfyS6eNsOQWQollgI=; b=tvfUD/K8hGqcm6EhGGZbMB9VoMpqkllYZi4hKisZsxNQjHx5D/ZdZdUk6zVvBepq9m R6aqAVVn6oHqdvY6mkWJljMvNvkGwTzw/gcFHB3v1b7RmOfJklAd73wJyZ104HhYbJet ENvDBqv6ZaEfwUiyJIU5D9M0y7NzUxUrpKvbuWtG+uGJaNEPMHgOihdCrI9H0tqOWiA2 ldimpG+STO4EYQVhrDI5/wfAxBOiCQToKIblDa2AlrY7S74RJ/kziVZU3cgoS5gVU/aa 1/VbUQPyPQEj3ptk7rE4M2rrw0FldER/3gx7EWct9+xAijjprR4dIwFzMMvmK6Z4ku7O vhNg==
X-Gm-Message-State: ANhLgQ34aIcZyl14+6QjenMkQ8kD4G4RhFIjRwSUGhW9kPxok5ZXQbJN i2tjMU7XiZmsje9WPedziiwGwfRCg8SyRyFDkA8x2XcALcY=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vsp9cg0I2efmduxQv+xHQWgMnMOv99OUnlo8C18?= =?utf-8?q?3SjZgGrWzxMOCmyn3Qvv4EQPzijeV1Akftr9arEaXpb7foI=3D?=
X-Received: by 2002:a17:906:eb83:: with SMTP id mh3mr5674028ejb.329.1584003385168; Thu, 12 Mar 2020 01:56:25 -0700 (PDT)
MIME-Version: 1.0
References: <5480B86B-3D6B-490B-9CAC-609EE7A41278@cisco.com> <CALypLp9LxKxSnSg7Omu_zdtywTFM5Mf0GKsaN8Ra+orxcfD3Og@mail.gmail.com> <473EA3D0-688D-4047-83B9-ED351937232A@cisco.com>
In-Reply-To: <473EA3D0-688D-4047-83B9-ED351937232A@cisco.com>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Thu, 12 Mar 2020 09:56:09 +0100
Message-ID: <CALypLp_Tn069rT65qqbOctX_pzF1SvqtGDMTHXfiSOdW2Kjevg@mail.gmail.com>
To: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
Cc: "int-dir@ietf.org" <int-dir@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-dmm-pmipv6-dlif.all@ietf.org" <draft-ietf-dmm-pmipv6-dlif.all@ietf.org>, "dmm@ietf.org" <dmm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000018bfac05a0a48796"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/TdvsVFZf6-6JEBsbyn3RJcPNCD4>
Subject: Re: [DMM] [Last-Call] Intdir telechat review of draft-ietf-dmm-pmipv6-dlif -05
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: Thu, 12 Mar 2020 08:56:31 -0000

Hi Carlos,

Thanks again. Short comment below.

On Thu, Mar 12, 2020 at 6:00 AM Carlos Pignataro (cpignata) <
cpignata@cisco.com> wrote:

> Hi, Carlos,
>
> Thanks for the response! Please see inline, prefaced with CMP.
>
> 2020/03/08 午後0:43、CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>のメールt;のメール:
>
> Hi Carlos,
>
> Thanks for your review. Please find inline below my comments.
>
> On Sat, Feb 29, 2020 at 4:15 AM Carlos Pignataro (cpignata) <
> cpignata@cisco.com> wrote:
>
>> Reviewer: Carlos Pignataro
>> Review result: Ready with Nits
>>
>> I am an assigned INT directorate reviewer for this Internet-Draft.  These
>> comments were written primarily for the benefit of the Internet Area
>> Directors.
>> Document editors and shepherd(s) should treat these comments just like
>> they
>> would treat comments from any other IETF contributors and resolve them
>> along
>> with any other Last Call comments that have been received. For more
>> details on
>> the INT Directorate, see http://www.ietf.org/iesg/directorate.html.
>>
>> I hope these comments are clear and useful.
>>
>> As requested, from the Internet area Directorate review, these two DMM
>> documents are being reviewed together:
>> * draft-ietf-dmm-distributed-mobility-anchoring-14
>> * draft-ietf-dmm-pmipv6-dlif-05
>>
>> This document defines distributed mobility anchoring, in terms of the
>> different configurations and functions to provide IP mobility support,
>> including network-based or host-based mobility support.
>>
>> The intended status is Informational. It is a very well written and
>> comprehensive
>> document. It is technically sound.
>>
>> No major or minor issues.
>>
>> Nits:
>>
>> A set of small nits for your consideration.
>>
>> 1.  Introduction
>>
>>    As a Mobile Node (MN) attaches to an access router and establishes a
>>    link between them, a /64 IPv6 prefix anchored to the router may be
>>    assigned to the link for exclusive use by the MN [RFC6459].  The MN
>>    may then configure a global IPv6 address from this prefix and use it
>>    as the source IP address in a flow to communicate with its
>>    correspondent node (CN).
>>
>> Capitalize:
>> s/correspondent node/Correspondent Node/
>>
>> 2.  Conventions and Terminology
>>
>>    These include terms such as mobile node (MN), correspondent node
>>    (CN), home agent (HA), home address (HoA), care-of-address (CoA),
>>    local mobility anchor (LMA), and mobile access gateway (MAG).
>>
>> Capitalize “Mobile Node” (as per § 1), “Corespondent Node”, etc.
>>
>> Similar within this same § 2, “mobile router”, etc.
>> Same throughout the document (e.g., “router advertisement (RA)”)
>>
>> 4.3.  Mobility case, anchor relocation
>>
>>    The IP prefix/address anchoring may move without changing the IP
>>    prefix/address of the flow.  Here the LM and FM functions in Figure 1
>>    in Section 3.1 are implemented as shown in Figure 7.
>>
>> “Figure 1 in Section 3.1.1 are implemented”
>>
>>                          Figure 7: Anchor mobility
>>
>> Should this figure’s label be “Anchor Relocation” instead of ‘Anchor
>> mobility”?
>>
>> 5.  Security Considerations
>>
>>    As stated in [RFC7333], "a DMM solution MUST supportany security
>>
>> s/supportany/support any/
>>
>> 8.2. Informative References
>>
>> The relationship of this document and draft-ietf-dmm-deployment-models is
>> mostly clear, thank you for that.
>>
>> I hope you fid these comments useful.
>>
>> Carlos Pignataro.
>>
>>
>> https://tools.ietf.org/html/draft-ietf-dmm-pmipv6-dlif-05
>>
>> I am an assigned INT directorate reviewer for this Internet-Draft.  These
>> comments were written primarily for the benefit of the Internet Area
>> Directors.
>> Document editors and shepherd(s) should treat these comments just like
>> they
>> would treat comments from any other IETF contributors and resolve them
>> along
>> with any other Last Call comments that have been received. For more
>> details on
>> the INT Directorate, see http://www.ietf.org/iesg/directorate.html.
>>
>> I hope these comments are clear and useful.
>>
>> As requested, from the Internet area Directorate review, these two DMM
>> documents are being reviewed together:
>> * draft-ietf-dmm-distributed-mobility-anchoring-14
>> * draft-ietf-dmm-pmipv6-dlif-05
>>
>> This document provides an approach to distributed mobility management
>> by extending network-based mobility protocols (like Proxy Mobile IPv6). In
>> this solution, mobility sessions are anchored at the last IP hop router.
>>
>> This document’s intended status is Experimental. It is well written for
>> such a complex comprehensive document, and technically complete and
>> sensible.
>>
>> No major or minor issues.
>>
>> Nits:
>>
>> Please find some small comments for your consideration:
>>
>>
>> 4.1.  Proxy Binding Update
>>
>>    A new flag (D) is included in the Proxy Binding Update to indicate
>>    that the Proxy Binding Update is coming from a Mobility Anchor and
>>    Access Router and not from a mobile access gateway.  The rest of the
>>    Proxy Binding Update format remains the same as defined in [RFC5213].
>>
>>    0               1               2               3
>>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>                                    |            Sequence #         |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>    |A|H|L|K|M|R|P|F|T|B|S|D| Reser |            Lifetime           |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> However, for RFC 5213 S 8.1:
>>
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>       |A|H|L|K|M|R|P|  Reserved       |            Lifetime           |
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> So, therefore, seems like:
>> 1. The definition of Flags F, T, B, and S is missing.
>> 2. “Reser” is not really clear and “Rsrvd” seems to fit and be more
>> unambiguous.
>>
>
> [CB] I've replaced "Reser" with "Rsrvd". The other flags are defined in
> other RFCs, published after RFC 5213. Do I need to explain what each of
> these flags do in this document? In any case, there might be additional
> flags defined in the future, so I think it is not needed.
>
>
>
> CMP: The problem I see is that the document currently says:
>    The rest of the
>    Proxy Binding Update format remains the same as defined in [RFC5213]
>
> But based on what you write, that is not the case.
>
> No, you do not need to explain what each flag does — but I’d suggest
> either not say where they are defined, or include the other RFCs.
>
> I checked IANA and found:
>
> https://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml#mobility-parameters-11
>
> [CB] OK, I was referring to the rest of the PBU format in general. I can
add that a note referring to the IANA registry for the definition and
references of the flags. Would that work?

Thanks,

Carlos


>
>
>> 4.2.  Proxy Binding Acknowledgment
>>
>> …
>>   The rest of the Proxy Binding Acknowledgment format
>>    remains the same as defined in [RFC5213].
>>
>>    0                   1                   2                   3
>>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>                                    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>                                    |   Status      |K|R|P|T|B|S|D| |
>>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> However, from RFC 5213:
>>
>>        0                   1                   2                   3
>>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>                                       |   Status      |K|R|P|Reserved |
>>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>> And thus, Flags T, B, S are not defined.
>>
>
> [CB] Same as before. Additional flags were defined and added to IANA
> registry after RFC 5213 was published. I refer to RFC 5213 as it is where
> the actual PBU/PBA format was specified (although they are basically BU/BA
> with P flag set to 1).
>
>
> THanks, I understand. I was commenting on the text that says “the rest is
> defined in RFC5213”.
>
>
>> 4.3.  Anchored Prefix Option
>>
>>    Anchored Prefix
>>
>>       A sixteen-byte field containing the mobile node's IPv6 Anchored
>>       Prefix.  Only the first Prefix Length bytes are valid for the
>>       Anchored Prefix.  The rest of the bytes MUST be ignored.
>>
>> Not being pedantic, but:
>> s/byte/octet/g // throughout.
>> Or… "128-bit” instead of “sixteen-octet”.
>>
>
> [CB] OK, I see that RFC 6275 uses only "octet", while RFC 5213 uses both
> "octet" and "byte". But I agree that using only one is the right thing to
> do. I've chosen "octet" as you suggested.
>
>
> Thanks! As strictly there can be non-octet bytes.
>
>
>>
>> 5.  IANA Considerations
>>
>>    This document defines six new mobility options that need to be
>>    registered in the Mobility Options registry on the Mobile IPv6
>>    parameters registry.  The required IANA actions are marked as IANA-1
>>    to IANA-6.
>>
>> It would be useful to breakout the specific IANA requests in a table,
>> sections, or other structure detailing how it should look in the IANA
>> registries.
>>
>
> [CB] I've added some additional text, but following the approach of RFC
> 5213, which keeps it simple. I hope this is sufficient.
>
>
> Thank you.
>
>
>> 6. Security Considerations
>>
>> Is there underlying protection against spoofing that can be called out?
>> This should be addressed in the Security Dir review, so I will not mention
>> it here 🙂
>>
>
> [CB] We assume that using the mechanisms described for RFC 5213 is enough.
> We have added some additional considerations for the risks/procedures that
> are specific to the distributed solution.
>
>
> Ack.
>
>
>> 8.2.  Informative References
>>
>>    [I-D.ietf-dmm-deployment-models]
>>               Gundavelli, S. and S. Jeon, "DMM Deployment Models and
>>               Architectural Considerations", draft-ietf-dmm-deployment-
>>               models-04 (work in progress), May 2018.
>>
>> Since there are key definitions from this document, should this be
>> Normative?
>>
>
> [CB] Since this document is not going to be progressed any further, we
> have included the relevant terms in the terminology section and remove the
> reference.
>
>
> Got it.
>
>
>
>>
>>    [RFC7333]  Chan, H., Ed., Liu, D., Seite, P., Yokota, H., and J.
>>               Korhonen, "Requirements for Distributed Mobility
>>               Management", RFC 7333, DOI 10.17487/RFC7333, August 2014,
>>               <https://www.rfc-editor.org/info/rfc7333>.
>>
>> Similarly, should this reference be Normative instead of Informative?
>>
>
> [CB] I don't have a strong opinion here. I've moved it to Normative, but I
> think it could stay as Informative as well.
>
>
> Your call. Thanks for considering.
>
>
>> Appendix B.  Implementation experience
>>
>> Should this really be an Implementation Status section [RFC7942], as it
>> describes a point in time rather than learnings?
>>
>> Should the Appendices clarify they make no normative specs?
>>
>
> [CB] Based also on other comments we have remove both appendixes.
>
>
> Ack.
>
>
>> I hope these comments are useful.
>>
>
> [CB] Yes, they are indeed. Thanks!
>
>
> :-) Super.
>
> (Another) Carlos.
>
>
> Carlos
>
>
>>
>> Thank you very much,
>>
>> Carlos Pignataro.
>
>
>