Re: [DMM] Tsvart last call review of draft-ietf-dmm-pmipv6-dlif-04

CARLOS JESUS BERNARDOS CANO <> Sat, 02 November 2019 11:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 49CB3120EA9 for <>; Sat, 2 Nov 2019 04:45:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eUdFcT-VteWO for <>; Sat, 2 Nov 2019 04:45:18 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 10B7B1213E2 for <>; Sat, 2 Nov 2019 04:45:18 -0700 (PDT)
Received: by with SMTP id p59so9441723edp.7 for <>; Sat, 02 Nov 2019 04:45:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x2BYLZxIxSAdt8ypoIQIORGGOqYh56gnCIuumwf7wWQ=; b=nAV7SZSZaSaY0VhNCfKKiX576UJLCpjr4GQ9tNwhj9/MQ67e/QlXz6rLSA7xlph/UT 3VazXn3X6drNshoFhh6l6XYkNj1ApGKcR8jkJu0kSJl9vGYobK16Sl96NYbNVSUNGNNN aADqe8ubLHwhhMMWmPiSOy7UyYUA93cGwDR6J4cSdV0TkfKYY3p5EmQ7btwPbdTpyPyB Ju1661iNirywP/e26zxX8mUig5TxRb7x0XH2K1HZlOyx9LOgnSTjxArEkwcVFsg9c779 qz4tAC2g2fiBxdrHLI5gi1PQJzKo6xMyEF1FlMiCWadhzrRmIXSmq55mF/lmsBx+LwB/ Lz5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x2BYLZxIxSAdt8ypoIQIORGGOqYh56gnCIuumwf7wWQ=; b=mqOVBLk0ZjhA/hCID8/nv/hovS/5/2BviJDzsrBA0VDf+tZ73vofwWQ45A7meFbnLk DWd5PSQ1JWUwCRlxJ7uBLl7pLbKImUBEeIQoT0pBTBDPEtBRZebKET42tr0X29NSVNiB zL6vHrVkRHqtw1aT3HrYZbew9VMVXt/ycD5Ix610FroC2/MB45Fu7O0PzMmE7UZJN5ga 4cUf5T9TuOSckUQMe6QIiOfkk5arkuWnFAZ1lOZSUGOUxQZdmIHsRHi6MMPO5ZFR0Rnz S2cds3oNMRC372qW9jC/Xdzj5hUM7FqiqO1HqkH57Ew9A4XNk4IyvpUMXJ3IfcUXGyge hZkA==
X-Gm-Message-State: APjAAAX1gN6qK+HuGJbYkHD5uVSP8B5Awc1NrJDvEmhpJF1GOaCxICzJ 1Wd3QZAJWCqgDNqmR/kw1di4mr7ENpQSeMJA3hSdsQ==
X-Google-Smtp-Source: APXvYqyMg9u+FQN8yjW5bbJ3saZU6ASCWr7o2kNaxodf+eTNakKybBufK71tbhOc+FSoSoSgXhM7756TWX9eRG1A0XI=
X-Received: by 2002:a17:906:448e:: with SMTP id y14mr14770700ejo.136.1572695116290; Sat, 02 Nov 2019 04:45:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Date: Sat, 2 Nov 2019 12:45:00 +0100
Message-ID: <>
To: Joerg Ott <>
Cc:,,, dmm <>
Content-Type: multipart/alternative; boundary="000000000000bf3eb305965b9d43"
Archived-At: <>
Subject: Re: [DMM] Tsvart last call review of draft-ietf-dmm-pmipv6-dlif-04
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: Sat, 02 Nov 2019 11:45:27 -0000

Hi Joerg,

We've just posted a new revision addressing your comments.



On Fri, Oct 18, 2019 at 1:24 PM CARLOS JESUS BERNARDOS CANO <>

> 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
>> 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
>> 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
>> 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":

Special Issue "Beyond 5G Evolution":