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

From: Alvaro Retana <[email-masked]>
Date: Tue, 08 May 2018 05:47:19 -0700

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

---

From: Harish Sitaraman <[email-masked]>
Date: Wed, 9 May 2018 17:40:07 +0000

Hi Alvaro,

Thanks for your review comments. Please see inline [HS]...

On 5/8/18, 5:47 AM, "Alvaro Retana" <[email-masked]> wrote:

    Please refer to https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_iesg_statement_discuss-2Dcriteria.html&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CXKOXD_3UIPrRhmyXS8lTOnJ2ZY8S-bng806Yu9IBa0&m=TLOz2gHnca7-96T3D19D0PaKwAjLfXD-9Omd2gL5Xig&s=F5hyR8TprarYNOOmisrr3vphde9_VoIu_k2gndnt27E&e=
    for more information about IESG DISCUSS and COMMENT positions.

    The document, along with other ballot positions, can be found here:
    https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dteas-2Dsr-2Drsvp-2Dcoexistence-2Drec_&d=DwIDaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CXKOXD_3UIPrRhmyXS8lTOnJ2ZY8S-bng806Yu9IBa0&m=TLOz2gHnca7-96T3D19D0PaKwAjLfXD-9Omd2gL5Xig&s=A3WH8hRvuZ8tnerORf6Nf31nkO-7Y22n8JXq1n3uihE&e=

    

[HS] Ok. We can add the following text in section 3 (before 3.1):
[HS]
The following section lists SR and RSVP co-existence solution options. A specific solution is not recommended as
all solutions are valid even though some may not satisfy all the requirements. If a solution is
acceptable for an operator based on their deployment model then such a solution can be chosen.

[HS] I'm ok to lower case the normative words in all requirements considering an operator can still choose a solution knowing that it provides.

    

[HS] The point in the shared-labels draft is that if there was a network running that new SR RSVP-TE tunnel and 
if that network needs to introduce SR then any of the solutions in the co-existence draft can still be used. In any case, 
no change is required in the co-existence draft and we can revisit the text in the shared-labels draft later, if necessary.
   
    (4) Nits:

[HS] We can remove the line "In other cases, services running on RSVP-TE might be migrated to run over SR."
    
    (4.2) From §3.2:

[HS] We can remove the last sentence "This does not fit with assumption 2 mentioned earlier."
The intent with the requirement was that RSVP-TE compute engines may be distributed but in this
case both are centralized.

[HS] We can change this to "The IGP-TE update threshold SHOULD be lower..."

--
Harish