Re: [Pce] Final IPR check for draft-ietf-pce-pceps

[Diego R. Lopez]

I am not aware of any IPR that applies to this draft

On 11 Apr 2017, at 06:50 , Jonathan Hardwick 
mailto:jonathan.hardw...@metaswitch.com>> 
wrote:

Dear authors

Could you please send an email to the PCE mailing list saying whether you are 
aware of any IPR that applies to draft-ietf-pce-pceps and, if so, if it has 
been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669 
and 5378 for more details.)  If you are not aware of any IPR that applies, 
please reply saying “I am not aware of any IPR that applies to this draft”.

A reply is required from each of you before we can proceed.

Many thanks
Jon

--
"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/

e-mail: diego.r.lo...@telefonica.com
Tel:+34 913 129 041
Mobile: +34 682 051 091
--

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

Re: [Pce] Final IPR check for draft-ietf-pce-pceps

[Qin Wu]

I am not aware of any IPR that is applicable to this draft .

-Qin
发件人: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
发送时间: 2017年4月11日 12:51
收件人: draft-ietf-pce-pc...@ietf.org
抄送: Cyril Margaria; pce@ietf.org
主题: Final IPR check for draft-ietf-pce-pceps

Dear authors


Could you please send an email to the PCE mailing list saying whether you are 
aware of any IPR that applies to draft-ietf-pce-pceps and, if so, if it has 
been disclosed in compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669 
and 5378 for more details.)  If you are not aware of any IPR that applies, 
please reply saying “I am not aware of any IPR that applies to this draft”.

A reply is required from each of you before we can proceed.

Many thanks
Jon

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

[Pce] 答复: Poll for adoption: draft-dhody-pce-pcep-exp-codepoints-03

[Lizhenbin]

Yes/support.

Best Regards,
Zhenbin(Robin)



发件人: Pce [mailto:pce-boun...@ietf.org] 代表 Jonathan Hardwick
发送时间: 2017年4月10日 18:39
收件人: pce@ietf.org
抄送: pce-cha...@ietf.org; 
draft-dhody-pce-pcep-exp-codepoi...@ietf.org
主题: [Pce] Poll for adoption: draft-dhody-pce-pcep-exp-codepoints-03

All,

This is the start of a two week poll on making 
draft-dhody-pce-pcep-exp-codepoints-03 a PCE working group document.
https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-exp-codepoints/


Please review the draft and send an email to the list indicating “yes/support” 
or “no/do not support”.  If indicating no, please state your reasons.  If yes, 
please also feel free to provide comments you'd like to see addressed once the 
document is a WG document.



The poll ends on Monday, April 24.



Many thanks,
Jon

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

[Pce] I-D Action: draft-ietf-pce-pceps-12.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Path Computation Element of the IETF.

Title   : Secure Transport for PCEP
Authors : Diego R. Lopez
  Oscar Gonzalez de Dios
  Qin Wu
  Dhruv Dhody
Filename: draft-ietf-pce-pceps-12.txt
Pages   : 19
Date: 2017-04-11

Abstract:
   The Path Computation Element Communication Protocol (PCEP) defines
   the mechanisms for the communication between a Path Computation
   Client (PCC) and a Path Computation Element (PCE), or among PCEs.
   This document describe the usage of Transport Layer Security (TLS) to
   enhance PCEP security, hence the PCEPS acronym proposed for it.  The
   additional security mechanisms are provided by the transport protocol
   supporting PCEP, and therefore they do not affect the flexibility and
   extensibility of PCEP.

   This document updates RFC 5440 regarding the PCEP initialization
   phase specification.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-pce-pceps/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-pceps-12
https://datatracker.ietf.org/doc/html/draft-ietf-pce-pceps-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pceps-12


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [Pce] Poll for adoption: draft-dhody-pce-pcep-exp-codepoints-03

[Olivier Dugeon]

Yes / Support

Olivier


Le 10/04/2017 à 12:38, Jonathan Hardwick a écrit :
>
> All,
>
>  
>
> This is the start of a two week poll on making 
> draft-dhody-pce-pcep-exp-codepoints-03 a PCE working group document.
>
> https://datatracker.ietf.org/doc/draft-dhody-pce-pcep-exp-codepoints/
>
>  
>
> Please review the draft and send an email to the list indicating 
> “yes/support” or “no/do not support”.  If indicating no, please state your 
> reasons.  If yes, please also feel free to provide comments you'd like to see 
> addressed once the document is a WG document.
>
>  
>
> The poll ends on Monday, April 24.
>
>  
>
> Many thanks,
>
> Jon
>
>  
>
>
>
> ___
> 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

[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 LSP remains
   constant and can be used to correlate ac

Re: [Pce] Last Call: (PCEP Extensions for Stateful PCE) to Proposed Standard

[Jonathan Hardwick]

Hi Adrian

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: Adrian Farrel [mailto:adr...@olddog.co.uk] 
Sent: 16 February 2017 22:10
To: i...@ietf.org
Cc: draft-ietf-pce-stateful-...@ietf.org; pce@ietf.org; pce-cha...@ietf.org
Subject: RE: [Pce] Last Call:  (PCEP 
Extensions for Stateful PCE) to Proposed Standard

IETF last call

I have read and commented on this document during its production by the PCE 
working group. It constitutes a missing piece of the puzzle that we started 
with RFC 4655.

The publication of this work as an RFC is long overdue to the point that 
implementers have become confused over the last couple of years about whether 
it would ever be published.

However, on re-reading this final version, I notice a few points.
Nothing major.

Thanks for the work,
Adrian

---
  
The reference to [I-D.ietf-pce-stateful-pce-app] is for some terms that are 
fundamental to understanding this document.  It needs to be a normative 
reference.

Jon> ACK. Should be RFC 8051.

---

3.1.3 has...
   Note that existing configuration tools and protocols can be used to
   set LSP state.
...which is true, but is lacking references for the inquisitive mind.

Just need some form of "(such as, )"

Jon> "... , such as a Command Line Interface (CLI) tool."

---

In the RBNF in section 6 there is some mismatch between hyphen and underscore. 
Not only is there a mixture of uses, but sometime the same construct is named 
in different ways (e.g., in 6.1 you have  and 
)

Jon> ACK, will tidy this up.

---

In 6.2, would it help show consistency with 6.1 and remove potential confusion 
if

  ::= 

read

  ::= 

Jon> ACK

---

The use of TBD in the document to flag where IANA allocations need to be 
updated in the document is going to cause the RFC editor additional work and is 
error prone. What you should probably do is use TBD1, TBD2, etc. in the text 
and then include those flags in the IANA considerations sections.

However (!) I note that early allocation has been done for most of the code 
points. So...
- The IANA section should refer to this and ask IANA to confirm those
  allocations and update the registry to point to this document when it
  is an RFC
- The actual numbers can be filled in in place of all the TBDs
- It would help the reader/coder if you pointed forward to the new
  registries (for example, from 7.3.3 to 8.9)

Jon> ACK although having me do it is equally error prone ;-)

---

7.3.2 Symbolic Path Name

You need to give some clues!
Is this supposed to be printable?
Is this in a particular character set?
Is it supposed to be null terminated (which would mean that if it was a 
multiple of 4 octets you'd need another four octets of pad)

Jon> This was also raised by others - here is my proposed resolution.

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 LSP remains
   constant and can be used to correlate across the PCEP session instances.

   The other protocol identifiers for the LSP cannot reliably be used to
   identify the LSP across multiple PCEP sessions, for the following reasons.
   -  The PLSP-ID is unique only within the scope of a 

Re: [Pce] Mirja Kühlewind's No Objection on draft-ietf-pce-stateful-pce-18: (with COMMENT)

[Jonathan Hardwick]

Hi Mirja

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

It is possible for a PCC or a stateful PCE not to support updates and still to 
advertise the STATEFUL-PCE-CAPABILITY TLV.  This scenario is called a "passive 
stateful PCE".  A passive stateful PCE does not update LSP state, but it does 
still synchronize LSP state with its PCCs, which allows it to take account of 
dependencies with existing LSPs when calculating paths for new LSPs (for 
example, to avoid two LSPs traversing the same link).  It is discussed in 
section 5.8.1.

Best regards
Jon


-Original Message-
From: Mirja Kühlewind [mailto:i...@kuehlewind.net] 
Sent: 14 March 2017 12:22
To: The IESG 
Cc: draft-ietf-pce-stateful-...@ietf.org; Julien Meuric 
; pce-cha...@ietf.org; julien.meu...@orange.com; 
pce@ietf.org
Subject: Mirja Kühlewind's No Objection on draft-ietf-pce-stateful-pce-18: 
(with COMMENT)

Mirja Kühlewind has entered the following ballot position for
draft-ietf-pce-stateful-pce-18: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce/



--
COMMENT:
--

Minor comment:
The U flag in the STATEFUL-PCE-CAPABILITY TLV is probably not necessary as the 
presents of this TVL already indicates that updates are supported; however not 
an issue.


___
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 NOT be used if one or
both
   PCEP Speakers have not included the Stateful PCE Capability TLV in
   their r

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 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 ; Lionel Morand 
; 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] Stephen Farrell's No Objection on draft-ietf-pce-stateful-pce-18: (with COMMENT)

[Stephen Farrell]

Hi Jon,

That looks fine to me. (Note though that now that I've escaped
from the IESG, what I think no longer matters:-)

Cheers,
S.

On 11/04/17 15:35, Jonathan Hardwick wrote:
> Hi Stephen
> 
> Many thanks for this comment.  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: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] 
> Sent: 16 March 2017 12:48
> To: The IESG 
> Cc: draft-ietf-pce-stateful-...@ietf.org; Julien Meuric 
> ; pce-cha...@ietf.org; julien.meu...@orange.com; 
> pce@ietf.org
> Subject: Stephen Farrell's No Objection on draft-ietf-pce-stateful-pce-18: 
> (with COMMENT)
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-pce-stateful-pce-18: No Objection
> 
> When responding, please keep the subject line intact and reply to all email 
> addresses included in the To and CC lines. (Feel free to cut this 
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce/
> 
> 
> 
> --
> COMMENT:
> --
> 
> In 10.1, some references seem to be needed to say how to do that 
> authentication and encryption. IIUC, that's a work in progress, or is that 
> right? If so, when's it likely to be done and usable?
> 
> Jon> You are correct - this is being specified in draft-ietf-pce-pceps.  That 
> document is ready to be submitted to the IESG (we are only waiting for the 
> IPR poll to conclude) but draft-ietf-pce-stateful-pce is likely to be 
> published first.
> We already discussed how to handle this with 
> draft-ietf-pce-stateful-sync-optimizations, which was approved for 
> publication recently.  I think that we should handle it in a consistent way 
> for draft-ietf-pce-stateful-pce.  So I propose this change:
> 
> OLD
>As a general precaution, it is RECOMMENDED that these PCEP extensions
>only be activated on authenticated and encrypted sessions across PCEs
>and PCCs belonging to the same administrative authority.
> NEW
>As a general precaution, it is RECOMMENDED that these PCEP extensions
>only be activated on authenticated and encrypted sessions across PCEs
>and PCCs belonging to the same administrative authority, using Transport 
> Layer
>Security (TLS) [I-D.ietf-pce-pceps], as per the recommendations and
>best current practices in [RFC7525].  An administrator could also expose 
> the
>speaker entity id as part of the certificate, so that the peer's identity 
> can be verified.
> END NEW
> 
> 



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

Re: [Pce] Status of draft-ietf-pce-wson-rwa-ext

[Julien Meuric]

  
  
Hi Cyril, hi Adrian,

Don't worry, even though we missed several datatracker cycles, the
I-D isn't forgotten and a shepherd has been appointed: me. ;-)

The chairs had decided to apply WFQ over the I-D processing queue.
Considering the low pressure product implementers put on the
interoperability along this I-D (feedback to the chairs welcome on
that), it got preempted to free bandwidth for the stateful I-Ds and
the associated codepoint clash. Now that these are with the IESG, I
should be able to share my review soon (i.e., by next IETF).

Regards,

Julien


Apr. 11, 2017 - cmarga...@juniper.net:


  
  
  
  
  
  
  

  Hi, 
  
  
  From what I can recall, there was no comment pending.
Grep'ing through my archives I found : the following last messages regarding the gmpls
  draft are :
  
  
  Other comments addressed : https://mailarchive.ietf.org/arch/msg/pce/3oswQvIe4THUtUSUnXwKfmfeVmg,
also reflected in https://www.ietf.org/proceedings/94/slides/slides-94-pce-0.pdf

  
  
  
  WG comments addressed: https://mailarchive.ietf.org/arch/msg/pce/vPZsnrCy4kh7H8VaMDz6I-XI8uw
  
  
  
  
  The document status from the slides is Shepherd assigned.
  
  
  I will be happy to address any actions that I can complete
on my side.
  
  
  Cyril


From:
Adrian Farrel 
Sent: Monday, April 10, 2017 4:40:28 PM
  
   

  
  
  Thanks Jon!

Looks like I need to chivvy the authors of
draft-ietf-pce-gmpls-pcep-extensions.

But, oh look! It has expired. A year ago!

Wow! Any archaeologists out there want to dig through the
mail archive to find
out what needed to be done?

Thanks,
Adrian

> -Original Message-
> From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
> Sent: 10 April 2017 08:37
> 
> Hi Adrian
> 
> Thanks for checking.  This draft depends normatively on
draft-ietf-pce-gmpls-
> pcep-extensions, which I believe still has some actions
to be completed.  Our
plan
> is to advance both together.
> 
> Cheers
> Jon
> 
> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org]
On Behalf Of Adrian Farrel
> Sent: 07 April 2017 18:33
> 
> Hi,
> 
> Did https://datatracker.ietf.org/doc/draft-ietf-pce-wson-rwa-ext
disappear
> down a crack?
> 
> Looks like WG last call completed and the draft was
updated.
> Also the shepherd write-up was updated.
> 
> Does the big red button need to be pressed to send this
to the AD?
> 
> Thanks,
> Adrian
> 
  


  


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