Subject: [Pce] Shepherd Review of draft-ietf-pce-stateful-path-protection-05

From: <[email-masked]>
Date: Thu, 6 Jun 2019 18:15:00 +0200

Hi authors of draft-ietf-pce-stateful-path-protection,

Thank you for the update following Dhruv's comments.

To summarize, I mainly have 2 issues to point out:
- The I-D depends on RFC 4872 and reuses the P, S and PT flags (which is
great); however, the side effect of redefining (why?) the expansion of
the S bit (Standby vs. Secondary) leads to a common behavior with an
opposite flag value between the specifications! As suggested by the
reference in section 3.2., we expect alignment here.
- In sections 4.5 and 6.3, the Error-Type for associations has shifted
from 26 (early allocated by IANA) to 29 (from nowhere); this mistake
makes me wonder about the implementation status of the I-D.

Then, looking at the details.
------
Header
---
- As pointed out by Dhruv, we still miss a valid justification for the 7
names listed on the front page, all the more as you exceed the
recommended threshold by 2.
------
Abstract
---
- s/A stateful Path Computation Element/An active stateful Path
Computation Element/
- s/for a stateful PCE/for an active stateful PCE/
------
1. Introduction
---
- s/the PCE Initiated mode/the PCE-Initiated mode/
------
3. PCEP Extensions
---
- s/[I-D.ietf-pce-association-group]
specify/[I-D.ietf-pce-association-group] specifies/
- s/The length field is 16 bit-long and has/The length field (16 bits) has/
- s/Following flags are currently defined -/The following flags are
currently defined:/
- s/Following values are/The following values are/
- s/i.e. P bit is unset/i.e. as if P bit is unset/
------
4. Operation
---
- s/[RFC8231], the the association group/[RFC8231]. The association group/
- s/to a LSP/to an LSP/
- s/includes PPAG./includes PPAGs./
- s/PCC Initiated/PCC-Initiated/
- s/remove on or more/remove one or more/
- s/PCC would report/PCC reports/
- s/via Path Computation Report(PCRpt) message/via the Path Computation
Report (PCRpt) message/
- s/LSPs to a stateful PCE/LSPs to an active PCE/
- s/where PCE would/where the PCE would/
- s/via Path Computation Update(PCUpd) message/via the Path Computation
Update (PCUpd) message/
- s/to PCC via PCUpd message/to the PCC via the PCUpd message/
- s/refer [I-D.litkowski-pce-state-sync]/refer to
[I-D.litkowski-pce-state-sync]/
- s/PCE Initiated LSPs/PCE-Initiated LSPs/
- s/both the PCE and PCC/both the PCE and the PCC/
- s/uses PCUpd or Path Computation Initiate(PCInitiate) message/uses the
PCUpd or the Path Computation Initiate (PCInitiate) messages/
- s/at PCC/at the PCC/
- s/Same procedure/The same procedure/
- s/with Error-Type= 29/with Error-Type 26/
- s/and Error-Value = TBD3/and Error-Value TBD3/
- s/1:N (with N=1),/1:N with N=1,/
- s/and protection LSP/and one protection LSP
- s/a PCEP Speaker/a PCEP speaker/
- s/with Error-Type=29/with Error-Type 26/
- s/and Error-Value = TBD4/and Error-Value TBD4/
- s/continue to apply/continues to apply/
------
5. Other considerations
---
- s/Other considerations/Other Considerations/
- s/LSPs.The/LSPs. The/
- s/for the the protection LSP/for the protection LSP/
- s/both ASSOCIATION object/both ASSOCIATION objects/
- s/and disjoint association/and the disjoint association/
------
6. IANA considerations
---
- s/IANA considerations/IANA Considerations/
- s/Action [RFC8126]. Each bit should be tracked with the following
qualities:/Action [RFC8126]./  [The sentence appears twice.]
- s/new Error-Type and Error-Value/new Error-Value/
- The table in section 6.3 is confusing. A way to clarify would be to
say: "allocate new error values for Error-Type 26 within [...]" and
change the 1st column into "Error-Value".
------

Cheers,

Julien

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Mahendra Singh Negi <[email-masked]>
Date: Wed, 12 Jun 2019 10:41:23 +0000

Hi Julien,

All the outstanding issues are resolved except "number of authors". 
Please find the new draft-version and version-diff links below:
.
Version-06:
https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-path-protection-06

Version Diff:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-path-protection-06

Regards,
Mahendra

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 06 June 2019 21:45
To: [email-masked]
Cc: [email-masked]
Subject: Shepherd Review of draft-ietf-pce-stateful-path-protection-05

To summarize, I mainly have 2 issues to point out:
- The I-D depends on RFC 4872 and reuses the P, S and PT flags (which is great); however, the side effect of redefining (why?) the expansion of the S bit (Standby vs. Secondary) leads to a common behavior with an opposite flag value between the specifications! As suggested by the reference in section 3.2., we expect alignment here.
- In sections 4.5 and 6.3, the Error-Type for associations has shifted from 26 (early allocated by IANA) to 29 (from nowhere); this mistake makes me wonder about the implementation status of the I-D.

Then, looking at the details.
------
Header
---
- As pointed out by Dhruv, we still miss a valid justification for the 7 names listed on the front page, all the more as you exceed the recommended threshold by 2.
------
Abstract
---
- s/A stateful Path Computation Element/An active stateful Path Computation Element/
- s/for a stateful PCE/for an active stateful PCE/
------
1. Introduction
---
- s/the PCE Initiated mode/the PCE-Initiated mode/
------
3. PCEP Extensions
---
- s/[I-D.ietf-pce-association-group]
specify/[I-D.ietf-pce-association-group] specifies/
- s/The length field is 16 bit-long and has/The length field (16 bits) has/
- s/Following flags are currently defined -/The following flags are currently defined:/
- s/Following values are/The following values are/
- s/i.e. P bit is unset/i.e. as if P bit is unset/
------
4. Operation
---
- s/[RFC8231], the the association group/[RFC8231]. The association group/
- s/to a LSP/to an LSP/
- s/includes PPAG./includes PPAGs./
- s/PCC Initiated/PCC-Initiated/
- s/remove on or more/remove one or more/
- s/PCC would report/PCC reports/
- s/via Path Computation Report(PCRpt) message/via the Path Computation Report (PCRpt) message/
- s/LSPs to a stateful PCE/LSPs to an active PCE/
- s/where PCE would/where the PCE would/
- s/via Path Computation Update(PCUpd) message/via the Path Computation Update (PCUpd) message/
- s/to PCC via PCUpd message/to the PCC via the PCUpd message/
- s/refer [I-D.litkowski-pce-state-sync]/refer to [I-D.litkowski-pce-state-sync]/
- s/PCE Initiated LSPs/PCE-Initiated LSPs/
- s/both the PCE and PCC/both the PCE and the PCC/
- s/uses PCUpd or Path Computation Initiate(PCInitiate) message/uses the PCUpd or the Path Computation Initiate (PCInitiate) messages/
- s/at PCC/at the PCC/
- s/Same procedure/The same procedure/
- s/with Error-Type= 29/with Error-Type 26/
- s/and Error-Value = TBD3/and Error-Value TBD3/
- s/1:N (with N=1),/1:N with N=1,/
- s/and protection LSP/and one protection LSP
- s/a PCEP Speaker/a PCEP speaker/
- s/with Error-Type=29/with Error-Type 26/
- s/and Error-Value = TBD4/and Error-Value TBD4/
- s/continue to apply/continues to apply/
------
5. Other considerations
---
- s/Other considerations/Other Considerations/
- s/LSPs.The/LSPs. The/
- s/for the the protection LSP/for the protection LSP/
- s/both ASSOCIATION object/both ASSOCIATION objects/
- s/and disjoint association/and the disjoint association/
------
6. IANA considerations
---
- s/IANA considerations/IANA Considerations/
- s/Action [RFC8126]. Each bit should be tracked with the following qualities:/Action [RFC8126]./  [The sentence appears twice.]
- s/new Error-Type and Error-Value/new Error-Value/
- The table in section 6.3 is confusing. A way to clarify would be to
say: "allocate new error values for Error-Type 26 within [...]" and change the 1st column into "Error-Value".
------

Cheers,

Julien

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.