[Teas] Alvaro Retana's No Objection on draft-ietf-teas-sr-rsvp-coexistence-rec-03: (with COMMENT)

[Alvaro Retana <[e-mail]>]

Alvaro Retana has entered the following ballot position for
draft-ietf-teas-sr-rsvp-coexistence-rec-03: 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-sr-rsvp-coexistence-rec/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) The Abstract says that this document provides "solution options" -- it
would be very nice if a recommendation (or at least general guidance) was
provided by the authors.  This point was brought up in the OpsDir review [1],
to which the authors replied:

   "The intent behind the recommendations is to not take a position on which
   solution is preferable. All solutions are valid but some do not satisfy all
   the requirements. However, if a solution is acceptable (based on their
   deployment of SR and RSVP and knowing which requirements are not satisfied)
   for an operator then such a solution can be chosen. "

That seems like a reasonable answer.  It would be good if, at least, text to
the effect was included in the document.

(2) Given, from the text above, that not all requirements may be as important
in a specific deployment, I find the use of rfc2119 language to describe them
(in the Introduction) confusing and inappropriate.  Please consider not using
Normative text in that section.

(3) While wondering whether there was a recommendation coming out of this
document, I looked for other documents referencing it, and found 1:
draft-ietf-mpls-rsvp-shared-labels ("Signaling RSVP-TE tunnels on a shared MPLS
forwarding plane").  I realize that the topic is not exactly a match, but this
sentence is included in it: "The RSVP-TE tunnels that use this shared
forwarding plane can co-exist with MPLS-SR LSPs
[I-D.ietf-spring-segment-routing-mpls] as described in
[I-D.ietf-teas-sr-rsvp-coexistence-rec]."

I took a very quick look at draft-ietf-mpls-rsvp-shared-labels and the
mechanism described there didn't look like any of the options described here. 
Is the mechanism described in draft-ietf-mpls-rsvp-shared-labels an option to
the problem addressed in this document?  If so, is it worth including a short
description?  If not, then the sentence above sounds misleading.

[I realize I may be asking questions about a different document...but I'm
taking the license given that the editor for this document is also an author in
the other one. ;-) ]

(4) Nits:

(4.1) This text in the Abstract seems redundant: "In some instances, operators
are also migrating existing services from RSVP-TE to SR LSPs...In other cases,
services running on RSVP-TE might be migrated to run over SR."

(4.2) From §3.2:
   Note that it is not enough for the controller to just maintain the
   unified view of the available capacity, it must also perform the path
   computation for the RSVP-TE LSPs, as the reservations for the SR LSPs
   are not reflected in the TED.  This does not fit with assumption 2
   mentioned earlier.

Assumption 2 says that "Engines that compute RSVP-TE paths may have no
knowledge of the existence of the SR paths in the same domain.", but in the
scenario described here (where the controller "must also perform the path
computation for the RSVP-TE LSPs"), then the assumption is not true as the
controller would in fact have knowledge of the coexistence.  This is just a
nit: I don't think the last sentence is accurate...

(4.3) This text is normatively redundant: "It is RECOMMENDED that the IGP-TE
update threshold SHOULD be lower..."  RECOMMENDED and SHOULD mean the same
thing.

[1] https://mailarchive.ietf.org/arch/msg/ietf/KwkK9VbeISPl9zgVmzdwLOB2FM0