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

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

Hi Carlos,

Thanks again. Short comment below.

On Thu, Mar 12, 2020 at 6:00 AM Carlos Pignataro (cpignata) <
[e-mail]> wrote:

> Hi, Carlos,
>
> Thanks for the response! Please see inline, prefaced with CMP.
>
> 2020/03/08 午後0:43、CARLOS JESUS BERNARDOS CANO <[e-mail]>のメール:
>
> Hi Carlos,
>
> Thanks for your review. Please find inline below my comments.
>
> On Sat, Feb 29, 2020 at 4:15 AM Carlos Pignataro (cpignata) <
> [e-mail]> 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.
>
>
>