RSVP-TE Path Diversity Using Exclude Route
draft-ietf-teas-lsp-diversity-10

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. 

I did find much of the document well written and an easy read. The diagrams were also (surprisingly) clear.

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)

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

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?

The Abstract should stand on its own; and, as such, needs to expand the "XRO" and "EXRS" acronyms (similar to the Introduction).

For completeness, the definition of the "E" flag in section 2.1 probably needs to indicate that bit 0x08 is reserved, and MUST be set to 0 send, ignored on receipt.

In section 3.2, on page 19, concerning the following text:

      If, subsequent to the initial signaling of a diverse LSP, the 
      requested exclusion constraints for the diverse LSP are no longer 
      satisfied and an alternative path for the diverse LSP that can 
      satisfy those constraints exists, then: 

The phrasing "no longer satisfied" seems a bit incomplete, as (by my understanding) the constraints might not have been satisfied in the first place, if the L-bit was set in the initial request. I presume that, if this were to happen, you'd want to signal when a compliant path became available -- but the current text doesn't indicate that this is okay. Perhaps something like: "...are no longer satisfied (or, in the case that the initial request triggered a "Failed to satisfy Exclude Route" error subcode, remain unsatisfied), and an alternative path for..."

From the abstract: "Three different
mechanisms are supported how LSP diversity can be accomplished in
the provider or core network:..."

Is there a missing word around "... supported how..."?

I'm not sure that the security considerations here are accurate. Specifically, the PAS seems like it might potentially leak information about paths, because if I am able to learn someone else's PAS values, I can tell if they are routed along the same paths as I am. Is that correct? If so, it seems like it might be useful to recommend self-encrypting PAS values so that two identical paths given to separate people have different PAS values.

Also, it seems like it S 2.3 would be clearer if you factored out the algorithm for processing the XRO values from the differential treatment depending on the L bit. Perhaps you could just have one list and use [SHOULD (L=1), MUST(L=0)] or something?

I agree with the SecDir review, but don't see a response so I am bringing attention to it here:
https://mailarchive.ietf.org/arch/msg/secdir/pLKMfe4j8dPeNdEgWYu3SAnC-rs

- Maybe RFC4920 should be a normative reference (due to sec 1.1)?

I’m looking at this text,

           0x04 = Penultimate node exception
   
               Indicates that the penultimate node of the LSP being
               signaled MAY be shared with the excluded path even when
               this violates the exclusion flags.

and wondering whether you could either provide some recommendation about doing this/not doing this, or give an example of why doing this/not doing this makes operational sense. The other exceptions do make sense to me, so I’m only curious about this one.

* Section 2.1
  Is there a separate diversity identifier type called "IPv6 Client Initiated Identifier" as referenced in the following text

"When the diversity identifier type is set to "IPv6 Client Initiated Identifier""

If there isn't such a DI Type, can you please fix this text.