Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path Diversity using Exclude Route
Summary: Has enough positions to pass.
Deborah Brungard Yes
Ben Campbell No Objection
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..."?
Benoit Claise No Objection
Spencer Dawkins No Objection
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.
Suresh Krishnan No Objection
* 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.
Warren Kumari No Objection
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?
Mirja Kühlewind No Objection
- Maybe RFC4920 should be a normative reference (due to sec 1.1)?
Terry Manderson No Objection
Kathleen Moriarty No Objection
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
Eric Rescorla No Objection
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?
Alvaro Retana No Objection
Adam Roach No Objection
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..."