[Pce] Roman Danyliw's No Objection on draft-ietf-pce-stateful-path-protection-10: (with COMMENT)

Roman Danyliw via Datatracker <noreply@ietf.org> Wed, 18 September 2019 21:01 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: pce@ietf.org
Delivered-To: pce@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81026120052; Wed, 18 Sep 2019 14:01:22 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Roman Danyliw via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-pce-stateful-path-protection@ietf.org, Julien Meuric <julien.meuric@orange.com>, pce-chairs@ietf.org, julien.meuric@orange.com, pce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.101.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Roman Danyliw <rdd@cert.org>
Message-ID: <156884048251.4597.11655493158307521478.idtracker@ietfa.amsl.com>
Date: Wed, 18 Sep 2019 14:01:22 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/I469noEirAemyCbuwS7qOsYepm0>
Subject: [Pce] Roman Danyliw's No Objection on draft-ietf-pce-stateful-path-protection-10: (with COMMENT)
X-BeenThere: pce@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 18 Sep 2019 21:01:23 -0000

Roman Danyliw has entered the following ballot position for
draft-ietf-pce-stateful-path-protection-10: 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-pce-stateful-path-protection/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

** Section 3.2.  It took me a bit to understand that the Path Protection
Association TLV goes in an ASSOCIATION Object per Section 6 of
[I-D.ietf-pce-association-group].  On initial reading of “[t]he Path Protection
Association TLV is an optional TLV for use with the Path Protection Association
Type” this relationship wasn’t clear.  I’d recommend an editorial update to
make it clearer.  I believe this is related Ben Kaduk’s DISCUSS #5 (which I
support).

** Section 3.2  The protection type field specifies the protection type of the
LSP.  Section 1 notes that “one working LSP [can be associated with] one or
more protection LSPs using the generic association mechanism.”  Assuming a case
were multiple protection LSPs are specified, is it valid for the protections
type to be different?

** Section 4.5.  For clarity, I would recommend being precise with the exact
code point names when discussing conflicting combinations of protection types. 
For example, s/1+1 or 1:N/1+1 (i.e., protection type=0x08 or 0x10) or 1:N
(i.e., protection type = 0x04) with N=1 per <insert IANA registry name>/

Baring these combinations, are other any other remaining combinations of
protection types legal given different protection LSPs in the same PPAG (e.g.,
0x1 + 0x2)?

** Editorial Nits:
-- Section 1.  s/effect/affect/

-- Section 1.  Per “When the working LSPs are computed and controlled by the
PCE, there is benefit in a mode of operation where protection LSPs are as
well”, I couldn’t parse the second clause.