Opsdir last call review of draft-ietf-teas-sr-rsvp-coexistence-rec-02

Al Morton <acmorton@att.com> Fri, 13 April 2018 00:12 UTC

Return-Path: <acmorton@att.com>
X-Original-To: ietf@ietf.org
Delivered-To: ietf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4201D12D7ED; Thu, 12 Apr 2018 17:12:48 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Al Morton <acmorton@att.com>
To: ops-dir@ietf.org
Cc: ietf@ietf.org, teas@ietf.org, draft-ietf-teas-sr-rsvp-coexistence-rec.all@ietf.org
Subject: Opsdir last call review of draft-ietf-teas-sr-rsvp-coexistence-rec-02
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152357836822.26354.17205107713324070834@ietfa.amsl.com>
Date: Thu, 12 Apr 2018 17:12:48 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/KwkK9VbeISPl9zgVmzdwLOB2FM0>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.22
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2018 00:12:48 -0000

Reviewer: Al Morton
Review result: Has Nits

    Recommendations for RSVP-TE and Segment Routing LSP co-existence

This memo considers coexistence of SR LSPs and RSVP-TE LSPs,
or migration to SR, and lists 5 methods as solutions to the
problems posed.  Although only one of the solutions (3.5) is
developed in detail, the text never makes a clear recommendation
among the 5 solutions. At least two seem viable (3.1 and 3.5).
Operators would probably appreciate a clear recommendation from 
the authors, if possible.

Edits/nits follow, see [acm]:

1.  Introduction

   The problem space can be generalized as a dark bandwidth problem to
   cases where any other service exists in the network that runs in
   parallel across common links and whose bandwidth is not reflected in
   the available and reserved values in the TED.  The general problem is
   management of dark bandwidth pools and can be generalized to cases
   where any other service exists in the network that runs in parallel
   across common links and whose bandwidth is not reflected in the
   available and reserved values in the TED. 
You've written two sentences above that essentially say the same thing.
Although it appears in the Abstract, TED should be spelled-out in the 
body text.

   In most practical
   instances given the static nature of the traffic demands, limiting
   the available reservable bandwidth available to RSVP-TE has been an
   acceptable solution.  However, in the case of SR traffic, there is
   assumed to be very dynamic traffic demands and there is considerable
   risk associated with stranding capacity or overbooking service
   traffic resulting in traffic drops.

   The high level requirements or assumptions to consider are:

   1.  Placement of SR LSPs in the same domain as RSVP-TE LSPs MUST NOT
       introduce inaccuracies in the TED used by distributed or
       centralized path computation engines.

   2.  Engines that compute RSVP-TE paths MAY have no knowledge of the
       existence of the SR paths in the same domain.
[acm] suggest 
s/2.../Knowledge of the
       existence of the SR paths in the same domain is OPTIONAL for
	   engines that compute RSVP-TE paths./
or, s/MAY/may/ since this is only an assumption?

   3.  Engines that compute RSVP-TE paths SHOULD NOT require a software
       upgrade or change to their path computation logic.

   4.  Protocol extensions SHOULD be avoided or be minimal as in many
       cases this co-existence of RSVP-TE and SR MAY be needed only
       during a transition phase.

   5.  Placement of SR LSPs in the same domain as RSVP-TE LSPs that are
       computed in a distributed fashion MUST NOT require migration to a
       central controller architecture for the RSVP-TE LSPs.

2.  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Solution options

3.1.  Static partitioning of bandwidth

   In this model, the static reservable bandwidth of an interface can be
   statically partitioned between SR and RSVP-TE and each can operate
   within that bandwidth allocation and SHOULD NOT preempt each other.

   While it is possible to configure RSVP-TE to only reserve up to a
   certain maximum link bandwidth and manage the remaining link
   bandwidth for other services, this is a deployment where SR and RSVP-
   TE are separated in the same network (ships in the night) and can
   lead to suboptimal link bandwidth utilization not allowing each to
   consume more, if required and constraining the respective

   The downside of this approach is the inability to use the reservable
   bandwidth effectively and inability to use bandwidth left unused by
   the other protocol.
... so this option satisfies all requirements and assumptions?

3.2.  Centralized management of available capacity

   In this model, a central controller performs path placement for both
   RSVP-TE and SR LSPs.  The controller manages and updates its own view
   of the in-use and the available capacity.  As the controller is a
   single common entity managing the network it can have a unified and
   consistent view of the available capacity at all times.
Comment and a question:
This also makes the central controller a single point of failure.
What is the Recovery & Restoration Strategy? (care to cite a reference?)

   A practical drawback of this model is that it requires the
   introduction of a central controller managing the RSVP-TE LSPs as a
   prerequisite to the deployment of any SR LSPs.  Therefore, this
   approach is not practical for networks where distributed TE with
   RSVP-TE LSPs is already deployed, as it requires a redesign of the
   network and is not backwards compatible.  This does not satisfy
   requirement 5.

   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.
... So, this option fails to satisfy key requirements and assumptions.
(suggest to state that)


3.5.  TED consistency by reflecting SR traffic


   The following methodology can be used at every TE node for this
sugest to identify this list as Parameters for the methodology.
s/solution:/solution, using the following parameters:/

   o  T: Traffic statistics collection time interval

   o  N: Traffic averaging calculation (adjustment) interval such that N
      = k * T, where k is a constant integer multiplier greater or equal
      to 1.  Its purpose is to provide a smoothing function to the
      statistics collection.
k should be a separate list item, preceding N.