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

Roman Danyliw <rdd@cert.org> Tue, 24 September 2019 12:22 UTC

Return-Path: <rdd@cert.org>
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 A5793120096; Tue, 24 Sep 2019 05:22:02 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 o-xTl3CAEuL8; Tue, 24 Sep 2019 05:22:00 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D72120233; Tue, 24 Sep 2019 05:22:00 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x8OCLuYH037781; Tue, 24 Sep 2019 08:21:56 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x8OCLuYH037781
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1569327716; bh=2IA9wKNCsX2eIk66AKBB3D2C1C67z03XMB0aTQsyusw=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=EFSp+Se3KPjlkz4tkshxqW4CmsaYMqmdl3FnkxiGrfURcpcYfq9YOYl/OTB5p3XYK mPgqGdhUYsZuStgIo4+6VWa+kaZIcoJcHr431r5T+3S/zUpMOGuPJDH72cydWmBM/o 4LOPA3RPPKbhDM3L2l+mMOPV+lKbqPfFX3vIYNXM=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x8OCLs1Q009597; Tue, 24 Sep 2019 08:21:54 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0468.000; Tue, 24 Sep 2019 08:21:54 -0400
From: Roman Danyliw <rdd@cert.org>
To: Dhruv Dhody <dhruv.ietf@gmail.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-pce-stateful-path-protection@ietf.org" <draft-ietf-pce-stateful-path-protection@ietf.org>, Julien Meuric <julien.meuric@orange.com>, pce-chairs <pce-chairs@ietf.org>, "pce@ietf.org" <pce@ietf.org>
Thread-Topic: Roman Danyliw's No Objection on draft-ietf-pce-stateful-path-protection-10: (with COMMENT)
Thread-Index: AQHVbmRDfvjd7IDUj0yUzcN1b5Ef+qc6o1QAgAAd98A=
Date: Tue, 24 Sep 2019 12:21:54 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B3464ED1@marathon>
References: <156884048251.4597.11655493158307521478.idtracker@ietfa.amsl.com> <CAB75xn4ih=5h3ZSomt+kKBYzRZGCrMbXME3bQDC4Z9ud-7GNhg@mail.gmail.com>
In-Reply-To: <CAB75xn4ih=5h3ZSomt+kKBYzRZGCrMbXME3bQDC4Z9ud-7GNhg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/RzNYMjg1J84dM_TCBMNEwSaXxfU>
Subject: Re: [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
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: Tue, 24 Sep 2019 12:22:03 -0000

Hi Dhruv!

Thanks for these proposed edits.  They address my comments.

> -----Original Message-----
> From: Dhruv Dhody [mailto:dhruv.ietf@gmail.com]
> Sent: Tuesday, September 24, 2019 2:09 AM
> To: Roman Danyliw <rdd@cert.org>
> Cc: The IESG <iesg@ietf.org>rg>; draft-ietf-pce-stateful-path-
> protection@ietf.org; Julien Meuric <julien.meuric@orange.com>om>; pce-chairs
> <pce-chairs@ietf.org>rg>; pce@ietf.org
> Subject: Re: Roman Danyliw's No Objection on draft-ietf-pce-stateful-path-
> protection-10: (with COMMENT)
> 
> Hi Roman,
> 
> Thanks for your comments. Few thoughts...
> 
> On Thu, Sep 19, 2019 at 2:31 AM Roman Danyliw via Datatracker
> <noreply@ietf.org> wrote:
> >
> > 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-protecti
> > on/
> >
> >
> >
> > ----------------------------------------------------------------------
> > 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).
> >
> 
> This is updated to "The Path Protection Association TLV is an optional TLV
> for use in the ASSOCIATION Object with the Path Protection Association
> Type."

Thanks.  That is much clearer.

> > ** 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?
> >
> 
> An explicit error text has been added to make sure LSPs within the
> association group has the same Protection Type.

> > ** 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>/
> >
> 
> Based on Barry's comment this was simplified and now we have just two
> case 1+1 and 1:N. The protection type values could be added in brackets.
>
> > 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)?
> >
> 
> As per RFC 4872, all "other" values are reserved.
> As per Ben's comment, this was added - "Any type already defined or that
> could be defined in the future for use in the RSVP-TE PROTECTION object is
> acceptable in this TLV unless explicitly stated otherwise."

Thanks.  For both of the items above, the proposed approach is clearer and addresses my comment.

> > ** 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.
> >
> >

Thanks,
Roman


> 
> Thanks!
> Dhruv