Re: [Pce] Opsdir last call review of draft-ietf-pce-stateful-pce-auto-bandwidth-10

Dhruv Dhody <> Thu, 29 August 2019 05:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 46DD8120879; Wed, 28 Aug 2019 22:15:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YL_xKMfi7Hxe; Wed, 28 Aug 2019 22:15:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 752EA120220; Wed, 28 Aug 2019 22:15:16 -0700 (PDT)
Received: by with SMTP id z3so4454769iog.0; Wed, 28 Aug 2019 22:15:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QcElg+9mHhPIBlJ7Mo9A/Or+EQehgMr14P0yFBjDk2U=; b=Y6HRm1z0a6QKojJltjZvQV6S07VbRdCeTwYFtNIPyC/raTMflGM0FU1JGZzXwI6wzg TA84a7tGVs1cTEPoLdwq3xFtRYhipnh5Z7yzfAIxBDOgZRQ7k3/aJJUC8I0m0aIAdlES rXdjMezCcWHERD/KIsek2IF+jVcOsOG+HFvp4/vez0QsQQVewYD7h6Lc3u1pUrZ2TmR2 H0Cgdb8VQF3sdt7KrVneu8eEI8pcZKJv6PLYwGqzpZ3roc/ybqVf/kbUNZu1Q0WIOFgJ yFqjIZfTTpct+MutML+jvpvLmCfAFjxsdOPXoviyYrMNuBs4wdLeRc8qoJUpejllhb2l YQzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QcElg+9mHhPIBlJ7Mo9A/Or+EQehgMr14P0yFBjDk2U=; b=IOn6JllmRwI8EH5o7Nm+CQo6WmYNIljkmY02u+A88r4ZZ89DvYqa1Ujo639dX8ynHh /MK/hwlBFHZvB7AZGoKBRdsfVdmp/m1T3P2PusNzUG5C1lPmoVQH7HnAfF+2HnFsdrq7 j1vJeWK5yxbX48c4lyAktn1/ZuTsqaQGHDvPzXcjiL/RHN99y6q2ZW8UVPpvoWs9O5WO 0bQv/HEwd40/WEAmp7abcS6aepywS89WvNT1rOzYmhD3ifWEd1KDTguiwX5d2gzryQ4h MTY9/hmwBm0Hr49qgNS76x/yHrNcdNwqFW5y5Eyvx4FcxN7+DZRFxRy3OKG0yEy44Vsf ierQ==
X-Gm-Message-State: APjAAAX5Zx31PU3A/xLFp4qFQ9rLG8HDtWXZcoVkiHezd6zYLI6pKbbZ aFcXuFDmtNp7KwjSUUyaE+Yjbg1tIMF3j29XZF0=
X-Google-Smtp-Source: APXvYqy4DS/rwK7f3Qjf6UrvST53JYfUbDkLRZhjtZUMzM1aZmNJkZ/IhkmG5dKYXXN9mW1ojknAiCqlxW9hB+kX11Q=
X-Received: by 2002:a6b:b44c:: with SMTP id d73mr9090328iof.279.1567055715596; Wed, 28 Aug 2019 22:15:15 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Dhruv Dhody <>
Date: Thu, 29 Aug 2019 10:44:39 +0530
Message-ID: <>
To: "Joe Clarke (jclarke)" <>
Cc: "" <>, "" <>, " Discussion" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [Pce] Opsdir last call review of draft-ietf-pce-stateful-pce-auto-bandwidth-10
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 29 Aug 2019 05:15:22 -0000

Hi Joe,

On Wed, Aug 28, 2019 at 8:53 PM Joe Clarke (jclarke) <> wrote:

> >> ===
> >>
> >> In section 6.6, do you have any more concrete recommendations on a reasonable
> >> limit of LSPs with auto-bandwidth that you have discovered from testing or
> >> operational experience?  Providing some data here may prove useful, even if it
> >> is somewhat anecdotal.
> >>
> >>
> >
> > We discussed this and felt reluctance in putting a number down in the
> > RFC, esp when we don't do it for our base published RFCs (ex. such as
> > how many LSPs can be delegated to a PCE). I also checked with at least
> > one vendor and was told that it is quite dependent on the deployment
> > scenario and would let the operator decide.
> Maybe not a hard number, but is there any kind of example you could provide for a given scenario that provides clearer guidance on what kind of impact  each one of these LSPs would present?

How is this -

6.6.  Impact On Network Operations

   In order to avoid any unacceptable impact on network operations, an
   implementation SHOULD allow a limit to be placed on the number of
   LSPs that can be enabled with auto-bandwidth feature.  For each LSP
   enabled with auto-bandwidth feature there is an extra load on PCC, as
   it needs to monitor the traffic and report the calculated bandwidth
   to be adjusted to the PCE. The PCE further re-compute paths based on
   the requested bandwidth and update the path to the PCC, which in
   turns triggers the re-signalling of the path. All these steps adds
   extra load and churn in the network and thus operator needs to take
   due care while enabling this features on a number of LSPs.


> Joe