Subject: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01

From: <[email-masked]>
Date: Mon, 1 Dec 2014 18:18:02 +0100

Dear all,

As planned, this message ignites a 3-week WG Last Call on both 
draft-ietf-pce-pce-initiated-lsp-02 and 
draft-ietf-pce-stateful-sync-optimizations-01. It will end on Monday 
December 22 at 11:59 PM, HST.

Please send your comments to the PCE mailing list.

Thanks,

JP & 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: Jeff Tantsura <[email-masked]>
Date: Mon, 1 Dec 2014 19:07:45 +0000

Yes/support

Cheers,
Jeff

-----Original Message-----
From: "[email-masked]" <[email-masked]>
Organization: Orange
Date: Monday, December 1, 2014 at 9:18 AM
To: "[email-masked]" <[email-masked]>
Subject: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and
draft-ietf-pce-stateful-sync-optimizations-01

>__________________________________________________________________________
>_______________________________________________
>
>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,
>This message and its attachments may contain confidential or privileged
>information that may be protected by law;
>_______________________________________________
>Pce mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/pce

---

From: Ina Minei <[email-masked]>
Date: Tue, 2 Dec 2014 11:45:45 -0800

Support as co-author.

On Mon, Dec 1, 2014 at 9:18 AM, <[email-masked]> wrote:

> draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01.
> It will end on Monday December 22 at 11:59 PM, HST.
>
> ____________________________________________________________
> _____________________________________________________________
>

---

From: Hariharan Ananthakrishnan <[email-masked]>
Date: Tue, 2 Dec 2014 19:49:33 +0000

Support.

- Hari

---

From: "Jan Medved (jmedved)" <[email-masked]>
Date: Wed, 3 Dec 2014 03:09:52 +0000

Support on both

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Thu, 4 Dec 2014 16:49:38 +0000

Support both but with two comments :

Draft-ietf-pce-pce-initiated-lsp-02: 
in the 3.2 Operation Overview is mentioned R flag in SRP object before to have defined it (this is new ). So I would suggest, as in other PCE-drafts, to ad a little session about the NEW PCEP things introduced that means :
New PCEP message --> INITIATE
New flag I in the Stateful PCE capability TLV
New flag R in SRP object
New flag C in LSP object

Draft-ietf-pce-stateful-synch-optimization-01:
Just an editorial note , in figure 7 it is likely to be D=1 not T=1 since the example is for incremental delta syncronization .

Thanks

Sergio

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: lunedì 1 dicembre 2014 18:18
To: [email-masked]
Subject: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01

Dear all,

As planned, this message ignites a 3-week WG Last Call on both
draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01. It will end on Monday December 22 at 11:59 PM, HST.

Thanks,

JP & 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: Robert Varga <[email-masked]>
Date: Thu, 18 Dec 2014 15:44:59 +0100

Hello,

donning the implementer (as opposed to co-author) hat, I have comments 
pertaining to draft-ietf-pce-pce-initiated-lsp, specifically to Section 
6. In general it seems to contradict the general outline of the 
extension as stated in section 3.2 paragraph 4.

The first paragraph clearly forbids the use of PCRpt D=0 for 
PCE-initiated LSPs. It is not clear whether this restriction applies to 
all PCRpts, or only the PCRpt solicited by the PCInitiate message. 
Section 3.2 paragraph 4 seems to indicate this applies to solicited 
PCRpts only, which is what makes sense. A clarification is definitely 
needed.

The third paragraph seems to be replacing the normal delegation 
mechanics with a PCInitiate-driven exchange. It does not specify whether 
it is legal for a PCE to send PCUpd(D=1) after a session flap or not. It 
feels like it is not legal and PCInitiate is intended to fully replace 
it, but that would contradict section 3.2 paragraph 4. This needs to be 
clarified.

My preference would be to remove pretty much all of this paragraph, 
bringing the mechanics to what section 3.2 outlines. Unfortunately there 
are already some implementations deployed, so we need to factor in the 
compatiblity with the installed base. Can we perhaps allocate another 
bit in the Stateful PCE Capability TLV and mark the current one as 
reserved/deprecated?

Thanks,
Robert

On 12/01/2014 06:18 PM, [email-masked] wrote:
> a l'expediteur et le detruire ainsi que les pieces jointes. Les 
> messages electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or 
> privileged information that may be protected by law;

---

From: Ramon Casellas <[email-masked]>
Date: Fri, 19 Dec 2014 12:57:18 +0100

El 01/12/2014 a las 18:18, [email-masked] escribió:
> draft-ietf-pce-pce-initiated-lsp-02

Hi authors, all,

A fast review of the draft, please note:

* Error:   "To indicate a delete operation, the PCE MUST use the R flag 
in the
    SRP object in a PCUpd message.  As a result of the deletion request,
    the PCC MUST remove all state related to the LSP, and send a PCRpt
    with the R flag set in the LSP object for the removed state"

it should be PCInitiate, as later described in Section 5.4 
"PCE-initiated removal of a PCE-initiated LSP is done by setting the R
    (remove) flag in the SRP Object in the PCInitiate message from the 
PCE." as well as the RBNF (note that, personally I would favor being 
picky as in  "in the SRP object of the PCE-initiated-lsp-instantiation 
within the PCInitiate message" etc. notably when multiple lsp requests 
can be in a message)

* Confused by the sentence " Every request from the PCE receives a new 
SRP-ID-number.  This number is unique per PCEP session and is 
incremented each time an operation
    (initiation, update, etc) is requested from the PCE" i.e., the 
"unicity-per-session" (although the intent is clear)

* Indent 0,1,2,3 digits to describe bit position in the SRP object format.

* Minor nit: IANA considerations section should mention new R flag in SRP.

* Error-value=13: LSP cleanup TLV missing -> this looks like a leftover 
from an old version?

* I would have some very minor comments about error conditions, 
hopefully triggering some discussion
- I am a bit confused about the differences between ET=19 -Invalid 
operation- and ET=24 -LSP instantiation error-
("Is the error a result of an invalid operation? ;)"
- Why is "non-zero plsp-id" an invalid operation rather than a "bad 
parameter value"?
- Why is "Speaker identity included for an LSP that is not 
PCE-initiated" a bad parameter rather than an invalid operation?
- Why is there a type "bad parameter value" yet the error "unacceptable 
instantiation parameters" a value within the "instantiation error" type?
I am aware there may be deployments and changing this may be problematic,

Best regards
Ramon

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 22 Dec 2014 10:43:39 +0000

Hi All, 

> draft-ietf-pce-pce-initiated-lsp-02 

Support with following comments: 

(1) We should align the tone of the draft to http://tools.ietf.org/html/rfc7399#section-20 which differentiates between the recommendation for instantiation (this draft), and the actual (NMS like) instantiation of the LSPs (marked out of scope). This could either be done by a suitable text in Introduction and/or use of phrase 'recommend instantiation' in the document. 

(2) In sec 3.2,
OLD:
To indicate a delete operation, the PCE MUST use the R flag in the
SRP object in a PCUpd message.
NEW:
To indicate a delete operation, the PCE MUST use the R flag in the
SRP object in a PCInitiate message.

I guess Ramon pointed this out already! 

(3) In sec 5.3.1, we are changing the meaning of the SPEAKER-IDENTITY-ID TLV, which was earlier used in OPEN to identify the exact PCEP-Speaker but now here it identifies the PCE that initiated the LSP. This looks like a hack, a better idea would be to define a new TLV type PCE-INITIATED-IDENTITY-ID with the same format. 

(4) Section 9.1, it says...
Rapid flaps triggered by the PCE can also be an attack vector.  This
will be discussed in a future version of this document.

The text for this needs to be added. 

(5) It would be nice to have a manageability consideration section. 

(6) Few lines on state synchronization should also be added -  If the DB did not survive the PCC restart, PCE must send the PCE initiated message again. During state synchronization the PCE should get the status of PCE Initiated LSPs with C flag set in the LSP object. Incase of redelegation to a different PCE the same should be reported during state synchnronization with D=0. The original PCE should also be allowed to send PCInitiate to get back the delegation. (this is not allowed in the current text as PCInitiate with non-zero PLSP-ID is allowed only during State Timeout timer)  

Nits
- Reference to 2119, as SHOULD, MUST are used in the document 
- Expand on first use LER, LSR etc 
- Reference to SRP, LSP, PLSP-ID as defined in [I-D.ietf-pce-stateful-pce]
- section 3.2 s/PCinitiate/PCInitiate/
- section 4 s/A PCC indicates its ability.../A PCEP speaker indicates its ability/ (because both PCC and PCE needs to do this)
- section 4.1 Type=16 should be removed as its TBD in the base document as well http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10#section-7.1.1
- section 4.1 
OLD:
If set to 1 by a PCE, the I flag indicates that the PCE will
attempt to instantiate LSPs.
NEW:
If set to 1 by a PCE, the I flag indicates that the PCE can
attempt to instantiate LSPs.

> and draft-ietf-pce-stateful-sync-
> optimizations-01. 

Support (As a co-author)

Regards,
Dhruv

> _____________________________________________________________________
> ____________________________________________________
> 
> 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.
> 
> 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.

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 22 Dec 2014 10:44:56 +0000

Hi Robert, 

See inline...

> From: Pce [mailto:[email-masked]] On Behalf Of Robert Varga
> Sent: 18 December 2014 20:15
> To: [email-masked]; [email-masked]
> Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-
> 02 and draft-ietf-pce-stateful-sync-optimizations-01
> 
> Hello,
> 
> donning the implementer (as opposed to co-author) hat, I have
> comments pertaining to draft-ietf-pce-pce-initiated-lsp, specifically
> to Section 6. In general it seems to contradict the general outline
> of the extension as stated in section 3.2 paragraph 4.
> 
> The first paragraph clearly forbids the use of PCRpt D=0 for PCE-
> initiated LSPs. It is not clear whether this restriction applies to

But http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10#section-5.5.1 says.. 

Note that for an LSP to remain delegated to a PCE, the PCC MUST set
the Delegate flag to 1 on each LSP Status Report sent to the PCE.

So the D flag must be set on all PCRpts (including the solicited (first) PCRpt and any other PCRpt message). 

I am not sure what text in section 3.2 paragraph 4 is an issue?  

> mechanics with a PCInitiate-driven exchange. It does not specify
> whether it is legal for a PCE to send PCUpd(D=1) after a session flap
> or not. It feels like it is not legal and PCInitiate is intended to
> fully replace it, but that would contradict section 3.2 paragraph 4.
> This needs to be clarified.

I think some clarification is needed. The text says..

In case of PCEP session failure, control over PCE-initiated LSPs
reverts to the PCC at the expiration of the redelegation timeout.  To
obtain control of a PCE-initiated LSP, a PCE (either the original or
one of its backups) sends a PCInitiate message, including just the
SRP and LSP objects, and carrying the PLSP-ID of the LSP it wants to
take control of.

During state synchronization itself (full or incremental) the D flag could be set while reporting the status of PCE-Initiated LSP (with C flag set) if re-delegation is not done to another PCE. I feel the same behavior make sense for PCC-Initiated LSP as well incase one wants to delegate to the same PCE again after session down. It should not be mandatory to send PCInitiage message in all cases. 

Regards,
Dhruv

> bringing the mechanics to what section 3.2 outlines. Unfortunately
> there are already some implementations deployed, so we need to factor
> in the compatiblity with the installed base. Can we perhaps allocate
> another bit in the Stateful PCE Capability TLV and mark the current
> one as reserved/deprecated?
> 
> Thanks,
> Robert
> 
> _
> > ___________________________________________________
> >
> >
> > As emails may be altered, Orange is not liable for messages that
> have
> > been modified, changed or falsified.
> > Thank you.
> >

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Mon, 22 Dec 2014 10:59:03 +0000

Hi Druhv,

as I pointed out in mail,

in section 3.2 , when you talked about R flad in SRP, the fleg is new and is introduced in the following chapter.

For me text should be:

(2) In sec 3.2,

OLD:

To indicate a delete operation, the PCE MUST use the R flag in the SRP object in a PCUpd message.

NEW:

To indicate a delete operation, a new R flag is introduced in the SRP object and to be used in a PCInitiate message.

Thanks

Sergio

-----Original Message-----
From: Pce [mailto:[email-masked]] On Behalf Of Dhruv Dhody
Sent: lunedì 22 dicembre 2014 11:44
To: [email-masked]; [email-masked]
Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and draft-ietf-pce-stateful-sync-optimizations-01

Hi All,

(2) In sec 3.2,

OLD:

To indicate a delete operation, the PCE MUST use the R flag in the SRP object in a PCUpd message.

NEW:

To indicate a delete operation, the PCE MUST use the R flag in the SRP object in a PCInitiate message.

Rapid flaps triggered by the PCE can also be an attack vector.  This will be discussed in a future version of this document.

Nits

- section 4.1

OLD:

If set to 1 by a PCE, the I flag indicates that the PCE will attempt to instantiate LSPs.

NEW:

If set to 1 by a PCE, the I flag indicates that the PCE can attempt to instantiate LSPs.

Support (As a co-author)

Regards,

Dhruv

> 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

> [email-masked]<mailto:[email-masked]>

Pce mailing list

[email-masked]<mailto:[email-masked]>

---

From: Robert Varga <[email-masked]>
Date: Mon, 22 Dec 2014 16:07:40 +0100

> Hi Robert,

Hello Dhruv,

See inline

> So the D flag must be set on all PCRpts (including the solicited (first) PCRpt and any other PCRpt message).

Right, but that would also mean that a PCE-initiated LSP cannot be 
reported to backup PCEs, as that would mean the LSP is delegated to 
multiple PCEs at the same time...

> I am not sure what text in section 3.2 paragraph 4 is an issue?

The specific text is this:

    Once instantiated, the delegation procedures for PCE-initiated LSPs
    are the same as for PCC initiated LSPs as described in
    [I-D.ietf-pce-stateful-pce  <https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-02#ref-I-D.ietf-pce-stateful-pce>].  This applies to the case of a PCE
    failure as well.

Which is precisely what I understand you are implying in your response 
below.

> During state synchronization itself (full or incremental) the D flag could be set while reporting the status of PCE-Initiated LSP (with C flag set) if re-delegation is not done to another PCE. I fe…

Bye,
Robert

---

From: Cyril Margaria <[email-masked]>
Date: Mon, 22 Dec 2014 11:36:36 -0500

Hi,

I have the following comments on draft-ietf-pce-pce-initiated-lsp-02:
Some comments require non minor changes (security section). I think the
document should progress, but I am not sure its fully ready for LC.

Section 3.2. "Operation overview"

- "A PCE may return a delegation to the PCC in order to facilitate
re-delegation of its LSPs to an alternate PCE."
  In this context (protocol operation), a MAY seems appropriate.

Section 4.1:
-  In draft-ietf-pce-stateful-sync-optimizations-01, the U is referenced in
the list of flags. draft-ietf-pce-pce-initiated-lsp-02 could use the same
format.

Section 5

 - The section is a mix of object definition and procedures, the procedures
could be more clearly marked (having separate object format and procedure
section, or changing the section titles)

Section 5.1.

 - The error procedure refers to I-D.ietf-pce-stateful-pce for a message
defined in this document, I-D.ietf-pce-stateful-pce should not define error
procedure for unknown message.
   I believe you are refering to the error values
  OLD:
  "If either the SRP or the LSP object is missing, the PCC MUST send a
PCErr as described in [I-D.ietf-pce-stateful-pce]."

  NEW:
  "If either the SRP or the LSP object is missing, the PCC MUST send a
PCErr with error-type 6 (Mandatory Object missing) and error-value=10 (SRP
Object missing), respectively error-value=8 (LSP Object missing). Those
errors are defined defined in [I-D.ietf-pce-stateful-pce]."

 - Section 3.2 has a more strict definition of the message content, that
matches the RBNF, namely including the ERO and ENDPOINTS objects,
   the text of section 3.2 sould be moved to this section (the overview
being more detailed than the definition), but its also repeated in section
5.3., maybe better to reference section 5.3 or have section 5.3 be a
"procedures" subsection

Section 5.2.

 - "The type object is defined in [I-D.ietf-pce-stateful-pce]."
  This sentence could be removed

Section 5.3

- OLD: "The LSP is set up using RSVP-TE, extensions for other setup methods
are outside the scope of this draft."
  NEW: "The LSP is assumed to be set up using RSVP-TE, extensions for other
setup methods are outside the scope of this draft."

- OLD: "The END-POINTS Object is mandatory for an instantiation request of
an RSVP-signaled LSP."
  NEW: "The END-POINTS Object is mandatory for an instantiation request."

 Regardless of RSVP or other protocol, the END-POINTS is required on a lot
of PCEP messages, so if new signaling protocols does not require the
END-POINTS, its better to leave the new definition that will affect other
PCEP messages to that document.

 - Error code 6 (Object missing) for a missing TLV seems confusing, its
more a malformed object content (as the TLV is part of the object), the TLV
missing error should be reparented to error-type=10 (Reception of an
invalid object)
 - "If there is conflict with
   the LSP name, the PCC MUST send a PCErr message with Error-type=23
   (Bad Parameter value) and Error-value=1 (SYMBOLIC-PATH-NAME in use).
   The only exception to this rule is for LSPs for which the State
   timeout timer is running (see Section 6)."
 I am unsure the exception is a good mechanism, this is detailed further in
the comment for section 6.

 - "LSPs that were instantiated as a result of a PCInitiate message MUST
have the C flag set in the LSP object."
  C flag is not yet defined, please add reference to the section or has
Object extensions then procedures

 - "If the PCC determines that the LSP parameters proposed in the
PCInitiate message are unacceptable, it MUST trigger a PCErr with
   error-type=TBD (PCE instantiation error) and error-value=1 (Unacceptable
instantiation parameters)."

  This procedure is cleaner and offers more possibility for the PCE to know
which parameter was wrong, base draft should use the same

 - "A PCC MUST relay to the PCE errors it encounters in the..."
  This imply that the PCC SHOULD wait for the LSP to be signaled before
reporting the LSP State,  I would suggest the following text:

 "The PCC SHOULD respond to the PCInitiate message when the LSP has been
signaled. On succesful completion ... (Last paragraph).
  On unsucessfull completion a PCC MUST relay ..."

 - on PCInitiate , the Symbolic Path Name TLV is mandatory, the LSP
Identifiers TLVs may be present unless specified (I do not see any
drawback/limitation, behavior is the same as mplsTunnelIndex)
   is this correct?
 - Are the LSP Error Code TLV and  RSVP Error Spec TLV accepted, rejected
or ignored?
 - Section 5.3.1 indicated a new optional TLV (SPEAKER-IDENTITY-ID), maybe
a TLV presence rules section could be usefull, its now distributed over
different sections and levels.

Section 5.3.1.

 - Is there any specific reason to have the flag defined as a subsection of
the instantiation procedure rather than a separate section as the R flag?
 - Nits : draft-ietf-pce-stateful-pce-10 define Flag, the document defines
Flags, name should be aligned

 - "If the TLV appears for an LSP for which the C flag is 0,
   the TLV MUST be ignored the PCC MUST send a PCErr message with Error-
   type 23 ("Bad parameter value") and error value 2 ("Speaker identity
   included for an LSP that is not PCE-initiated")."

 To ease procedure,  why not allow it? this can be set to the PCC
SPEAKER-IDENTITY-ID for that matter, or simply ignored, it can be up to the
PCE. Why is the error necessary here?

Section 5.4:

 - OLD: "If the PLSP-ID specified in the PCInitiate message was not created
by the PCE, the PCC MUST send a PCErr message indicating "LSP is not PCE
initiated" (Error code 19,
   error value TBD)."
 - NEW: "If the PLSP-ID specified in the PCInitiate message was not created
by a PCE, the PCC MUST send a PCErr message indicating "LSP is not PCE
initiated" (Error code 19,
   error value TBD)."
 (In case of multiple PCEs)

 - TLV presence rules are missing:
  - is symbolic path name, lsp identifiers, ..etc  allowed or ignored?
  - does it make sense to allow the SPEAKER-IDENTITY TLV for debugging
purpose in the subsequent PCRpt ?

Section 6:
 - For the delegation bit, adding "to the PCE the LSP is delegated to"
would make the text more clear

 - What does contains the PCErr message of type 19 (Invalid Operation) and
value TBD "Delegation for PCE-initiated LSP cannot be revoked"?
   I believe it should at least contains the LSP object.

 - 'A PCE MAY return a delegation to the PCC, to allow for LSP transfer
   between PCEs.  Doing so MUST trigger the State Timeout Interval timer
   ([I-D.ietf-pce-stateful-pce]).'

   the state timeout interval is defined as "time period before flushing
LSP state associated
      with that PCEP session" (in case of session closed)
   In the context of a PCE returning the delegation, the State Timeout
interval should only apply to the LSP, not the the state associated to the
session. This should be stated

 - "To  obtain control of a PCE-initiated LSP, a PCE (either the original
or one of its backups) sends a PCInitiate message, ..."
   It feels a bit of a patch, I believe the PCC can redelegate the LSP to
the "original" PCE or to the "preferred" PCE by itself (Policies and
SPEAKER-IDENTITY-ID would allow for that), rather than adding an exception
(who wins in case the timeout is long and several PCEs connect at the same
time, for say a network failure?)

Section 8.

- Missing the new bit definition of Section 4.1. Stateful PCE Capability
TLV (according to draft-ietf-pce-stateful-pce-10, section 8.6.)
   I : bit  29
- Missing the new bit definition of Section 5.2. The R flag in the SRP
Object - The bit number should be defined (bit 31), should a new registry
be defined at this point?

Section 8.3
 - As described before, error-type=23, error-value=2 is not needed
 - Error-type=24, error-value=3 : OLD: "RSVP signaling error" , NEW:
"signaling error" The type of error is included in the TLV, Restricting the
error to RSVP is too stong.

Section 9.1:
 "Rapid flaps triggered by the PCE can also be an attack vector.  This will
be discussed in a future version of this document."
 Its rather time to document them

 The exception mechanism also introduce another attack (restart the session
and steal LSPs)

 Was the END-POINTS under PCE control considered? This would allow a
malicious PCE to strain other AS/domains.

On 22 December 2014 at 05:59, BELOTTI, SERGIO (SERGIO) <
[email-masked]> wrote:

> To indicate a delete operation, a new R flag is introduced in the SRP
> object and to be used in a PCInitiate message.
>
>
>
> Thanks
>
>
>
> Sergio
>
>
>
>
>
>
>
> Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02 and
> (1) We should align the tone of the draft to
> http://tools.ietf.org/html/rfc7399#section-20 which differentiates
> between the recommendation for instantiation (this draft), and the actual
> (NMS like) instantiation of the LSPs (marked out of scope). This could
> either be done by a suitable text in Introduction and/or use of phrase
> 'recommend instantiation' in the document.
>
>
>
> (2) In sec 3.2,
>
> OLD:
>
> (3) In sec 5.3.1, we are changing the meaning of the SPEAKER-IDENTITY-ID
> TLV, which was earlier used in OPEN to identify the exact PCEP-Speaker but
> now here it identifies the PCE that initiated the LSP. This looks like a
> hack, a better idea would be to define a new TLV type
> PCE-INITIATED-IDENTITY-ID with the same format.
>
>
>
> Rapid flaps triggered by the PCE can also be an attack vector.  This will
> be discussed in a future version of this document.
>
>
>
> (6) Few lines on state synchronization should also be added -  If the DB
> did not survive the PCC restart, PCE must send the PCE initiated message
> again. During state synchronization the PCE should get the status of PCE
> Initiated LSPs with C flag set in the LSP object. Incase of redelegation to
> a different PCE the same should be reported during state synchnronization
> with D=0. The original PCE should also be allowed to send PCInitiate to get
> back the delegation. (this is not allowed in the current text as PCInitiate
> with non-zero PLSP-ID is allowed only during State Timeout timer)
>
>
>
> Nits
>
> - section 4 s/A PCC indicates its ability.../A PCEP speaker indicates its
> ability/ (because both PCC and PCE needs to do this)
>
> - section 4.1 Type=16 should be removed as its TBD in the base document as
> well
> http://tools.ietf.org/html/draft-ietf-pce-stateful-pce-10#section-7.1.1
>
> - section 4.1
>
> OLD:
>

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 22 Dec 2014 17:18:13 +0000

Hi Robert,

(snip)

Hello,

needed.

Right, but that would also mean that a PCE-initiated LSP cannot be reported to backup PCEs, as that would mean the LSP is delegated to multiple PCEs at the same time...

[Dhruv]: A clarification that one is referring to the PCE that initiated the LSP in the paragraph should clear that up.

   [I-D.ietf-pce-stateful-pce<https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-02#ref-I-D.ietf-pce-stateful-pce>].  This applies to the case of a PCE

   failure as well.
Which is precisely what I understand you are implying in your response below.

[Dhruv]:

take control of.

Regards,

Dhruv

Bye,
Robert

Thanks,

Robert

On 12/01/2014 06:18 PM, [email-masked]<mailto:[email-masked]> wrote:

Dear all,

draft-ietf-pce-stateful-sync-optimizations-01. It will end on

Monday

Thanks,

JP & Julien

_

confidentielles ou privilegiees et ne doivent donc pas etre

diffuses,

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

privileged information that may be protected by law; they should

not

and

have

Thank you.

Pce mailing list

Pce mailing list

---

From: Dhruv Dhody <[email-masked]>
Date: Mon, 22 Dec 2014 17:23:54 +0000

Hit sent by mistake while I was still typing my response, jumping directly to it inline...

<snip>

   failure as well.

[Dhruv]: I guess the basic delegation procedure is same, but the difference comes out in revoking of delegation, re-delegation etc, so I agree a better clarifying text is needed.
<snip>

Regards,
Dhruv

---

From: Cyril Margaria <[email-masked]>
Date: Mon, 22 Dec 2014 14:03:29 -0500

Hi,

I have the following comments on
draft-ietf-pce-stateful-sync-optimizations-01.

Section 3 :
  The documents proposes different optimizations, spending a paragraph or
two to describe the different optimizations, then a list of extensions, and
finish with procedures would help.

Section 3.2
 - A bit INCLUDE-DB-VERSION (IDB) is defined, section 7 defines the S bit.

Section 3.2.2
 - OLD: "The type of the TLV is [TBD] and it has a a variable length, which
         MUST be greater than 0 and padded to 4-octet alignment (, and
padding
         is not included in the Length field).
         "
   NEW: "The type of the TLV is [TBD] and it has a a variable length, which
         MUST be greater than 0. The Value is padded to 4-octet alignment.
The  padding
        is not included in the Length field"

   The value field is padded, not the lenght

Section 4.

-  Incremental is not allowed, because Paragraph 6 of section 3.2 indicates:
   "Otherwise, the PCC MUST perform state synchronization to the stateful
PCE."
   Section 3.2 should take into consideration all the bits defined, moving
the procedures after all the object definition would allow for an easier
understanding.
- proposes-> defines

Section 4.2.
  - Figure 7: I believe this is the D flag, not the T flag

Section 5.

The use case is different from section 6, but they use the same bit to
advertize that capability, so if T bit is set, the PCC MUST/SHOULD/MAY wait
the trigger from the PCE??

Section 6.2.
 - OLD: "The PCC MUST respond with a PCRpt message and SHOULD include the
SRP-ID-number of  the PCUpd that triggered the resynchronization."
   NEW: "The PCC MUST respond with a PCRpt message with the LSP state, SYNC
Flag set to 0 and MUST include the SRP-ID-number of  the PCUpd that
triggered the resynchronization."
    SHOULD -> MUST.
        draft-ietf-pce-stateful-pce-10, section 5.6.2 indicates that the
PCRpt MUST include the SRP id in the subsequent PCErr or PCRpt. I see no
justification in the text to change the mechanism described in
draft-ietf-pce-stateful-pce-10.
    The SYNC flag MUST be set to 0, otherwise it may be confused with a
full sync.

 - I believe all those updates are scoped only to the session that
triggered the delta/PCE triggered sync, adding it explicitly would be good,
as its a change in the PCRpt mechanism of the PCC.

- What happens if the PCE sends multiple resync requests while the a full
resync is in progress?

Section 7:

- This should under section 3.3. PCEP Extensions, and refer to the section
defining the bit behavior,
- D bit requires the S bit to be set, correct? A corresponding error is
missing
- The behavior of T bit is not clear, see comment of section 5.
- T bit and D&S bit combination : it seems the T bit behavior does not
depend on the INCLUDE-DB-VERSION and Delta, so it can be set independently.
This should be specified.

Manageability section is missing.

Section 8.3.
Suggested values are off, 29 is the suggested value of the I bit of
draft-ietf-pce-pce-initiated-lsp-02.
I believed this should be:

TBD(suggested value 27)  DELTA-LSP-SYNC-CAPABILITY   This document
TBD(suggested value 28)  TRIGGERED-SYNC              This document
TBD(suggested value 30)  INCLUDE-DB-VERSION          This document

Section 9.

 The document introduces new messages that may introduce load on the PCC, a
malicious PCE may flood the PCC with resync requests, this should be
mentioned.

---

From: Cyril Margaria <[email-masked]>
Date: Mon, 22 Dec 2014 14:04:15 -0500

Hi,

While reviewing draft-ietf-pce-stateful-sync-optimizations, I catched the
following additional nit:

SPEAKER-IDENTITY-ID -> SPEAKER-ENTITY-ID

- Missing a Manageability Considerations section, following RFC6123

On 22 December 2014 at 11:36, Cyril Margaria <[email-masked]>
wrote:

> -  In draft-ietf-pce-stateful-sync-optimizations-01, the U is referenced
> in the list of flags. draft-ietf-pce-pce-initiated-lsp-02 could use the
> same format.
>
>
> Section 5
>
>  - The section is a mix of object definition and procedures, the
> procedures could be more clearly marked (having separate object format and
> procedure section, or changing the section titles)
>
> Section 5.1.
>
> - OLD: "The LSP is set up using RSVP-TE, extensions for other setup
> methods are outside the scope of this draft."
>   NEW: "The LSP is assumed to be set up using RSVP-TE, extensions for
> other setup methods are outside the scope of this draft."
>
>  I am unsure the exception is a good mechanism, this is detailed further
> in the comment for section 6.
>
>
>    error-type=TBD (PCE instantiation error) and error-value=1
> (Unacceptable instantiation parameters)."
>
>   This procedure is cleaner and offers more possibility for the PCE to
> know which parameter was wrong, base draft should use the same
>
>  - Is there any specific reason to have the flag defined as a subsection
> of the instantiation procedure rather than a separate section as the R flag?
>  - OLD: "If the PLSP-ID specified in the PCInitiate message was not
> created by the PCE, the PCC MUST send a PCErr message indicating "LSP is
> not PCE initiated" (Error code 19,
>    error value TBD)."
>  - NEW: "If the PLSP-ID specified in the PCInitiate message was not
> created by a PCE, the PCC MUST send a PCErr message indicating "LSP is not
> PCE initiated" (Error code 19,
>    error value TBD)."
>  "Rapid flaps triggered by the PCE can also be an attack vector.  This
> will be discussed in a future version of this document."
>  The exception mechanism also introduce another attack (restart the
> session and steal LSPs)
>
>> Subject: Re: [Pce] WG Last Call on draft-ietf-pce-pce-initiated-lsp-02
>> and draft-ietf-pce-stateful-sync-optimizations-01
>>
>>
>>
>> Hi All,
>>
>>
>>
>> - section 4.1 Type=16 should be removed as its TBD in the base document
>> as well