PCEP Extensions for Associating Working and Protection LSPs with Stateful PCE
Note: This ballot was opened for revision 10 and is now closed.
Deborah Brungard Yes
Alissa Cooper No Objection
Roman Danyliw No Objection
Comment (2019-09-18 for -10)
** 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.
Benjamin Kaduk (was Discuss) No Objection
Thank you for addressing my Discuss (and Comment) points!
Mirja Kühlewind No Objection
Barry Leiba No Objection
Comment (2019-09-14 for -10)
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.
Alexey Melnikov No Objection
Alvaro Retana No Objection
Adam Roach No Objection
Martin Vigoureux No Objection
Éric Vyncke No Objection
Comment (2019-09-18 for -10)
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 ?