[Pce] PCE WG Minutes for IETF100

2017-11-20 Thread Dhruv Dhody 
Hi WG,

The minutes are uploaded at https://datatracker.ietf.org/
doc/minutes-100-pce/
Please let me know if there are any comments.

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

Re: [Pce] Second WG Last Call for draft-ietf-pce-lsp-setup-type

2017-11-20 Thread Jeff Tantsura 
As co-author  - yes/support

Regards,
Jeff

> On Nov 21, 2017, at 00:32, Julien Meuric  wrote:
> 
> Dear PCE WG,
> 
> Considering the concerns discussed on the list after the 1st WG Last
> Call, especially about the backward compatibility of the additional TLV
> (please see Jon's change list), this message starts a 2nd LC on
> draft-ietf-pce-lsp-setup-type-06. It will end on Monday December 4.
> 
> Thanks for your careful reviews,
> 
> Julien
> 
> ___
> Pce mailing list
> Pce@ietf.org
> https://www.ietf.org/mailman/listinfo/pce

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

[Pce] Second WG Last Call for draft-ietf-pce-lsp-setup-type

2017-11-20 Thread Julien Meuric 
Dear PCE WG,

Considering the concerns discussed on the list after the 1st WG Last
Call, especially about the backward compatibility of the additional TLV
(please see Jon's change list), this message starts a 2nd LC on
draft-ietf-pce-lsp-setup-type-06. It will end on Monday December 4.

Thanks for your careful reviews,

Julien

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

Re: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

2017-11-20 Thread stephane.litkowski 
Hi Jon,

Thanks for the update.
One comment regarding this paragraph:
"If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP
   speaker MUST infer that the peer supports path setup using at least
   RSVP-TE.  The PCEP speaker MAY also infer that the peer supports
   other path setup types, but the means of inference are outside the
   scope of this document."

Why not enforcing here ? I mean if a PCEP speaker uses a PST that was not 
advertised in the capability TLV, the PST is rejected by a PCError.
During the OPEN message, peers may agree on the PST to be used on the session 
based on the common subset.

What's your opinion on that ?

Brgds,

Stephane

-Original Message-
From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com] 
Sent: Monday, November 20, 2017 16:07
To: pce@ietf.org
Cc: MEURIC Julien IMT/OLN; LITKOWSKI Stephane OBS/OINIS
Subject: FW: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

Dear PCE WG

This new revision of the LSP setup type draft makes the following changes.

1) Added a capability TLV for the OPEN object and rules for processing it, as 
discussed in the attached thread. This is to address Julien's WGLC comment that 
there was no way for a PCEP speaker to express that it doesn't support RSVP-TE 
as a path setup type.

2) Made the path setup type explicit for anything other than RSVP-TE paths 
(where absence of TLV implies RSVP-TE).  This is to address Stephane's recent 
comment to the list.

3) Updated the IANA / code point text to reflect that we have had an early 
allocation.

4) Made some editorial fixes and clarifications.

Best regards
Jon

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: 20 November 2017 14:59
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt


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

Title   : Conveying path setup type in PCEP messages
Authors : Siva Sivabalan
  Jeff Tantsura
  Ina Minei
  Robert Varga
  Jon Hardwick
Filename: draft-ietf-pce-lsp-setup-type-06.txt
Pages   : 10
Date: 2017-11-20

Abstract:
   A Path Computation Element can compute traffic engineering paths (TE
   paths) through a network that are subject to various constraints.
   Currently, TE paths are label switched paths (LSPs) which are set up
   using the RSVP-TE signaling protocol.  However, other TE path setup
   methods are possible within the PCE architecture.  This document
   proposes an extension to PCEP to allow support for different path
   setup methods over a given PCEP session.



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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-06
https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-setup-type-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-setup-type-06


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

_

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

[Pce] FW: I-D Action: draft-ietf-pce-segment-routing-11.txt

2017-11-20 Thread Jonathan Hardwick 
This new revision brings draft-ietf-pce-segment-routing in-line with the new 
LSP-SETUP-TYPE-CAPABILITY TLV just published in 
draft-ietf-pce-lsp-setup-type-06.

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: 20 November 2017 15:01
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-11.txt


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

Title   : PCEP Extensions for Segment Routing
Authors : Siva Sivabalan
  Clarence Filsfils
  Jeff Tantsura
  Wim Henderickx
  Jon Hardwick
Filename: draft-ietf-pce-segment-routing-11.txt
Pages   : 22
Date: 2017-11-20

Abstract:
   Segment Routing (SR) enables any head-end node to select any path
   without relying on a hop-by-hop signaling technique (e.g., LDP or
   RSVP-TE).  It depends only on "segments" that are advertised by Link-
   State Interior Gateway Protocols (IGPs).  A Segment Routed Path can
   be derived from a variety of mechanisms, including an IGP Shortest
   Path Tree (SPT), explicit configuration, or a Path Computation
   Element (PCE).  This document specifies extensions to the Path
   Computation Element Protocol (PCEP) that allow a stateful PCE to
   compute and initiate Traffic Engineering (TE) paths, as well as a PCC
   to request a path subject to certain constraint(s) and optimization
   criteria in SR networks.



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

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

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


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

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

[Pce] FW: I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

2017-11-20 Thread Jonathan Hardwick 
Dear PCE WG

This new revision of the LSP setup type draft makes the following changes.

1) Added a capability TLV for the OPEN object and rules for processing it, as 
discussed in the attached thread. This is to address Julien's WGLC comment that 
there was no way for a PCEP speaker to express that it doesn't support RSVP-TE 
as a path setup type.

2) Made the path setup type explicit for anything other than RSVP-TE paths 
(where absence of TLV implies RSVP-TE).  This is to address Stephane's recent 
comment to the list.

3) Updated the IANA / code point text to reflect that we have had an early 
allocation.

4) Made some editorial fixes and clarifications.

Best regards
Jon

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: 20 November 2017 14:59
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt


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

Title   : Conveying path setup type in PCEP messages
Authors : Siva Sivabalan
  Jeff Tantsura
  Ina Minei
  Robert Varga
  Jon Hardwick
Filename: draft-ietf-pce-lsp-setup-type-06.txt
Pages   : 10
Date: 2017-11-20

Abstract:
   A Path Computation Element can compute traffic engineering paths (TE
   paths) through a network that are subject to various constraints.
   Currently, TE paths are label switched paths (LSPs) which are set up
   using the RSVP-TE signaling protocol.  However, other TE path setup
   methods are possible within the PCE architecture.  This document
   proposes an extension to PCEP to allow support for different path
   setup methods over a given PCEP session.



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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-06
https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-setup-type-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-setup-type-06


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
--- Begin Message ---
Mahendra, many thanks for your input.



PCE WG, we have a backwards compatible proposal on the table which, apart from 
making a special case of SR-PCE-CAPABILITY, seems reasonably clean (or, at 
least, not seriously broken).  Shall we go forwards with that?



Best regards

Jon





From: Mahendra Singh Negi [mailto:mahendrasi...@huawei.com]
Sent: 25 July 2017 13:12
To: adr...@olddog.co.uk; 'Julien Meuric' ; Jonathan 
Hardwick ; pce@ietf.org; Dhruv Dhody 

Cc: draft-ietf-pce-lsp-setup-t...@ietf.org; 
draft-ietf-pce-segment-rout...@ietf.org
Subject: RE: [Pce] Can we make a non-backwards compatible change to 
draft-ietf-pce-lsp-setup-type?



Dear All,



This is to answer on implantation row, apologies for the delayed response,  YES 
we do have our PCEP solutions deployed in mixed SR/RSVP-TE environments.

I am afraid any non-backward compatible changes will break our solution. So 
hope we choose a backward compatible solution.



Regards,

Mahendra (Huawei Tech India Pvt Ltd)



From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: 25 July 2017 16:26
To: 'Julien Meuric'; 'Jonathan Hardwick'; pce@ietf.org
Cc: 
draft-ietf-pce-lsp-setup-t...@ietf.org;
 
draft-ietf-pce-segment-rout...@ietf.org
Subject: Re: [Pce] Can we make a non-backwards compatible change to 
draft-ietf-pce-lsp-setup-type?



Sighing slightly:-)



If, as may be the case, there is a demand to make this work either as currently 
specified or to be seamlessly interoperable with what is already specified then 
so be it. Let's make that as a conscious decision.



However, I think that using 7120 as an "excuse" is a bad idea. What 7120 is 
saying is that the allocated code point must show some stability in meaning 
from the point of early allocation on to RFC (just as it would need to if the 
RFC was revised). But that is not saying that, upon noticing that we are a herd 
of lemmings rushing towards the cliff we must say "We have always rushed 
towards the cliff. Our parents rushed towards the cliff. We must continue even 
if

[Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

2017-11-20 Thread 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 WG of the IETF.

Title   : Conveying path setup type in PCEP messages
Authors : Siva Sivabalan
  Jeff Tantsura
  Ina Minei
  Robert Varga
  Jon Hardwick
Filename: draft-ietf-pce-lsp-setup-type-06.txt
Pages   : 10
Date: 2017-11-20

Abstract:
   A Path Computation Element can compute traffic engineering paths (TE
   paths) through a network that are subject to various constraints.
   Currently, TE paths are label switched paths (LSPs) which are set up
   using the RSVP-TE signaling protocol.  However, other TE path setup
   methods are possible within the PCE architecture.  This document
   proposes an extension to PCEP to allow support for different path
   setup methods over a given PCEP session.



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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-06
https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-setup-type-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-setup-type-06


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

[Pce] I-D Action: draft-ietf-pce-wson-rwa-ext-07.txt

2017-11-20 Thread 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 WG of the IETF.

Title   : PCEP Extension for WSON Routing and Wavelength 
Assignment
Authors : Young Lee
  Ramon Casellas
Filename: draft-ietf-pce-wson-rwa-ext-07.txt
Pages   : 25
Date: 2017-11-20

Abstract:
   This document provides the Path Computation Element communication
   Protocol (PCEP) extensions for the support of Routing and Wavelength
   Assignment (RWA) in Wavelength Switched Optical Networks (WSON).
   Lightpath provisioning in WSONs requires a routing and wavelength
   assignment (RWA) process.  From a path computation perspective,
   wavelength assignment is the process of determining which wavelength
   can be used on each hop of a path and forms an additional routing
   constraint to optical light path computation.


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

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-pce-wson-rwa-ext-07
https://datatracker.ietf.org/doc/html/draft-ietf-pce-wson-rwa-ext-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-wson-rwa-ext-07


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] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints

2017-11-20 Thread Jonathan Hardwick 
I'm OK with downgrading the "must" to a "may" (in lowercase).
Cheers
Jon



From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: 19 November 2017 14:43
To: 'Julien Meuric' ; 'Dhruv Dhody' 
; Jonathan Hardwick 
Cc: draft-ietf-pce-pcep-exp-codepoi...@ietf.org; pce@ietf.org
Subject: RE: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints

That works for me, although I would probably lower-case the "MAY".

A

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Julien Meuric
Sent: 17 November 2017 17:30
To: Dhruv Dhody; Jonathan Hardwick
Cc: 
draft-ietf-pce-pcep-exp-codepoi...@ietf.org;
 pce@ietf.org
Subject: Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints

Hi,

IMHO, the correct wording lies in between. RFC 5440 set the default for PCEP 
("A PCEP-ERROR object is used to report a PCEP error"). Further specification 
(e.g. RFC 8231) MAY add message-specific behavior, but I think it is wrong to 
mandate a new behavior for each new message. I would thus suggest :
   If the PCE does not understand or support an experimental object with
   the P flag set in the Object Header, in the Path Computation Request
   message (PCReq), the entire PCEP message is rejected and PCE responds
   with a PCErr message with Error-Type="Unknown Object" or "Not
   supported object" as described in [RFC5440]. Otherwise, the object is
   ignored. Message-specific behavior MAY be specified (e.g., [RFC8231]
   defines rules for a PCC to handle an unknown object in an Update
   (PCUpd) message).

My 2 cents,

Julien

Nov. 13, 2017 - dhruv.dh...@huawei.com:



Section 5

The following paragraph does not tell the whole story.

   A PCE that does not recognize an experimental PCEP object, will
   reject the entire PCEP message and send a PCE error message with
   Error- Type="Unknown Object" or "Not supported object" as described
   in [RFC5440].

If the P flag is clear in the object header, then the PCE MAY ignore the object 
instead of generating this error message. Also, you do not discuss what a PCC 
would do on receipt of a PCUdp or PCInitiate containing an unrecognised 
experimental object - it is inconsistent that you don't cover these cases.  
(FWIW, RFC 8231 is a bit ambiguous about what a PCC should do about the PCUpd. 
Section 6.2 says that a PCErr should be sent, but then it refers to section 
7.3.3, which says that a PCRpt should be sent. Hmmm.)

[[[Dhruv Dhody]]] Yes. How about I update to this -

   If the PCE does not understand or support an experimental object with
   the P flag set in the Object Header, in the Path Computation Request
   message (PCReq), the entire PCEP message is rejected and PCE responds
   with a PCErr message with Error-Type="Unknown Object" or "Not
   supported object" as described in [RFC5440].  Otherwise the object is
   ignored.  In case of stateful PCE messages [RFC8231], the P flag is
   ignored and the unknown object handling is as per the stateful PCE
   extensions.

And let's try to handle the inconsistency in RFC 8231 with an errata perhaps? 
And handle PCE-initiated during AUTH48?

[Jon] I think this is OK, but if we are just going to point the reader at 
RFC8231, then we might as well do the same with RFC5440, rather than duplicate 
its text.  And we should write something that allows for the possibility that 
more message types may be relevant in future.  How about

   If a PCEP speaker does not understand or support an experimental object
   then the way it handles this situation depends on the message type.
   For example, a PCE handles an unknown object in the Path Computation Request
   (PCReq) message according to the rules of [RFC5440].  A PCC handles an
   unknown object in an Update (PCUpd) message according to the rules of 
[RFC8231]
   and, in an LSP Initiate Request (PCInitiate) message, according to the rules 
of
   [I-D.ietf-pce-pce-initiated-lsp].  Any document that adds a new PCEP message
   type must specify how to handle unknown objects on that message.

Note that this last sentence is not an RFC2119 MUST because it defines author 
behaviour, not device behaviour.

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