[Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-association-group-09: (with COMMENT)

Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 11 July 2019 07:38 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 0DFE31202B1; Thu, 11 Jul 2019 00:38:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-pce-association-group@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.98.3
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <156283069004.32356.1196331021996927206.idtracker@ietfa.amsl.com>
Date: Thu, 11 Jul 2019 00:38:10 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/pce/62_9ci4WpHO4xoVPSWG0AgbSVwA>
Subject: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-association-group-09: (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: Thu, 11 Jul 2019 07:38:10 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-pce-association-group-09: 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-association-group/



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

I'm always a little reluctant to publish framework documents without any
examples of using that framework (i.e., this document does not define
any association types), but this work seems well thought-out and it
looks like there are a handful of association types in development by
the WG.  Would it be worth listing a few as informational references to
give the reader a broader sense of what associations might be used for?

Thanks for the note in the shepherd writeup about the author count!

Thank you also for the very readable document -- it's clear that the
authors took care to organize the content in a manner accessible to
the reader.

As a general note, do we need to say anything about the multi-byte
integer values being encoded in network byte order?  (Perhaps following
RFC 5440's implicit convention is the right thing to do.)

Section 1

   [RFC6780] defines the RSVP ASSOCIATION object, which was defined in
   the context of GMPLS-controlled Label Switched Paths (LSPs) to be

nit: is this supposed to be  RFC 4872?

Section 3.3

   The dynamically created association can be reported to the PCEP peer
   via the PCEP messages as per the stateful extensions.  While the
   operator-configured association is known to the PCEP peer before
   hand, a PCEP peer could ask for a LSP to join the operator-configured
   association via the stateful PCEP messages.

nit: I suggest s/While/When/, if I understand correctly.

   Multiple types of associations can exist, each with their own
   association identifier space.  The definition of the different
   association types and their behaviours is outside the scope of this
   document.  The establishment and removal of the association
   relationship can be done on a per LSP basis.  An LSP may join
   multiple association groups, of different or of the same association
   type.

Is it possible for an LSP to join multiple association groups of the
same type and then for configuration to be assigned to two groups in a
manner that conflicts?  What procedure is used for conflict resolution
in such a case?

Section 3.4

   Association identifier range for sources other than the PCEP speaker
   (for example an NMS system) is not communicated in PCEP and the
   procedure for operator-configured association range setting is
   outside the scope of this document.

Given the discussion in the rest of the document, it seems that
reserving a specific range for operator configuration (across all
association types) is too rigid to meet the various anticipated use
cases.  Is that a correct assessment?

Section 5.1

   If the Assoc-type is not recognized or supported by the PCEP speaker,
   it MUST ignore that respective Start-Assoc-ID and Range.  If the
   Start-Assoc-ID or Range are set incorrectly, the PCEP session MUST be
   rejected with error type 1 and error value 1 (PCEP session
   establishment failure / Reception of an invalid Open message).

I could maybe see competent engineers disagreeing about which of these
MUSTs would take precedence in a case where both apply.

   The Assoc-type MAY appear more than once in the OP-CONF-ASSOC-RANGE
   TLV in the case of a non-contiguous Operator-configured Association
   Range.  The PCEP speaker originating this TLV MUST NOT carry
   overlapping ranges for an association type.  If a PCEP peer receives
   overlapping ranges for an association type, it MUST consider the Open
   message malformed and MUST reject the PCEP session with error type 1
   and error value 1 (PCEP session establishment failure / Reception of
   an invalid Open message).

This might be a good place to specify the  handling if a
received range would cross the 0xffff boundary.

Section 6.1.1

   The Global Association Source TLV is an optional TLV for use in the
   Association Object.  The meaning and the usage of Global Association
   Source is as per [RFC6780].

Do we want to say Section 4 specifically of 6780?
(Similarly for Extended Association ID.)

Section 6.1.4

   the association group.  In this document, all these fields are called
   'association parameters'.  Note that the ASSOCIATION object MAY

I would humbly suggest s/all these fields are called 'association
parameters'/these fields are collectively called 'association
parameters'/.

Section 6.3.1

   The ASSOCIATION Object is OPTIONAL and MAY be carried in the Path
   Computation Update (PCUpd), Path Computation Report (PCRpt) and Path
   Computation Initiate (PCInitiate) messages.

   When carried in PCRpt message, it is used to report the association
   group membership pertaining to a LSP to a stateful PCE.  The PCRpt
   message are used for both initial state synchronization operations
   (Section 5.6 of [RFC8231]) as well as whenever the state of the LSP
   changes.  The associations MUST be included during the state
   synchronization operations.

I suspect this is just my hazy memory of OPTIONAL, but how does "MUST be
included" match up with "OPTIONAL".

Section 6.4

Do I understand correctly that for dynamically created association
groups, the creation is effected by just using the relevant parameters
in a request(/update/etc.) and there is no need to separately create or
allocate the association?

   If a PCE peer is unwilling or unable to process the ASSOCIATION
   object, it MUST return a PCErr message with the Error-Type "Not
   supported object" and follow the relevant procedures described in
   [RFC5440].  [...]

Does this imply that the P flag in the common header should always be
set for ASSOCIATION objects?

   In case the LSP is delegated to another PCE on session failure, the
   associations (and association information) set by the PCE remains
   intact, unless updated by the new PCE that takes over.

This includes the association source address?

Section 8

   attack vector.  An attacker could report too many associations in an
   attempt to load the PCEP peer.  The PCEP peer responds with PCErr as

"report" in the sense of causing the peer to create state to track them?

Section 12.2

Since the RFC 7525 procedures are RECOMMENDED, I think that reference
needs to be normative.