Hello Xian,
Thank you for the thorough review. Please find answers inline below, the
comments accepted were already incorporated in what will become version 06 of
the draft.
Thanks a lot for the careful reading and useful feedback,
Ina
[snip]
-Introduction
*2nd paragraph: "between and across PCEP sessions", what do you intend to say?
It is same as "within and across PCEP sessions" mentioned later?
[Ina] - yes, and fixed.
-Terminology
*last sentence of delegation definition: what does it want to say? It seems to
imply that the control of LSP can be shifted from one PCC to another PCC, which
I believe is not true. Please clarify.
[Ina] This text is unchanged since version 03. The last sentence reads: "An LSP
is owned by a single PCC at any given point in time." This change was suggested
by Jon Hardwick, and meant as a clarification of the text discussing ownership
of the LSP. I'm not sure why it implies that the control can be shifted, that
is not the intention. Any suggestion?
*"LSP Priority: a specific pair of MPLS setup and hold priority values as
defined in [RFC3209].", only applies to MPLS? Or should be applicable also to
GMPLS?
[Ina] Applicable to both, but this terminology will be removed when the use
cases are removed once the applicability draft is adopted. It was included for
the use cases in the motivation section.
* add "PCEP Speaker" in this section? This phrase is used quite often
[Ina] PCEP speaker is a well known term used in multiple RFCs, I don't think we
need to add to the terminology (it is there in 5440 for example)
-Section 5.4.1
* "When State Synchronization avoidance is enabled on a PCEP session, a PCC
includes the LSP-DB-VERSION TLV as an optional TLV in the LSP Object on each
LSP State", I do not understand what this sentence tries to say. Whether to
skip a state sync. is not an option, but rather decided by the LSP state DBv,
right?
[Ina] The sentence says that the PCC includes the TLV in the LSP object. Not
sure why this implies skipping state sync. Is the word "optional TLV" the
source of the confusion?
* Figure 7 does not match the text in this section. "Purge LSP state" is done
at the end of the state synchronization, from the text description.
[Ina] Thank you for catching this, fixed.
-Section 5.5.4
* "the backup PCE may have only a subset of LSPs delegated to it. The backup
PCE does not update any LSPs that are not delegated to it," What does the first
sentence intend to say?
[Ina] It means that the backup may be primary for a subset of the LSPs in the
network. (example below). I think the word "only" is the source of the
confusion, clarified the text.
Why a backup PCE will have LSPs delegated to it? For the 2nd sentence, is it
trying to describe the behavior of backup PCE during primary PCE failure
condition? If not, i do not understand under what condition can a
backup/standby PCE update LSP status/parameters. Please clarify.
[Ina] Two PCEs, PCE1 and PCE2 exist in a network, and 3 LSPs (LSP1, LSP2, LSP3)
exist in the network. LSP1 and LSP2 are delegated to PCE1, LSP3 is delegated to
PCE2. PCE2 is the backup for PCE1. So in normal operation, the backup has only
LSP3 delegated to it, and cannot change LSP1 and LSP2, but will receive the
updates on their state. If PCE1 fails, the PCC will redelegate LSP1 and LSP2 to
PCE2.
-Section 5.5.5:
* hot-standby PCE is mentioned, would be good to explain how it is different
from the backup PCE.
[Ina] Cleaned up the text. Hot-standby means it is ready to take over.
-Section 6.1 - 6.3:
* the explanation of <path> in Section 6.2 should also be included in Section
6.1? The level of details of the RBNF is not the same in these two sections.
Do you mean the two <path> constructs have different meaning? That would be
confusing.
[Ina] Thank you for catching. The intention is for them to be the same, this
was an editing oversight.
* “In that case, SRP-ID-number MUST be included while the state of the LSP is
"pending", afterwards reserved value 0x00000000 SHOULD be used.." I do not
understand what this sentence is trying to say, could you explain a bit? The
word "afterwards" is confusing.
[Ina] The text is discussing a scenario where multiple report messages are
generated as a result of a single update. The SRP-ID-number is echoed in the
first of the messages, while unsolicited subsequent messages get the value of
0. New text:
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 for the first message, for subsequent messages the
reserved value 0x00000000 SHOULD be used.
* Last sentence in Section 6.2 is incomplete? If multiple Error Code possible,
a reference to the section specifying the error code would be useful.
[Ina] Thank you for catching, section 7.3.3 (lsp-error-code tlv) is added as a
reference.
* If PCE has the ability to put a LSP in non-operational state(assume it
should be accepted by a PCC), why it would cause PCC to send a PCRpt including
LSP-ERROR-TLV as specified in last sentence in Section 6.1?
[Ina] The sentence reads:
"If the LSP transitioned to non-operational state, the PCC SHOULD
include the LSP-ERROR-TLV (Section 7.3.3) with the relevant LSP Error
Code to report the error to the PCE."
This transition is a result of some event that happened on the PCC (e.g. an
RSVP issue), not because of the PCE requesting state transition.
-Section 6.4 - 6.5:
*"[I-D.ietf-pce-gmpls-pcep-extensions] is extended to optionally include the
LSP object after the END-POINTS object. For illustration purposes, the
encoding from [RFC5440] will become:", which drafts you are based? You
mentioned extending GMPLS-PCEP-Extensions, but the encoding is still based on
RFC5440. Same applies for Section 6.5. To avoid confusing, better get them
consistent.
[Ina] The text states "for illustration purposes, the encoding from rfc5440
will become...". The text does not attempt to show what the encoding from the
gmpls draft will become once you insert the lsp object after the end-points
object. I can remove the reference to the gmpls-pcep-extensions and reference
the gmpls draft?
* I think for each extension provided, there should be a need/justification. I
am much in favor of these extensions since you can see the motivations/use
cases described in [draft-zhang-pce-pcep-stateful-pce-gmpls]. However, these
two sections still lack of the motivation. Maybe you can point me to relevant
points listed earlier in this contribution or to use the before-mentioned draft?
[Ina]Sorry, I don't follow the comment. Can you please clarify?
-Section 7:
* “PCE Redundancy Group Identifier TLV", I understand the need of this. But I
am confused by the explanation presented in the current text, about the usage
of this optional TLV. How can it help to decide whether to do state
synchronization or not? By the time, the PCC and PCE establish the session and
start exchanging OPEN,the DBv is the parameter to help make a decision, right?
[Ina] The redundancy group tlv section is still due for cleanup, but was
deferred to the next revision. I will defer this discussion.
* Why we need to make this SRP newly defined in Section 7.2 as a MUST carried
object? If the PCE is passive, there is no such a need, right?
[Ina] The SRP allows correlation of events and errors in a reliable way. This
draft is focused on active stateful. The negotiation of support of stateful
capability implies active stateful (the extensions of this draft). For passive
stateful this may not be adding any value, but currently there is no way to
indicate support of passive mode only.
* Given the fact that SYNC bit is used for new functions (forced full state
synchronization after the stateful PCE is fully functional). The statement "The
S Flag MUST be set to 0 otherwise." no longer holds true. Please update them.
[Ina] Thanks for catching: New text "The S flag MUST be set to 0 in other PCRpt
messages sent by the PCC. The S flag MAY be set to 1 by the PCE in a PCUpd
message (see section 5.4.2).
* I do not see any details on the "LSP-sig-type" as that of the 3-bit O bit.
But rather they are mentioned in a later section. If you prefer not to
duplicate, at least refer to that section as currently defined for this field.
I do not think this change has ever been discussed before, right? SO what is
the intention for this new filed?
[Ina] There was a request to make this generic for support of LSPs that are not
necessarily RSVP signaled (see
http://tools.ietf.org/html/draft-sivabalan-pce-segment-routing-01 for a use
case). This field will likely become a TLV in the next revision, will update
when this text will change.
* Section 7.3.1 encoding of LSP identifier TLV is wrong. Extended Tunnel ID is
usually filled with source address. So now you end up with two source
addresses, which do not make sense. I think Ramon raised the comment before but
was ignored. Since he made a valid point, so please consider updating this.
[Ina] I think you are suggesting to include the tunnel remote address in the
identifier tlv, right? Thinking of how we use this TLV (always tagging along an
LSP object), not sure why we would need the remote address. We do need the
others to identify the instance of the path. Do you have another use case in
mind?
* What is the rationale to add Tunnel ID TLV and Symbolic Path Name TLV before
in LSPA object? And now, I see that the first TLV is deleted, and why?
[Ina] tunnel id is not needed once there is only a single path in the lsp
object. There was an old dependency with the protection draft, which is now not
necessary and removed.
---Editorial:
Abstract:
-expand MPLS-TE, GMPLS and LSP since they appear first time in the draft;
Introduction:
s/a Path Control Element/a Path Computation Element s/between PCE and
PCE/between PCEs
Terminology:
s/is an extension of Passive Stateful PCE/is an extension of passive stateful
PCE s/Revocation An operation /Revocation: An operation s/an operation where an
Active Stateful PCE requests a PCC /An operation where an active stateful PCE
requests a PCC s/ information about and attributes / information about
attributes
Section 3.2:
s/PCC's LSPs in the event PCE/PCC's LSPs in the event of PCE
Section 4:
s/Several new functions will be required in/Several new functions are required
[Ina] all of the above ok
Section 5.3:
s/If the PCEP Speakers support the extensions of this draft/If the PCEP
speakers do not support the extensions of this draft
[Ina] Actually, the text is correct. If the speakers don't support this draft,
they cannot send the pcerr. If they support this draft, but didn't negotiate
the support, they should send this error (instead of just a generic error
message)
Section 5.5.5:
s/Redelegation on PCE failure/Redelegation on PCE Failure s/within the
Redelegation Timeout,/within the redelegation timeout interval,
Section 5.8:
s/A Permanent PCEP session /A permanent PCEP session
Section 6.2:
s/the PCC MUST respond with an PCErr message/the PCC MUST respond with a PCErr
message
Section 7.3:
s/during which time for an RSVP-signaled LSP/during which time for a
RSVP-signaled LSP...
________________________________________
发件人: [email protected] [[email protected]] 代表 Ina Minei [[email protected]]
发送时间: 2013年7月2日 5:54
到: [email protected]
主题: Re: [Pce] I-D Action: draft-ietf-pce-stateful-pce-05.txt
Version 05 of the draft addresses many of the issues raised on the list, in
particular: support for more robust error reporting and correlation,
clarifications on the make-before-break behavior and behavior under failure
conditions.
Review and comments are welcome.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of
[email protected]
Sent: Monday, July 01, 2013 2:44 PM
To: [email protected]
Cc: [email protected]
Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-05.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element Working Group of the
IETF.
Title : PCEP Extensions for Stateful PCE
Author(s) : Edward Crabbe
Jan Medved
Ina Minei
Robert Varga
Filename : draft-ietf-pce-stateful-pce-05.txt
Pages : 60
Date : 2013-07-01
Abstract:
The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests.
Although PCEP explicitly makes no assumptions regarding the
information available to the PCE, it also makes no provisions for
synchronization or PCE control of timing and sequence of path
computations within and across PCEP sessions. This document
describes a set of extensions to PCEP to enable stateful control of
MPLS-TE and GMPLS LSPs via PCEP.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce
There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-05
A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-05
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
_______________________________________________
Pce mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pce
