Re: [RTG-DIR] [Pce] RtgDir review: draft-ietf-pce-association-diversity-08.txt
Mahend Negi <mahend.ietf@gmail.com> Sat, 31 August 2019 09:53 UTC
Return-Path: <mahend.ietf@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 0B0481200A3; Sat, 31 Aug 2019 02:53:36 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 tJ5lNwYK8-FW; Sat, 31 Aug 2019 02:53:32 -0700 (PDT)
Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 A3D05120099; Sat, 31 Aug 2019 02:53:32 -0700 (PDT)
Received: by mail-ot1-x32b.google.com with SMTP id 100so9324489otn.2; Sat, 31 Aug 2019 02:53:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0PXK8UYwV8LwAMGYo1pS67PwitdQ58hZ/Dy5XA95oaI=; b=T0vFU8CTf7Rr08EUrIO4mFlyf912Sw8eYdRZ7ct8rQUqBU0H4oZ2cIe27kuE0LOSw8 h1zLVyRt7o+ckZjepSEhIDAslzMU1LxxeBkh4h4dL4NKY8OXtViUo6Bi3J38fT4W4P1J 2zzTfQ7WcX7/0+KHzeF9UmgW6hE3hmaCaDy1qih7tchmLb6tPifnuQj1/ar2+UA/YeIh UlBkHXkvX1PINXF9D0gavWe6BZIh48lVcVwPM8Jg0C4XmnTHJyqbXCKUbvQkGrhG2Zb2 DPKPSL04EvT6rACksy9Vx9/+kLbStN7JT1Fp0awt0da37lXkMZzZMwn977pour4DOksx ZtTQ==
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=0PXK8UYwV8LwAMGYo1pS67PwitdQ58hZ/Dy5XA95oaI=; b=NKeJT/gIbIEkMvfTDCXO9rFuptiBMdt7fd8fopN/NT+nGJ0fmaTxMo1WbUnqUcEpkd 6n5FENrZLqQEJp3KpdyDwvlj4PAgxHlUcNyHNixLMVORr4xoDdYMN0oGdimGLS/2qnk0 Osvr1ts7UQk+jFHym6oFi29aR6n0rk+gVA5+k6aAQ36hpd5+T6zjjQSqHW7ZkX8TPwMD HAajyxjfF1UvA2EMgjhxRruaQxslfU6Ee44eo/j2djegD3+ViZ7Uief73BZUPGNeTcgm wg5lyRrhOHbS/riOd+71DtfVxWIXgBsRG+2tnp+O/iEsDkJDpeDpFvhL21uUr0LHc8XB IKnA==
X-Gm-Message-State: APjAAAVwTPKKzquCnR1O8RRQnSKolRi7E63UMBWYCWqoal9LWgsCGWke sUpJHhEsLGt8gD7PSqsmjg0ZCP+/AK2c/E7AhAQ=
X-Google-Smtp-Source: APXvYqzBEQRmR7nFeqhfmvXyegO67SWw0bcioixZ+GtFeSaj5DmOjeTM+a5A7SCk7CqL8MFEtOkpl+iVXItXh0YXL6M=
X-Received: by 2002:a9d:6213:: with SMTP id g19mr14937717otj.257.1567245211988; Sat, 31 Aug 2019 02:53:31 -0700 (PDT)
MIME-Version: 1.0
References: <CANK0pbZ0kpXHoT80Xj40KoR_B+w_frwhUn082aEwMLi=AWxSyA@mail.gmail.com> <CAM5Nu_wq1jNmjyYrHqmpA+Reb7wkXCy2JH_XNPC9D67DSK1kNQ@mail.gmail.com> <CANK0pbYVB1fY44v9Qab+4D3FROPkHihJyrEPykwf0-8OUD1LRg@mail.gmail.com>
In-Reply-To: <CANK0pbYVB1fY44v9Qab+4D3FROPkHihJyrEPykwf0-8OUD1LRg@mail.gmail.com>
From: Mahend Negi <mahend.ietf@gmail.com>
Date: Sat, 31 Aug 2019 15:23:20 +0530
Message-ID: <CAM5Nu_zBQQ9+j6EWG7z07V1+rmhdW9f58dLVE8EFFwrPHMHRjg@mail.gmail.com>
To: Emmanuel Baccelli <Emmanuel.Baccelli@inria.fr>
Cc: draft-ietf-pce-association-diversity.all@ietf.org, "<rtg-ads@ietf.org>" <rtg-ads@ietf.org>, rtg-dir@ietf.org, pce@ietf.org
Content-Type: multipart/alternative; boundary="00000000000022f94a059166b6b1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/ICUBtU_LZ-Ld9X6zYVyerbXSMVw>
Subject: Re: [RTG-DIR] [Pce] 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: Sat, 31 Aug 2019 09:53:37 -0000
Hi Emmanuel, Thanks for your review, updated in the new version. FYI: New Version: https://datatracker.ietf.org/doc/html/draft-ietf-pce-association-diversity-10 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-association-diversity-10 Regards, Mahendra On Mon, Aug 26, 2019 at 4:09 PM Emmanuel Baccelli < Emmanuel.Baccelli@inria.fr> wrote: > Dear Mahend > > thanks for you answers. Your changes look fine to me. > > Two last nits: > > - in the sentence you added in section 5.6 when the T flag is set, "In > case of other PCEP message, the PCE MUST return a PCErr message with > Error-Type 26". > => PCEP message other than what? This is not crystal clear. I suggest you > clarify explicitly. > > - in the sentence you added in section 5.6 when the T flag is unset, "the > PCE is allowed to relax disjointness by either applying a requested > objective function (Section 5.4) if specified. Otherwise the PCE is > allowed to reduce the required level of disjointness (as it deems fit)" > => as-is, there seems to be a typo: a spurious "either". How about: > > "the PCE is allowed to relax disjointness by applying a requested > objective function (Section 5.4) if specified. Otherwise, if no objective > function is specified, the PCE is allowed to reduce the required level of > disjointness as it deems fit" > > Cheers > > Emmanuel > > On Tue, Aug 13, 2019 at 4:58 PM Mahend Negi <mahend.ietf@gmail.com> wrote: > >> Hi Emmanuel, >> >> Thanks for your comments. Please see inline, do find attached reworked >> draft and version-diff for reference. >> >> On Tue, Aug 13, 2019 at 3:21 AM Emmanuel Baccelli < >> Emmanuel.Baccelli@inria.fr> wrote: >> >>> 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? >>> >> >> When T flag is set, we would have a case of no-path for the new LSP. It >> would be good to also indicate that the new LSP could not be added into the >> association group. I have added text for this. >> >> What is the state of other LSPs in an existing association after another >>> LSP was added, which resulted in the required disjointness now fails? >>> >> >> The other LSPs would not be impacted. So as such there is no specific >> security threat with T flag. But, it would be good to add some generic >> text. Updated section - >> >> 6. Security Considerations >> >> >> This document defines one new type for association, which on itself does >> not add any new security concerns beyond those discussed in >> >> [RFC5440], [RFC8231] and [I-D.ietf-pce-association-group]. But, adding of >> a spurious LSP into the disjointness association group >> >> could lead to re-computation and set-up of all LSPs in the group, that >> could be used to overwhelm the PCE and the network. >> >> >> Also, as stated in [I-D.ietf-pce-association-group], much of the >> information carried in the Disjointness Association object, as per >> >> this document is not extra sensitive. It often reflects information that >> can also be derived from the LSP Database, but association >> >> provides a much easier grouping of related LSPs and messages. The >> disjointness association could provide an adversary with the >> >> opportunity to eavesdrop on the relationship between the LSPs. Thus >> securing the PCEP session using Transport Layer Security (TLS) >> >> [RFC8253], as per the recommendations and best current practices in >> [RFC7525], is RECOMMENDED. >> >>> >> >> >>> 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. >>> >> >> OK >> >>> >>> 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. >>> >> >> OK >> >>> >>> 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. >>> >> >> Added (as it deems fit). >> >> >>> 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". >>> >> Your assumption is right. >> >> >>> >>> 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. >>> >> I think, adding "as it deems fit" is better and let implementations >> decide with protocol signalling the result. >> >> >>> 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. >>> >> Do you still feel this to be necessary? I am not too sure. >> >> >> Thanks! >> >> >> _______________________________________________ >>> Pce mailing list >>> Pce@ietf.org >>> https://www.ietf.org/mailman/listinfo/pce >>> >>
- [RTG-DIR] RtgDir review: draft-ietf-pce-associati… Emmanuel Baccelli
- Re: [RTG-DIR] [Pce] RtgDir review: draft-ietf-pce… Mahend Negi
- Re: [RTG-DIR] [Pce] RtgDir review: draft-ietf-pce… Emmanuel Baccelli
- Re: [RTG-DIR] [Pce] RtgDir review: draft-ietf-pce… Dhruv Dhody
- Re: [RTG-DIR] [Pce] RtgDir review: draft-ietf-pce… Mahend Negi