Hi,
(maybe duplicated, I did not see my first email on the list after 1 hour)
I support draft-ietf-pce-stateful-pce-app-02 LC.
I Have the following comment for draft-ietf-pce-stateful-pce-09:
Section 2
The document references the following timers:
- State Timeout Interval
- Redelegation Timeout Interval
RFC5440 defines an Appendix B. PCEP Variables, having a dedicated section
for those variables would be better, as they are integral part of the
extensions.
Section 5.4
After the first paragraph, add:
The State synchronization start with a LSP state report having the SYNC
Flag in the LSP Object set to 1.
Reason: This would allow for the PCC to fully resend its database after
the Initialization phase, and clarify the PCE operation.
Section 5.6.1
OLD
Once an LSP is up, the PCC sends an LSP State Report carried on a
PCRpt message to the PCE, indicating that the LSP's status is 'Up'.
If the LSP could not be set up, the PCC sends an LSP State Report
indicating that the LSP is "Down' and stating the cause of the
Failure.
NEW
Once an LSP is up, the PCC sends an LSP State Report carried on a
PCRpt message to the PCE, indicating that the LSP's status is 'Up' or
'Active'.
If the LSP could not be set up, the PCC sends an LSP State Report
indicating that the LSP is "Down' and stating the cause of the
failure.
OLD
In such cases, the PCC may choose to only send the PCRpt
indicating the latest status ('Up' or 'Down¹).
NEW
In such cases, the PCC may choose to only send the PCRpt
indicating the latest status (ŒActive¹, 'Up' or 'Down').
Reason : Active is also a possible state.
Section 5.6.2
OLD
If the PCC decides that the LSP parameters proposed in the PCUpd message
are unacceptable, it MUST report this error by including the
LSP-ERROR-CODE TLV (Section 7.3.3
<https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-09#section-7.3.3>)
with LSP error-value=³Unacceptable parameters" in the LSP object in the
PCRpt message to the PCE
NEW
If the PCC decides that the LSP parameters proposed in the PCUpd message
are unacceptable, it MUST report this error by including the
LSP-ERROR-CODE TLV (Section 7.3.3
<https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-09#section-7.3.3>)
with LSP error-value=³Unacceptable parameters" in the LSP object in the
PCRpt message to the PCE. The PCC MAY/SHOULD include the objects that were
not accepted in the PCRpt message.
Reason: If the PCC includes the objects (current PCC values) that caused
the PCUpd to be rejected, it would help the PCE avoid resending them. A
PCErr would allow to include the objects, a new error type would be needed
but error handling from PCE side should be rather easy. Another
possibility is having the LSP-ERROR-CODE containing a list of
Object-Class, OT .
OLD
Once an LSP is up, the PCC sends an LSP State Report (PCRpt message)
to the PCE, indicating that the LSP's status is 'Up'. If the LSP
could not be set up, the PCC sends an LSP State Report indicating
that the LSP is 'Down' and stating the cause of the failure.
NEW
Once an LSP is up or active, the PCC sends an LSP State Report (PCRpt
message)
to the PCE, indicating that the LSP's status is 'Up¹ (resp. 'Active').
If the LSP
could not be set up, the PCC sends an LSP State Report indicating
that the LSP is 'Down' and stating the cause of the failure.
Section 6.1
OLD
The RRO SHOULD be included by the PCC when the path is up,
NEW
The RRO SHOULD be included by the PCC when the path is up or active,
Section 7
Replace MUST by SHOULD, this is restricting a lot future documents (not
allowing to enforce/ignore gracefully some objects)
Section 7.3.
Nits: Using Synchronize would be better aligned with other bits definition
S bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on transmission
and MUST be ignored on receipt.
R bit: Add: On PCUpd the R flag SHOULD (MUST?) be set to 0 on transmission
and MUST be ignored on receipt
(or it is allowed on PCUpd?)
O bit: Add: On PCUpd the O Field SHOULD (MUST?) be set to 0 on
transmission and MUST be ignored on receipt.
Section 7.3.3.
The error value ŒLSP preempted¹ could seem a bit redundant with ŒRSVP
signaling error¹ and the corresponding RSVP preempted error code, I
believe the error code ŒLSP preempted¹ should be seen when a PCC-local
administrative preemption is made, and the RSVP signaling error should be
used otherwise (the error node can be of value for the PCE)
BR
Cyril
On 6 October 2014 09:57, Dhruv Dhody <dhruv.i...@gmail.com> wrote:
> Hi WG,
>
> Support both the documents, and are basically ready for publications.
>
> I re-read the documents again, here are some nits/comments which can
> be handled along the process.
>
> --------
>
> For draft-ietf-pce-stateful-pce-app: (listed as a contributor)
>
> - In sec 3. Overview of the Stateful PCE Protocol Extensions; the word
> tunnel is used in below paragraph, for consistency with rest of the
> document can it be changed to LSP.
>
> [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to
> enable stateful control of tunnels within and across PCEP sessions in
> compliance with [RFC4657]. It includes mechanisms to effect tunnel
> state synchronization between PCCs and PCEs, delegation of control
> over tunnels to PCEs, and PCE control of timing and sequence of path
> computations within and across PCEP sessions.
>
> Since we are not using RFC2119 keywords in this document, we should
> not use 'SHOULD'.
>
> LSP state synchronization (C-E): after the session between a PCC and
> a stateful PCE is initialized, the PCE can perform path
> computation and update attributes in a PCC. However, if the goal
> of the PCE is to provide accurate path information based on the
> most up-to-date state of the network, the PCE SHOULD wait until it
> learns the state of the PCC's LSP states before doing so.
>
> - In sec 4.3. PCE Survivability; a reference to
> draft-ietf-pce-stateful-sync-optimizations can be added for
> readability.
>
> - Expand on first use PCReq, LER, NMS, RRO, RSVP-TE
>
> - Suggest if you can add IANA consideration section and explicitly say
> that there are no request for IANA in this document.
>
> - Some unused references like MXMN-TE, MPLS-PC, NET-REC (perhaps
> because of older version text from draft-ietf-pce-stateful-pce)
>
> --------
>
> For draft-ietf-pce-stateful-pce:
>
> - RFC2119 keywords requirement language should be added as subsection
> in introduction.
>
> 1.1 Requirements Language
>
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in RFC 2119 [RFC2119].
>
> - In sec 3.2. Objectives
> OLD:
> Allow a PCC to delegate control of its LSPs to an active stateful
> PCE such that a single LSP is under the control a single PCE at
> any given time.
> NEW:
> Allow a PCC to delegate control of its LSPs to an active stateful
> PCE such that a LSP is under the control a single PCE at
> any given time.
> The current text gives an impression that only one LSP (a single LSP)
> is under control of a PCE.
>
> - In sec 5.4. State Synchronization, for figure 2 and 3 'PCErr=?' is
> used, I suggest either to put the error type/code or remove '=?'.
>
> - Update reference for minei-pce-stateful-sync-optimizations to
> ietf-pce-stateful-sync-optimizations
>
> - I am not sure what is the correct way to put comments inside RBNF,
> or better yet they should simply be avoided. In section 6.3, 6.4 and
> 6.5 "<<<<" and "<---" are used.
>
> - The alignment for the byte markers is incorrect in figure 10
>
> - In sec 7.3.2. Symbolic Path Name TLV, can the following text be added?
>
> The Symbolic Path Name is padded to 4-bytes alignment; padding
> itself is not included in the Length field.
>
> - In sec 7.3.3. LSP Error Code TLV, we should say - "The following LSP
> Error Codes are *currently* defined:"; so that future documents can
> easily extend it.
>
> - In 9.6. Impact on Network Operation s/PcE/PCE
>
> - ietf-pce-gmpls-pcep-extensions can be removed as a normative reference.
>
> - there are bunch of idnits that you may wish to handle (see attached)
>
> --------
>
> Dhruv
>
>
> On Sun, Sep 14, 2014 at 3:42 PM, JP Vasseur (jvasseur)
> <jvass...@cisco.com> wrote:
> > Dear WG,
> >
> > Both draft-ietf-pce-stateful-pce-app-02 and
> draft-ietf-pce-stateful-pce-09
> > are now stable ready for WG Last Call.
> > This starts a 3-week WG Last call, which will end on Oct 6 at noon ET.
> >
> > Please send your comments on the mailing list.
> >
> > ps: this WG LC will be followed by another WG LC on
> > draft-ietf-pce-stateful-sync-optimizations-01
> > and draft-ietf-pce-pce-initiated-lsp-01.
> >
> >
> > Thanks.
> >
> > JP and Julien.
> >
> > _______________________________________________
> > Pce mailing list
> > Pce@ietf.org
> > https://www.ietf.org/mailman/listinfo/pce
> >
>
> _______________________________________________
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce
>
>
_______________________________________________
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce
