Re: [Pce] Review of draft-ietf-pce-stateful-pce-18

[lionel.morand]

Hi Julien, Jon,

Thank you for your feedback.
Please see below my answer/feedback (indicated with [LM2])

Regards,

Lionel
 
> Hi Julien
> 
> You are right, but it is *really easy* for the reader to confuse "stateful
> capability" with "update capability" and "active stateful capability".  Case 
> in
> point: I just confused them in my reply to Lionel.
> 
> We should fix each of the three points below to make this clearer.

[LM2] I agree :)

> Jon, Lionel,
> 
> I believe Lionel got confused by the wording introduced in RFC 8051:
> - no report, no update means stateless PCE;
> - report, no update means passive stateful PCE;
> - report and update means active (stateful) PCE.

[LM2] understood!
> 
> > =
> >
> > [LM] active/passive mode are not  advertized in PCEP. s/if active
> > stateful PCE capability was not advertised/if stateful PCE capability
> > was not advertised
> >
> > Jon> ACK
> >
> > =
> [JM] NACK! ;-)
> Actually, the passive mode is advertised using the Stateful-capability-object 
> TLV
> with the U bit unset, the active mode by setting the U bit.
> 
[LM2] "il faut être sorti de Saint-Cyr pour comprendre" as we say in french :)
Could be good to add something like "(as indicated by the U-bit clear in 
Stateful-capability-object)"

> > =
> >
> > Note that even if the update capability has not been advertised, a PCE
> > can still accept LSP Status Reports from a PCC and build and maintain
> > an up to date view of the state of the PCC's LSPs.
> >
> > [LM] I don't undersand. Is it not in contradiction with
> >
> > "If the PCEP Speaker on the PCE supports the extensions of this draft
> > but did not advertise this capability, then upon receipt of a PCRpt
> > message from the PCC, it MUST generate a PCErr with error- type
> > 19 (Invalid Operation), error-value 5 (Attempted LSP State Report if
> > active stateful PCE capability was not advertised) (see Section
> > 8.5) and it SHOULD terminate the PCEP session."
> >
> > Or does it mean that there is another way than PCRpt message for the
> > PCC to send LSP status reports to the PCE?
> >
> > Jon> ACK.  I think that the statement in the draft is bogus and I
> > propose to delete this sentence from it.
> >
> > =
> [JM] I do not think that the text is bogus:
> - case 1: no advertised capability on update but advertised on report (i.e. 
> passive
> stateful) => no error message;
> - case 2: no advertised capability on update nor report (i.e. stateless) => 
> error.

[LM2] After multiple readings and thanks to your explanation, I think I have 
understood. Am I correct saying that the PCE will accept LSP Status Reports 
from a PCC ONLY if the stateful PCE capability has been advertised (i.e. 
Stateful Capability TLV with the 'LSP Update' Flag cleared)? If it is the case, 
is it really required to keep this text, as in the previous paragraph we find 
the conditions to accept/reject reports from the PCC?
> 
> > =
> >
> > [LM] Would it be useful to discover (using another TLV) whether the
> > PCE is an active/passive stateful PCE, as in IGP-based capabilities
> > discovery mechanism?
> >
> > Jon> This can be inferred immediately from the U flag in the
> > STATEFUL-PCE-CAPABILITY TLV.  Passive mode is synonymous with not
> > sending / handling PCUpd messages.
> >
> > =
> [JM] The mechanism is there, but section 7.1.1 may deserve an explicit use of
> the "passive/active" terms, to make sure the capability terminology is aligned
> with the vocabulary in the IGP section.

[LM2] I can only be agree with you :)


_

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.

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Review of draft-ietf-pce-stateful-pce-18

[Jonathan Hardwick]

Hi Julien

You are right, but it is *really easy* for the reader to confuse "stateful 
capability" with "update capability" and "active stateful capability".  Case in 
point: I just confused them in my reply to Lionel.

We should fix each of the three points below to make this clearer.

Cheers
Jon

-Original Message-
From: Julien Meuric [mailto:julien.meu...@orange.com] 
Sent: 11 April 2017 16:00
To: Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; Lionel Morand 
<lionel.mor...@orange.com>; ops-...@ietf.org
Cc: draft-ietf-pce-stateful-pce@ietf.org; pce@ietf.org; i...@ietf.org
Subject: Re: [Pce] Review of draft-ietf-pce-stateful-pce-18

Jon, Lionel,

I believe Lionel got confused by the wording introduced in RFC 8051:
- no report, no update means stateless PCE;
- report, no update means passive stateful PCE;
- report and update means active (stateful) PCE.

More details below, [JM].

Thanks for the work,

Julien


Apr. 11, 2017 - jonathan.hardw...@metaswitch.com:
> =
> 
> [LM] active/passive mode are not  advertized in PCEP. s/if active 
> stateful PCE capability was not advertised/if stateful PCE capability 
> was not advertised
> 
> Jon> ACK
> 
> =
[JM] NACK! ;-)
Actually, the passive mode is advertised using the Stateful-capability-object 
TLV with the U bit unset, the active mode by setting the U bit.

> =
> 
> Note that even if the update capability has not been advertised, a PCE 
> can still accept LSP Status Reports from a PCC and build and maintain 
> an up to date view of the state of the PCC's LSPs.
> 
> [LM] I don't undersand. Is it not in contradiction with
> 
> "If the PCEP Speaker on the PCE supports the extensions of this draft 
> but did not advertise this capability, then upon receipt of a PCRpt 
> message from the PCC, it MUST generate a PCErr with error- type
> 19 (Invalid Operation), error-value 5 (Attempted LSP State Report if  
> active stateful PCE capability was not advertised) (see Section
> 8.5) and it SHOULD terminate the PCEP session."
> 
> Or does it mean that there is another way than PCRpt message for the  
> PCC to send LSP status reports to the PCE?
> 
> Jon> ACK.  I think that the statement in the draft is bogus and I
> propose to delete this sentence from it.
> 
> =
[JM] I do not think that the text is bogus:
- case 1: no advertised capability on update but advertised on report (i.e. 
passive stateful) => no error message;
- case 2: no advertised capability on update nor report (i.e. stateless) => 
error.

> =
> 
> [LM] Would it be useful to discover (using another TLV) whether the 
> PCE is an active/passive stateful PCE, as in IGP-based capabilities 
> discovery mechanism?
> 
> Jon> This can be inferred immediately from the U flag in the
> STATEFUL-PCE-CAPABILITY TLV.  Passive mode is synonymous with not 
> sending / handling PCUpd messages.
> 
> =
[JM] The mechanism is there, but section 7.1.1 may deserve an explicit use of 
the "passive/active" terms, to make sure the capability terminology is aligned 
with the vocabulary in the IGP section.

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Review of draft-ietf-pce-stateful-pce-18

[Julien Meuric]

Jon, Lionel,

I believe Lionel got confused by the wording introduced in RFC 8051:
- no report, no update means stateless PCE;
- report, no update means passive stateful PCE;
- report and update means active (stateful) PCE.

More details below, [JM].

Thanks for the work,

Julien


Apr. 11, 2017 - jonathan.hardw...@metaswitch.com:
> =
> 
> [LM] active/passive mode are not  advertized in PCEP. s/if active 
> stateful PCE capability was not advertised/if stateful PCE
> capability was not advertised
> 
> Jon> ACK
> 
> =
[JM] NACK! ;-)
Actually, the passive mode is advertised using the
Stateful-capability-object TLV with the U bit unset, the active mode by
setting the U bit.

> =
> 
> Note that even if the update capability has not been advertised, a 
> PCE can still accept LSP Status Reports from a PCC and build and 
> maintain an up to date view of the state of the PCC's LSPs.
> 
> [LM] I don't undersand. Is it not in contradiction with
> 
> "If the PCEP Speaker on the PCE supports the extensions of this
> draft but did not advertise this capability, then upon receipt of a
> PCRpt message from the PCC, it MUST generate a PCErr with error- type
> 19 (Invalid Operation), error-value 5 (Attempted LSP State Report if
>  active stateful PCE capability was not advertised) (see Section
> 8.5) and it SHOULD terminate the PCEP session."
> 
> Or does it mean that there is another way than PCRpt message for the
>  PCC to send LSP status reports to the PCE?
> 
> Jon> ACK.  I think that the statement in the draft is bogus and I 
> propose to delete this sentence from it.
> 
> =
[JM] I do not think that the text is bogus:
- case 1: no advertised capability on update but advertised on report
(i.e. passive stateful) => no error message;
- case 2: no advertised capability on update nor report (i.e. stateless)
=> error.

> =
> 
> [LM] Would it be useful to discover (using another TLV) whether the 
> PCE is an active/passive stateful PCE, as in IGP-based capabilities 
> discovery mechanism?
> 
> Jon> This can be inferred immediately from the U flag in the 
> STATEFUL-PCE-CAPABILITY TLV.  Passive mode is synonymous with not 
> sending / handling PCUpd messages.
> 
> =
[JM] The mechanism is there, but section 7.1.1 may deserve an explicit
use of the "passive/active" terms, to make sure the capability
terminology is aligned with the vocabulary in the IGP section.

___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Review of draft-ietf-pce-stateful-pce-18

[Jonathan Hardwick]

Hi Lionel

Many thanks for a very thorough review.  I'm picking up this thread and 
replying as PCE working group chair, as the authors are unavailable.  I 
apologise for the delay.

Please see my proposed resolutions inline below, marked with "Jon>"

Best regards
Jon


-Original Message-
From: Lionel Morand [mailto:lionel.mor...@orange.com]
Sent: 16 March 2017 09:46
To: ops-...@ietf.org
Cc: draft-ietf-pce-stateful-pce@ietf.org; pce@ietf.org; i...@ietf.org
Subject: Review of draft-ietf-pce-stateful-pce-18

Reviewer: Lionel Morand
Review result: Has Issues

I have reviewed this document as part of the Operational directorate's ongoing 
effort to review all IETF documents being processed by the IESG.  These 
comments were written with the intent of improving the operational aspects of 
the IETF drafts. Comments that are not addressed in last call may be included 
in AD reviews during the IESG review.  Document editors and WG chairs should 
treat these comments just like any other last call comments.

I've pointed out some "issues" that might not be real issues for people 
involved in PCE but that could be at least clarified for readers of this 
document. Detailed comments are provided below.

Regards,

Lionel


2.  Terminology

   This document uses the following terms defined in [RFC5440]: PCC,
   PCE, PCEP Peer, PCEP Speaker.

   This document uses the following terms defined in [RFC4655]: TED.

   This document uses the following terms defined in [RFC3031]: LSP.

   This document uses the following terms defined in
   [I-D.ietf-pce-stateful-pce-app]: Stateful PCE, Passive Stateful PCE,
   Active Stateful PCE, Delegation, LSP State Database.

[LM] I didn't find a clear definition of the LSP state, except through the 
definition of the LSP State database in ietf-pce-stateful-pce-app, i.e.

   The second is the LSP
   State Database (LSP-DB), in which a PCE stores attributes of all
   active LSPs in the network, such as their paths through the network,
   bandwidth/resource usage, switching types and LSP constraints.

As this document heavily relies on this LSP state concept, it could be useful 
to (re-)define it in this document or to find a correct reference for it.

Jon> The definition of LSP State Database given by draft-ietf-pce-stateful-app 
(now RFC 8051) does contain a pretty good description of the LSP State ("paths 
through the network, bandwidth/resource usage, switching types and LSP 
constraints ").  I know it's written informally ("such as...") but I think it's 
good enough.

=

3.2.  Objectives

   The objectives for the protocol extensions to support stateful PCE
   described in this document are as follows:

[...]

   o  Allow a PCC to delegate control of its LSPs to an active
stateful
  PCE such that a given LSP is under the control of a single PCE
at
  any given time.  A PCC may revoke this delegation at any time
  during the lifetime of the LSP.  If LSP delegation is revoked
  while the PCEP session is up, the PCC MUST notify the PCE about
  the revocation.  A PCE may return an LSP delegation at any
point
  during the lifetime of the PCEP session.

[LM] I'm assuming that the PCE returning the delegation has also to
notify the PCC. If so, maybe:

 "the If LSP delegation is returned by the PCE while the PCEP
  session is up, the PCE MUST notify the PCE about the
revocation."

[LM] the bullet point could be then splitted into two bullets, one for
PCC, one for PCE.

Jon> ACK.  This would probably be best as two sub-bullets.



5.4.  Capability Advertisement

   During PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
   advertise their support of stateful PCEP extensions.  A PCEP
Speaker
   includes the "Stateful PCE Capability" TLV, described in
   Section 7.1.1, in the OPEN Object to advertise its support for
PCEP
   stateful extensions.  The Stateful Capability TLV includes the
'LSP
   Update' Flag that indicates whether the PCEP Speaker supports LSP
   parameter updates.

   The presence of the Stateful PCE Capability TLV in PCC's OPEN
Object
   indicates that the PCC is willing to send LSP State Reports
whenever
   LSP parameters or operational status changes.

   The presence of the Stateful PCE Capability TLV in PCE's OPEN
message
   indicates that the PCE is interested in receiving LSP State
Reports
   whenever LSP parameters or operational status changes.

[LM] is it "willing/interested for" or just a capability indication?
It is not the same thing from a procedure point of view.

Jon> It is "willing / interested for" as written - it's not just a capability.  
If the TLV is included in each OPEN message then the LSP state is synchronized 
automatically.  If a device has the capability but does not want to do it for 
some reason then it omits the TLV.

=

   The PCEP extensions for stateful PCEs MUST N

Re: [Pce] Review of draft-ietf-pce-stateful-pce-18

[Jonathan Hardwick]

Hi Joel

Many thanks for these comments.  I'm picking up this thread and replying as PCE 
working group chair, as the authors are unavailable.  I apologise for the delay.

Please see my proposed resolutions inline below, marked with "Jon>"

Best regards
Jon


-Original Message-
From: Joel Halpern [mailto:j...@joelhalpern.com] 
Sent: 17 February 2017 03:38
To: gen-...@ietf.org
Cc: draft-ietf-pce-stateful-pce@ietf.org; pce@ietf.org; i...@ietf.org
Subject: Review of draft-ietf-pce-stateful-pce-18

Reviewer: Joel Halpern
Review result: Ready with Issues





Minor issues:
   At the end of section 5.4, the text talks about a PCE accepting status 
updates even if the  stateful capability has not been negotiated.  Which is 
fine.  But as written, the text seems to say that doing so means that the PCE 
will be able to "build and maintain an up to date view of the state of the 
PCC's LSPs".  However, if the capability has not been negotiated, I do not see 
how the PCE can count on getting full and timely state reports.  Trying to 
infer why a PCC is sending such a report in the absence of the agreement seems 
problematic.

Jon> I agree.  I propose that we delete this sentence:
" Note that even if the update
   capability has not been advertised, a PCE can still accept LSP Status
   Reports from a PCC and build and maintain an up to date view of the
   state of the PCC's LSPs. "



This comment may be a misunderstanding or mis-expectation on my part.  I 
would have expected one of the ways o using an active PCE is to have the PCE 
decide (under suitable circumstances) that an LSP is needed between two PCCs.  
As far as I can tell, the text in section
5.8.2 and 5.8.3 prohibits that.  A PCE is only allowed to send an LSP Update 
Request (in a PCUpd message) for an LSP that has been delegated to it.  At that 
point I thought that a PCC could delegate a block of unsetup LSPs to the PCE.  
But then looking at 5.8.2, the text states that for each delegation, the PCC 
must request an initial path.  That seems to prohibit delegating a block of 
LSPs for future updates.  Is the intention to prohibit the driving of LSP 
creation from the PCE?

Jon> Yes, the intention is that the PCE does not drive creation of the LSPs.  
That behaviour is allowed but is described by a separate draft 
(draft-ietf-pce-pce-initiated-lsp).  I propose to clarify this in the 
introduction to the draft, so that future readers don't get caught by the same 
mis-expectation.  We'll add the following text to section 1, and add an 
informative reference to draft-ietf-pce-pce-initiated-lsp.  OK?

NEW
   The extensions that this document describes do not permit the
   PCE to drive creation of an LSP.  The companion document
   [I-D. ietf-pce-pce-initiated-lsp] specifies PCE-initiated LSP creation.



I have looked but I can not find the text explaining the significance and 
use of the Symbolic path name.  It is mandated by the draft.  There seems to be 
an implicit assumption taht it is needed by the PCE.  If the explanation of how 
or why it is needed is not present, it should be.

Jon> Agreed.  Several of our reviewers have picked up on this.  I think we 
should clarify this in section 7.3.2 "Symbolic Path Name TLV".

OLD
   Each LSP (path) MUST have a symbolic name that is unique in the PCC.
   This symbolic path name MUST remain constant throughout an LSP's
   lifetime, which may span across multiple consecutive PCEP sessions
   and/or PCC restarts.  The symbolic path name MAY be specified by an
   operator in a PCC's configuration.  If the operator does not specify
   a unique symbolic name for a path, the PCC MUST auto-generate one.

   The SYMBOLIC-PATH-NAME TLV MUST be included in the LSP object in the
   LSP State Report (PCRpt) message when during a given PCEP session an
   LSP is first reported to a PCE.  A PCC sends to a PCE the first LSP
   State Report either during State Synchronization, or when a new LSP
   is configured at the PCC.  The symbolic path name MAY be included in
   the LSP object in subsequent LSP State Reports for the LSP.

   

   Symbolic Path Name (variable): symbolic name for the LSP, unique in
   the PCC.

NEW
   Each LSP MUST have a symbolic path name that is unique in the PCC.
   The symbolic path name is a human-readable string that identifies an
   LSP in the network.  The symbolic path name MUST remain constant
   throughout an LSP's lifetime, which may span across multiple
   consecutive PCEP sessions and/or PCC restarts.  The symbolic path
   name MAY be specified by an operator in a PCC's configuration.  If the
   operator does not specify a unique symbolic name for an LSP, then the
   PCC MUST auto-generate one.   

   The PCE uses the symbolic path name as a stable identifier for the LSP.
   If the PCEP session restarts, or the PCC restarts, or the PCC re-delegates
   the LSP to a different PCE, the symbolic path name for the 

[Pce] Review of draft-ietf-pce-stateful-pce-18

[Lionel Morand]

Reviewer: Lionel Morand
Review result: Has Issues

I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written with the intent of improving the
operational aspects of the IETF drafts. Comments that are not
addressed in last call may be included in AD reviews during the IESG
review.  Document editors and WG chairs should treat these comments
just like any other last call comments. 

I've pointed out some "issues" that might not be real issues for
people involved in PCE but that could be at least clarified for
readers of this document. Detailed comments are provided below.

Regards,

Lionel


2.  Terminology

   This document uses the following terms defined in [RFC5440]: PCC,
   PCE, PCEP Peer, PCEP Speaker.

   This document uses the following terms defined in [RFC4655]: TED.

   This document uses the following terms defined in [RFC3031]: LSP.

   This document uses the following terms defined in
   [I-D.ietf-pce-stateful-pce-app]: Stateful PCE, Passive Stateful
PCE,
   Active Stateful PCE, Delegation, LSP State Database.

[LM] I didn't find a clear definition of the LSP state, except through
the definition of the LSP State database in ietf-pce-stateful-pce-app,
i.e.

   The second is the LSP
   State Database (LSP-DB), in which a PCE stores attributes of all
   active LSPs in the network, such as their paths through the
network,
   bandwidth/resource usage, switching types and LSP constraints.

As this document heavily relies on this LSP state concept, it could be
useful to (re-)define it in this document or to find a 
correct reference for it.


3.2.  Objectives

   The objectives for the protocol extensions to support stateful PCE
   described in this document are as follows:

[...]

   o  Allow a PCC to delegate control of its LSPs to an active
stateful
  PCE such that a given LSP is under the control of a single PCE
at
  any given time.  A PCC may revoke this delegation at any time
  during the lifetime of the LSP.  If LSP delegation is revoked
  while the PCEP session is up, the PCC MUST notify the PCE about
  the revocation.  A PCE may return an LSP delegation at any
point
  during the lifetime of the PCEP session.

[LM] I'm assuming that the PCE returning the delegation has also to
notify the PCC. If so, maybe:
 
 "the If LSP delegation is returned by the PCE while the PCEP 
  session is up, the PCE MUST notify the PCE about the
revocation."

[LM] the bullet point could be then splitted into two bullets, one for
PCC, one for PCE.

5.4.  Capability Advertisement

   During PCEP Initialization Phase, PCEP Speakers (PCE or PCC)
   advertise their support of stateful PCEP extensions.  A PCEP
Speaker
   includes the "Stateful PCE Capability" TLV, described in
   Section 7.1.1, in the OPEN Object to advertise its support for
PCEP
   stateful extensions.  The Stateful Capability TLV includes the
'LSP
   Update' Flag that indicates whether the PCEP Speaker supports LSP
   parameter updates.

   The presence of the Stateful PCE Capability TLV in PCC's OPEN
Object
   indicates that the PCC is willing to send LSP State Reports
whenever
   LSP parameters or operational status changes.

   The presence of the Stateful PCE Capability TLV in PCE's OPEN
message
   indicates that the PCE is interested in receiving LSP State
Reports
   whenever LSP parameters or operational status changes.

[LM] is it "willing/interested for" or just a capability indication?
It is not the same thing from a procedure point of view.

   The PCEP extensions for stateful PCEs MUST NOT be used if one or
both
   PCEP Speakers have not included the Stateful PCE Capability TLV in
   their respective OPEN message.  If the PCEP Speaker on the PCC
   supports the extensions of this draft but did not advertise this
   capability, then upon receipt of PCUpd message from the PCE, it
MUST
   generate a PCErr with error-type 19 (Invalid Operation),
error-value
   2 (Attempted LSP Update Request if the stateful PCE capability was
   not advertised)(see Section 8.5) and it SHOULD terminate the PCEP
   session.  If the PCEP Speaker on the PCE supports the extensions
of
   this draft but did not advertise this capability, then upon
receipt
   of a PCRpt message from the PCC, it MUST generate a PCErr with
error-
   type 19 (Invalid Operation), error-value 5 (Attempted LSP State
   Report if active stateful PCE capability was not advertised) (see
   Section 8.5) and it SHOULD terminate the PCEP session. 

[LM] why the recommendation for closing the session if an explicit
error is sent back? The session could remain open i.e. except stateful
PCEP extensions,everything else would be fine. If the session
termination is the right thing to do, as we are in a clear error case
(as the PCEP speaker should not send the report or the update), the
SHOULD should probably be a MUST hee. 

[LM] Is 

Re: [Pce] Review of draft-ietf-pce-stateful-pce-18

[Robert Varga]

On 02/17/2017 04:37 AM, Joel Halpern wrote:
> 
> This comment may be a misunderstanding or mis-expectation on my
> part.  I would have expected one of the ways o using an active PCE is
> to have the PCE decide (under suitable circumstances) that an LSP is
> needed between two PCCs.  As far as I can tell, the text in section
> 5.8.2 and 5.8.3 prohibits that.  A PCE is only allowed to send an LSP
> Update Request (in a PCUpd message) for an LSP that has been delegated
> to it.  At that point I thought that a PCC could delegate a block of
> unsetup LSPs to the PCE.  But then looking at 5.8.2, the text states
> that for each delegation, the PCC must request an initial path.  That
> seems to prohibit delegating a block of LSPs for future updates.  Is
> the intention to prohibit the driving of LSP creation from the PCE?

I think this may be a case consistency rotting over the years this draft
has been out there, which also affects my recollection of reasoning
behind the text.

Sections 5.8.1 and 5.8.2 govern how to transition from 'passive
stateful' mode of operation, where the PCC uses PCRpt to communicate
state and PCReq to solicit updates. They are not meant (or at least not
when they were originally written) to restrict the delegation procedure.

The wording of 5.8.2's first paragraph has an implicit unstated goal of
ensuring that the LSP will be set up, i.e. the PCC first makes an
explicit request to acquire the parameters needed to signal the LSP and
then delegates the LSP, thus ensuring a computation is made.

I think it is still valid for PCC to delegate an LSP without performing
5.8.1, in which case the PCE decides when (and if) to push the
parameters required to make the LSP operational.

I do see this as a problem, as the PCC is free to revoke the delegation,
based solely on its local policy, if the PCE fails to fill in the LSP
parameters in a reasonable time frame -- reverting to either local
control or to 5.8.1 mechanics.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Review of draft-ietf-pce-stateful-pce-18

[Robert Varga]

On 02/17/2017 05:42 AM, Joel M. Halpern wrote:
> So it is intentional that this draft prohibits that behavior (PCE driven
> establishment)?

Yes, it is intentional. pce-stateful-pce is designed so that the PCC
remains the ultimate master of state, in line with RFC5440.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Review of draft-ietf-pce-stateful-pce-18

[Robert Varga]

On 02/17/2017 01:10 PM, Dhruv Dhody wrote:
> Hi Joel, 
> 
> In my opinion the motivation behind section 5.8.2 is to make sure that, if a 
> PCC needs to request a path to be computed by PCE immediately, PCC should use 
> the existing PCReq message to achieve that. 
>  
> Can the PCC delegate an unsignalled LSP to PCE via PCRpt message? In my 
> interpretation it can, in some cases[1]. I would let the authors confirm on 
> this. 

Yes, it can.

The second paragraph on 5.8.2 is not intended to restrict usage of
delegation, but rather highlight the scenario where the LSP is
established without PCE's help.

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Review of draft-ietf-pce-stateful-pce-18

[Dhruv Dhody]

Hi Joel, 

In my opinion the motivation behind section 5.8.2 is to make sure that, if a 
PCC needs to request a path to be computed by PCE immediately, PCC should use 
the existing PCReq message to achieve that. 
 
Can the PCC delegate an unsignalled LSP to PCE via PCRpt message? In my 
interpretation it can, in some cases[1]. I would let the authors confirm on 
this. 

Thanks,
Dhruv

[1] https://mailarchive.ietf.org/arch/msg/pce/bexK_Nc2wHgQzV-XUC8lqMec8zY

> -Original Message-
> From: Joel M. Halpern [mailto:j...@joelhalpern.com]
> Sent: 17 February 2017 10:13
> To: Dhruv Dhody <dhruv.dh...@huawei.com>; gen-...@ietf.org
> Cc: draft-ietf-pce-stateful-pce@ietf.org; pce@ietf.org; i...@ietf.org
> Subject: Re: [Pce] Review of draft-ietf-pce-stateful-pce-18
> 
> So it is intentional that this draft prohibits that behavior (PCE driven
> establishment)?
> 
> Yours,
> Joel
> 
> On 2/16/17 11:35 PM, Dhruv Dhody wrote:
> > Hi Joel,
> >
> > Regarding your comment -
> >
> >> Is the intention to prohibit the driving of LSP creation from the
> >> PCE?
> >
> > This capability is described in -
> > https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07
> > (document expired recently, authors should refresh it)
> >
> > Thanks,
> > Dhruv
> >
> >> -Original Message-
> >> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Joel Halpern
> >> Sent: 17 February 2017 09:08
> >> To: gen-...@ietf.org
> >> Cc: draft-ietf-pce-stateful-pce@ietf.org; pce@ietf.org;
> >> i...@ietf.org
> >> Subject: [Pce] Review of draft-ietf-pce-stateful-pce-18
> >>
> >> Reviewer: Joel Halpern
> >> Review result: Ready with Issues
> >>
> >> I am the assigned Gen-ART reviewer for this draft. The General Area
> >> Review Team (Gen-ART) reviews all IETF documents being processed by
> >> the IESG for the IETF Chair.  Please treat these comments just like
> >> any other last call comments.
> >>
> >> For more information, please see the FAQ at
> >>
> >> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> >>
> >> Document: draft-ietf-pce-stateful-pce-??
> >> Reviewer: Joel Halpern
> >> Review Date: 2017-02-16
> >> IETF LC End Date: 2017-02-28
> >> IESG Telechat date: 2017-03-16
> >>
> >> Summary:
> >>
> >> Major issues:
> >>
> >> Minor issues:
> >>At the end of section 5.4, the text talks about a PCE accepting
> >> status updates even if the  stateful capability has not been
> >> negotiated.  Which is fine.  But as written, the text seems to say
> >> that doing so means that the PCE will be able to "build and maintain
> >> an up to date view of the state of the PCC's LSPs".  However, if the
> >> capability has not been negotiated, I do not see how the PCE can
> >> count on getting full and timely state reports.  Trying to infer why
> >> a PCC is sending such a report in the absence of the agreement seems
> problematic.
> >>
> >> This comment may be a misunderstanding or mis-expectation on my part.
> >> I would have expected one of the ways o using an active PCE is to
> >> have the PCE decide (under suitable circumstances) that an LSP is
> >> needed between two PCCs.  As far as I can tell, the text in section
> >> 5.8.2 and 5.8.3 prohibits that.  A PCE is only allowed to send an LSP
> >> Update Request (in a PCUpd message) for an LSP that has been
> >> delegated to it.  At that point I thought that a PCC could delegate a
> >> block of unsetup LSPs to the PCE.  But then looking at 5.8.2, the
> >> text states that for each delegation, the PCC must request an initial
> >> path.  That seems to prohibit delegating a block of LSPs for future
> >> updates.  Is the intention to prohibit the driving of LSP creation from
> the PCE?
> >>
> >> I have looked but I can not find the text explaining the
> >> significance and use of the Symbolic path name.  It is mandated by
> >> the draft.  There seems to be an implicit assumption taht it is
> >> needed by the PCE.  If the explanation of how or why it is needed is not
> present, it should be.
> >>
> >> Nits/editorial comments:
> >> Should the text on the S bit in section 7.3 (the LSP Object
> >> definition) note that it should be set to 0 on all messages sent by the
> PCE?
> >> Should that also be stated for the R bit?  And the O bits?
> >>
> >>   Section 9.2 seems very odd.  It states that the IETF "SHOULD" do
> >> some additional work.  I understand why teh work is needed.  But this
> >> does not seem to match the RFC 2119 meaning of SHOULD as it does not
> >> apply to eitehr the implementor or the implementation.
> >>
> >>
> >> ___
> >> 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

Re: [Pce] Review of draft-ietf-pce-stateful-pce-18

[Dhruv Dhody]

Hi Joel, 

Regarding your comment - 

> Is the intention to prohibit the driving
> of LSP creation from the PCE?

This capability is described in - 
https://tools.ietf.org/html/draft-ietf-pce-pce-initiated-lsp-07 (document 
expired recently, authors should refresh it)

Thanks,
Dhruv 

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Joel Halpern
> Sent: 17 February 2017 09:08
> To: gen-...@ietf.org
> Cc: draft-ietf-pce-stateful-pce@ietf.org; pce@ietf.org; i...@ietf.org
> Subject: [Pce] Review of draft-ietf-pce-stateful-pce-18
> 
> Reviewer: Joel Halpern
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-pce-stateful-pce-??
> Reviewer: Joel Halpern
> Review Date: 2017-02-16
> IETF LC End Date: 2017-02-28
> IESG Telechat date: 2017-03-16
> 
> Summary:
> 
> Major issues:
> 
> Minor issues:
>At the end of section 5.4, the text talks about a PCE accepting status
> updates even if the  stateful capability has not been negotiated.  Which is
> fine.  But as written, the text seems to say that doing so means that the
> PCE will be able to "build and maintain an up to date view of the state of
> the PCC's LSPs".  However, if the capability has not been negotiated, I do
> not see how the PCE can count on getting full and timely state reports.  
> Trying
> to infer why a PCC is sending such a report in the absence of the agreement
> seems problematic.
> 
> This comment may be a misunderstanding or mis-expectation on my part.
> I would have expected one of the ways o using an active PCE is to have the
> PCE decide (under suitable circumstances) that an LSP is needed between two
> PCCs.  As far as I can tell, the text in section
> 5.8.2 and 5.8.3 prohibits that.  A PCE is only allowed to send an LSP Update
> Request (in a PCUpd message) for an LSP that has been delegated to it.  At
> that point I thought that a PCC could delegate a block of unsetup LSPs to
> the PCE.  But then looking at 5.8.2, the text states that for each delegation,
> the PCC must request an initial path.  That seems to prohibit delegating a
> block of LSPs for future updates.  Is the intention to prohibit the driving
> of LSP creation from the PCE?
> 
> I have looked but I can not find the text explaining the significance
> and use of the Symbolic path name.  It is mandated by the draft.  There seems
> to be an implicit assumption taht it is needed by the PCE.  If the explanation
> of how or why it is needed is not present, it should be.
> 
> Nits/editorial comments:
> Should the text on the S bit in section 7.3 (the LSP Object
> definition) note that it should be set to 0 on all messages sent by the PCE?
> Should that also be stated for the R bit?  And the O bits?
> 
>   Section 9.2 seems very odd.  It states that the IETF "SHOULD" do some
> additional work.  I understand why teh work is needed.  But this does not
> seem to match the RFC 2119 meaning of SHOULD as it does not apply to eitehr
> the implementor or the implementation.
> 
> 
> ___
> 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] Review of draft-ietf-pce-stateful-pce-18

[Joel Halpern]

Reviewer: Joel Halpern
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-pce-stateful-pce-??
Reviewer: Joel Halpern
Review Date: 2017-02-16
IETF LC End Date: 2017-02-28
IESG Telechat date: 2017-03-16

Summary:

Major issues:

Minor issues:
   At the end of section 5.4, the text talks about a PCE accepting
status updates even if the  stateful capability has not been
negotiated.  Which is fine.  But as written, the text seems to say
that doing so means that the PCE will be able to "build and maintain
an up to date view of the state of the PCC's LSPs".  However, if the
capability has not been negotiated, I do not see how the PCE can count
on getting full and timely state reports.  Trying to infer why a PCC
is sending such a report in the absence of the agreement seems
problematic.

This comment may be a misunderstanding or mis-expectation on my
part.  I would have expected one of the ways o using an active PCE is
to have the PCE decide (under suitable circumstances) that an LSP is
needed between two PCCs.  As far as I can tell, the text in section
5.8.2 and 5.8.3 prohibits that.  A PCE is only allowed to send an LSP
Update Request (in a PCUpd message) for an LSP that has been delegated
to it.  At that point I thought that a PCC could delegate a block of
unsetup LSPs to the PCE.  But then looking at 5.8.2, the text states
that for each delegation, the PCC must request an initial path.  That
seems to prohibit delegating a block of LSPs for future updates.  Is
the intention to prohibit the driving of LSP creation from the PCE?

I have looked but I can not find the text explaining the
significance and use of the Symbolic path name.  It is mandated by the
draft.  There seems to be an implicit assumption taht it is needed by
the PCE.  If the explanation of how or why it is needed is not
present, it should be.

Nits/editorial comments: 
Should the text on the S bit in section 7.3 (the LSP Object
definition) note that it should be set to 0 on all messages sent by
the PCE?  Should that also be stated for the R bit?  And the O bits?

  Section 9.2 seems very odd.  It states that the IETF "SHOULD" do
some additional work.  I understand why teh work is needed.  But this
does not seem to match the RFC 2119 meaning of SHOULD as it does not
apply to eitehr the implementor or the implementation.


___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce