[RTG-DIR] RtgDir review: draft-ietf-pce-association-diversity-08.txt

Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr> Mon, 12 August 2019 21:51 UTC

Return-Path: <emmanuel.baccelli@gmail.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E241120896; Mon, 12 Aug 2019 14:51:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.397
X-Spam-Level:
X-Spam-Status: No, score=-1.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 jNrhwVqgzbpy; Mon, 12 Aug 2019 14:51:38 -0700 (PDT)
Received: from mail-ot1-f47.google.com (mail-ot1-f47.google.com [209.85.210.47]) (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 B0AE7121649; Mon, 12 Aug 2019 06:18:51 -0700 (PDT)
Received: by mail-ot1-f47.google.com with SMTP id c34so18513306otb.7; Mon, 12 Aug 2019 06:18:51 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=GlG/nqEZRC+OPb63Z0vAm+rspyg+azAoVgMryJh6IxA=; b=n4reSzFOz36F9CM68RSy4gcyLnaxB14cI3bV4gUCeMO2GYw9oyZEFyrNRrYq6BLhQ1 SntXUmN/1LrkI4WULLTJF3krBVA/+UM2+s/14Zi6jLFigQtdtoZuIa4OTSZyObeQVA5a Rf2KGrTeQCdKDXi2pq8zRruYoQyozvDMVr0nRyyxqvtHu4bFq5OTVdaQ7TVwMZCiWAMy HgnHRbEbk3Xu2M+njIpUan40sU7PTRm6+J/IW8V8mq5TBVU4tzrBOqKzS175x0t1TgvE 8ByrzlFGUruY4YgXww2qj36o3EzRm71VEW4uu+jgFVJLOoaNXth4+eFCMQvEGF6ADRoJ uRVw==
X-Gm-Message-State: APjAAAWN9NOD2Uzl9nhP7+aA4iGR1LoK2ptGfcJpk1+oO52lm9p+/ikz gWzCTIzPdISXqRK9lldEwDVtbvXm8L2xwBqbnCSX3kex
X-Google-Smtp-Source: APXvYqxy7Ogc7TMJYq4bi4kMKH38kEp+q/zL153BtybOEVgf2UT5qcmupy78ypDb2qyUbRfMAvtAcUgb34XsAqgGqBs=
X-Received: by 2002:aca:b1c1:: with SMTP id a184mr14022841oif.2.1565615930783; Mon, 12 Aug 2019 06:18:50 -0700 (PDT)
MIME-Version: 1.0
From: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Date: Mon, 12 Aug 2019 15:18:39 +0200
Message-ID: <CANK0pbZ0kpXHoT80Xj40KoR_B+w_frwhUn082aEwMLi=AWxSyA@mail.gmail.com>
To: "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>
Cc: rtg-dir@ietf.org, draft-ietf-pce-association-diversity.all@ietf.org, pce@ietf.org
Content-Type: multipart/alternative; boundary="00000000000068ba48058feb5d8a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/ZuYWZyNHY6nmDtJg_CwoJy2EsrE>
Subject: [RTG-DIR] RtgDir review: draft-ietf-pce-association-diversity-08.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Aug 2019 21:51:41 -0000

Hello,

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and sometimes
on special request. The purpose of the review is to provide assistance to
the Routing ADs. For more information about the Routing Directorate, please
see http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft.

Document: draft-ietf-pce-association-diversity-08.txt
Reviewer: Emmanuel Baccelli
Review Date: 12/08/2019
Intended Status: Standards Track

Summary of comments:

    The procotol extension is simple, and its operation is documented
pretty well.
    The document is concise, and clear from my point of view.
    See below a couple of remarks that could be considered prior to
publication.

Major Issues:

    No major issues found.

Minor Issues:

    In Section 5 (Security): If I understand correctly, dynamically adding
a new LSP to an existing disjoint association affects the (re)computation
and the (re)characterization of all LSPs in this association. In this case,
is it entirely obvious to me that there is no specific threat using the
attack vector of adding an LSP to an existing association, when flag T is
set?
What is the state of other LSPs in an existing association after another
LSP was added, which resulted in the required disjointness now fails?

Nits:

    In Section 3 (Motivation): In my opinion, this section might benefit
from being split in two: a pure motivation section, and an applicability
section.

    In Section 4.1: it is stated that "a PCE may be limited in the number
of LSPs it can take into account when computing disjointness" [...] "the
PCE may provide no path, a shortest path, or a constrained path based on
relaxing disjointness, etc.  The disjoint status is informed to the PCC."
Here, it would be useful to forward reference to section 4.6.

    In section 4.6: the spec seems to suppose that there exists an absolute
order ranking different levels of disjointness,
such that a PCE can simply take the decision to "reduce disjointness" to
the next best level.
I suspect that this is not always easy to rank in complex cases, if at all
possible.

Are some more flags foreseen (tbd in section 6.2 ?) for more fine-grained
characterization of "relaxed disjointness" in complex cases e.g. when
adding an LSP to an already-large disjoint association ?
I assume the answer is "not really".

Assuming the above, without becoming too ugly, specification could be more
explicit about ranking levels of disjointness which relaxing decisions
should be made, when flag T is unset.
Else, the spec could add a clarifying sentence on the difficulty of
ordering absolutely many different levels of disjointness for many LSPs, in
the same association.