[Pce] Quick review of draft-chen-pce-sr-ingress-protection-00

Dhruv Dhody <dhruv.ietf@gmail.com> Mon, 15 July 2019 15:27 UTC

Return-Path: <dhruv.ietf@gmail.com>
X-Original-To: pce@ietfa.amsl.com
Delivered-To: pce@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7805F12019B; Mon, 15 Jul 2019 08:27:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73_XQYcQ77KQ; Mon, 15 Jul 2019 08:27:26 -0700 (PDT)
Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EF2F1201B3; Mon, 15 Jul 2019 08:27:23 -0700 (PDT)
Received: by mail-io1-xd35.google.com with SMTP id e20so4389129iob.9; Mon, 15 Jul 2019 08:27:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=lTQAR44qNFSPoTWFbOkiQC6vNB3nf9U+hcq6SsLIJYs=; b=TETJeKyB7FzKPZoMByArB0tAts2KNspxOAFfbqXlOI/f46yafPUvvpmzvnjmWetoj7 twPuFVSlvOg901mikGe4fEzih3VD+NnxH+NGtjk5aXrFcPdO/kiGCfPxZynFjWBROzsL UjwVDtDDhGskEhUxoj67TnNqsWkKsqzgmYhX/Uo4Qg2L2WIBVpCaGkWsB38k8LN1NCKl k6BMeJeShPkaBdSmER7ad+EW0RMvOjZTTa98e9BOVmHOgo4DATT7xLqzB5vYsjnwAe/D 53X6pzyZUnz1NJsiNdKeHXKLi9t3lABSThx+EIZGofGhtInLCLkSxzidlmJIpMTYQJDD fiPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=lTQAR44qNFSPoTWFbOkiQC6vNB3nf9U+hcq6SsLIJYs=; b=pHPD39YRcJHyulEA7g0gk3sesG3ipcj8j4YU/N97lVqdZaq0jyVlu6AEYcZ4QHE9uV MJm9QfpVwgBFrnR9wLqWCA1JsMexxAiTIE9PqZz65m1Jx/wTgDWIQh5NS6DiN5l7U/qn wmj7D30xz7tNr4yvVe9AQqVQf9/vaFCFfmWQEcn9vNhoTY1SI/RC2dR2p6qJVbP6E1/S 54gxlDCORpQUDO2ohz8125kgro7/oRjtjMmQ00gCiVuk5/rvSZiYlVlEPFsb6OqscaFk 9ORCPwD0iDX+q9Yz5v1Nlg9AzyQ7hKYi7erEKnS/A8SBpc+Vw7EbB62uq5QkpiWpaQP/ 4yJA==
X-Gm-Message-State: APjAAAW4cQ50LXkEUpxFWIxTfSB7mPDBYQ/iVhiW10f21BYIcmDzAfOR uE4Z1jQx2AG0tcVOg169jN66gBGdqXeMDSGG+RkXFHh5
X-Google-Smtp-Source: APXvYqxZ9v/LrB0Qr5Yde6z2hS7b3q+KeiMT6IdOPmxbkaE9C3SjyaSBqQXjevPmMLXNmGvT3fbHKhwkcQ2HV6o5SfI=
X-Received: by 2002:a02:b90e:: with SMTP id v14mr28522347jan.122.1563204442516; Mon, 15 Jul 2019 08:27:22 -0700 (PDT)
MIME-Version: 1.0
From: Dhruv Dhody <dhruv.ietf@gmail.com>
Date: Mon, 15 Jul 2019 20:56:46 +0530
Message-ID: <CAB75xn7s2b3rp4Ef+V35-_hHRzhYTHM1dxi3uF7MScFaH4bJYg@mail.gmail.com>
To: draft-chen-pce-sr-ingress-protection@ietf.org
Cc: pce@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/O2G8qzQLTZifP8b8T1ddZITVfMI>
Subject: [Pce] Quick review of draft-chen-pce-sr-ingress-protection-00
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Path Computation Element <pce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pce>, <mailto:pce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pce/>
List-Post: <mailto:pce@ietf.org>
List-Help: <mailto:pce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pce>, <mailto:pce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Jul 2019 15:27:29 -0000

Hi Authors,

I did a quick review of your I-D, but some key questions came up, it
would be nice if they could be clarified before hand.

(1) It needs to be made clear that why does backup egress needs to
know about the details of the primary SR path at the primary ingress?
Since things are driven by PCE/controller and there is no signalling,
the motivation needs to be different than RFC 8424 for RSVP-TE.  IMHO
the only reason for backup ingress to be aware of these details would
be to detect the failure of the primary ingress itself. And the
benefit offered by that isn't clear.

(2) Once the motivations are cleared up, then we should explore the
use of existing techniques like PCEP-Flowspec [1] instead of defining
new sub-TLVs for traffic description.  I see you have a few new things
like virtual network but not clear how they would be used and why are
tightly coupled for this use-case.

I hope you would focus on these aspects during your presentation.
Discussion on the list would be even better.

Thanks,
Dhruv

[1] https://tools.ietf.org/html/draft-ietf-pce-pcep-flowspec-03