Path Computation Element Communication Protocol (PCEP) Extensions for Associating Working and Protection Label Switched Paths (LSPs) with Stateful PCE
draft-ietf-pce-stateful-path-protection-11

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

Thank you for the work put into this document. I am trusting the routing AD for their deep understanding of this document and their approval.

Nevertheless, I have 2 COMMENTs which are mere questions of mine.

Regards,

-éric

== COMMENTS ==

-- Section 3.2 --
C.1) Any reason to have a field named "unassigned flags" rather than "reserved"? After all, those bits could be used later for something different than flags. Also applicable to section 6.2.

C.2) is there any reason the "P", "S" and "PT" are described right to left ?

Thanks for this document.  I have only editorial suggestions.  There's no need to reply in any detail; just please consider adopting these suggestions.  Thanks.

— Abstract —

   Multiprotocol Label Switching Traffic
   Engineering Label Switched Paths (MPLS LSP)

Shouldn’t that be “(MPLS-TE LSPs)”?

— Section 1 —

   [RFC5440] describes PCEP for communication between a Path Computation
   Client (PCC) and a PCE or between a pair of PCEs as per [RFC4655].  A
   PCE computes paths for MPLS-TE LSPs based on various constraints and
   optimization criteria.

Even though you expanded some of these acronyms in the Abstract, they have to be expanded again in the Introduction, because the Abstract and the document itself each has to stand separately.

That said, “MPLS-TE” and “PCE” are in the RFC Editor’s list of common acronyms that don’t need expansion, so you can expand them or not, as you please.  But “PCEP” and “LSP” do need expansion here.

You should also be consistent in using “MPLS-TE” (with the hyphen), so please check the instances of “MPLS TE” without the hyphen, and change them.  The RFC Editor will flag this anyway, and it saves time during final editing and AUTH48 if you fix it now.

   It includes
   mechanisms to effect LSP state synchronization between PCCs and PCEs,
   delegation of control of LSPs to PCEs, and PCE control of timing and
   sequence of path computations within and across PCEP sessions and
   focuses on a model where LSPs are configured on the PCC and control
   over them is delegated to the PCE.

This is a really long sentence, and can do with being split in two.  I suggest changing “sessions and” to “sessions.  Stateful PCE”.

   Furthermore, a mechanism to
   dynamically instantiate LSPs on a PCC based on the requests from a
   stateful PCE or a controller using stateful PCE, is specified in
   [RFC8281].

This reads oddly in passive voice, and you have a clear subject to use.  So I suggest:

NEW
   Furthermore, [RFC8281] specifies a mechanism to
   dynamically instantiate LSPs on a PCC based on the requests from a
   stateful PCE or a controller using stateful PCE.
END

      computes the path for the protection LSP and update the PCC with

“updates”

   Note that protection LSP can be established (signaled) prior to the
   failure (in which case the LSP is said to be in standby mode
   [RFC4427] or a Primary LSP [RFC4872]) or post failure of the
   corresponding working LSP according to the operator choice/policy
   (known as secondary LSP [RFC4872]).

“a protection LSP”

I suggest changing “post failure” to “after failure”, as it reads better.

I’m not sure about the antecedent to “according to the operator choice/policy”.  I think you mean that the establishment can be prior to failure or after failure, according to operator choice or policy, is that right?  In that case, the sentence isn’t worded well.  May I suggest this?:

NEW
   Note that a protection LSP can be established (signaled) before
   the failure (in which case the LSP is said to be in standby mode
   [RFC4427] or a Primary LSP [RFC4872]) or after failure of the
   corresponding working LSP (known as secondary LSP [RFC4872]).
   Whether to establish it before or after failure is according
   to operator choice or policy.
END

   [I-D.ietf-pce-association-group] introduces a generic mechanism to
   create a grouping of LSPs which can then be used to define
   associations between a set of LSPs that is equally applicable to
   stateful PCE (active and passive modes) and stateless PCE.

When I first read this I thought “that is equally applicable” applied to the set of LSPs.  I think you mean it to apply to the generic mechanism — that is, the generic mechanism is equally applicable.  Assuming that’s right (note inserted comma and split sentences):

NEW
   [I-D.ietf-pce-association-group] introduces a generic mechanism to
   create a grouping of LSPs, which can then be used to define
   associations between a set of LSPs.  The mechanism is equally
   applicable to stateful PCE (active and passive modes) and stateless
   PCE.
END

— Section 3.2 —

      Protecting (P): 1 bit - This bit is as defined in Section 14.1 of
      [RFC4872] to indicate if the LSP is working or protection LSP.

At a minimum, make it “a working or protection LSP” (add the article).
Better still, “a working (0) or protection (1) LSP.”  I know it says that in RFC 4872, but I think it makes sense to include that here.

      Secondary (S): 1 bit - This bit is as defined in Section 14.1 of
      [RFC4872] to indicate if the LSP is primary or secondary LSP.  The
      S flag is ignored if the P flag is not set.

Similarly, add the article “a”, and also consider “a primary (0) or secondary (1) LSP.”

   If the TLV is missing, it is considered that the LSP is the working
   LSP (i.e. as if P bit is unset).

Is this really “the working LSP”, or should it be “a working LSP”?

— Section 4 —

   An LSP is associated with other LSPs with which they interact by
   adding them to a common association group via the ASSOCIATION object.

The number disagreement here is confusing, so I’m not sure what you mean to say.  I think you mean that the other LSPs are added to the group, in which case change “they interact” to “it interacts”.


— Section 4.2 —

   A PCC can associate a set of LSPs under its control for path
   protection purpose.

“purposes”

   PCC reports the change in association to PCE(s) via Path Computation
   Report (PCRpt) message.

Either “a Path Computation Report (PCRpt) message” or “Path Computation Report (PCRpt) messages”.

   It is expected that both working and protection LSP are delegated

“LSPs”

— Section 4.5 —

   When the protection type is set to 1+1 or 1:N with N=1, there MUST be
…
   When the protection type is set to 1:N with N>1, there MUST be

This is a style thing, so take it or leave it as you please — it’s not wrong the way it’s written.  It’s just that the “1:N with N=1” and “1:N with N>1” distinction isn’t necessary, and I think it’s distracting and invites uncertainty.  If you just made these like this:

NEW
   When the protection type is set to 1+1, there MUST be
…
   When the protection type is set to 1:N, there MUST be
END

…it would be equally correct, but also simpler and, I think, less likely to be confusing.

— Section 5 —

   association of one LSP to another LSP across different RSVP - Traffic
   Engineering (RSVP-TE) sessions

Is it typical to have that hyphen there in the first line?  Isn’t it more typical to write “RSVP Traffic Engineering (RSVP-TE)” without the extra hyphen?

   The information in the PPAG TLV in PCEP as received from the
   PCE, is used to trigger

Remove the comma.

Thank you for addressing my Discuss (and Comment) points!