Hi Emmanuel, Thanks for you review, the last two nits seems reasonable to me.
Regards, Dhruv 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
