Hi,
I have a some comments on this revision:
1) Section 3.1 seems quite generic and mainly related to Stateful PCE and not
the extensions themselves, as the document is quite big (46 pages), it could be
considered to shift the text to the applicability draft.
2) One important change is that the Stateful PCE does NOT allow anymore to
reference the LSP in the PCReq and PCRep messages. This make the stateful PCEP
extensions a pure LSP-DB update mechanism, this is quite a change that drops a
set of useful Stateful functionalities (routing policy based on LSP sender,
planned path, ...etc). In addition this do es remove the capability of a PCE to
re-order the PCRep mentioned in section 3.1.2.
It would help if we could have a summary of the changes (and why), I find the
path of having a Path Computation Element Protocol stateful extension not
allowing LSP state in path computation request.
3) During discussion some important architectural consideration were mentioned,
but they are not described in section 5
In Section 5.2 the reason indicated for having in-band PCRpt and PCUpd was to
simplify the PCE operation for one PCC by serializing the Requests and the
update message for easier correlation of events. Furthermore the document
requires this (which I believe can be worked around by never sending anything
if an existing LSP-DB update protocol is used)
4) Section 5.3
The capability advertisement reflects a design principle, which is not stated:
the extensions requires the support of PCRpt message for the reason that should
be addressed by 3).
The drawback of this mandated PCRpt support is at minimum a RECOMMENDED
extended session opening mechanism. I believe the reason is to remove the
number of supported options. If this is the case (and if there are other
reasons), it would be good if this is stated.
5) Section 5.3
Editorial : "Note that even if the
update capability has not been advertised, a PCE can still receive
LSP Status Reports from a PCC and build and maintain an up to date
view of the state of the PCC's LSPs."
Could be removed
6) Section 5
The section title is "Architectural Overview of Protocol Extensions", yet it
describes procedures. I think that the content should be split into
architectural aspects and procedures. For example. RFC5440 does have an
architecture section, which summarize the procedures, but the procedures are
described in each message.
For instance section 5.4 describe session opening extension, a separate section
should describe the procedure, separated from architectural principle.
Procedure are described starting at paragraph 4. This apply to the other
sub-sections too.
7) Section 6.1
OLD
"If the PCRpt message is in response to a PCUpd message, the SRP
object SHOULD be included and the value of the SRP-ID-number in the
SRP Object MUST be the same as that sent in the PCUpd message that
triggered the state that is reported."
NEW
"If the PCRpt message is in response to a PCUpd message of the same PCEP
session,
the SRP object MUST be included and the value of the SRP-ID-number in the
SRP Object MUST be the same as that sent in the PCUpd message that
triggered the state that is reported."
If the object SHOULD be present, this is a pure recommendation, but section 7.2
(SRP object) indicates that each id is considered unacknowledged (and should
not be reused) if no PCRpt comes with an higher id (for that LSP). If the
recommendation is not followed all ids may end up unacknowledged.
The second point is that is must be scoped to the session that sent the PCUpd,
(the D bit also?) otherwise PCEs NOT having the delegation will interpret that
as delegation request, which it may allow, then the behavior is up to the PCC
implementation (One policy could be to delegate to the newest in case the TCP
session is hanging).
8) Section 6.1
You forbid state compression on PCRpt, only on PCUpd. I do not see the benefit,
could you detail why? Soft state signaling protocol may introduce some spurious
state change. The document states no FSM for the states, so it should not
matter.
9) Section 6.2
Regarding the Make-before-break : there will be 2 path co-existing, they
should have then different symbolic-path-name, correct?
10) Section 6.2
PCUpd state compression and SRP-ID : its allowed to compress updates,
keeping the most recent one. A provision should be made in case of SRP-ID
wrap-up, otherwise high SRP-ID will not be acknowledged.
11) section 6.3
- RFC5511 does not define comments,
- The format makes me wonder why the RP is not used instead of the SRP. I
understand that the id-space are different, but a new bit in the RP flag could
easily distinguish it (PCE RP (1) versus PCC RP (0)) what would be the
drawbacks of it? The advantage would be that we do not need to redefine the
PCErr and reuse the existing definitions and mechanisms for RP.
12) Section 7
P and I are note related to path computation requests only, I do not see why
its optional, the P & I Bit would be very useful in PCUpd messages.
13) Section 7.1.1
A PCEP document must not mandate the use of a particular signaling protocol,
the RSVP part must be removed.
14) section 7.2
Why a state pending is not an ack? This seems to mix the PCEP protocol
mechanism and the provisioning mechanism. Could you explain the reason for this
choice (at least per mail)
15) Section 7.2
Why can the SRP contains a path name when its already present in the
mandatory LSP object?
16) Section 7.2
As the ID is present in PCRpt, which may be sent to different session after an
PCUpd, a reference to section 6.1 on the mirroring of the SRP per session or a
note could be useful
17) Section 7.3
D bit should be scoped to the PCEP session having the delegation. If this is
correct please it.
S bit should also be scoped to the PCEP session, this is kind of obvious but it
does not hurt to state it.
18) Section 7.3
This raise the point of how can you identify an LSP, it seems that one LSP
can have different RSVP identifiers (as you state). Could you care to explain
how to identify an LSP in that case, because I am confused.
19) Section 7.3.1
I would remove the RSVP-signaled statement.
From protocol mechanism there are the following LSP identifiers, with
different relation :
PLSP-ID : Unique per PCEP session, mandatory, represent a LSP
LSP-Identifier TLV : mandatory
SYMBOLIC-PATH-NAME : mandatory for a path and LSP
An LSP may have different LSP-Identifier during its lifetime, (what happens if
the same LSP-Identifier appear with a different PLSP-ID?)
You indicate that a LSP is a path (section 7.3.2), there is a 1:1 relationship
between a PLSP-ID and a path name, but potentially an arbitrary relationship
between PLSP-ID and LSP-Identifiers.
This is quite confusing, I do not understand why so many identifiers are
required.
I would understand an unique symbolic LSP id (I dislike the term name, it can
be any identifier and not a string) that is mapped per session to PLSP-ID for
efficiency.
In addition to this PCC unique identifier the LSP identifier TLV (optional) or
LSP name (ascii string, optional) could be added.
What would speak against this proposal?
In addition there should be only one symbolic LSP id TLV per LSP object.
20) section 7.3.3 and section 7.3.4
There is 2 TLV for the error reporting, presence rule are more complicated.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=[TBD] | Length=variable |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Error type | Additional error length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Additional Error information |
~ Depend on LSP Error code ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The additional error type can be RSVP or String , when RSVP the format of 7.3.4
is used.
Addition question : how many TLVs can be present in the LSP object?
Mit freundlichen Grüßen / Best Regards
Cyril Margaria
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> [email protected]
> Sent: Wednesday, October 09, 2013 8:42 AM
> To: [email protected]
> Cc: [email protected]
> Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-07.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-07.txt
> Pages : 47
> Date : 2013-10-08
>
> 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-07
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-pce-stateful-pce-07
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> 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
