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

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