Hi,
Please find comments on the new revision (-05).
Regards,
Dhruv
---Sec 2 Terminology:
* There are lots of technical details in this section. IMO this section
should just introduce the terms and point to relevant sections for more
details.
* State Timeout Interval: 'b)the PCC makes changes to the LSP state' - Do
you mean that PCC takes control of the LSP state and get the LSP state
either from a pre-configured default, or use local CSPF, or
stateless/passive-stateful PCE etc and try to establish this new LSP state
using make-before-break? Note the LSP state may turn out to be same as the
one set by the active stateful PCE and this LSP state should not be flushed
even though there is no change in the LSP state.
* LSP State Database: This definition seems from the point of view of the
PCC, IMHO a more generic definition would be better.
---Sec 5.4 State Synchronization:
A small text may be added to suggest what should happen if PCC has no LSP
state to synchronize. (Send PCRpt, PLSP-ID=0, SYNC=0) to notify sync end to
the PCE which may still be waiting for state synchronization.
---Sec 5.4.1 State Synchronization Avoidance
OLD:
If a
PCC's LSP State Database survived the restart, the PCC will include
the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain
the last LSP State Database version sent on an LSP State Report from
the PCC in the previous PCEP session.
NEW:
If a
PCC's LSP State Database survived the restart of a PCEP session, the PCC
will include
the LSP-DB-VERSION TLV in its OPEN object and the TLV will contain
the latest LSP State Database version sent on an LSP State Report from
the PCC in the previous PCEP session.
PCC should send the latest DB version to the PCE for state synchronization.
---Sec 5.5.4 Redundant Stateful PCEs:
I suggest we use following terminology to avoid confusion, inline with
[ietf-pce-questions-00] as well as other drafts.
Primary or Backup PCE - Where a backup PCE exists to perform functions in
the network, only in the event of a failure of the primary PCE.
Load-Balanced PCE - share the computation load all the time.
This way we could avoid confusion, such as the one mention in Xian's
comment.
---Sec 6.1 The PCRpt Message
* I also feel SRP should be an optional parameter as PCRpt is also sent
without an update - e.g. passive; initial state sync; delegation; report to
other stateful PCEs (all of them will use SRP-ID=0).
* <path> as defined in [RFC5440] which makes <ERO> as a mandatory object,
but in the first delegated message or for LSP down we will not have any
path, in which case <ERO> should be made optional.
* Since PCRpt is also used for a delegation of a LSP which has been
configured at the PCC, i feel <ENDPOINT> object must be a part of PCRpt as
an optional object to tell the source and destination just like PCReq
* 'No state compression is allowed for state reporting (at PCC).' Can you
clarify the intention for this? Do mean to say that for any LSP changes,
that happen at PCC must be sent to PCE but in section 5.6.1 we say 'the PCC
may choose to only send the PCRpt indicating the latest status ('Up' or
'Down').'
---Sec 6.2 The PCUpd Message
* If stateful PCE cannot setup path or wants to set the LSP state
non-operational/down, there will be no path and hence IMO <ERO> should be
optional here too.
* OLD
A PCC MAY respond with multiple LSP State
Reports to report LSP setup progress of a single LSP. In that case,
the SRP-ID-number MUST be included while the state of the LSP is
"pending", afterwards the reserved value 0x00000000 SHOULD be used..
NEW
A PCC MAY respond with multiple LSP State
Reports to report LSP setup progress of a single LSP. In that case,
the SRP-ID-number MUST be included in the first report message,
afterwards the reserved value 0x00000000 SHOULD be used.
Because PCC may choose to only send the PCRpt indicating the latest status
('Up' or 'Down') [section 5.6.1]
---Sec 6.3 The PCErr Message
* RBNF is needed
* Making SRP mandatory for all stateful PCE capable session is unnecessary.
---Sec 7.2 SRP Object
* Is there any role of SRP in make-before-break success / failure cases?
---Sec 7.4 Optional TLVs for the LSPA Object
A small text for need for TLVs in LSPA object would be useful?
----------------------Editorial:
Introduction:
s/Path Computation Element Protocol (PCEP./Path Computation Element Protocol
(PCEP).
Section 5.1
Expand: CLI
Section 5.3
s/(PCE pr PCC)/(PCE or PCC)
Sec 5.4
Figure 3: Successful state synchronization - the (Sync done) marker is at
the wrong place.
Sec 5.4.1
OLD:
Note that a PCE MAY force State Synchronization by not including the
LSP-DB-VERSION TLV in its OPEN object.
NEW:
Note that a PCC/PCE MAY force State Synchronization by not including the
LSP-DB-VERSION TLV in its OPEN object.
Sec 5.6.1
s/a single PC Reply/a single PCRep message
Sec 6.2
s/LSP-IDENTIFIERS-TLV or the old path/LSP-IDENTIFIERS-TLV of the old path
Sec 7.2
s/PCEerr messages/PCErr messages
Sec 7.3
5-7 - Reserved: these values MUST be set to 0 on transmission and
MUST be ignored on receipt.
The above description is used for bit, not for values!
Sec 7.3.5
OLD
Since a PCE does not send LSP updates to a PCC, a PCC should never
encounter this TLV. A PCC SHOULD ignore the LSP-DB-VERSION TLV, were
it to receive one from a PCE.
NEW
Since a PCE does not update DB version, a PCC should never
encounter this TLV. A PCC SHOULD ignore the LSP-DB-VERSION TLV, were
it to receive one from a PCE.
IMO 'send LSP updates' gets confusing with sending of PCUpd update message.
Sec 8.5
TUNNEL-ID should be removed
****************************************************************************
***
Dhruv Dhody, System Architect, Huawei Technologies, Bangalore, India, Ph.
+91-9845062422
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
