Subject: Re: [Pce] WG Last Call on draft-ietf-pce-stateful-pce-app-02 and draft-ietf-pce-stateful-pce-09

From: Dhruv Dhody <[email-masked]>
Date: Mon, 6 Oct 2014 19:27:29 +0530

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)
<[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pce
>

---

From: Cyril Margaria <[email-masked]>
Date: Mon, 6 Oct 2014 13:29:18 -0400

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

---

From: <[email-masked]>
Date: Thu, 9 Oct 2014 15:39:39 +0200

Hi all.

These last calls have ended. We have only seen one public review.
Authors, please address received comments, including the one
received today.

Thanks,

JP & Julien

Sep. 14, 2014 - JP Vasseur (jvasseur):

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.

ps: this WG LC will be followed by another WG LC on draft-ietf-pce-stateful-sync-optimizations-01

Thanks.

JP and Julien.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Ina Minei <[email-masked]>
Date: Sun, 26 Oct 2014 21:36:04 -0700

Dhruv,

Thank you for the careful review.  Please find inline below, ###.

> ### This section was already included in the draft, just below the
abstract. I moved it to the introduction

> is under control of a PCE.

### Yes, I replaced to "a given LSP is under the control of a single PCE at
any given time".

> used, I suggest either to put the error type/code or remove '=?'.

### done

> ietf-pce-stateful-sync-optimizations
### done

> 6.5 "<<<<" and "<---" are used.
### removed

> - The alignment for the byte markers is incorrect in figure 10
###fixed

>      itself is not included in the Length field.
### No, I think this is a disruptive change for implementations that
already handle the variable length of this TLV. Doing what you propose
would break the parsing code.

> Error Codes are *currently* defined:"; so that future documents can
### ok

> ###ok

> ###ok

> draft-ietf-pce-stateful-pce-09

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 27 Oct 2014 05:44:06 +0000

Hi Ina,

Snipping to the only open issue…

    The Symbolic Path Name is padded to 4-bytes alignment; padding
     itself is not included in the Length field.
### No, I think this is a disruptive change for implementations that already handle the variable length of this TLV. Doing what you propose would break the parsing code.

But RFC5440 TLV definition require this
http://tools.ietf.org/html/rfc5440#section-7.1
7.1<http://tools.ietf.org/html/rfc5440#section-7.1>.  PCEP TLV Format
   A PCEP object may include a set of one or more optional TLVs.

   All PCEP TLVs have the following format:

   Type:   2 bytes
   Length: 2 bytes
   Value:  variable

   A PCEP object TLV is comprised of 2 bytes for the type, 2 bytes
   specifying the TLV length, and a value field.

   The Length field defines the length of the value portion in bytes.
   The TLV is padded to 4-bytes alignment; padding is not included in
   the Length field (so a 3-byte value would have a length of 3, but the
   total size of the TLV would be 8 bytes).

So I am hoping the implementations of stateful PCE should follow the base RFC5440 TLV definition .

Regards,
Dhruv

---

From: Ina Minei <[email-masked]>
Date: Sun, 26 Oct 2014 22:57:11 -0700

Thank you for the careful review, please see inline ###.

[snip]
> for those variables would be better, as they are integral part of the

### They are discussed in the main part of the draft, their use etc is
introduced as early as page 4 of the doc. The suggested values for these
timers are added in the operational section in the appendix, where they
logically belong and I don't think we want to move them.

> the Initialization phase, and clarify the PCE operation.

### This is covered in the current text and also clearly shown in figure 1.
.

> ### Thank you for catching

> Reason : Active is also a possible state.
### Added

> <https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-09#section-7.3.3
> >)
> <https://tools.ietf.org/html/draft-ietf-pce-stateful-pce-09#section-7.3.3
> >)
> ### While I agree in principle, I think if we go down this road we should
also include the reason
why the object was rejected to make this useful. Unless others feel
strongly, I would not add this.

>    that the LSP is 'Down' and stating the cause of the failure.
### Done

### done

> transmission and MUST be ignored on receipt.

### This would preclude use of these bits in future documents, so  I prefer
not to add this.

> used otherwise (the error node can be of value for the PCE)
###  I think there is value to keep preemption separate from signaling
error, and I prefer to leave them
distinct.

---

From: Ina Minei <[email-masked]>
Date: Sun, 26 Oct 2014 23:06:18 -0700

Dhruv, thank you for sending the reference. In that case, should already be
compliant since the draft defines new pcep tlvs.

On Sun, Oct 26, 2014 at 10:44 PM, Dhruv Dhody <[email-masked]>
wrote:

> *7.1* <http://tools.ietf.org/html/rfc5440#section-7.1>*.  PCEP TLV Format*
>

---

From: Cyril Margaria <[email-masked]>
Date: Mon, 27 Oct 2014 09:57:02 -0400

Hi Ina,

Thanks, see inline for the open points.

> logically belong and I don't think we want to move them.

I think it will be easier for YANG/MIB module designers to have a small
appendix for those, with recommended values repeated there. The rest of the
document does not need to  be changed in that regards.

> ### This is covered in the current text and also clearly shown in figure
> 1. .
>

It is implicit in the text,, I think making it explicit would be better for
implementations.

> strongly, I would not add this.

I think having the mechanism would be aldready usefull with existing error
messages.
Having WG feedback in also welcomed.

> ### This would preclude use of these bits in future documents, so  I
> prefer not to add this.
>

Reserved bit are usually defined as follows  "Unassigned bits are
considered reserved. They MUST be set to zero on transmission and MUST be
ignored on receipt."

So restricting those values on PCUpd in this document does not preclude
another document indicating how to use them when supporting that other
document (It will be likely negotiated). Moreover this allows the new
defining document to make sure that those bits have a specific value when
using the stateful document.

> error, and I prefer to leave them

My comment was not much on removing it, but have the text scope them
better, as they are mutually exclusive, implementation wise I would like to
know when to send the PCEP preempted, and the signaling preempted.