Re: [Pce] Comments for draft-ietf-pce-stateful-pce-05
Hi Ina,
Thanks for your mail, Please find response to the few items, rest is
snipped.
From: Ina Minei [mailto:i...@juniper.net]
Sent: Friday, July 19, 2013 1:01 AM
To: dhruv.dh...@huawei.com; draft-ietf-pce-stateful-...@tools.ietf.org
Cc: pce@ietf.org
Subject: RE: Comments for draft-ietf-pce-stateful-pce-05
Dhruv,
Thank you for the careful review, please find answers inline. The comments
accepted are already incorporated in what will become version 06 of the
draft.
Thank you,
Ina
[snip]
---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.
[Ina] But the text talks about a load-balanced pce where one is also
performing a backup function.
[Dhruv Dhody] Yes by load-balanced PCE I meant one that share and also act
as backup to each other. I feel it would be good if we could align our
terminology - Option 1: Primary-Backup and Load-Balanced or Option 2: use
the term pure-backup for the first case).
---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).
[Ina] If it is made optional, there is no way to ensure that it is present
in the cases when it is needed.
[Dhruv Dhody]We have option - 1: SRP object mandatory SRP_ID can be 0;
option-2: SRP object optional but when present SRP_ID can never be 0.
When the PCRpt is in response to PCUpd (it carry SRP object and has a valid
SRP-ID) and when it is unsolicited the object is not present at all.
I do not understand the argument that we should make an object mandatory
just to make sure that it is present in that one case (i.e. when in response
for PCUpd)
* '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').'
[Ina] If you received two requests LSP1 - new bw and LSP1 new path you have
to send two reports, one for each of these operations. If there is one
request, but the lsp goes through multiple phases to arrive there, you can
report just the final phase.
[Dhruv Dhody] I understand it now and agree, but may be a clarifying text
would help to avoid the confusion that I had.
---Sec 6.3 The PCErr Message
* Making SRP mandatory for all stateful PCE capable session is unnecessary.
[Ina] Please explain the second point, while bearing in mind that this draft
is for active stateful pce (negotiation of the capability means active
stateful, there is no way to signal passive stateful)
[Dhruv Dhody] I am confused. In my understanding, presence of the 'Stateful
PCE Capability TLV' in OPEN would mean support for stateful PCE (section
5.3). If both party set the U bit (LSP-UPDATE-CAPABILITY) then its Active
stateful PCE otherwise its a Passive stateful PCE with support for sending
and receiving PCRpt messages only.
Regarding making the object mandatory (response is as above)
---Sec 7.2 SRP Object
* Is there any role of SRP in make-before-break success / failure cases?
[Ina] Let's say you ask for a reoptimization, but the new path fails because
there is an RSVP setup error. An error must be generated that relates this
failure to the PCupd message that required the optimization.
[Dhruv Dhody] Thanks and I agree, do you think if this could be explained
in draft as well?
---Sec 7.4 Optional TLVs for the LSPA Object
A small text for need for TLVs in LSPA object would be useful?
[Ina]Not sure I follow. The lspa object has optional tlvs. The symbolic name
can be added as one of these optional tlvs. Was the question why is the
symbolic name one of the optional tlvs?
[Dhruv Dhody] Yes, rephrased - When will one carry this TLV in LSPA?
--Editorial:
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!
[Ina] I don't agree, please see rfc3209 which makes use of plenty of
reserved values
[Dhruv Dhody] What I meant was remove these values MUST be set to 0 on
transmission and MUST be ignored on receipt.. Just say - 5-7 - Reserved for
private/future use
Regards,
Dhruv
***
Dhruv Dhody, System Architect, Huawei Technologies, Bangalore, India, Ph.
+91-9845062422
This e-mail
Re: [Pce] Comments for draft-ietf-pce-stateful-pce-05
Dhruv,
Thank you for the careful review, please find answers inline. The comments
accepted are already incorporated in what will become version 06 of the draft.
Thank you,
Ina
[snip]
---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.
[Ina] I think you mean the section on state cleanup - shortened by removing the
cases and the reference on the duration of the timer (these are discussed in
the text)
* 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.
[Ina] yes, that is exactly right. I have added this in a subsequent section
* LSP State Database: This definition seems from the point of view of the PCC,
IMHO a more generic definition would be better.
[Ina] Yes, you are right. How about information about all lsps and their
attributes.
---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.
[Ina] Ok, done.
---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.
[Ina] Ok.
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.
[Ina] But the text talks about a load-balanced pce where one is also performing
a backup function.
---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).
[Ina] If it is made optional, there is no way to ensure that it is present in
the cases when it is needed.
* 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
[Ina] I will discuss these proposals with the co-authors at the upcoming ietf
and get back afterwards.
* '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').'
[Ina] If you received two requests LSP1 - new bw and LSP1 new path you have to
send two reports, one for each of these operations. If there is one request,
but the lsp goes through multiple phases to arrive there, you can report just
the final phase.
---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 0x 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 0x SHOULD be used.
[Ina] Yes, I changed along these lines following Xian's comment
Because PCC
[Pce] Comments for draft-ietf-pce-stateful-pce-05
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 0x 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 0x 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
