[Teas] Alvaro Retana's No Objection on draft-ietf-teas-sr-rsvp-coexistence-rec-03: (with COMMENT)
Alvaro Retana <aretana.ietf@gmail.com> Tue, 08 May 2018 12:47 UTC
Return-Path: <aretana.ietf@gmail.com>
X-Original-To: teas@ietf.org
Delivered-To: teas@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81F7D12DA26; Tue, 8 May 2018 05:47:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana <aretana.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-teas-sr-rsvp-coexistence-rec@ietf.org, Lou Berger <lberger@labn.net>, teas-chairs@ietf.org, teas@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.80.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152578363952.16205.2655023440805977966.idtracker@ietfa.amsl.com>
Date: Tue, 08 May 2018 05:47:19 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/oGBkK_T43_4-pN9jAfa1z7eilJA>
Subject: [Teas] Alvaro Retana's No Objection on draft-ietf-teas-sr-rsvp-coexistence-rec-03: (with COMMENT)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 May 2018 12:47:20 -0000
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
- [Teas] Alvaro Retana's No Objection on draft-ietf… Alvaro Retana
- Re: [Teas] Alvaro Retana's No Objection on draft-… Harish Sitaraman