Subject: [Pce] Comments on draft-ietf-pce-stateful-pce-02

From: Dhruv Dhody <[email-masked]>
Date: Mon, 11 Mar 2013 20:33:17 +0530

Hi,

Please find the review comments for this draft (there is some overlap with
comments from Jon, Cyril etc)

*Major Comments:*
(1) State synchronisation:
a. PCE should determine the synchronisation is over as soon as possible, as
updates, request etc are blocked during synchronisation. Maybe the last
report message can have SYNC=0 (similar to F - fragmentation bit in RP
object) or as Jon suggested an empty report but then the RBNF of PCRpt
should support it.

b. I also dont like the use of word 'purge' with respect to old or stale
entries during PCEP session up/down. A mechanism to mark LSP entries as
stale and waiting for them to be refreshed after session up and deleted (or
'purged') only after some timer expiry.

(2) The PCRpt Message:
<state-report> ::= <LSP>[<path-list>] Where: <path-list>::=<path>[<path-list>].
Is this to specify primary and backup? In which case the status of the
paths needs to reported separately in case of standby but we have only one
LSP object here to specify the operational status. Also LSP-ID of primary
and backup would be different.

Also applicable to PCUpd message.
I feel the backup path should be updated and reported separately with each
having there own encoding for LSP object.

(3) Node Identifier TLV
PCC may use address that survives the session restart (Loopback, MPLS
LSR-ID etc), i suggest we mention this in the document and provide guidance
to implementers to do this if possible.

(4) LSP Object:
a. What is relationship between the LSP-ID in LSP object and the LSP-ID in
LSP Identifier TLVs?
b. There is no mechanism to report the 'pending' state right now? O-Bit as
zero will mean down, not pending.

(5) Make-Before-Break:
There is a need to clarify how MBB is achieved, what is the LSP-ID in case
of updates and reports?

*Minor Comments: *
(1) Abstract/Introduction
There is a consistent use of phrase "between and across PCEP sessions". Can
you clarify?

(2) Re-look the terminology section as some terms are no longer in the
document.

(3) LSP Protection
In case of delegated PCE, the desired protection may also be configured at
PCC and the active stateful PCE should support it, the stateful PCE having
full control over the protection / restoration settings can only be
achieved with instantiation capability and should be out of scope from this
document.

(4) Delegation
a. The wording "an LSP may be delegated to one or more PCEs." .. this is
incorrect, from the reading it looks as if this is happening at the same
time.

b. Active stateful PCE LSP Update (sec 5.6.2)
OLD:
A PCC may choose to compress LSP State Updates to only reflect the most up to
date state, as discussed in the previous section.
NEW:
A PCC may choose to compress LSP State Reports to only reflect the most up to
date state, as discussed in the previous section.

(5) Symbolic Path Name TLV
The length of this TLV must be greater then 0 as well as multiple of four.

(6) LSP state DB version TLV (page 40, para 2)
"Since a PCE does not send LSP updates to a PCC, a PCC should never
encounter this TLV". LSP updates here can be easily confused with the PCUpd
messages. Kindly reword this.

Regards,
Dhruv

---

From: Ina Minei <[email-masked]>
Date: Sat, 23 Mar 2013 00:10:58 +0000

Dhruv,

Thank you for the review. Please see answers inline below ###.

Ina

From: [email-masked] [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: Monday, March 11, 2013 8:03 AM
To: [email-masked]
Subject: [Pce] Comments on draft-ietf-pce-stateful-pce-02

Hi,

Please find the review comments for this draft (there is some overlap with comments from Jon, Cyril etc)

Major Comments:
(1) State synchronisation:
a. PCE should determine the synchronisation is over as soon as possible, as updates, request etc are blocked during synchronisation. Maybe the last report message can have SYNC=0 (similar to F - fragmentation bit in RP object) or as Jon suggested an empty report but then the RBNF of PCRpt should support it.
### Please see version 03 of the draft.

b. I also dont like the use of word 'purge' with respect to old or stale entries during PCEP session up/down. A mechanism to mark LSP entries as stale and waiting for them to be refreshed after session up and deleted (or 'purged') only after some timer expiry.
### Please see version 03 of the draft.

(2) The PCRpt Message:
<state-report> ::= <LSP>[<path-list>] Where: <path-list>::=<path>[<path-list>]. Is this to specify primary and backup? In which case the status of the paths needs to reported separately in case of standby but we have only one LSP object here to specify the operational status. Also LSP-ID of primary and backup would be different.

Also applicable to PCUpd message.
I feel the backup path should be updated and reported separately with each having there own encoding for LSP object.
### Clarification on backup paths will be done in the protection doc. I agree with you the text needs to be cleaned up in the base spec, will do so in 04.

(3) Node Identifier TLV
PCC may use address that survives the session restart (Loopback, MPLS LSR-ID etc), i suggest we mention this in the document and provide guidance to implementers to do this if possible.
### the node-id (now renamed to predundancy-group-id) will be further clarified in version 04

(4) LSP Object:
a. What is relationship between the LSP-ID in LSP object and the LSP-ID in LSP Identifier TLVs?
### The lsp-id in the lsp object was renamed to plsp-id to avoid such confusion.

b. There is no mechanism to report the 'pending' state right now? O-Bit as zero will mean down, not pending.
### The O-bit will be revisited in version 04.

(5) Make-Before-Break:
There is a need to clarify how MBB is achieved, what is the LSP-ID in case of updates and reports?
### Please see version 03.

Minor Comments:
(1) Abstract/Introduction
There is a consistent use of phrase "between and across PCEP sessions". Can you clarify?
### LSPs may move from one PCE to another.

(2) Re-look the terminology section as some terms are no longer in the document.
### Could you send the correction?

(3) LSP Protection
In case of delegated PCE, the desired protection may also be configured at PCC and the active stateful PCE should support it, the stateful PCE having full control over the protection / restoration settings can only be achieved with instantiation capability and should be out of scope from this document.
### The whole discussion on protection belongs in a separate document.

(4) Delegation
a. The wording "an LSP may be delegated to one or more PCEs." .. this is incorrect, from the reading it looks as if this is happening at the same time.
### To a single PCE, text is clarified in 03.

b. Active stateful PCE LSP Update (sec 5.6.2)
OLD:
A PCC may choose to compress LSP State Updates to only reflect the most up to date state, as discussed in the previous section.
NEW:
A PCC may choose to compress LSP State Reports to only reflect the most up to date state, as discussed in the previous section.
### Actually, I think we mean updates, not reports (if receiving multiple updates, may choose to do state compression during processing)

(5) Symbolic Path Name TLV
The length of this TLV must be greater then 0 as well as multiple of four.
### I think this is not necessary to specify in words, the figure should be sufficient.

(6) LSP state DB version TLV (page 40, para 2)
"Since a PCE does not send LSP updates to a PCC, a PCC should never encounter this TLV". LSP updates here can be easily confused with the PCUpd messages. Kindly reword this.
### Will do.

Regards,
Dhruv