Re: [DMM] Benjamin Kaduk's Discuss on draft-ietf-dmm-pmipv6-dlif-05: (with DISCUSS and COMMENT)

CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es> Fri, 20 March 2020 18:46 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 446E13A0DB5 for <dmm@ietfa.amsl.com>; Fri, 20 Mar 2020 11:46:41 -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 qfV_REFqudVJ for <dmm@ietfa.amsl.com>; Fri, 20 Mar 2020 11:46:35 -0700 (PDT)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 B590D3A0DAF for <dmm@ietf.org>; Fri, 20 Mar 2020 11:46:34 -0700 (PDT)
Received: by mail-ed1-x52d.google.com with SMTP id z65so8387558ede.0 for <dmm@ietf.org>; Fri, 20 Mar 2020 11:46: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=drscbpGtGlIfm6SiDv6RmCse6eLI7Fj5jNE62zrE1p4=; b=rCYytnriIzHCAAuZfP7wZGOFkwFFx6AAsJMYsmusXUqcHBpXBWtos/jW9P255Qs/n6 jeq6pbSeg78OI+Ccj6WeFZzTvS6/9ZYLVFkc56Wjb/pz3JHjwxQnrfVHbP8ZYpPFgGsO Ig/7dxnXdba+Dej8ilcP4l7ONsaappoSsK14Dstjz238E+Z4sEkib6wYHF/WKtUWCMzD doeMmrWX2QDxIfnEJK2smdhEtcGYhIQZZy+o7ptA3ohUgUMqzQhClzhEdNmeuuP73pC7 CTA5LSZTxzP2UhtGz5bFhMO2O/LdTC1meOMftQZ6XQZkSnV0yDLOjs2NdDumtffGIz4L lkDg==
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=drscbpGtGlIfm6SiDv6RmCse6eLI7Fj5jNE62zrE1p4=; b=MC7GbpBTmgO2cbdbp7rs4LKEBzVo11L5ErwON4w0ntnlSCr5ieGE512Ps911EAd1KJ xWnp6VTxdr5j6fhGNfdEUHQohNdBYEKzmOcLArs1O5dyp3oIben5Wd7eAMZ2q9KNaVI5 qDrRfSmYVh6kqlgRFGF7MuDP5BhJ5VoNoRKuWWivs5NIHbx1vYz/m+p3zMVcDahTyLcv eLIO10pX72bwZ9jxJeZgoeSY18MzmHjdEgWcq5Pe6zzeeOEEhtlHfcfJitT9fC+WWdxd T50MyuXXAs+KUiDdJNRVSr4Jz/gphZJdILDqKamjVk4f1SUn9WQQGkfSSB5FPtwBFoxf W7gQ==
X-Gm-Message-State: ANhLgQ0Zrr803Fel/Yoz5KVG4vf9oVeYT1alWvDje18yA5EYDgbGJ/UN Pjrbsq0+dJWktIoltVh3W7l6sQS28jIV43KU8CKJjA==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vv1VTvrwil058iipZNsrS+eau/vBPcowv54JL4b?= =?utf-8?q?EPh701fy8LZY8nvkQ0coJiot7QFSY8baLyS3voGoGUgwkW0=3D?=
X-Received: by 2002:a50:8b41:: with SMTP id l59mr9301451edl.44.1584729992694; Fri, 20 Mar 2020 11:46:32 -0700 (PDT)
MIME-Version: 1.0
References: <158338573858.29475.12173301575622176655@ietfa.amsl.com> <CALypLp9NAHJppV-0bE0WTuhtFykW5D6dAKLNXApVxTO+JnBhqQ@mail.gmail.com> <20200320174412.GQ50174@kduck.mit.edu>
In-Reply-To: <20200320174412.GQ50174@kduck.mit.edu>
From: CARLOS JESUS BERNARDOS CANO <cjbc@it.uc3m.es>
Date: Fri, 20 Mar 2020 19:46:16 +0100
Message-ID: <CALypLp8dLG5sm_qKJLLgFG+rt4uFF2gCUdODg2CSQW3OAMGbkg@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
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>
Content-Type: multipart/alternative; boundary="00000000000047c21605a14db499"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmm/oN84ml5P6mfA5NJWvfMpzKObOGw>
Subject: Re: [DMM] Benjamin Kaduk'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: Fri, 20 Mar 2020 18:46:52 -0000

Thanks a lot Benjamin!

Carlos

On Fri, Mar 20, 2020 at 6:45 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

> Hi Carlos,
>
> Also inline (but not much left to say!)
>
> On Sun, Mar 08, 2020 at 06:58:14PM +0100, CARLOS JESUS BERNARDOS CANO
> wrote:
> > Hi Benjamin,
> >
> > Thanks a lot for another very good review. Please find my comments inline
> > below.
> >
> > On Thu, Mar 5, 2020 at 6:22 AM Benjamin Kaduk via Datatracker <
> > noreply@ietf.org> wrote:
> >
> > > Benjamin Kaduk 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:
> > > ----------------------------------------------------------------------
> > >
> > > I have a very boring Discuss point and a somewhat boring point, and
> > > expect to change my ballot to Yes once they're resolved.
> > >
> > > In Section 3.2 we say that pacing mechanisms "MAY" be used to avoid
> > > bursts when the CMD is fanning out PBUs, but in Section 6 we say that
> > > pacing "SHOULD" be used; please resolve the inconsistency (preferrably
> > > with "MUST" as Mirja requests).
> > >
> >
> > [CB] Done in version -06 (to be submitted soon).
> >
> >
> > >
> > > Please also include some discussion of privacy considerations (I give
> > > some suggestions in the COMMENT).
> > >
> >
> > [CB] OK, I'll do.
> >
> >
> > >
> > >
> > > ----------------------------------------------------------------------
> > > COMMENT:
> > > ----------------------------------------------------------------------
> > >
> > > Thanks for this well-written document!  It is clearly written, and when
> > > multiple approaches exist, does well at laying out the different
> options
> > > and their pros/cons, as befits an Experimental document.  Also, several
> > > times I have started to write a comment only to realize that it is
> > > answered by the following text :)
> > >
> >
> > [CB] Thanks, very much appreciated.
> >
> >
> > >
> > > Section 1
> > >
> > >    The Distributed Mobility Management (DMM) paradigm aims at
> minimizing
> > >    the impact of currently standardized mobility management solutions
> > >    which are centralized (at least to a considerable extent).
> > >
> > > I'd consider saying a little more about which aspects of their
> operation
> > > are centralized.  Perhaps the following paragraph suffices, though.
> > >
> >
> > [CB] I've added another reference to RFC 7333, where this is explained in
> > detail. As you mention below, we go a bit into these aspects of
> centralized
> > operation in the following paragraph, and I personally believe it is
> better
> > not to add too much text on this aspect (which is covered by RFC 7333).
> > Please, let me know if you are not happy with this resolution.
> >
> >
> > >
> > >    Following this idea, in our proposal, the central anchor is moved to
> > >    the edge of the network, being deployed in the default gateway of
> the
> > >    mobile node.  That is, the first elements that provide IP
> > >
> > > (side note: Using the singular "central anchor" poses an interesting
> > > rhetorical question: is the (formerly) single central anchor being
> > > duplicated and spread amongst all access routers, or does there remain
> a
> > > single central anchor (per MN), just one that moves around along with
> > > the MN.)
> > >
> >
> > [CB] The whole idea of the DMM approach specified in this document is
> that
> > we move from a "single central anchor" to a "multiple distributed
> anchors".
> > Note that the specified approach allows for a central anchor to be still
> > present (and used by an MN for communications where it is more
> > appropriate), but this is more an operational decision (probably more in
> > scope of RFC 8653).
> >
> >
> > >
> > >    anchors to retrieve the MN's previous location(s).  Also, a key-
> > >    aspect of network-based DMM, is that a prefix pool belongs
> > >    exclusively to each MAAR, in the sense that those prefixes are
> > >    assigned by the MAAR to the MNs attached to it, and they are
> routable
> > >    at that MAAR.
> > >
> > > It might be worth some statement relating this "ownership" of prefixes
> > > to actual mobility events -- e.g., they are assigned to MNs attached to
> > > it at that time, but remain with those MNs as mobility occurs, but
> > > always remain routable at that MAAR as well as towards the MN itself.
> > >
> > > [CB] OK, I've added a sentence adopting part of your text. Thanks.
> >
> >
> > >    We consider partially distributed schemes, where the data plane only
> > >    is distributed among access routers similar to MAGs, whereas the
> > >
> > > nit: I suggest s/the data plane only/only the data plane/
> > >
> >
> > [CB] OK, thanks.
> >
> >
> > >
> > >    control plane is kept centralized towards a cardinal node used as
> > >    information store, but relieved from any route management and MN's
> > >    data forwarding task.
> > >
> > > What's the scope of "single" here -- per deployment, per prefix, per
> > > MAAR, ...?
> > >
> >
> > [CB] Sorry, I don't get this comment. I don't see "single" mentioned in
> the
> > quoted textl
>
> Sorry!  I was assuming that the "cardinal node" was a single centralized
> information store, and that's the "single" I was trying to ask about.
> Re-reading, I would assume that this "cardinal node" is per deployment, so
> it may not be worth changing the text if that's in fact the case.
>
> >
> > >
> > >    P-MAAR (Previous MAAR).  When a MN moves to a new point of
> attachment
> > >       a new MAAR might be allocated as its anchor point for future IPv6
> > >       prefixes.  The MAAR that served the MN prior to new attachment
> > >       becomes the P-MAAR.  It is still the anchor point for the IPv6
> > >       prefixes it had allocated to the MN in the past and serves as the
> > >
> > > (side note? Do we expect those previous allocations to eventually "time
> > > out" as sessions using them terminate?  Or are the allocations more
> > > permanent, with intent to reuse if/when the MN returns to that MAAR?)
> > >
> >
> > [CB] The expectation is that previous allocations will eventually
> time-out
> > as sessions using them terminate.
> >
> >
> > >
> > > Section 3
> > >
> > >    interest and eventually take the appropriate action.  The procedure
> > >    adopted for the query and the messages exchange sequence might vary
> > >    to optimize the update latency and/or the signaling overhead.  Here
> > >
> > > nit: wrong pluralization in "messages exchange sequence"
> > >
> >
> > [CB] OK, fixed.
> >
> >
> > >
> > > Section 3.1
> > >
> > >    3.  Since this is an initial registration, the CMD stores a
> permanent
> > >        BCE containing as primary fields the MN-ID, Pref1 and MAAR1's
> > >        address as a Proxy-CoA.
> > >
> > > [how permanent is "permanent"?]
> > >
> >
> > [CB] I've removed "permanent" as it is not really needed. The BCE stays
> at
> > the CMD until the session is de-registered (it is "more permanent" that
> the
> > BCEs at the P-MAARs).
> >
> >
> > >
> > > Section 3.2
> > >
> > >    1.  When the MN moves from its current point of attachment and
> > >        attaches to MAAR2 (now the S-MAAR), MAAR2 reserves another IPv6
> > >        prefix (Pref2), it stores a temporary BCE, and it sends a plain
> > >        PBU to the CMD for registration.
> > >
> > > It's not clear to me at this point how MAAR2 has enough information to
> > > determine that this will be a "plain" PBU vs. the the PBU used for
> > > initial registration.  (That said, it's also not clear to me that the
> > > send PBU actually differs on the wire, so maybe this is just a
> > > rhetorical question.  Er, a question of rhetoric, that is.)
> > >
> >
> > [CB] They are actually the same PBUs, as MAAR2 does not know at that
> point
> > if the MN had been already registered. Both PBUs would be "plain". I've
> > removed "plain" and "another" to make it clearer.
> >
> >
> > >
> > >    4.  The CMD, after receiving the PBA, updates the BCE populating an
> > >        instance of the P-MAAR list.  The P-MAAR list is an additional
> > >        field on the BCE that contains an element for each P-MAAR
> > >        involved in the MN's mobility session.  The list element
> contains
> > >        the P-MAAR's global address and the prefix it has delegated (see
> > >        Appendix B for further details).  Also, the CMD sends a PBA to
> > >        the new S-MAAR, containing the previous Proxy-CoA and the prefix
> > >        anchored to it embedded into a new mobility option called
> > >        Previous MAAR Option (defined in Section 4.5), so that, upon PBA
> > >        arrival, a bi-directional tunnel can be established between the
> > >        two MAARs and new routes are set appropriately to recover the IP
> > >        flow(s) carrying Pref1.
> > >
> > > To check my understanding: there will only be one Previous MAAR Option
> > > present and it will describe only a single MAAR, which implies that if
> > > there are multiple P-MAARs, traffic directed to an arbitrary prefix
> > > based at one of them is expected to traverse multiple tunnels from
> > > P-MAAR to P-MAAR before making its way to the S-MAAR and the MN?
> > > [Hmm, looks like my understanding is wrong.  I'd consider making
> > > "previous Proxy-CoA" and "the prefix anchored to it" plural to give the
> > > reader a hint as to what's coming, though I can understand if there is
> > > desire to keep the initial mobility example simple and only gradually
> > > introduce the complexity in question.]
> > >
> >
> > [CB] I've been looking at it and changing it back and forth several
> times.
> > I prefer to keep the initial mobility example. Just to answer your
> > question, in general there might be multiple options. This is what the
> text
> > you point below should indicate (among other things).
> >
> >
> > >    For MN's next movements the process is repeated except the number of
> > >    P-MAARs involved increases (accordingly to the number of prefixes
> > >    that the MN wishes to maintain).  Indeed, once the CMD receives the
> > >    first PBU from the new S-MAAR, it forwards copies of the PBU to all
> > >    the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR
> > >    prior to handover) and in the P-MAARs list.  They reply with a PBA
> to
> > >    the CMD, which aggregates them into a single one to notify the
> > >    S-MAAR, that finally can establish the tunnels with the P-MAARs.
> > >
> > > I'm not sure I understand the cardinality of P-CoA -- is it one,
> > > the single S-MAAR prior to handover, or many, all P-MAARs in the list?
> > >
> >
> > [CB] There are multiple P-CoAs, but current writing might lead to think
> > there is only one. One P-CoA is the one listed in the BCE (the one of the
> > previously visited MAAR) plus the P-CoAs listed in the P-MAAR list. I've
> > rewritten a bit the text trying to make this clearer: "Indeed, once the
> CMD
> > receives the first PBU from the new S-MAAR, it forwards copies of the PBU
> > to all the P-MAARs indicated in the BCE, namely the one registered as
> > current P-CoA (i.e., the MAAR prior to handover) plus the ones in the
> > P-MAARs list."
>
> Thanks, this helps a lot!
>
> >
> > >    When there are multiple previous MAARs, e.g., k MAARs, a single PBU
> > >    received by the CMD triggers k outgoing packets from a single
> > >    incoming packet.  This may lead to packet bursts originated from the
> > >    CMD, albeit to different targets.  Pacing mechanisms MAY be
> > >    introduced to avoid bursts on the outgoing link.
> > >
> > > I'll defer to my TSV colleagues, but a "SHOULD" feels more comfortable
> > > than "MAY" to me, here.
> > >
> >
> > [CB] Actually, based on other comments we have decided to go for "MUST".
>
> Indeed.  (It looks like I forgot to change this comment when I added a note
> to my discuss point after I read Mirja's position.)
>
> >
> > > Section 3.3
> > >
> > >    The handover latency experienced in the approach shown before can be
> > >    reduced if the P-MAARs are allowed to signal directly their
> > >    information to the new S-MAAR.  This procedure reflects what was
> > >    described in Section 3.2 up to the moment the P-MAAR receives the
> PBU
> > >    with the P-MAAR option.  At that point a P-MAAR is aware of the new
> > >
> > > nit(?): I think this is the S-MAAR option, not the P-MAAR option?
> > >
> >
> > [CB] Right! Thanks.
> >
> >
> > >
> > >    S-MAAR including the prefix it is anchoring.  This latter PBA does
> > >    not need to include new options, as the prefix is embedded in the
> HNP
> > >    option and the P-MAAR's address is taken from the message's source
> > >    address.  The CMD is relieved from forwarding the PBA to the S-MAAR,
> > >
> > > (side note: this assumes there's no NAT or tunneling or similar between
> > > MAARs, which seems like a plausible assumption, at least for now.)
> > >
> >
> > [CB] Yes, that's right.
> >
> >
> > >
> > > Section 3.4
> > >
> > >    side.  When P-MAARs complete the update, they send a PBA to the CMD
> > >    to indicate that the operation is concluded and the information is
> > >    updated in all network nodes.  This procedure is obtained from the
> > >
> > > Is there anything useful to say about behavior on timeout at the CMD
> > > (failing to reive a PBA from one or more P-MAARs)?
> > >
> > > [CB] A new Section 3.6 "Retransmissions and Rate Limiting" has been
> added
> > (to address also other received comments). I hope this addresses this
> > comment.
>
> It doesn't directly give guidance about the CMD's behavior as a recipient,
> but it does give some more context for the expected operation of the
> system, which should be enough.
>
> >
> > > Section 3.5
> > >
> > >    The de-registration mechanism devised for PMIPv6 cannot be used as
> is
> > >    in this solution.  The reason for this is that each MAAR handles an
> > >
> > > nit: s/as is/as-is/
> > >
> >
> > [CB] Fixed, thanks.
> >
> >
> > >
> > >    Indeed, when a previous MAAR initiates a de-registration procedure,
> > >    because the MN is no longer present on the MAAR's access link, it
> > >    removes the routing state for that (those) prefix(es), that would be
> > >    deleted by the CMD as well, hence defeating any prefix continuity
> > >    attempt.  The simplest approach to overcome this limitation is to
> > >
> > > nit(?): s/when/if/.  At least, this makes more sense to me if I do that
> > > ... maybe I'm just confused.
> > >
> >
> > [CB] OK, fixed.
> >
> >
> > >
> > >    serving MAAR to de-register the whole MN session.  This can be
> > >    achieved by first removing any layer-2 detachment event, so that de-
> > >    registration is triggered only when the session lifetime expires,
> > >
> > > I see that RFC 5213 has some mechanisms for lifetime management, but
> > > didn't get to look closely enough to understand how clear the necessary
> > > lifetime management will be in the DMM case when there are multiple
> > > prefixes registered to a given MN at different MAARs.  (Also, 5213
> > > doesn't seem to use the "session lifetime" phrase verbatim.)
> > >
> >
> > [CB] I've replaced "session lifetime" with "binding lifetime" to make it
> > more consistent with the terminology used in RFC 5213. Note that
> "mobility
> > session" is used in RFC 5213.
>
> Thanks!
>
> >
> > >
> > > Section 3.6
> > >
> > >    requiring special support from the mobile node's IP stack.  This
> > >    document defines the Distributed Logical Interface (DLIF), which is
> a
> > >    software construct that allows to easily hide the change of
> > >    associated anchors from the mobile node.
> > >
> > > A software construct in the MAAR, right?
> > >
> >
> > [CB] Yes, I've added "in the MAAR" to the text.
> >
> >
> > >
> > >
> > > How common is "HMAC" as an abbreviation for "hardware MAC address"?
> > > It's also an abbreviation for Hash-based Message Authentication Code,
> > > which confuses my poor security-focused brain, though I acknowledge
> that
> > > this does not necessarily extend to most of the target audience for
> this
> > > document...
> > >
> >
> > [CB] It is not common. To avoid potential confusions I've removed HMAC
> and
> > just used MAC, which I think it is sufficient in the scope of this
> document
> > (as we use LMAC for the logical one).
> >
> >
> > >    and MN3, while MAAR2 is serving MN1.  MN1, MN2 and MN3 have two
> > >    P-MAARs: MAAR1 and MAAR2.  Note that a serving MAAR always plays the
> > >
> > > Do they have two P-MAARs, or one P-MAAR and one S-MAAR (each)?
> > >
> >
> > [CB] You are right. Here there was a mistake, as P-MAAR was being mixed
> > with anchoring MAAR. I've removed that sentence to keep it clearer.
> >
> >
> > >    role of anchoring MAAR for the attached (served) MNs.  Each MAAR has
> > >    one single physical wireless interface.
> > >
> > > Have we defined "anchoring MAAR" yet?
> > >
> >
> > [CB] We have added a definition to the terminology section.
> >
> >
> > > Also, I assume that the "single physical interface" is just "as
> depicted
> > > in this example" and not a protocol requirement :)
> > >
> >
> > [CB] Yes, right.
> >
> >
> > >
> > >    As introduced before, each MN always "sees" multiple logical routers
> > >    -- one per P-MAAR -- independently of its currently serving MAAR.
> > >
> > > [same P-MAAR vs. S-MAAR split as above]
> > >
> >
> > [CB] Right, fixed by replacing P-MAAR with anchoring MAAR.
> >
> >
> >
> > >
> > >    by the serving MAAR (MAAR2) configuring an additional distributed
> > >    logical interface: mn1mar1, which behaves exactly as the logical
> > >    interface configured by MAAR1 when MN1 was attached to it.  This
> > >
> > > nit(?): "exactly" is asking for pedants to try and poke holes in the
> > > claimed perfection.
> > >
> >
> > [CB] Right, I removed "exactly".
> >
> >
> > >
> > >    deprecated).  The goal is to deprecate the prefixes delegated by
> > >    these MAARs (which will be no longer serving the MN).  Note that on-
> > >
> > > nit(?): s/which will be no longer/so that they will no longer be/, IIUC
> > >
> >
> > [CB] Fixed.
> >
> >
> > >
> > > Section 4.1
> > >
> > > The intdir reviewer's comments regarding the flag bits seem apropos (I
> > > presume they were allocated by other extensions to 5213, but we should
> > > say something about it).
> > >
> >
> > [CB] OK, I'll address this in my response to the intdir review.
>
> It looks like the plan is to reference the IANA registry for the flags?
> That sounds good, though I assume it's still only in the editor's copy.
>
> >
> > >
> > >
> > >    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
> > >
> > > "D" is for "DMM", I trust?  It could be worth mentioning.
> >
> >
> > [CB] Yes, done.
> >
> >
> > >
> >
> >
> > > Is the D bit set for the PBUs sent from CMD to P-MAAR as well?
> > >
> >
> > [CB] Yes, I've fixed that.
> >
> >
> > > (I see that the PBA description uses a slightly different formulation
> to
> > > cover the 'D' bit; is there a reason to diverge?)
> > >
> >
> > [CB] No reason. I've updated the text to use the same formulation.
> >
> >
> > >
> > >    Mobility Options
> > >
> > >       Variable-length field of such length that the complete Mobility
> > >       Header is an integer multiple of 8 octets long.  This field
> > >       contains zero or more TLV-encoded mobility options.  The encoding
> > >       and format of defined options are described in Section 6.2 of
> > >       [RFC6275].  The MAAR MUST ignore and skip any options that it
> does
> > >       not understand.
> > >
> > > MAARs that *receive* PBUs must be P-MAARs, right?
> > >
> >
> > [CB] Yes, but also a CMD. Therefore I've replaced "MAAR" with "receiving
> > node".
> >
> >
> > > Section 4.2
> > >
> > >    MAAR (D)
> > >
> > >       The D is set to indicate that the sender of the message supports
> > >       operating as a Mobility Anchor and Access Router.  When a MAG
> that
> > >       does not support the extensions described in this document
> > >       receives a message with the D-Flag set, it MUST ignore the
> message
> > >       and an error MUST be returned.
> > >
> > > Is the CMD considered a MAAR for this purpose?
> > >
> >
> > [CB] I've replaced "operating as a Mobility Anchor and Access Router"
> with
> > "operating as a MAAR or a CMD".
> >
> >
> > >       contains zero or more TLV-encoded mobility options.  The encoding
> > >       and format of defined options are described in Section 6.2 of
> > >       [RFC6275].  The MAAR MUST ignore and skip any options that it
> does
> > >       not understand.
> > >
> > > What about the CMD?
> > >
> >
> > [CB] Same.. Therefore I've replaced "MAAR" with "receiving node".
> >
> >
> > >
> > > Section 4.3, 4.4
> > >
> > >    Prefix Length
> > >
> > >       8-bit unsigned integer indicating the prefix length of the IPv6
> > >       prefix contained in the 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.
> > >
> > > Is the prefix length bits or bytes?
> > >
> >
> > [CB] Bits. Fixed (also mentioned by another review).
> >
> >
> > >
> > > Section 4.4
> > >
> > > Is this also used to convey "local" prefixes in the PBA from CMD to
> > > S-MAAR?  (If not, how does the S-MAAR know to advertise them from its
> > > DLIF?)
> > >
> >
> > [CB] Yes, this is right. I've rewritten the text to reflect it.
> >
> > >
> > > Section 4.5
> > >
> > > What's the alignment requirement?
> > > (There's no need to put in a Reserved octet to keep things word
> > > aligned?)
> > >
> >
> > [CB] You are right. And this is embarrassing, as the internal code we use
> > is actually using the format with the extra reserved byte that was not
> > reflected in the document.
> >
> >
> > >    Prefix Length
> > >
> > >       8-bit unsigned integer indicating the prefix length of the IPv6
> > >       prefix contained in the option.
> > >    [...]
> > >    Home Network Prefix
> > >
> > >       A sixteen-byte field containing the mobile node's IPv6 Home
> > >       Network Prefix.  Only the first Prefix Length bytes are valid for
> > >       the mobile node's IPv6 Home Network Prefix.  The rest of the
> bytes
> > >       MUST be ignored.
> > >
> > > [is the prefix length bits or bytes?]
> > >
> >
> > [CB] Bits. Fixed.
> >
> >
> > >
> > > Section 4.6
> > >
> > > Is there an alignment requirement for this option?
> > >
> >
> > [CB] Yes, added.
> >
> >
> > >
> > >    This new option is defined for use with the Proxy Binding Update and
> > >    Proxy Binding Acknowledgement messages exchanged between the CMD and
> > >
> > > When is this option used in a PBA?
> > >
> >
> > [CB] Right, it is only used in a PBU. Fixed.
> >
> >
> > >
> > > Section 4.7
> > >
> > >    A new DLIF Link-local Address option is defined for use with the
> > >    Proxy Binding Update and Proxy Binding Acknowledgment messages
> > >    exchanged between MAARs.  This option is used for exchanging the
> > >
> > > MAARs but not CMDs?
> > > When is this used in the PBU?
> > >
> >
> > [CB] Also CMDs. And only in PBA. Fixed.
> >
> >
> > >
> > > Section 4.8
> > >
> > >    A new DLIF Link-layer Address option is defined for use with the
> > >    Proxy Binding Update and Proxy Binding Acknowledgment messages
> > >    exchanged between MAARs.  This option is used for exchanging the
> > >
> > > MAARs but not CMDs?
> > > When is this used in the PBU?
> > >
> >
> > [CB] Same as before.
> >
> >
> > >
> > > Section 6
> > >
> > > Unfortunately it seems that RFC 5213 does not include any privacy
> > > considerations discussion.  While the privacy properties of this
> > > protocol bear similarities to those of RFC 5213, it seems that there
> are
> > > also some significant differences, so I do think it is important to
> > > produce some documentation of privacy considerations for this document.
> > > The main factor would, of cousre, be tracking which entities obtain
> > > updates/information about the location of the MN, what those entities
> > > are expected to do with that data, and how trusted they are to be
> proper
> > > custodians of it.  Other factors may exist as well, including the
> > > potential for side-channel information leakage, e.g., due to traffic
> > > analysis.  There might also be a reverse situation where exposing the
> > > link-layer address(es) of a P-MAAR have privacy considerations, though
> I
> > > don't have anything particular in mind at the moment.
> > >
> >
> > [CB] OK, I see your point. I've tried to add something in version -06.
> Let
> > me know if you think it is sufficient (I tried to keep it short and
> simple,
> > while still addressing your point).
>
> I think it covers the key points.  Since all the parties are highly trusted
> anyway, we don't need to go into great detail.
>
> >
> > >
> > >    security concerns of Proxy Mobile IPv6 [RFC5213].  It is recommended
> > >    that the signaling messages, Proxy Binding Update and Proxy Binding
> > >    Acknowledgment, exchanged between the MAARs are protected using
> IPsec
> > >    using the established security association between them.  This
> > >
> > > This is essentially unchanged from 5213, just with different names for
> > > the endpoints, right, and so the existing guidance/experiences apply?
> > >
> >
> > [CB] Yes, it should apply. We haven't identified anything different.
> >
> >
> > >
> > > I think we should also say something about all MAARs and the CMD being
> > > trusted parties.  We should also say something about the authorization
> > > model (I assume it's just "all trusted parties are trusted to perform
> > > all operations relevant to their role", but that's still useful to
> say).
> > >
> >
> > [CB] OK, I've added a sentence on that.
> >
> >
> > >
> > >    When the CMD acts as a PBU/PBA relay, the CMD may act as a relay of
> a
> > >    single PBU to multiple previous MAARs.  In situations of many fast
> > >    handovers (e.g., with vehicular networks), there may exist multiple
> > >    previous (e.g., k) MAARs exist.  In this situation, the CMD creates
> k
> > >
> > > nit: remove the redundant "exist"
> > >
> >
> > [CB] Done.
> >
> >
> > >
> > >    When the CMD acts as MAAR locator, mobility signaling (PBAs) is
> > >    exchanged between P-MAARs and current S-MAAR.  This requires
> security
> > >    associations to exist between the involved MAARs (in addition to the
> > >    ones needed with the CMD).
> > >
> > > Is this relevant because of scaling/resource-consumption concerns or
> > > keying/trust ones?
> > >
> >
> > [CB] This is relevant because RFC 5213 uses a model in which signalling
> is
> > exchanged only between LMA (the anchor) and MAGs (the access routers),
> > while in this document there are some operation modes that also involve
> > signalling between MAARs (the access routers). This was just to highlight
> > this point (it is related to the point you made before about the trust
> > model).
>
> Okay, thanks for the clarification.
>
> >
> > >
> > > Appendix A.5
> > >
> > >    not implement existing mobility protocols.  Furthermore, a DMM
> > >    solution SHOULD work across different networks, possibly operated as
> > >    separate administrative domains, when the needed mobility management
> > >
> > > Hmm, separate administrative domains makes the risk of NAT relatively
> > > higher (per previous comment about NAT).
> > >
> > >    intervention.  The partially distributed DMM solution can be
> deployed
> > >    across different domains with trust agreements if the CMDs of the
> > >    operators are enabled to transfer context from one node to another.
> > >
> > > It would probably be worth expounding a bit more about this scenario
> and
> > > the necessary trust/authorization relationships, in the security
> > > considerations.
> > >
> > > [CB] As per other comment from IESG evaluation I've removed the two
> > appendixes.
> >
> > Huge thanks for your very good points!
>
> And thanks for all the updates!
> I will go update my ballot position now.
>
> -Ben
>