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 < [email protected]> 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 <[email protected]> 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 < >> [email protected]> 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 >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/pce >>> >>
_______________________________________________ Pce mailing list [email protected] https://www.ietf.org/mailman/listinfo/pce
