Last Call Review of draft-ietf-teas-lsp-diversity-08
review-ietf-teas-lsp-diversity-08-opsdir-lc-bagdonas-2017-08-30-00

Hi there.

I have reviewed this document as part of the Operations Directorate's document
review process.

Overall the document seems to be heading in the right direction. There are some
issues related to clarity of RFC2119 language usage, especially less
restrictive forms and how that would relate to interoperability, the handling
of undefined values and errors, terminology could be aligned better to base
GMPLS and TE specifications. The document does not cover manageability or
operational considerations at all - given that it is proposing protocol
extensions that require operator involvement, a section on operational
considerations and possible extensions to management models and procedures
should be covered. The Path-Key based signalling form seems to have interdomain
signalling related security aspects that would need to be looked a bit deeper.
The document would benefit from terminology and acronyms section specific to
the proposed mechanism.

The larger comment on time scale and granularity aspects of SRLG aware path
calculation. The document is based on the assumption of a longer time period
between LSP signalling requests and path reoptimizations. What is the reason
for it, and what would be needed if the proposed solution is expected to
operate in closer to real time environment (minutes instead of weeks)? What is
the source of the time granularity restriction?

Diversity information flooding specifics are stated as being out of scope. How
would that impact interoperability?

PAS identifier name space may be smaller or not comparable with SRLG group
identifier name space, is there a need to have any form of mapping mechanism in
place?

Small nits:

- Example based on figure 1 has got details wrong.

- Terms need to be consistent throughout the document - initiated/controlled is
used interchangeably, this seems to be coming from the merge of the 3 original
drafts.

- There is no "IPv4/IPv6" diversity identifier, they are separate per address
family and text should be expanded to describe them separately.

- Could the text describing the operation of L bit be simplified by stating
that L bit has the same semantics as in any other object - strict/loose hop
selection, and therefore diversity identifier is interpreted as a strict or
loose entity that MUST or MAY be taken into account?

There is a set of editorial nits and fixes throughout the document, a marked
version of the document is attached.

Thank you.

Ignas