Re: [Teas] Warren Kumari's No Objection on draft-ietf-teas-lsp-diversity-08: (with COMMENT)

[Warren Kumari <[e-mail]>]

On Thu, Nov 2, 2017 at 1:29 PM, Dieter Beller <[e-mail]> wrote:
> Hi Warren,
>
> my apologies for the late response - it was difficult for me finding time in
> the last weeks to address the IESG review comments.
>
> Please find inline below how we suggest to address your comments.
>
> Could you please let us know whether your comments are adequately addressed.

Yes thank you -- your solutions work for me, thanks for addressing my comments.
W

>
>
> Thanks,
> Dieter and co-authors
>
> On 30.08.2017 21:51, Warren Kumari wrote:
>
> Warren Kumari has entered the following ballot position for
> draft-ietf-teas-lsp-diversity-08: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-teas-lsp-diversity/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I support Adam's position. I also think that Ignas Bagdonas' OpsDir review (
> https://datatracker.ietf.org/doc/review-ietf-teas-lsp-diversity-08-opsdir-lc-bagdonas-2017-08-30/
> ) needs careful consideration / addressing. I almost balloted DISCUSS from
> them, but trust that they will be addressed.
>
>
> We are carefully considering these review comments.
>
>
> I did find much of the document well written and an easy read. The diagrams
> were also (surprisingly) clear.
>
>
> thanks for this positive feedback!
>
>
> I have some nits / comments, mainly around the abstract.
> 1:   "Resource ReserVation Protocol-Traffic Engineering (RSVP-TE)"  -
> s/ReserVation/ReSerVation/ (otherwise the (R)RSVP would be (R)RVP)
>
>
> Changed as suggested.
>
>
> 2: " Three different mechanisms are supported how LSP diversity can be
> accomplished in the provider or core network: ..." - this doesn't really
> parse.
> Perhaps " Three different mechanisms providing LSP diversity in the provider
> or
> core network are supported:..." ? Not great, but ...
>
>
> We modified this sentence as follows:
>
> Three different mechanisms are defined to accomplish LSP diversity in the
> provider or core network: the signaled diversity type indicates whether
> diversity is based on client, path computation engine (PCE), or network
> assigned identifiers.
>
> 3: "The solution described in this document is based on the assumption that
> LSPs are requested sequentially, i.e., the time period between the LSP setup
> requests for the two LSPs may be longer (days, weeks, months)." -- may be
> longer than what? Perhaps "may be relatively long" or "may be on the order
> of
> days / weeks / months"?
>
> 4" "Re-routing the first LSP that may have existed for a longer period of
> time
> is not considered." - again, longer than what? Longer than the second (/
> Ntn)?
> Longer than months?
>
>
> Does the following revised text address your comments 3 and 4?
>
> The solution described in this document is based on the assumption that LSPs
> are requested sequentially, i.e., the time period between the LSP setup
> requests for the two LSPs may be relatively long (in the order of days,
> weeks, months). Re-routing the LSP that was established first and may have
> existed for some time is not considered.
>
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf