Re: [Pce] IPR Poll on draft-ietf-pce-association-policy

[Jonathan Hardwick]

I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.

Cheers
Jon

From: Hariharan Ananthakrishnan 
Sent: 04 September 2020 22:08
To: slitk...@cisco.com; msiva...@gmail.com; jefftant.i...@gmail.com; Jonathan 
Hardwick ; Mahend Negi 
; c...@huawei.com
Cc: pce@ietf.org
Subject: IPR Poll on draft-ietf-pce-association-policy

NOTE: Message is from an external sender

Hi Authors,



In preparation for WG LC on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.



Please respond (copying the mailing list) to say one of:



I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of the IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

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

Re: [Pce] I-D Action: draft-ietf-pce-stateful-flags-00.txt

[Jonathan Hardwick]

I support publication.
Cheers
Jon

-Original Message-
From: Dhruv Dhody  
Sent: 08 November 2019 16:07
To: pce@ietf.org
Subject: Re: [Pce] I-D Action: draft-ietf-pce-stateful-flags-00.txt

Hi WG,

As instructed by our AD, I-D has been posted with the file name change
- draft-ietf-pce-stateful-flags-00.

https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-flags/

The chairs request the WG to reaffirm that the WG supports the publication of 
the I-D by Friday 22nd Nov. We request you to be vocal to enable us to judge 
consensus (and justify it).

Thanks!
Dhruv & Julien


On Thu, Nov 7, 2019 at 9:30 PM  wrote:
>
>
> 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   : Updated Rules for Processing Stateful PCE Request 
> Parameters Flags
> Author  : Adrian Farrel
> Filename: draft-ietf-pce-stateful-flags-00.txt
> Pages   : 6
> Date: 2019-11-07
>
> Abstract:
>Extensions to the Path Computation Element Communication Protocol
>(PCEP) to support stateful Path Computation Elements (PCEs) are
>defined in RFC 8231.  One of the extensions is the Stateful PCE
>Request Parameters (SRP) object.  That object includes a Flags field
>that is a set of 32 bit flags, and RFC 8281 defines an IANA registry
>for tracking assigned flags.  However, RFC 8231 does not explain how
>an implementation should set unassigned flags in transmitted
>messages, nor how an implementation should process unassigned,
>unknown, or unsupported flags in received messages.
>
>This document updates RFC 8231 by defining the correct behaviors.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-flags/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-pce-stateful-flags-00
> https://datatracker.ietf.org/doc/html/draft-ietf-pce-stateful-flags-00
>
>
> 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

Re: [Pce] WG LC for draft-farrel-pce-stateful-flags-01

[Jonathan Hardwick]

I have read the document. It's straightforward and clear. I think it's ready to 
be published.
Cheers
Jon

-Original Message-
From: Pce  On Behalf Of Dhruv Dhody
Sent: 09 September 2019 12:05
To: pce@ietf.org
Cc: pce-chairs 
Subject: Re: [Pce] WG LC for draft-farrel-pce-stateful-flags-01

NOTE: Message is from an external sender

Hi WG,

We have only one response so far. This is a focused small document, with just 
1-2 pages of the main content that updates a problem that was found in RFC 
8231. This might seem trivial but it is important as a WG that we fix issues in 
our published RFCs and make it easier for later work and implementations.

Please read and comment, if you feel the document should not be published, 
please state your reason. We urge you to be vocal on the list either way, you 
have another week as WG LC closes on 16th Sept.

Thanks!
PCE Chairs

On Fri, Aug 30, 2019 at 11:43 PM Dhruv Dhody  wrote:
>
> Hi WG,
>
> This email starts a 'working group last call' for
> draft-farrel-pce-stateful-flags-01 [1]. This I-D is focused and has an 
> uncontroversial fix to RFC 8231, we are moving it directly to WGLC. 
> See [2] for context.
>
> Please indicate your support or concern for this draft.
>
> If you are opposed to the progression of the draft, please articulate 
> your concern.
>
> If you support, please indicate that you have read the latest version 
> and it is ready for publication.
>
> As always, review comments and nits are most welcome.
>
> The WG LC will end on 16th September 2019.
>
> Thanks,
> PCE Chairs
>
> [1] https://datatracker.ietf.org/doc/draft-farrel-pce-stateful-flags/
> [2] 
> https://mailarchive.ietf.org/arch/msg/pce/tTkJKO34xTD0CY48IJCk5FjmiJ4

___
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] WG adoption poll for draft-sivabalan-pce-binding-label-sid-07

[Jonathan Hardwick]

I support adoption of this draft (as co-author).
The binding label provides a mechanism for interworking between separate MPLS 
switching domains, which is an important consideration as SR is rolled out.  
Extending PCEP with this capability is a logical and necessary step.

Cheers
Jon

-Original Message-
From: Pce  On Behalf Of Dhruv Dhody
Sent: 20 August 2019 18:45
To: pce@ietf.org
Cc: pce-chairs 
Subject: [Pce] WG adoption poll for draft-sivabalan-pce-binding-label-sid-07

NOTE: Message is from an external sender

Hi WG,

This email begins the WG adoption poll for
draft-sivabalan-pce-binding-label-sid-07 [1].

Should this draft be adopted by the PCE WG? Please state your reasons - Why / 
Why not? What needs to be fixed before or after adoption? Are you willing to 
work on this draft? Review comments should be posted to the list.

One of the chairs did a pre-adoption review [2] and authors posted a new 
revision. Note that there are known implementations.

This adoption poll will end on 6th September 2019.

Thanks!
Dhruv (for the chairs)


[1] https://tools.ietf.org/html/draft-sivabalan-pce-binding-label-sid-07
[2] https://mailarchive.ietf.org/arch/msg/pce/oaBIRA9FnNsV6-JrKKRCdwtLysk

___
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] IPR poll on draft-sivabalan-pce-binding-label-sid-07

[Jonathan Hardwick]

I am not aware of any IPR applicable to this draft that should be disclosed in 
accordance with IETF IPR rules.

Cheers
Jon

From: Hariharan Ananthakrishnan 
Sent: 21 August 2019 04:40
To: Siva Sivabalan (msiva) ; cfils...@cisco.com; 
jefftant.i...@gmail.com; Jonathan Hardwick ; 
stef...@previdi.net; chengl...@huawei.com
Cc: pce@ietf.org
Subject: IPR poll on draft-sivabalan-pce-binding-label-sid-07

NOTE: Message is from an external sender

Hi Authors,



In preparation for Working Group last call on this draft, I'd like all

authors and contributors to confirm on the list that they are in compliance

with IETF IPR rules.



Please respond (copying the mailing list) to say one of:



I am not aware of any IPR applicable to this draft that should be disclosed

in accordance with IETF IPR rules.



I am aware of IPR applicable to this draft, and it has already been

disclosed to the IETF.



I am aware of IPR applicable to this draft, but that has not yet been

disclosed to the IETF. I will work to ensure that it will be disclosed in a

timely manner.



Thanks,

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

Re: [Pce] Routing directorate review of draft-ietf-pce-stateful-pce-auto-bandwidth-09

[Jonathan Hardwick]

Thanks Rakesh, sounds good to me.
Jon

From: Rakesh Gandhi 
Sent: 21 June 2019 18:30
To: Jonathan Hardwick 
Cc: rtg-...@ietf.org; rtg-...@ietf.org; pce@ietf.org; 
draft-ietf-pce-stateful-pce-auto-bandwidth@ietf.org
Subject: Re: [Pce] Routing directorate review of 
draft-ietf-pce-stateful-pce-auto-bandwidth-09

NOTE: Message is from an external sender
Hi Jon,

Thank you for the review comments. Please see inline with ...

On Tue, Jun 18, 2019 at 5:53 AM Jonathan Hardwick 
mailto:40metaswitch@dmarc.ietf.org>>
 wrote:
Hi there

I have reviewed this draft for the routing directorate as part of preparing it 
for IETF last call and IESG review.

I was familiar with this document from the time that I chaired the PCE working 
group, but this was the first time I read it all the way through and paid 
attention to all details.  I found it easy to read and understand.  I think it 
is basically ready to go with a few small clarifications and nits, below.

Cheers
Jon

Document: draft-ietf-pce-stateful-pce-auto-bandwidth-09
Reviewer: Jon Hardwick
Review Date: 18 June 2019
IETF LC End Date: LC not started yet
Intended Status: Standards Track

Comments
Section 3 is somewhat redundant IMO.

 We can keep it given the Figure showing the extensions unless there is a 
preference to remove it.

4.1 you should ideally provide a reference for how to do MBB signalling.

 Added [RFC3209].

4.3 “Similarly, if a PCC gets overwhelmed due to signaling churn, it can notify 
the PCE to temporarily suspend new LSP setup requests.”  I think this is 
covered by 5.7 as well as the PCE case, but you only refer to 5.7 for the 
latter. Please point to 5.7 for both cases.

 Added.

5.1 Not a big deal, but I wonder if there is any practical reason to 
differentiate the final two bullets.

 There is a precedence for the second bullet error message in [RFC 8231] 
(e.g. error-value 2). The first bullet error message just comes from the 
existing behaviour without this extension.


5.6 Why are AUTO-BANDWIDTH-ATTRIBUTES required (MUST) in the LSPA object of a 
PCRpt?  If the LSP is PCE-initiated, then the PCE already knows what attributes 
were specified.  If the LSP is PCC-Initiated, then the attributes are the PCC’s 
business – the PCE can’t change them (per 5.5) and I don’t think the PCE even 
needs to know what they are.

 Agree. Removed the sentence.

7.2 Misuses RFC 2119 language to request an action from a working group.  In 
other documents (when there is not already a draft in progress to do it) we 
have reworded this as “the YANG / MIB could be updated” etc.

 Updated the text.


Nits
5: “Extensions to the PCEP” would sound better as “PCEP Extensions”

 Fixed.

7: In RFC 6123 it says “The Manageability Considerations section SHOULD be 
placed immediately before the Security Considerations section in any 
Internet-Draft.” – but here, it comes after.

 Updated.

Thanks,
Rakesh



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

[Pce] Routing directorate review of draft-ietf-pce-stateful-pce-auto-bandwidth-09

[Jonathan Hardwick]

Hi there

I have reviewed this draft for the routing directorate as part of preparing it 
for IETF last call and IESG review.

I was familiar with this document from the time that I chaired the PCE working 
group, but this was the first time I read it all the way through and paid 
attention to all details.  I found it easy to read and understand.  I think it 
is basically ready to go with a few small clarifications and nits, below.

Cheers
Jon

Document: draft-ietf-pce-stateful-pce-auto-bandwidth-09
Reviewer: Jon Hardwick
Review Date: 18 June 2019
IETF LC End Date: LC not started yet
Intended Status: Standards Track

Comments
Section 3 is somewhat redundant IMO.
4.1 you should ideally provide a reference for how to do MBB signalling.
4.3 "Similarly, if a PCC gets overwhelmed due to signaling churn, it can notify 
the PCE to temporarily suspend new LSP setup requests."  I think this is 
covered by 5.7 as well as the PCE case, but you only refer to 5.7 for the 
latter. Please point to 5.7 for both cases.
5.1 Not a big deal, but I wonder if there is any practical reason to 
differentiate the final two bullets.
5.6 Why are AUTO-BANDWIDTH-ATTRIBUTES required (MUST) in the LSPA object of a 
PCRpt?  If the LSP is PCE-initiated, then the PCE already knows what attributes 
were specified.  If the LSP is PCC-Initiated, then the attributes are the PCC's 
business - the PCE can't change them (per 5.5) and I don't think the PCE even 
needs to know what they are.
7.2 Misuses RFC 2119 language to request an action from a working group.  In 
other documents (when there is not already a draft in progress to do it) we 
have reworded this as "the YANG / MIB could be updated" etc.

Nits
5: "Extensions to the PCEP" would sound better as "PCEP Extensions"
7: In RFC 6123 it says "The Manageability Considerations section SHOULD be 
placed immediately before the Security Considerations section in any 
Internet-Draft." - but here, it comes after.

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

[Pce] Shepherd review of dratf-ietf-pce-inter-area-as-applicability-07

[Jonathan Hardwick]

I have just completed a second shepherd review of this document.  For 
reference, my first review can be found at the link below.
https://mailarchive.ietf.org/arch/msg/pce/kAw8SJX3uv5_gsW7Qa03Td0pBU4

I would like to pass a massive vote of thanks to the authors for reacting 
brilliantly to my previous review and turning this document around.  It is now 
at a much higher quality level and is much easier to read.  I found a small 
number of typos below - feel free to hold these until the next revision..

Well done.  I will start the shepherd write-up.

Best regards
Jon


S1.2
s/ When a path has required/ When a path is required/

S3.1
s/a single point failure/a single point of failure/

S6.1.1
s/ must be include or exclude/ must be included or excluded/
s/ ASes are public entity as well as their interconnection/ ASes and their 
interconnections are public entities/

S7.1
s/ its TED is by participating/ its TED by participating/

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

[Pce] FW: New Version Notification for draft-ietf-pce-segment-routing-15.txt

[Jonathan Hardwick]

Hi PCE WG

This new version of the PCEP segment routing draft resolves all of the comments 
that we received during IESG review, except for the issue concerning the 
necessity of the backwards compatibility section, which is still pending.

Cheers
Jon


-Original Message-
From: internet-dra...@ietf.org  
Sent: Tuesday, 12 February, 2019 10:53 AM
To: Wim Henderickx ; Siva Sivabalan 
; Jonathan Hardwick ; 
Jonathan Hardwick ; Jeff Tantsura 
; Clarence Filsfils 
Subject: New Version Notification for draft-ietf-pce-segment-routing-15.txt

NOTE: Message is from an external sender


A new version of I-D, draft-ietf-pce-segment-routing-15.txt
has been successfully submitted by Jon Hardwick and posted to the IETF 
repository.

Name:   draft-ietf-pce-segment-routing
Revision:   15
Title:  PCEP Extensions for Segment Routing
Document date:  2019-02-12
Group:  pce
Pages:  33
URL:
https://www.ietf.org/internet-drafts/draft-ietf-pce-segment-routing-15.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/
Htmlized:   https://tools.ietf.org/html/draft-ietf-pce-segment-routing-15
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-15

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 Routing 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 Communication 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 constraints and
   optimization criteria in SR networks.





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.

The IETF Secretariat

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

Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Jonathan Hardwick]

Hi Benjamin

As I was preparing the next revision of this document, I realised I'd forgotten 
to reply to your email.  (I thought I had replied, but I can find no evidence 
that I did so!)

Anyway, I think we have converged.  Please see my proposals below, and 
apologies for my tardiness.

Cheers
Jon


> Isn't the 'F' bit fully redundant with NT?
> 
> [Jon] The F bit determines whether NAI is appended, or not.  NT gives the 
> type of the NAI that is appended.  The NT field has no meaning if F=0.

My (implicit) proposal was to assign a value for the NT field that means "no 
NAI is present", and to treat that value of NT as meaning that F=0, with any 
other value of NT meaning F=1, in which case the F bit does not add any new 
information.

[Jon2] Understood. Unfortunately, we have to make a pragmatic decision here as 
implementations are already fielded.  I have changed the text to say this to 
clarify.

NEW
   NAI Type (NT):  Indicates the type and format of the NAI contained in
  the object body, if any is present.  If the F bit is set to zero
  (see below) then the NT field has no meaning and MUST be ignored
  by the receiver.
END NEW


> It's interesting that the routing protocols' MSD value supersedes the 
> PCE-obtained one, given that all three (IS-IS, OSPF, and BGP-LS) documents 
> have text to the effect of "PCEP provides a way to get this, but if PCEP is 
> not used you can use our thing", which a naive reader would take to mean that 
> PCEP is intended to be the primary distribution mechanism.
> 
> [Jon] Probably needs to be fixed in the other documents.  PCEP is a fairly 
> blunt tool for specifying the MSD, which it can only do per node.  The IGPs 
> can do better by specifying the MSD per network interface.

Ah.  Unfortunately, at least the IS-IS document is already published as an RFC 
(8491) and thus immutable.  (I didn't check the others.)  I don't know whether 
it would be appropriate to add this explanation into this document since the 
other documents cannot (all) be changed.

[Jon2] I've reworded the text to make the relationship between PCEP and the 
IGPs clearer:

NEW
   Note that the MSD value exchanged via the SR-PCE-CAPABILITY sub-TLV
   indicates the SID/label imposition limit for the PCC node.  It is
   anticipated that, in many deployments, the PCCs will have network
   interfaces that are homogeneous with respect to MSD (that is, each
   interface has the same MSD).  In such cases, having a per-node MSD on
   the PCEP session is sufficient; the PCE SHOULD interpret this to mean
   that all network interfaces on the PCC have the given MSD.  However,
   the PCE MAY also learn a per-node MSD and a per-interface MSD from
   the routing protocols, as specified in: [RFC8491]; [RFC8476];
   [I-D.ietf-idr-bgp-ls-segment-routing-msd].  If the PCE learns the
   per-node MSD of a PCC from a routing protocol, then it MUST ignore
   the per-node MSD value in the SR-PCE-CAPABILITY sub-TLV and use the
   per-node MSD learned from the routing protocol instead.  If the PCE
   learns the MSD of a network interface on a PCC from a routing
   protocol, then it MUST use the per-interface MSD instead of the MSD
   value in the SR-PCE-CAPABILITY sub-TLV when it computes a path that
   uses that interface.
END NEW



> I don't think it's a good idea to just refer to "the security 
> mechanisms of [RFC 5440] and [RFC8281]", since there are qualitative 
> differences between the TCP authentication schemes and the full-on 
> encryption provided by TLS and IPsec.  (Also, what exactly are the 
> security mechanisms of RFC8281 supposed to be -- a quick look only 
> sees the new guidance to apply resource
> limits?)  The second paragraph only requires integrity protection to avoid 
> the vulnerability mentioned there, but the third paragraph requires 
> confidentiality protection to preent the attack.
> 
> [Jon] RFC 8281 pulls in RFC 8231 in its security section, as you note 
> above.  RFC 8231 says
> 
>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) [PCEPS], as per the recommendations
>and best current practices in [RFC7525].

That still doesn't seem to give the reader much guidance about which cases 
require encryption and which cases can safely proceed with just integrity 
protection (even though I'm happy to see the general recommendation to use 
TLS!).

[Jon2] OK, I understand. The strong steer is that TLS should be used all the 
time, but we haven't mandated it, so you are right, more guidance should be 
given.  I think your analysis is correct, so I've changed the text in the 
second and third paragraphs as follows.

NEW
   Note that this specification enables a network controller to
   instantiate a path in the network without the use of a hop-by-hop
   signaling 

Re: [Pce] Alvaro Retana's Discuss on draft-ietf-pce-segment-routing-14: (with DISCUSS and COMMENT)

[Jonathan Hardwick]

Hi Alvaro

I'm sorry that it has taken longer than I thought to reply to your comments!  
Please find our replies below.  I will post an updated version of the document 
as soon as I can.

Many thanks
Jon



--
DISCUSS:
--

I am balloting DISCUSS because I think that there are some technical and 
clarity issues that makes understanding, and potentially implementing this 
document hard.  I also want to discuss the "backwards compatibility" and the 
use of TLVs as sub-TLVs in PCEP as introduced in this document.

(1) MSD Definition.  The MSD may be learned from a variety of sources, 
including the SR-PCE-CAPABILITY sub-TLV defined in this document.  It is 
important then for the MSD to be defined consistently everywhere.  Please use 
the BMI-MSD definition from rfc8491.

[Jon] Happy to change this.  This draft actually pre-dates RFC 8491, but now 
the definition has moved there, we can point to it.


(2) Ability to signal the MSD per link, not just per node.  Clearly the 
calculation of paths through specific links (using an Adjacency SID, for
example) would require that information (if different/lower from what the node 
may support).

Note that §6.1 seems to assume that the MSD will normally be advertised through 
different mechanisms, and it uses that to work around the fact that there's no 
link-specific information: "Furthermore, whenever a PCE learns the MSD for a 
link via different means, it MUST use that value for that link regardless of 
the MSD value exchanged in the SR-PCE-CAPABILITY sub-TLV."  However, the text 
doesn't mandate the IGP/BGP-LS information to be available to the PCE.  IOW, as 
written, the specification can't guarantee the proper calculation of paths that 
require the PCE to consider link MSDs.

[Jon] In many deployments we anticipate that link MSDs are homogeneous.  In 
those cases, link state routing might not distribute per-link MSDs (e.g. 
routers might not even support RFC 8491).  In such cases, the per-node MSD on 
the PCEP session is sufficient.  All the draft says is that MSD information 
available from link state routing, if any, must take priority over that defined 
on the PCEP session.  I don't see a problem with that.


(3) Extensibility to advertise other MSD-Types. [This point is not 
DISCUSS-worthy, but I'm including it here since I'm already talking about the 
MSD.]

rfc8491 (aka I-D.ietf-isis-segment-routing-msd) and 
I-D.ietf-ospf-segment-routing-msd encode the MSD advertisement as a pair:
MSD-Type and MSD-Value, with the expectation that "new MSD-Types will be 
defined to signal additional capabilities, e.g., entropy labels, SIDs that can 
be imposed through recirculation, or SIDs associated with another data plane 
such as IPv6."  IOW, the encoding is reusable with other dataplanes.  I peeked 
into draft-negi-pce-segment-routing-ipv6 [*] and i don't see anything in there 
that couldn't be signaled using the SR-PCE-CAPABILITY sub-TLV defined here (+ 
the MSD_Value).  I think this is important for consistency.

[*] I realize that draft-negi-pce-segment-routing-ipv6 is not even a WG 
document, but it is the only potential reference I found to what a different 
dataplane might look line. 

[Jon] This document (and the SR-PCE-CAPABILITY) is scoped to MPLS only.  I 
believe that draft-negi defines its own SRV6-PCE-CAPABILITY TLV and I don't see 
any reference to MSD in it, but if a new MSD type is needed for other dataplane 
types, I think it's expected that a new SR capability TLV will be defined to 
convey it.  I don't expect to generalize the SR-PCE-CAPABILITY TLV.

Note that the MSD in the SR-PCE-CAPABILITY is a BMI-MSD. Although RFC 8491 
defines a generic MSD container, the MSD in this document is specifically a 
BMI-MSD.


(4) §6.2.2 (Interpreting the SR-ERO):

  o  If the subobjects contain NAI only, then the PCC first converts
 each NAI into a SID index value by looking it up in its local
 database, and then proceeds as above.

I believe that this step in the interpretation of the SR-ERO is not properly 
specified.

Which "local database" are you referring to?  §6.2.2.1 mentions the SR-DB (when 
talking about errors)...but the specification should be clear about which 
database and what the specific procedure is.

[Jon] You are right, this should be more explicit.  How about this.

NEW
  If the subobjects contain NAI only, the PCC first converts
  each NAI into a SID index value and then proceeds as above.
  To convert an NAI to a SID index, the PCC looks for a fully-specified
  prefix or adjacency matching the fields in the NAI.  If the PCC finds
  a matching prefix/adjacency, and the matching prefix/adjacency has a SID 
associated
  with it, then the PCC uses that SID.  If the PCC cannot find a
  matching prefix/adjacency, or if the matching prefix/adjacency has no SID 
associated
  with it, the PCC behaves as 

Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Jonathan Hardwick]

Hi Julien

At the moment, the L bit is simply called "the L bit" (not "limit" or 
"limitless") and is defined like this:

  *  L: A PCC sets this bit to 1 to indicate that it does not impose
 any limit on the MSD.

Although it might be the opposite of what you'd expect, I think the definition 
is nevertheless clear as it is written.

Cheers
Jon 

-Original Message-
From: Julien Meuric  
Sent: Monday, 7 January, 2019 9:37 AM
To: Jeff Tantsura 
Cc: Dhruv Dhody ; Jonathan Hardwick 
; Martin Vigoureux 
; The IESG ; 
draft-ietf-pce-segment-rout...@ietf.org; pce@ietf.org
Subject: Re: Martin Vigoureux's No Objection on 
draft-ietf-pce-segment-routing-14: (with COMMENT)

Hi Jeff,

You're right. I certainly don't want to change the specification, nor to add 
another ambiguity. I was just looking for a mnemonic to mitigate the confusion 
pointed out by Martin, to be considered between bracket (leaving the definition 
as is).
Would "limit-blind" make sense?

Cheers,

Julien


On 06/01/2019 20:20, Jeff Tantsura wrote:
> Hi Julien,
>
> Happy New Year to you too.
> There’s a slight difference between limitless (e.g. unlimited) and 
> limit has not been been imposed (not configured/unknown/etc).
> I think  “limitless” doesn’t convey the exact meaning. In simple terms
> - if L=1, don’t use MSD as a constraint in the path computation.
>
> Thanks,
> Jeff
>
> On Fri, Jan 4, 2019 at 02:28  <mailto:julien.meu...@orange.com>> wrote:
>
> Hi guys and happy new year! :-)
>
> Would it temper the confusion below if we added the term
> "limitless" to
> the L flag definition (section 5.1.1.)?
>
> My 2 cents,
>
> Julien
>
>
> On 21/12/2018 18:14, Jonathan Hardwick wrote:
> > I believe it is too late to change but I find L=1 meaning "no
> limit" is *very* confusing. For me L stands for Limit and when L=1
> there is a limit, when L=0 there is none.
> >
> > [Jon] Agree, both that it is confusing and too late to change 
> :-)
>
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Warren Kumari's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Jonathan Hardwick]

Thanks Warren - noted.
I have been in conference with my co-authors regarding Alvaro's comments.  We 
are close to having a complete reply.
My apologies for the delay.

Best regards
Jon


-Original Message-
From: Warren Kumari  
Sent: Friday, 7 December, 2018 4:41 PM
To: The IESG 
Cc: draft-ietf-pce-segment-rout...@ietf.org; Dhruv Dhody 
; pce-cha...@ietf.org; dhruv.i...@gmail.com; pce@ietf.org
Subject: Warren Kumari's No Objection on draft-ietf-pce-segment-routing-14: 
(with COMMENT)

Warren Kumari has entered the following ballot position for
draft-ietf-pce-segment-routing-14: 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-segment-routing/



--
COMMENT:
--

I’m balloting NoObj, but support Alvaro’s DISCUSS, especially point #4, and his 
comments, especially #1 and #7.


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

Re: [Pce] Spencer Dawkins' No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Jonathan Hardwick]

Spencer,

I think it is as Adrian has described below (thanks Adrian).  I will add the 
reference to RFC 8413.

Best regards
Jon

-Original Message-
From: Adrian Farrel  
Sent: Thursday, 6 December, 2018 2:49 PM
To: 'Spencer Dawkins' ; 'The IESG' 

Cc: pce@ietf.org; pce-cha...@ietf.org; draft-ietf-pce-segment-rout...@ietf.org
Subject: RE: [Pce] Spencer Dawkins' No Objection on 
draft-ietf-pce-segment-routing-14: (with COMMENT)

I think that for "bandwidth calendaring" we might reference 8413.

I *think* "on-demand engineering" is simply the converse. That is, traffic 
engineering / path computation at the time of request for service delivery. 
That is "what we have always done" and might not qualify for a specific 
reference.

But the authors will have a better view of what they meant 

Cheers,
Adrian
--
It's Christmas.
Buy someone you love a book of fairy tales.
https://www.feedaread.com/profiles/8604/
Available from your favourite online bookseller.
Or contact me to receive a signed copy by mail.

-Original Message-
From: Pce  On Behalf Of Spencer Dawkins
Sent: 06 December 2018 04:38
To: The IESG 
Cc: pce@ietf.org; pce-cha...@ietf.org; draft-ietf-pce-segment-rout...@ietf.org
Subject: [Pce] Spencer Dawkins' No Objection on 
draft-ietf-pce-segment-routing-14: (with COMMENT)

Spencer Dawkins has entered the following ballot position for
draft-ietf-pce-segment-routing-14: 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-segment-routing/



--
COMMENT:
--

I can guess what

   This mechanism is useful in Software Defined
   Networking (SDN) applications, such as on-demand engineering, or
   bandwidth calendaring.

means, but I'm guessing. Is there a reference for "on-demand engineering" or 
"bandwidth calendaring"?


___
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] Alissa Cooper's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Jonathan Hardwick]

Alissa

Thanks for your comment - sorry for the delay in replying.

> Section 8.4 strikes me as a little odd for an archival document -- presumably 
> draft-ietf-pce-pcep-yang either will or will not include the listed items, so 
> the recommendations will either be out-of-date or false once 
> draft-ietf-pce-pcep-yang is published.

[Jon] I agree.  Looking at the current PCEP YANG draft, I am not sure that all 
of this information is currently captured in the model.  So in this section, we 
are really pointing out SR-related information that this YANG model, or a 
future version of it, should address.  How about this:

OLD
   The PCEP YANG module [I-D.ietf-pce-pcep-yang] should include:
NEW
   The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang].  In future, this
   YANG module should be extended or augmented to provide the following
   additional information relating to segment routing.
END

Best regards
Jon


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

Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Jonathan Hardwick]

Hi Martin

Sorry for the delayed response.  Please find replies to your comments below.

Best regards
Jon



Could you elaborate on what you mean by: "or to perform a specific service on 
the packet."

[Jon] I think it should say "specific function".  Some examples of this can be 
found in draft-filsfils-spring-srv6-network-programming.  I think this is 
fairly tangential to the PCEP document, so is probably not worth referencing, 
and perhaps we should remove the text about "specific service" altogether.

s/A Segment Routed path/A Segment Routing path/

   In SR networks, an ingress node of an SR path prepends an SR header to
   all outgoing packets.  The SR header consists of a list of SIDs (or
   MPLS labels in the context of this document).
This appears twice in two consecutive paragraphs at the beginning of section 3.

[Jon] Thanks - the redundant text will be deleted.

I'm not a native english speaker but I find the use of "ERO subobject"
confusing when used to refer to the SR-ERO subobject. Maybe say the "the
(SR-ERO) subobject of the ERO".

[Jon] I think the original is OK.  In general, if I read "the  subobject", 
I interpret that as "the subobject of type ".


   Length:  Contains the total length of the subobject in octets,
  including the L, Type and Length fields.  The Length MUST be at
  least 8, and MUST be a multiple of 4.  An SR-ERO subobject MUST
  contain at least one of a SID or an NAI.  The length should
  include the SID and NAI fields if and only if they are not absent.
I am confused about the minimum length. L, Type and Length use 2 octets. What 
bring this to 8 considering that a SID is 4? 

[Jon] The NT and Flags fields add another 2 octets.  The diagram shows them but 
the text does not mention them, whereas it does mention L, Type and Length.  
Perhaps this would be less confusing:

OLD
   Length:  Contains the total length of the subobject in octets,
  including the L, Type and Length fields.
NEW
   Length:  Contains the total length of the subobject in octets.
END

Also the last sentence is very confusing. It seems normal not to count 
something which is not there. No need to say so. The current statement seems to 
contradict the preceding sentence in fact, so I'd just remove it.

[Jon] Agreed.

  *  A 4 octet MPLS label, where the 20 most significant bits encode
 the label value per [RFC3032].
s/MPLS label/MPLS Label Stack Entry/

I believe it is too late to change but I find L=1 meaning "no limit" is *very* 
confusing. For me L stands for Limit and when L=1 there is a limit, when L=0 
there is none.

[Jon] Agree, both that it is confusing and too late to change :-)

On the metric object.
You have the requirement that "the PCE MUST minimize the SID depth". This is a 
non actionable requirement. You need to set a bound. I very much understand 
that the bound is the specified sid depth (and you say it properly afterwards 
("the PCE MUST NOT return a path whose SID depth exceeds the given 
metric-value"), but still the sentence I point to is a non actionable 
requirement which you may want to reformulate.

[Jon] Agreed.  How about "the PCE minimizes the SID depth".

   If a PCEP session is established with a non-zero default MSD value,
   then the PCC MUST NOT send an MSD METRIC object with an MSD greater
   than the session's default MSD.
Out of curiosity, why do you forbid that case?

[Jon] The PCC starts a session saying its MSD is 4.  It then requests a path 
saying that the MSD must not exceed 5.  This is a clear contradiction.

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

Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-segment-routing-14: (with COMMENT)

[Jonathan Hardwick]

Hi Benjamin

Sorry for the delayed response.  Please find replies to your comments below.

Best regards
Jon


Abstract

   This document specifies extensions to the Path
   Computation Element Communication 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 constraints and
   optimization criteria in SR networks.

Why are we talking about TE paths now instead of SR?

[Jon] TE is the primary application for SR paths instantiated by a PCE.

Section 1

   Several types of segment are defined.  A node segment represents an
   ECMP-aware shortest-path to a specific node, and is always identified
   uniquely within the SR/IGP domain.  [...]

A path to a node is only going to be unique if the starting node is also 
included, is it not?

[Jon] I suggest we reword this to make it clearer:

OLD
   A node segment represents an
   ECMP-aware shortest-path to a specific node, and is always identified
   uniquely within the SR/IGP domain.
NEW
   A node segment uniquely identifies a specific node in the SR domain.
   Each router in the SR domain associates a node segment with an
   ECMP-aware shortest path to the node that it identifies.
END

Section 3

The sentences:

   In an SR network, the ingress node of an SR path prepends an SR
   header to all outgoing packets.  The SR header consists of a list of
   SIDs (or MPLS labels in the context of this document).

Appear virtually unchanged in both the start of the first paragraph and the 
middle of the second paragraph; is this duplication really needed?

[Jon] No - we'll remove the redundant text.

   A PCC MAY include an RRO containing the recorded LSP in PCReq and
   PCRpt messages as specified in [RFC5440] and [RFC8231], respectively.
   This document defines a new RRO subobject for SR networks.  The
   methods used by a PCC to record the SR-TE LSP are outside the scope
   of this document.

It's not entirely clear that we need to define a standard container to carry 
site-local data when a site-local container could also be used.

[Jon] Sorry, I don't understand your comment.  The RRO is an existing PCEP 
object whose subobjects are used to describe the actual path taken by an LSP.  
We are adding subobjects to represent SIDs.

Section 5.2

Please expand SRP (and RP, for that matter) on first usage.
(Interestingly, https://www.rfc-editor.org/materials/abbrev.expansion.txt
does not seem to have the correct expansion for this usage.)

[Jon] Will do.

Section 5.3.1

  *  C: If the M bit and the C bit are both set to 1, then the TC,
 S, and TTL fields in the MPLS label stack entry are specified
 by the PCE.  However, a PCC MAY choose to override these values
 according its local policy and MPLS forwarding rules.  If the M
 bit is set to 1 but the C bit is set to zero, then the TC, S,
 and TTL fields MUST be ignored by the PCC.  The PCC MUST set
 these fields according to its local policy and MPLS forwarding
 rules.  [...]

Must be ignored in incoming messages received from where?

[Jon] There are two types of entity in PCEP - PCC (client) and PCE (server).  
In any exchange of messages, one speaker takes the role of PCC and the other 
PCE.  Thus, "MUST be ignored by the PCC" implies that the messages are coming 
from the PCE.

Isn't the 'F' bit fully redundant with NT?

[Jon] The F bit determines whether NAI is appended, or not.  NT gives the type 
of the NAI that is appended.  The NT field has no meaning if F=0.

Section 5.3.2

Do we need to say anything about which node is the reference point for 
evaluating "local" and "remote" w.r.t. IP addresses?  (Maybe we don't, since 
these are always unidirectional adjacencies, right?)

[Jon] Effectively, yes.  An adjacency SID is always given within the context of 
a particular node - it is meaningful only on that node.  So "local" and 
"remote" are defined by that context.

Section 6.1

   If a PCC sets the N flag to 1, then the PCE MAY send an SR-ERO
   subobject containing NAI and no SID (see Section 6.2).  Otherwise,
   the PCE MUST NOT send an SR-ERO subobject containing NAI and no SID.

Sets the N flag in what message?

[Jon] This section is discussing capability exchange on the Open message.

 If a PCE receives an
   SR-PCE-CAPABILITY sub-TLV with the L flag set to 1 then it MUST
   ignore the MSD field and MUST assume that the sender can impose a SID
   stack of any depth.  [...]

nit: this second MUST seems like overkill; "and assumes" would probably work 
fine.  (Similarly for the following case.)

[Jon] OK

It's interesting that the routing protocols' MSD value supersedes the 
PCE-obtained one, given that all three (IS-IS, OSPF, and BGP-LS) documents have 
text to the effect of "PCEP provides a way to get this, but if PCEP is not used 
you can use our thing", which a naive reader would 

Re: [Pce] Alvaro Retana's Discuss on draft-ietf-pce-segment-routing-14: (with DISCUSS and COMMENT)

[Jonathan Hardwick]

Hi Alvaro

Many thanks for these comments.  I have read them, but need to have a 
discussion with my co-authors before I can answer them all.  I hope to get back 
to you with a full reply early next week.

Many thanks
Jon


-Original Message-
From: Alvaro Retana  
Sent: Wednesday, 5 December, 2018 3:25 PM
To: The IESG 
Cc: draft-ietf-pce-segment-rout...@ietf.org; Dhruv Dhody 
; pce-cha...@ietf.org; pce@ietf.org
Subject: Alvaro Retana's Discuss on draft-ietf-pce-segment-routing-14: (with 
DISCUSS and COMMENT)

Alvaro Retana has entered the following ballot position for
draft-ietf-pce-segment-routing-14: Discuss

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-segment-routing/



--
DISCUSS:
--

I am balloting DISCUSS because I think that there are some technical and 
clarity issues that makes understanding, and potentially implementing this 
document hard.  I also want to discuss the "backwards compatibility" and the 
use of TLVs as sub-TLVs in PCEP as introduced in this document.

(1) MSD Definition.  The MSD may be learned from a variety of sources, 
including the SR-PCE-CAPABILITY sub-TLV defined in this document.  It is 
important then for the MSD to be defined consistently everywhere.  Please use 
the BMI-MSD definition from rfc8491.

(2) Ability to signal the MSD per link, not just per node.  Clearly the 
calculation of paths through specific links (using an Adjacency SID, for
example) would require that information (if different/lower from what the node 
may support).

Note that §6.1 seems to assume that the MSD will normally be advertised through 
different mechanisms, and it uses that to work around the fact that there's no 
link-specific information: "Furthermore, whenever a PCE learns the MSD for a 
link via different means, it MUST use that value for that link regardless of 
the MSD value exchanged in the SR-PCE-CAPABILITY sub-TLV."  However, the text 
doesn't mandate the IGP/BGP-LS information to be available to the PCE.  IOW, as 
written, the specification can't guarantee the proper calculation of paths that 
require the PCE to consider link MSDs.

(3) Extensibility to advertise other MSD-Types. [This point is not 
DISCUSS-worthy, but I'm including it here since I'm already talking about the 
MSD.]

rfc8491 (aka I-D.ietf-isis-segment-routing-msd) and 
I-D.ietf-ospf-segment-routing-msd encode the MSD advertisement as a pair:
MSD-Type and MSD-Value, with the expectation that "new MSD-Types will be 
defined to signal additional capabilities, e.g., entropy labels, SIDs that can 
be imposed through recirculation, or SIDs associated with another data plane 
such as IPv6."  IOW, the encoding is reusable with other dataplanes.  I peeked 
into draft-negi-pce-segment-routing-ipv6 [*] and i don't see anything in there 
that couldn't be signaled using the SR-PCE-CAPABILITY sub-TLV defined here (+ 
the MSD_Value).  I think this is important for consistency.

[*] I realize that draft-negi-pce-segment-routing-ipv6 is not even a WG 
document, but it is the only potential reference I found to what a different 
dataplane might look line.

(4) §6.2.2 (Interpreting the SR-ERO):

  o  If the subobjects contain NAI only, then the PCC first converts
 each NAI into a SID index value by looking it up in its local
 database, and then proceeds as above.

I believe that this step in the interpretation of the SR-ERO is not properly 
specified.

Which "local database" are you referring to?  §6.2.2.1 mentions the SR-DB (when 
talking about errors)...but the specification should be clear about which 
database and what the specific procedure is.

For example, what is the specific process that the PCC needs to follow to 
convert a Node ID/IP address to the SID/MPLS label?  What if the SR-DB doesn't 
contain an SID associated to the specific Node ID/IP address?  How should the 
router react to that?  This case is not covered in the Error Handling section
(6.2.2.1) either.

A pointer to the SR-DB (as defined in I-D.ietf-spring-segment-routing-policy)
is not enough because it is composed of optional information (according to the 
description in §3 (Segment Routing Database)).  This document should be 
specific about what information must be contained in the SR-DB for the 
conversion to be successful.

The requirement of the information to be contained in the SR-DB makes 
I-D.ietf-spring-segment-routing-policy a Normative reference.

(5) §7 (Backward Compatibility)  "Some implementations, which are 

Re: [Pce] WG adoption poll for draft-zhao-pce-pcep-extension-for-pce-controller-08

[Jonathan Hardwick]

The poll has ended with the result that the draft will be adopted by the PCE WG.

Authors, please could you resubmit the draft as 
draft-ietf-pce-pcep-extension-for-pce-controller-00.  While you are doing this, 
please could you fix the typo in Chao Zhou's email address?  s/choa/chao/

Thanks
Jon

From: Jonathan Hardwick 
Sent: Saturday, 13 October, 2018 9:47 PM
To: pce@ietf.org
Cc: draft-zhao-pce-pcep-extension-for-pce-control...@ietf.org; 
pce-cha...@ietf.org
Subject: WG adoption poll for 
draft-zhao-pce-pcep-extension-for-pce-controller-08

This is the start of a two week poll on making 
draft-zhao-pce-pcep-extension-for-pce-controller-08 a PCE working group 
document.
https://datatracker.ietf.org/doc/draft-zhao-pce-pcep-extension-for-pce-controller/

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 Friday, October 26.

Many thanks,

Jon and Julien

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

[Pce] WG adoption poll for draft-zhao-pce-pcep-extension-for-pce-controller-08

[Jonathan Hardwick]

This is the start of a two week poll on making 
draft-zhao-pce-pcep-extension-for-pce-controller-08 a PCE working group 
document.
https://datatracker.ietf.org/doc/draft-zhao-pce-pcep-extension-for-pce-controller/

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 Friday, October 26.

Many thanks,

Jon and Julien

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

Re: [Pce] WG adoption poll for draft-zhang-pce-resource-sharing-07

[Jonathan Hardwick]

This poll ended a week ago, with a pretty limited response.  The chairs will 
discuss next steps with the authors.
Cheers
Jon

From: Jonathan Hardwick 
Sent: Friday, 21 September, 2018 2:19 PM
To: pce@ietf.org; draft-zhang-pce-resource-shar...@ietf.org
Cc: pce-cha...@ietf.org
Subject: WG adoption poll for draft-zhang-pce-resource-sharing-07

Hi PCE WG!

This is the start of a two week poll on making 
draft-zhang-pce-resource-sharing-07 a PCE working group document.
https://datatracker.ietf.org/doc/draft-zhang-pce-resource-sharing/

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 Friday, October 5.

Many thanks,

Jon and Julien


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

Re: [Pce] New Version Notification for draft-ietf-pce-segment-routing-13.txt

[Jonathan Hardwick]

Hi Dhruv

I will fix these.  In evaluating your comment (2) I realized that the first 
paragraph of the introduction is not quite correct in the way it defines a 
segment.  I will update that, too.

Cheers
Jon

-Original Message-
From: Dhruv Dhody  
Sent: Saturday, 13 October, 2018 10:25 AM
To: Jonathan Hardwick ; pce@ietf.org; Dhruv 
Dhody 
Subject: RE: New Version Notification for draft-ietf-pce-segment-routing-13.txt

Thanks Jon for this update. 
All my previous comments are handled. 

I was preparing the shepherd report, could you update these - 

(1) IDnits - 
https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pce-segment-routing-13.txt
 needs an update in references. 
  == Outdated reference: A later version (-19) exists of
 draft-ietf-isis-segment-routing-msd-16

  == Outdated reference: A later version (-23) exists of
 draft-ietf-ospf-segment-routing-msd-20

(2) Could you re-evaluate the internet drafts that are listed as normative 
references? In my view they are informative in nature. 

Thanks! 
Dhruv  

> -Original Message-
> From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
> Sent: 12 October 2018 22:20
> To: pce@ietf.org; Dhruv Dhody 
> Subject: [Pce] FW: New Version Notification for 
> draft-ietf-pce-segment- routing-13.txt
> 
> This revision addresses the recent comments from the shepherd review 
> and the 2nd WGLC.
> I believe that this is now ready for the IESG.  Dhruv - please check 
> you are happy with it.
> 
> Thanks
> Jon
> 
> -Original Message-
> From: internet-dra...@ietf.org 
> Sent: Friday, 12 October, 2018 5:47 PM
> To: Wim Henderickx ; Siva Sivabalan 
> ; Jonathan Hardwick 
> ;
> Jonathan Hardwick ; Jeff Tantsura 
> ; Clarence Filsfils 
> Subject: New Version Notification for draft-ietf-pce-segment-routing- 
> 13.txt
> 
> 
> A new version of I-D, draft-ietf-pce-segment-routing-13.txt
> has been successfully submitted by Jon Hardwick and posted to the IETF 
> repository.
> 
> Name: draft-ietf-pce-segment-routing
> Revision: 13
> Title:PCEP Extensions for Segment Routing
> Document date:2018-10-12
> Group:pce
> Pages:31
> URL:https://www.ietf.org/internet-drafts/draft-ietf-pce-
> segment-routing-13.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-
> routing/
> Htmlized:   https://tools.ietf.org/html/draft-ietf-pce-segment-
> routing-13
> Htmlized:   https://datatracker.ietf.org/doc/html/draft-ietf-pce-
> segment-routing
> Diff:   https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-
> routing-13
> 
> 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 Communication 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 constraints and
>optimization criteria in SR networks.
> 
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 
> ___
> 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: New Version Notification for draft-ietf-pce-segment-routing-13.txt

[Jonathan Hardwick]

This revision addresses the recent comments from the shepherd review and the 
2nd WGLC.
I believe that this is now ready for the IESG.  Dhruv - please check you are 
happy with it.

Thanks
Jon

-Original Message-
From: internet-dra...@ietf.org  
Sent: Friday, 12 October, 2018 5:47 PM
To: Wim Henderickx ; Siva Sivabalan 
; Jonathan Hardwick ; 
Jonathan Hardwick ; Jeff Tantsura 
; Clarence Filsfils 
Subject: New Version Notification for draft-ietf-pce-segment-routing-13.txt


A new version of I-D, draft-ietf-pce-segment-routing-13.txt
has been successfully submitted by Jon Hardwick and posted to the IETF 
repository.

Name:   draft-ietf-pce-segment-routing
Revision:   13
Title:  PCEP Extensions for Segment Routing
Document date:  2018-10-12
Group:  pce
Pages:  31
URL:
https://www.ietf.org/internet-drafts/draft-ietf-pce-segment-routing-13.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-pce-segment-routing/
Htmlized:   https://tools.ietf.org/html/draft-ietf-pce-segment-routing-13
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-pce-segment-routing
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-segment-routing-13

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 Communication 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 constraints and
   optimization criteria in SR networks.



  


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.

The IETF Secretariat

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

Re: [Pce] PCE segment routing extension

[Jonathan Hardwick]

Dhruv, Marina,

In the new revision of the PCE segment routing draft (which I am about to 
submit) I have addressed comment (2) below by adding this text.

In section 6.2.1:
“If an ERO specifies a new SR-TE path for an existing LSP and the PCC 
determines that the ERO contains SR-ERO subobjects that are not valid, then the 
PCC MUST NOT update the LSP.”

In section 6.2.2.1:
“If an ERO specifies a new SR-TE path for an existing LSP and the PCC 
encounters an error while processing the ERO, then the PCC MUST NOT update the 
LSP.”

Thanks
Jon

From: Dhruv Dhody 
Sent: Wednesday, 15 August, 2018 2:59 PM
To: Marina Fizgeer 
Cc: pce@ietf.org; Siva Sivabalan (msiva) ; Clarence Filsfils 
(cfilsfil) ; Jeff Tantsura ; 
wim.henderi...@alcatel-lucent.com; Jonathan Hardwick 
; Michael Gorokhovsky 
; Alexander Vainshtein 
; Alexander Ferdman 
; ron.sday...@ecitele.com; Dhruv Dhody 

Subject: Re: [Pce] PCE segment routing extension

Hi Marina,

I am the document shephered [1] for this I-D. I am working with the authors in 
the final stages towards RFC publication. Please see inline for my response.

Thanks!
Dhruv

[1] https://mailarchive.ietf.org/arch/msg/pce/38-FbYFEE33bTP6-yUXkKKGN8xw


On Wed, Aug 15, 2018 at 5:22 PM Marina Fizgeer 
mailto:marina.fizg...@ecitele.com>> wrote:
Dear authors of draft-ietf-pce-segment-routing-12,

My colleagues and I are interested in some clarifications:

1.   In section 6.2.1 “If the first SR-ERO represents an MPLS label value 
then the NAI field MUST NOT be absent…”

In case of binding SID as first SR-ERO, it can be MPLS label only, without NAI.
[Dhruv]: I am working with the authors in removing the restriction, you will 
find my rationale in [1].
But also note that while preparing MPLS label stack at PCE, this label stack 
should be from the POV of the ingress PCC.

2.   This draft defines the new error codes related to SR-ERO conversion, 
that were not defined in previous version.
What is expected behavior of PCC in additional to sending error message.

For example:

In case PCUpd for PCE initiated LSP, PCE sends new SR-ERO objects to PCC. PCC 
shall validate and interpret the SR-ERO EROs.

If SR-EROs cannot be converted to an MPLS label stack and a next hop, PCC shall 
send PCErr message with Error-Type “Reception of an invalid object”.

What is expected handling of new SR-EROs in updating LSP – LSP shall stay with 
old SR-ERO objects or with new ones, but in down state?
[Dhruv]: I agree that this should be clearly stated. Keeping the principle of 
make before break, staying on wil old SR path makes sense!

Thanks!
Dhruv



Best regards,

Marina Fizgeer
Email: marina.fizg...@gmail.com<mailto:marina.fizg...@gmail.com>
marina.fizg...@ecitele.com<mailto:marina.fizg...@ecitele.com>


___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___
___
Pce mailing list
Pce@ietf.org<mailto:Pce@ietf.org>
https://www.ietf.org/mailman/listinfo/pce
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] IPR check on draft-ietf-pce-stateful-pce-p2mp

[Jonathan Hardwick]

Dear authors of draft-ietf-pce-stateful-pce-p2mp,



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-stateful-pce-p2mp 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 publication can proceed.



Thanks,



Jon & Julien



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

[Pce] WG last call for draft-ietf-pce-stateful-pce-p2mp-07

[Jonathan Hardwick]

Hi all

This message begins a 2-week WG last call for 
draft-ietf-pce-stateful-pce-p2mp-07.
https://datatracker.ietf.org/doc/draft-ietf-pce-stateful-pce-p2mp/

Please read the document and reply to the PCE mailing list, indicating whether 
you believe this document is ready to be published or not (including any 
comments on why not).  The last call will end on Monday 15 October.

Best regards

Jon and Julien

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

[Pce] Publication has been requested for draft-ietf-pce-wson-rwa-ext-08

[Jonathan Hardwick]

Jonathan Hardwick has requested publication of draft-ietf-pce-wson-rwa-ext-08 
as Proposed Standard on behalf of the PCE working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-pce-wson-rwa-ext/

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

[Pce] WG adoption poll for draft-zhang-pce-resource-sharing-07

[Jonathan Hardwick]

Hi PCE WG!

This is the start of a two week poll on making 
draft-zhang-pce-resource-sharing-07 a PCE working group document.
https://datatracker.ietf.org/doc/draft-zhang-pce-resource-sharing/

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 Friday, October 5.

Many thanks,

Jon and Julien


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

Re: [Pce] PCE segment routing extension

[Jonathan Hardwick]

Michael, Marina,

To check I understand – you are proposing that the first label is a label from 
the PCC’s own SRGB and is not actually pushed, but is instead used locally by 
the PCC to identify the next hop?  That could work, and in particular I think 
it works well for binding labels.  I discussed this possibility with Dhruv at 
the last IETF meeting, but without conclusion.

As Dhruv points out in his review, this is not just a PCEP specific question.  
We should make sure that the interpretation is aligned across PCEP / BGP and 
netconf / YANG.

Cheers
Jon


From: Michael Gorokhovsky [mailto:michael.gorokhov...@ecitele.com]
Sent: Wednesday, August 15, 2018 5:33 PM
To: Jonathan Hardwick ; Marina Fizgeer 
; Dhruv Dhody 
Cc: pce@ietf.org; Siva Sivabalan (msiva) ; Clarence Filsfils 
(cfilsfil) ; Jeff Tantsura ; 
wim.henderi...@alcatel-lucent.com; Alexander Vainshtein 
; Alexander Ferdman 
; Ron Sdayoor ; Dhruv 
Dhody 
Subject: RE: [Pce] PCE segment routing extension

Hi Jon & all,

I concur with Marina here. Let us take your example with first label in SR-ERO 
list as L1. We have the following options here :

  1.  The label is associated with Prefix SID
  2.  The label is associated with adjacency SID
  3.  The label is associated with binding SID

In all of these cases first label shall be handled locally and differently in 
order to find the  next hop.
For example for adjacency segment the first label shall be not pushed and next 
hop of adjacency shall be used
For binding SID the first label shall be replaced with bound policy label stack.
The same approach from my POV shall be used for first label that is associated 
with prefix SID.  it shall be known locally for PCC and to be used to find 
actual next hop (or next hops with remote SRGBs) to destination SID. It may be 
done if first label (L1) allocated from local SRGB.

Regards, Michael

From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: Wednesday, August 15, 2018 7:03 PM
To: Marina Fizgeer 
mailto:marina.fizg...@ecitele.com>>; Dhruv Dhody 
mailto:dhruv.i...@gmail.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>; Siva Sivabalan (msiva) 
mailto:ms...@cisco.com>>; Clarence Filsfils (cfilsfil) 
mailto:cfils...@cisco.com>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; 
wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>; 
Michael Gorokhovsky 
mailto:michael.gorokhov...@ecitele.com>>; 
Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>; 
Alexander Ferdman 
mailto:alexander.ferd...@ecitele.com>>; Ron 
Sdayoor mailto:ron.sday...@ecitele.com>>; Dhruv Dhody 
mailto:dhruv.dh...@huawei.com>>
Subject: RE: [Pce] PCE segment routing extension

Hi Marina

Say that the first label in the SR-ERO is L1.  Then the PCE is instructing the 
PCC to push a stack of labels onto each packet that uses this LSP, where the 
outermost label is L1.  How does the PCC know which next hop to send the 
labelled packet to?  L1 does not identify the next hop; L1 is a label taken 
from the SRGB of the next hop.

If we assumed that all nodes use the same SRGB, then I agree, the PCC could 
look up L1 in its SRGB and work out what it refers to.  But we can’t assume 
that all nodes have the same SRGB.  Label L1 might not even be in the PCC’s 
SRGB.

Cheers
Jon


From: Marina Fizgeer [mailto:marina.fizg...@ecitele.com]
Sent: Wednesday, August 15, 2018 4:38 PM
To: Jonathan Hardwick 
mailto:jonathan.hardw...@metaswitch.com>>; 
Dhruv Dhody mailto:dhruv.i...@gmail.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>; Siva Sivabalan (msiva) 
mailto:ms...@cisco.com>>; Clarence Filsfils (cfilsfil) 
mailto:cfils...@cisco.com>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; 
wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>; 
Michael Gorokhovsky 
mailto:michael.gorokhov...@ecitele.com>>; 
Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>; 
Alexander Ferdman 
mailto:alexander.ferd...@ecitele.com>>; Ron 
Sdayoor mailto:ron.sday...@ecitele.com>>; Dhruv Dhody 
mailto:dhruv.dh...@huawei.com>>
Subject: RE: [Pce] PCE segment routing extension

Hi, Jonathan and Dhruv
Thank you for reply.

Please, see in line

Best regards,

Marina

From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: Wednesday, August 15, 2018 6:17 PM
To: Dhruv Dhody mailto:dhruv.i...@gmail.com>>; Marina 
Fizgeer mailto:marina.fizg...@ecitele.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>; Siva Sivabalan (msiva) 
mailto:ms...@cisco.com>>; Clarence Filsfils (cfilsfil) 
mailto:cfils...@cisco.com>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; 
wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>; 
Michael Gorokhovsky 
mailto:michael.gorokhov...@ecitele.com>>; 
Alexander Vainshtein 
mailto:alexander.vainsht...@e

Re: [Pce] PCE segment routing extension

[Jonathan Hardwick]

Hi Marina

Say that the first label in the SR-ERO is L1.  Then the PCE is instructing the 
PCC to push a stack of labels onto each packet that uses this LSP, where the 
outermost label is L1.  How does the PCC know which next hop to send the 
labelled packet to?  L1 does not identify the next hop; L1 is a label taken 
from the SRGB of the next hop.

If we assumed that all nodes use the same SRGB, then I agree, the PCC could 
look up L1 in its SRGB and work out what it refers to.  But we can’t assume 
that all nodes have the same SRGB.  Label L1 might not even be in the PCC’s 
SRGB.

Cheers
Jon


From: Marina Fizgeer [mailto:marina.fizg...@ecitele.com]
Sent: Wednesday, August 15, 2018 4:38 PM
To: Jonathan Hardwick ; Dhruv Dhody 

Cc: pce@ietf.org; Siva Sivabalan (msiva) ; Clarence Filsfils 
(cfilsfil) ; Jeff Tantsura ; 
wim.henderi...@alcatel-lucent.com; Michael Gorokhovsky 
; Alexander Vainshtein 
; Alexander Ferdman 
; Ron Sdayoor ; Dhruv 
Dhody 
Subject: RE: [Pce] PCE segment routing extension

Hi, Jonathan and Dhruv
Thank you for reply.

Please, see in line

Best regards,

Marina

From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: Wednesday, August 15, 2018 6:17 PM
To: Dhruv Dhody mailto:dhruv.i...@gmail.com>>; Marina 
Fizgeer mailto:marina.fizg...@ecitele.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>; Siva Sivabalan (msiva) 
mailto:ms...@cisco.com>>; Clarence Filsfils (cfilsfil) 
mailto:cfils...@cisco.com>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; 
wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>; 
Michael Gorokhovsky 
mailto:michael.gorokhov...@ecitele.com>>; 
Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>; 
Alexander Ferdman 
mailto:alexander.ferd...@ecitele.com>>; Ron 
Sdayoor mailto:ron.sday...@ecitele.com>>; Dhruv Dhody 
mailto:dhruv.dh...@huawei.com>>
Subject: RE: [Pce] PCE segment routing extension

Marina, Dhruv,

Please see below.

Cheers
Jon

From: Dhruv Dhody [mailto:dhruv.i...@gmail.com]
Sent: Wednesday, August 15, 2018 2:59 PM
To: Marina Fizgeer 
mailto:marina.fizg...@ecitele.com>>
Cc: pce@ietf.org<mailto:pce@ietf.org>; Siva Sivabalan (msiva) 
mailto:ms...@cisco.com>>; Clarence Filsfils (cfilsfil) 
mailto:cfils...@cisco.com>>; Jeff Tantsura 
mailto:jefftant.i...@gmail.com>>; 
wim.henderi...@alcatel-lucent.com<mailto:wim.henderi...@alcatel-lucent.com>; 
Jonathan Hardwick 
mailto:jonathan.hardw...@metaswitch.com>>; 
Michael Gorokhovsky 
mailto:michael.gorokhov...@ecitele.com>>; 
Alexander Vainshtein 
mailto:alexander.vainsht...@ecitele.com>>; 
Alexander Ferdman 
mailto:alexander.ferd...@ecitele.com>>; 
ron.sday...@ecitele.com<mailto:ron.sday...@ecitele.com>; Dhruv Dhody 
mailto:dhruv.dh...@huawei.com>>
Subject: Re: [Pce] PCE segment routing extension

Hi Marina,

I am the document shephered [1] for this I-D. I am working with the authors in 
the final stages towards RFC publication. Please see inline for my response.

Thanks!
Dhruv

[1] https://mailarchive.ietf.org/arch/msg/pce/38-FbYFEE33bTP6-yUXkKKGN8xw


On Wed, Aug 15, 2018 at 5:22 PM Marina Fizgeer 
mailto:marina.fizg...@ecitele.com>> wrote:
Dear authors of draft-ietf-pce-segment-routing-12,

My colleagues and I are interested in some clarifications:

1.   In section 6.2.1 “If the first SR-ERO represents an MPLS label value 
then the NAI field MUST NOT be absent…”

In case of binding SID as first SR-ERO, it can be MPLS label only, without NAI.
[Dhruv]: I am working with the authors in removing the restriction, you will 
find my rationale in [1].
But also note that while preparing MPLS label stack at PCE, this label stack 
should be from the POV of the ingress PCC.

[Jon] The difficulty is knowing which label space the first SR-ERO label comes 
from.  If it is a label from the PCC’s own SRGB then it can be used to infer 
the next hop.  If it is a label from the first downstream router’s SRGB, then 
the PCC needs more information to determine the next hop.  The draft currently 
assumes the latter.
[MF: ] Actually the next hop resolution for Node (prefix) SID can be performed 
in PCC only, for example, ECMP or LFA use cases, where there are multiple next 
hops. So, PCE shall send label in SRGB range of PCC, otherwise PCC cannot 
resolve it even though NAI is presented

2.   This draft defines the new error codes related to SR-ERO conversion, 
that were not defined in previous version.
What is expected behavior of PCC in additional to sending error message.

For example:

In case PCUpd for PCE initiated LSP, PCE sends new SR-ERO objects to PCC. PCC 
shall validate and interpret the SR-ERO EROs.

If SR-EROs cannot be converted to an MPLS label stack and a next hop, PCC shall 
send PCErr message with Error-Type “Reception of an invalid object”.

What is expected handling of new SR-EROs in updating LSP – LSP shall 

Re: [Pce] PCE segment routing extension

[Jonathan Hardwick]

Marina, Dhruv,

Please see below.

Cheers
Jon

From: Dhruv Dhody [mailto:dhruv.i...@gmail.com]
Sent: Wednesday, August 15, 2018 2:59 PM
To: Marina Fizgeer 
Cc: pce@ietf.org; Siva Sivabalan (msiva) ; Clarence Filsfils 
(cfilsfil) ; Jeff Tantsura ; 
wim.henderi...@alcatel-lucent.com; Jonathan Hardwick 
; Michael Gorokhovsky 
; Alexander Vainshtein 
; Alexander Ferdman 
; ron.sday...@ecitele.com; Dhruv Dhody 

Subject: Re: [Pce] PCE segment routing extension

Hi Marina,

I am the document shephered [1] for this I-D. I am working with the authors in 
the final stages towards RFC publication. Please see inline for my response.

Thanks!
Dhruv

[1] https://mailarchive.ietf.org/arch/msg/pce/38-FbYFEE33bTP6-yUXkKKGN8xw


On Wed, Aug 15, 2018 at 5:22 PM Marina Fizgeer 
mailto:marina.fizg...@ecitele.com>> wrote:
Dear authors of draft-ietf-pce-segment-routing-12,

My colleagues and I are interested in some clarifications:

1.   In section 6.2.1 “If the first SR-ERO represents an MPLS label value 
then the NAI field MUST NOT be absent…”

In case of binding SID as first SR-ERO, it can be MPLS label only, without NAI.
[Dhruv]: I am working with the authors in removing the restriction, you will 
find my rationale in [1].
But also note that while preparing MPLS label stack at PCE, this label stack 
should be from the POV of the ingress PCC.

[Jon] The difficulty is knowing which label space the first SR-ERO label comes 
from.  If it is a label from the PCC’s own SRGB then it can be used to infer 
the next hop.  If it is a label from the first downstream router’s SRGB, then 
the PCC needs more information to determine the next hop.  The draft currently 
assumes the latter.

2.   This draft defines the new error codes related to SR-ERO conversion, 
that were not defined in previous version.
What is expected behavior of PCC in additional to sending error message.

For example:

In case PCUpd for PCE initiated LSP, PCE sends new SR-ERO objects to PCC. PCC 
shall validate and interpret the SR-ERO EROs.

If SR-EROs cannot be converted to an MPLS label stack and a next hop, PCC shall 
send PCErr message with Error-Type “Reception of an invalid object”.

What is expected handling of new SR-EROs in updating LSP – LSP shall stay with 
old SR-ERO objects or with new ones, but in down state?
[Dhruv]: I agree that this should be clearly stated. Keeping the principle of 
make before break, staying on wil old SR path makes sense!

[Jon] I agree that this clarification should be added.

Thanks!
Dhruv



Best regards,

Marina Fizgeer
Email: marina.fizg...@gmail.com<mailto:marina.fizg...@gmail.com>
marina.fizg...@ecitele.com<mailto:marina.fizg...@ecitele.com>


___

This e-mail message is intended for the recipient only and contains information 
which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received 
this
transmission in error, please inform us by e-mail, phone or fax, and then 
delete the original
and all copies thereof.
___
___
Pce mailing list
Pce@ietf.org<mailto: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] Shepherd review of draft-ietf-pce-segment-routing-12

[Jonathan Hardwick]

Thanks for the review, Dhruv!  I'll think about your comments and get back to 
you SOON (possibly not until after my vacation next week).

Cheers
Jon

From: Dhruv Dhody [mailto:dhruv.dh...@huawei.com]
Sent: Thursday, August 9, 2018 12:36 PM
To: pce@ietf.org
Cc: pce-cha...@ietf.org; draft-ietf-pce-segment-routing@ietf.org; Dhruv 
Dhody 
Subject: Shepherd review of draft-ietf-pce-segment-routing-12

Hi,

I am assigned the shepherded for this document. I have previously given my 
input and liked the direction of the update with the -12 version, but also 
found some new issues.

Disclaimer - I discussed some of the points with the authors F2F during the 
IETF meeting as well.

Major:
***

(1) Though I appreciated the details in the new section 6.2.2. I feel the right 
place for this should be in 'draft-ietf-spring-segment-routing-mpls' because 
the source of the SID stack could be PCEP, BGP or Yang. The text related to the 
interpretation of the SID stack rightly belong in that draft and in this I-D 
should just refer it (and specify the PCEP specific error handling and 
procedures only).  I hope the chairs and AD of the WG could conclude on that. 
We could initiate a separate thread to discuss this point with spring chairs/AD.

(2) The change of the field ST (SID type) to NT (NAI type) was done in the last 
update. This change was done in the -12 version with the expectation that this 
is just a name change and would have no other impact. But since NAI is optional 
and might not be included, and in that case one would not be able to interpret 
what the SID represents when NAI is not provided. Though, it might be possible 
to find that information via searching the local database, there is no apparent 
benefit in making this change and limiting the knowledge of the SID type only 
when NAI is included.

Changes would be needed in various places including Section 6.2.1.

(3) There is no mention of the SR policy in the draft. This is a source of 
confusion, so a reference and relationship between them should be added in the 
Introduction.

(4) I think we should enhance the security consideration section 9 a little bit 
more. Since a label stack can be pushed directly for the PCE, this would have a 
bigger security impact then a path that gets further signaled by RSVP-TE and 
verified in control plane. We should talk about MSD information as well.

Minor:
***

(1) I am not comfortable with the use of term LSDB, you would note no other SR 
documents uses it either.  SR architecture also allow future innovation in 
control plane especially in the centralized mode. May be we should use the term 
SR-DB introduced by the policy draft? Or a generic term such as local database?

(2) In section 3, it describes the 3 representations for SR-ERO, I have 
following suggestion -
OLD:
   o  An ordered set of IP addresses representing network nodes/links:
  In this case, the PCC needs to convert the IP addresses into the
  corresponding MPLS labels by consulting its Link State Database
  (LSDB).

   o  An ordered set of SIDs, with or without the corresponding IP
  addresses.

   o  An ordered set of MPLS labels and IP addresses: In this case, the
  PCC needs to convert the IP addresses into the corresponding SIDs
  by consulting its LSDB.
NEW:
   o  An ordered set of IP addresses representing network nodes/links.
  In this case, the PCC needs to convert the IP addresses into the
  corresponding MPLS labels by consulting its Link State Database
  (LSDB).

   o  An ordered set of SID index values, with or without the corresponding IP
  addresses. The PCC needs to convert the index into the corresponding
  MPLS label stack as per [I-D.ietf-spring-segment-routing-mpls].

   o  An ordered set of MPLS labels, with or without corresponding IP
  address. The top label in the label stack received from the PCE is
  from the point of view of the ingress PCC and it must follow the
  procedures as described in [I-D.ietf-spring-segment-routing-mpls]
  while pushing the label stack.

The idea behind this is to specify that PCE should prepare the label stack with 
the top label from the point of view of Ingress and label stack might change. 
The change could be an outgoing label change as per the SRGB of neighbor 
towards which the packet is sent; or it could be an adjacency label pop 
identifying the out-interface.
- In section 6.2.1, we should remove this condition requiring NAI MUST be 
present for the first SR-ERO sub-object and corresponding error-code.
- In Section 6.2.2.1, we should update the procedure and the next-hop is not 
identified from the NAI

Regarding the text in section 6.2.2, once the agreement is met to move the text 
to the SR-MPLS document, the text needs to be modified accordingly from the 
point of view of a generic MPLS Control Plane Client (MCC). And we should 
simply refer to it saying PCC is one such client.
Note that 'only NAI' in SR-ERO would 

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

[Jonathan Hardwick]

Hi Mustapha

Yes, I think we can do that.  It's a small change and is backwards compatible.  
I can update the draft when submissions re-open.  Here is my proposal for the 
revised section 5.5 text:

5.5.  METRIC Object

   A PCC MAY specify the MSD for an individual path computation request
   using the METRIC object defined in [RFC5440].  This document defines
   a new type for the METRIC object to be used for this purpose as
   follows:

   o  T = 11: Maximum SID Depth of the requested path.

   The PCC sets the metric-value to the MSD for this path.  The PCC MUST
   set the B (bound) bit to 1 in the METRIC object, which specifies that
   the SID depth for the computed path MUST NOT exceed the metric-value.

   If a PCEP session is established with a non-zero default MSD value, then the
   PCC MUST NOT send an MSD METRIC object with an MSD greater than
   the session's default MSD.  If the PCE receives a path computation request
   with an MSD METRIC object on a session which is greater than the session's
   default MSD, then it MUST consider the request invalid and send
   a PCErr with Error-Type = 10 ("Reception of an invalid object") and
   Error-Value 9 ("MSD exceeds the default for the PCEP session").

Thanks
Jon

-Original Message-
From: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
[mailto:mustapha.aissa...@nokia.com] 
Sent: 29 June 2018 19:19
To: Jonathan Hardwick ; pce@ietf.org
Subject: RE: [Pce] FW: I-D Action: draft-ietf-pce-segment-routing-12.txt

Hi Jon,
There is one issue which I would like to discuss and it came up during the 
EANTC multi-vendor interop in March 2018.

The rule for handling MSD in Section 5.5 seems to be overly restrictive. The 
MSD value advertised in the Open message is useful as an upper bound for both 
pce-initiated LSP and pcc-initiated LSP. However, PCC may want to set a MSD 
value for a specific pcc-initiated LSP which is lower than that in the Open 
Object. The rules in Section 5.5 do not allow that as the presence of the MSD 
Metric object in the path request message is errored if a non-zero MSD was 
included in the Open message. If on the other hand you set the MSD in the Open 
message to zero, PCE will not discover the MSD to enforce for pce-initiated LSP.

What I would like to propose is to relax the rule such that a path request is 
only errored when the MSD Metric value is higher than that in the Open message. 
That way we can achieve the desired behavior for both pce-initiated and 
pcc-initiated LSP.

Here is the relevant paragraph in Section 5.5:
"
   If a PCEP session is established with a non-zero MSD value, then the
   PCC MUST NOT send an MSD METRIC object.  If the PCE receives a path
   computation request with an MSD METRIC object on a session with a
   non-zero MSD value then it MUST consider the request invalid and send
   a PCErr with Error-Type = 10 ("Reception of an invalid object") and
   Error-Value 9 ("Default MSD is specified for the PCEP session").
"

Mustapha.

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: Friday, June 29, 2018 1:22 PM
To: pce@ietf.org
Subject: [Pce] FW: I-D Action: draft-ietf-pce-segment-routing-12.txt

This new version addresses the feedback received during working group last 
call.  My apologies for the long delay.
Many thanks to those who took the time to review and comment on this.  The 
result is that the draft has been substantially tightened and many ambiguities 
resolved.
I will be replying to the individual commenters today.

Best regards
Jon

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: 29 June 2018 18:20
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-segment-routing-12.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-12.txt
Pages   : 32
Date: 2018-06-29

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 a

Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11

[Jonathan Hardwick]

Hi Cyril

Many apologies for the delay – please see below.

Cheers
Jon


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Cyril Margaria
Sent: 30 January 2018 16:49
To: Dhruv Dhody 
Cc: pce@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11

Hi,

I have the following (hopefully not too late) comments/questions:

Section 5.3 ERO Object

 S: When this bit is set, the SID value in the subobject body is

 null.  In this case, the PCC is responsible for choosing the

 SID value, e.g., by looking up its TED using the NAI which, in

 this case, MUST be present in the subobject.

- What is the associated procedure if the PCC cannot resolve the NAI to a SID? 
Should there be associated error codes. For instance the PCC may not be able to 
resolve the NAI  at all or the resolution may fail. In case the PCC does not 
support the NAI resolution, having this capability part of the capability 
exchange would improve interop, as the PCE can be capable to provide the SID.

[Jon]
I agree that a capability would be good.  Yes, if the NAI cannot be resolved, 
it should be rejected.
I have added both of these to the latest draft.
[/Jon]

- If Both S and F are cleared, should the PCC do the NAI resolution and verify 
that the SID match? Would error codes be needed)

[Jon]
If the SID is a bare label then the NAI may be given to help identify the next 
hop.  If the SID is an index and NAI is given as well, then the PCC SHOULD use 
the SID, because it is a more explicit instruction.  The PCE MAY give both SID 
and NAI for diagnostic / logging purposes.  I don’t think we should require the 
PCC to validate SID==NAI in that case; it should just use the SID as given.  I 
will clarify in the draft.
[/Jon]

Thanks,
Cyril


On 30 January 2018 at 01:19, Dhruv Dhody 
mailto:dhruv.dh...@huawei.com>> wrote:
Hi,

   I had reviewed and given comments on the I-D in the past, which the
   authors had addressed. I found these additional nits/suggestions.
   Apologies for being late by a day.

   Suggestions
   ---

   Section 1

   (1) Though it is true that a child PCE act as a PCC towards the
   parent PCE, I feel it is not wise to say the opposite, that is a PCC
   is acting as a PCE in this context. I see no advantage to bring up the
   H-PCE in this context. I suggest we remove it.

  A PCE, or a PCC operating as a PCE (in hierarchical PCE
  environment), computes paths for MPLS Traffic Engineering LSPs
  (MPLS-TE LSPs) based on various constraints and optimization
  criteria.

   (2) Since this document is related to MPLS data plane only, it would
   be nice to include a pointer to the SRv6 work in PCEP for the benefit
   of the readers.

   (3) Regarding first mention of PST
   OLD:
  This specification relies on the procedures specified in [I-
  D.ietf-pce-lsp-setup-type].
   NEW:
  This specification relies on the procedures specified in [I-
  D.ietf-pce-lsp-setup-type] for the path setup type for SR.

   Section 3

   (4) Regarding this text -

  SR-TE LSPs
  computed by a PCE can be represented in one of the following forms:

  o  An ordered set of IP address(es) representing network nodes/links:
 In this case, the PCC needs to convert the IP address(es) into the
 corresponding MPLS labels by consulting its Traffic Engineering
 Database (TED).

  o  An ordered set of SID(s).

  o  An ordered set of both MPLS label(s) and IP address(es): In this
 case, the PCC needs to convert the IP address(es) into the
 corresponding SID(s) by consulting its TED.

   Each SR-ERO object can include both SID and NAI (IP address); this
   case is different from the case 3 above, I suggest if some text can
   be added to make things clearer.

   Section 5.1.1

   (5) Why SHOULD in this text?

  A PCEP speaker SHOULD indicate its support of the function described
  in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the
  OPEN object with this new PST included in the PST list.

   Section 6

   (6) Regarding,

  A PCEP speaker that does not support the SR PCEP capability cannot
  recognize the SR-ERO or SR-RRO subobjects. As such, it MUST send a
  PCEP error with Error-Type = 4 (Not supported object) and Error-Value
  = 2 (Not supported object Type) as per [RFC5440].

   RFC 5440 did not state the behavior for unknown sub-object. My
   suggestion would be -

  A PCEP speaker that does not support the SR PCEP capability and
  thus cannot recognize the SR-ERO or SR-RRO subobjects, it will
  respond according to the rules for a malformed object as per
  [RFC5440].

   Section 7

   (7) Suggest to make Manageability Consideration section as per RFC
   6123

   (8) PCEP-Yang should be mentioned in section 7.2

   Section 8

   (9) Suggest we expand the security consideration section a bit based
   on recent DISCUSSes.


   Nits
   

   

Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11

[Jonathan Hardwick]

Hi Dhruv

My apologies for the delay.  Please find my replies and comments below.

Cheers
Jon

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Dhruv Dhody
Sent: 30 January 2018 09:20
To: Julien Meuric ; pce@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11

Hi, 

   I had reviewed and given comments on the I-D in the past, which the
   authors had addressed. I found these additional nits/suggestions.
   Apologies for being late by a day.  

   Suggestions
   ---

   Section 1

   (1) Though it is true that a child PCE act as a PCC towards the
   parent PCE, I feel it is not wise to say the opposite, that is a PCC
   is acting as a PCE in this context. I see no advantage to bring up the
   H-PCE in this context. I suggest we remove it. 

  A PCE, or a PCC operating as a PCE (in hierarchical PCE
  environment), computes paths for MPLS Traffic Engineering LSPs
  (MPLS-TE LSPs) based on various constraints and optimization
  criteria.

[Jon] OK with me - I'll trim it. [/Jon]

   (2) Since this document is related to MPLS data plane only, it would
   be nice to include a pointer to the SRv6 work in PCEP for the benefit
   of the readers.

[Jon] Changed introduction text as follows and added normative references.

The SR architecture can be implemented using either an MPLS forwarding plane 
[I-D.ietf-spring-segment-routing-mpls] or an IPv6 forwarding plane 
[I-D.ietf-6man-segment-routing-header].  The MPLS forwarding plane can be 
applied to SR without any change, in which case an SR path corresponds to an 
MPLS Label Switching Path (LSP). This document is relevant to the MPLS 
forwarding plane only.

[/Jon]

   (3) Regarding first mention of PST
   OLD:
  This specification relies on the procedures specified in [I-
  D.ietf-pce-lsp-setup-type].
   NEW:
  This specification relies on the procedures specified in [I-
  D.ietf-pce-lsp-setup-type] for the path setup type for SR.

[Jon] I changed it to:

  This specification relies on the procedures specified in [I-
  D.ietf-pce-lsp-setup-type] to exchange the segment routing
  capability and to specify that the path setup type of an LSP
  is segment routing..
[/Jon]

   Section 3

   (4) Regarding this text - 

  SR-TE LSPs
  computed by a PCE can be represented in one of the following forms:

  o  An ordered set of IP address(es) representing network nodes/links:
 In this case, the PCC needs to convert the IP address(es) into the
 corresponding MPLS labels by consulting its Traffic Engineering
 Database (TED).

  o  An ordered set of SID(s).

  o  An ordered set of both MPLS label(s) and IP address(es): In this
 case, the PCC needs to convert the IP address(es) into the
 corresponding SID(s) by consulting its TED.

   Each SR-ERO object can include both SID and NAI (IP address); this
   case is different from the case 3 above, I suggest if some text can
   be added to make things clearer. 

[Jon] Changed bullet 2 to:

An ordered set of SIDs, with or without the corresponding IP addresses.

[/Jon]

   Section 5.1.1

   (5) Why SHOULD in this text?

  A PCEP speaker SHOULD indicate its support of the function described
  in this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the
  OPEN object with this new PST included in the PST list.

[Jon] For backwards compatibility with shipping implementations that omit it. 
[/Jon]

   Section 6

   (6) Regarding, 

  A PCEP speaker that does not support the SR PCEP capability cannot
  recognize the SR-ERO or SR-RRO subobjects. As such, it MUST send a
  PCEP error with Error-Type = 4 (Not supported object) and Error-Value
  = 2 (Not supported object Type) as per [RFC5440].

   RFC 5440 did not state the behavior for unknown sub-object. My
   suggestion would be - 

  A PCEP speaker that does not support the SR PCEP capability and
  thus cannot recognize the SR-ERO or SR-RRO subobjects, it will
  respond according to the rules for a malformed object as per
  [RFC5440].

[Jon] OK [/Jon]

   Section 7

   (7) Suggest to make Manageability Consideration section as per RFC
   6123

[Jon] Done [/Jon]

   (8) PCEP-Yang should be mentioned in section 7.2

[Jon] Done [/Jon]

   Section 8
 
   (9) Suggest we expand the security consideration section a bit based
   on recent DISCUSSes.

[Jon] Have tweaked it a bit but I think (nay, hope) what we have is OK as it 
passed for the LSP setup type draft. [/Jon]

   Nits
   

   Section 5.3.3

   (2) 
   OLD:
  A PCEP speaker that does not recognize the SR-ERO subobject in PCRep,
  PCInitiate, PCUpd or PCRpt messages MUST reject the entire PCEP
  message and MUST send a PCErr message with Error-Type=3 ("Unknown
  Object") and Error-Value=2 ("Unrecognized object Type") or Error-
  Type=4 ("Not supported object") and Error-Value=2 ("Not supported

[Pce] FW: [Editorial Errata Reported] RFC8233 (5389)

[Jonathan Hardwick]

Just to confirm, this errata is correct.
Jon

-Original Message-
From: RFC Errata System [mailto:rfc-edi...@rfc-editor.org] 
Sent: 13 June 2018 11:50
To: dhruv.i...@gmail.com; bill...@huawei.com; vish...@nanosec.io; 
z...@cisco.com; ke-kum...@kddi.com; db3...@att.com; aretana.i...@gmail.com; 
martin.vigour...@nokia.com; Jonathan Hardwick 
; julien.meu...@orange.com
Cc: dhruv.i...@gmail.com; pce@ietf.org; rfc-edi...@rfc-editor.org
Subject: [Editorial Errata Reported] RFC8233 (5389)

The following errata report has been submitted for RFC8233, "Extensions to the 
Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware 
Label Switched Paths (LSPs)".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5389

--
Type: Editorial
Reported by: DHRUV DHODY 

Section: 3.1

Original Text
-
The METRIC object is defined in Section 7.8 of [RFC5440], comprising 
metric-value and metric-type (T field), and a flags field, comprising a number 
of bit flags (B bit and P bit).  This document defines the following types for 
the METRIC object.

Corrected Text
--
The METRIC object is defined in Section 7.8 of [RFC5440], comprising 
metric-value and metric-type (T field), and a flags field, comprising a number 
of bit flags (B bit and C bit).  This document defines the following types for 
the METRIC object.

Notes
-
The METRIC object (https://tools.ietf.org/html/rfc5440#section-7.8) has 2 flags 
defined - B (Bound) and C (Computed Metric). The P bit is incorrect in the 
original text, it should be C bit.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please use "Reply 
All" to discuss whether it should be verified or rejected. When a decision is 
reached, the verifying party can log in to change the status and edit the 
report, if necessary. 

--
RFC8233 (draft-ietf-pce-pcep-service-aware-13)
--
Title   : Extensions to the Path Computation Element Communication 
Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)
Publication Date: September 2017
Author(s)   : D. Dhody, Q. Wu, V. Manral, Z. Ali, K. Kumaki
Category: PROPOSED STANDARD
Source  : Path Computation Element
Area: Routing
Stream  : IETF
Verifying Party : IESG
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

[Pce] WG adoption poll for draft-wang-pce-pcep-extension-native-ip-01

[Jonathan Hardwick]

Hi PCE WG!

This is the start of a two week poll on making 
draft-wang-pce-pcep-extension-native-ip-01 a PCE working group document.
https://datatracker.ietf.org/doc/draft-wang-pce-pcep-extension-native-ip/

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, June 18.

Many thanks,

Jon and Julien


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

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

[Jonathan Hardwick]

PCE WG - this version addresses the comments received from the IESG.
Deborah - this version should be good to go to the RFC editor.

Many thanks
Jon

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: 04 May 2018 10:40
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-10.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-10.txt
Pages   : 12
Date: 2018-05-04

Abstract:
   A Path Computation Element (PCE) can compute Traffic Engineering (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 the PCE communication protocol (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-10
https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-setup-type-10

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


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

Re: [Pce] Warren Kumari's Discuss on draft-ietf-pce-lsp-setup-type-09: (with DISCUSS)

[Jonathan Hardwick]

Hi Warren, Ignas,

Sorry for the slow reply.  I think Deborah already explained our intent on the 
telechat.  As this document does not actually define any new path setup types 
(just a mechanism to allow multiple path setup types) we can really only make 
generalized statements about the sorts of issues that should be considered if a 
particular new setup type is introduced.  We chose to include a list of 
questions that anyone adding a new path setup type would need to answer.

To clarify this intent, I have made the following change.

OLD
   This document generalises PCEP to allow path setup methods other than
   RSVP-TE to be used by the network.  It is possible that, in a given
   network, multiple path setup methods will be used.  It is also
   possible that not all devices will support the same set of path setup
   methods.  Managing networks that combine multiple path setup methods
   may therefore raise some challenges from a configuration and
   observability point of view.

   Each document that introduces a new path setup type to PCEP must
   include a manageability section.  The manageability section must
   explain how operators can manage PCEP with the new path setup type.
   It must address the following questions, which are generally
   applicable when working with multiple path setup types in PCEP.

NEW
   This document generalises PCEP to allow path setup methods other than
   RSVP-TE to be used by the network (but does not define any new path
   setup types, besides RSVP-TE).  It is possible that, in a given
   network, multiple path setup methods will be used.  It is also
   possible that not all devices will support the same set of path setup
   methods.  Managing networks that combine multiple path setup methods
   may therefore raise some challenges from a configuration and
   observability point of view.

   Each document that defines a new Path Setup Type in the Path Setup
   Type Registry (Section 8.2) must include a manageability section.
   The manageability section must explain how operators can manage PCEP
   with the new path setup type.  It must address the following
   questions, which are generally applicable when working with multiple
   path setup types in PCEP.

END

Best regards
Jon

-Original Message-
From: Warren Kumari [mailto:war...@kumari.net] 
Sent: 05 April 2018 00:24
To: The IESG 
Cc: draft-ietf-pce-lsp-setup-t...@ietf.org; Julien Meuric 
; pce-cha...@ietf.org; julien.meu...@orange.com; 
pce@ietf.org
Subject: Warren Kumari's Discuss on draft-ietf-pce-lsp-setup-type-09: (with 
DISCUSS)

Warren Kumari has entered the following ballot position for
draft-ietf-pce-lsp-setup-type-09: Discuss

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-lsp-setup-type/



--
DISCUSS:
--

Ignas balloted NoObj; I'll be the baddie.

Section 6.  Manageability Considerations says:
---
Each document that introduces a new path setup type to PCEP must
   include a manageability section.  The manageability section must
   explain how operators can manage PCEP with the new path setup type.
   It must address the following questions, which are generally
   applicable when working with multiple path setup types in PCEP.

   o  What are the criteria for when devices will use the new path setup
  type in PCEP, and how can the operator control this?

   o  How can the network be migrated to the new path setup type, and
  are there any backwards compatibility issues that operators need
  to be aware of?

   o  Are paths set up using the new path setup type intended to coexist
  with other paths over the long term and, if so, how is this
  situation managed with PCEP?


So, I see lots of open questions, but no answers to any of these




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

Re: [Pce] WG adoption poll for draft-barth-pce-association-bidir-04

[Jonathan Hardwick]

This poll has ended, with the result that the document will be adopted by the 
PCE working group.

Authors - please could you resubmit the document (without changes) as 
draft-ietf-pce-association-bidir-00.

There were some comments received from Dhruv Dhody and Mike Taillon during 
working group last call.  Authors - please could you ensure that these comments 
are addressed promptly.  If any changes are required, you can include them in 
version -01 of the document.

Many thanks
Jon & Julien


From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: 10 April 2018 15:05
To: pce@ietf.org; draft-barth-pce-association-bi...@ietf.org
Cc: pce-cha...@ietf.org
Subject: WG adoption poll for draft-barth-pce-association-bidir-04

Dear PCE WG

This is the start of a two week poll on making 
draft-barth-pce-association-bidir-04 a PCE working group document.
https://datatracker.ietf.org/doc/draft-barth-pce-association-bidir/

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 Tuesday, April 24.

Many thanks,

Jon and Julien


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

Re: [Pce] Ben Campbell's No Objection on draft-ietf-pce-lsp-setup-type-09: (with COMMENT)

[Jonathan Hardwick]

Hi Ben

Thanks for the comments - please see [Jon] below.

Best regards
Jon

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Ben Campbell
Sent: 03 April 2018 21:00
To: The IESG 
Cc: pce@ietf.org; pce-cha...@ietf.org; draft-ietf-pce-lsp-setup-t...@ietf.org
Subject: [Pce] Ben Campbell's No Objection on draft-ietf-pce-lsp-setup-type-09: 
(with COMMENT)



Substantive Comments:

§1.1: There are at least a few instances of lower case versions of 2119 
keywords. Please consider using the boilerplate from RFC 8174.

[Jon] OK - done




§7:
Doesn't this need to say something about the possible security considerations 
when adding new path setup types ?

[Jon] I added the following in response to a similar comment from Benjamin 
Kaduk.  Do you think this covers it?

NEW
  Note that, if the security mechanisms of [RFC5440] and [RFC8281] are not 
used, then the protocol described by this draft could be attacked in the 
following new way.  An attacker, using a TCP man-in-the-middle attack, could 
inject error messages into the PCEP session when a particular PST is (or is 
not) used.  By doing so, the attacker could potentially force the use of a 
specific PST, which may allow them to subsequently attack a weakness in that 
PST.
END




Editorial Comments and Nits:

§5: "... it MUST consider that the peer suports only ...: I think perhaps 
"consider" should have been "assume"? Also, s/suports/supports.

[Jon] Thanks - fixed.


___
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] Mirja Kühlewind's No Objection on draft-ietf-pce-lsp-setup-type-09: (with COMMENT)

[Jonathan Hardwick]

Hi Mirja

Thanks - I agree with you and have corrected the text.

Cheers
Jon

-Original Message-
From: Mirja Kühlewind [mailto:i...@kuehlewind.net] 
Sent: 03 April 2018 16:06
To: The IESG 
Cc: draft-ietf-pce-lsp-setup-t...@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-lsp-setup-type-09: 
(with COMMENT)

Mirja Kühlewind has entered the following ballot position for
draft-ietf-pce-lsp-setup-type-09: 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-lsp-setup-type/



--
COMMENT:
--

Mostly editorial (and I guess already flagged by Alvaro and Martin):

This sentence (in sec 3 as well as the similar sentence in sec 4) should not 
use normative language because that basically non-sensical: "If a PCEP speaker 
does not recognize the PATH-SETUP-TYPE-CAPABILITY
   TLV, it MUST ignore the TLV in accordance with ([RFC5440])."
Should be instead:
"If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY
   TLV, it will ignore the TLV in accordance with ([RFC5440])."


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

Re: [Pce] Martin Vigoureux's No Objection on draft-ietf-pce-lsp-setup-type-09: (with COMMENT)

[Jonathan Hardwick]

Hi Martin

Yes, we can assume that implementations will use RSVP-TE if they don't support 
this draft.

I think the text you quoted has fallen into the mistake of using normative 
language to specify what is already written in RFC 5440.  Alvaro picked up 
another instance of this.  How about we change to:

   If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY
   TLV, it will ignore the TLV in accordance with [RFC5440].
and:
   If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it will
   ignore the TLV in accordance with [RFC5440], and will use RSVP-TE to set up 
the path.

I have added a clarification to the second sentence above, as you requested.

Cheers
Jon

-Original Message-
From: Martin Vigoureux [mailto:martin.vigour...@nokia.com] 
Sent: 03 April 2018 10:54
To: The IESG 
Cc: draft-ietf-pce-lsp-setup-t...@ietf.org; Julien Meuric 
; pce-cha...@ietf.org; julien.meu...@orange.com; 
pce@ietf.org
Subject: Martin Vigoureux's No Objection on draft-ietf-pce-lsp-setup-type-09: 
(with COMMENT)

Martin Vigoureux has entered the following ballot position for
draft-ietf-pce-lsp-setup-type-09: 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-lsp-setup-type/



--
COMMENT:
--

Document says:
   If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY
   TLV, it MUST ignore the TLV in accordance with ([RFC5440]).
and:
   If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it MUST
   ignore the TLV in accordance with ([RFC5440]).

I am fine with this but it does not say anything, explicitly, on what shall be 
the selected signalling protocol. I guess it will be RSVP-TE because I guess we 
treat this situation in the same way as if there had been no TLV. But since I 
am guessing, I feel it wouldn't hurt to be explicit. On the assumption that my 
guesses are correct, what about adding, for example, the following sentence (or 
anything else you'd judge more appropriate):
   From a signalling protocol selection point of view, this situation is
   treated as if the ... TLV was absent.


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

Re: [Pce] Spencer Dawkins' No Objection on draft-ietf-pce-lsp-setup-type-09: (with COMMENT)

[Jonathan Hardwick]

Hi Spencer

Thanks for your comments.  Please see [Jon] below.

Cheers
Jon

-Original Message-
From: Spencer Dawkins [mailto:spencerdawkins.i...@gmail.com] 
Sent: 03 April 2018 03:23
To: The IESG 
Cc: draft-ietf-pce-lsp-setup-t...@ietf.org; Julien Meuric 
; pce-cha...@ietf.org; julien.meu...@orange.com; 
pce@ietf.org
Subject: Spencer Dawkins' No Objection on draft-ietf-pce-lsp-setup-type-09: 
(with COMMENT)


I'll let you folks work with Benjamin on this, but I echo his concern about the 
level of specification covering sub-TLVs (Spencer's summary: "not much 
specification").  As a related comment, I note that not defining any sub-TLVs 
in this document prevents the authors from giving any examples of what sub-TLVs 
might be appropriate, which would have been helpful for me in both the Abstract 
and Introduction.

(I usually prefer clues about whether the reader should be reading a 
specification or not. It would be easier for me to know whether this document 
is relevant to me, if I knew what kinds of sub-TLVs were envisioned, even if 
only a couple of examples were provided. But do the right thing, of course)

[Jon] I have proposed an update to Benjamin.  The draft does not need any 
sub-TLVs, hence there are no examples, which has been a frequent pattern in PCE 
RFCs since the working group got started!  Having said that, we could 
immediately point to the first real example of a PST sub-TLV by providing an 
informative reference to draft-ietf-pce-segment-routing.  I don't see a problem 
doing this as the documents were always intended to be published together.  How 
about

OLD
  This document does not define any sub-TLVs.
NEW
  This document does not define any sub-TLVs; an example can be found in 
[I-D.ietf-pce-segment-routing].
END


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

Re: [Pce] Benjamin Kaduk's No Objection on draft-ietf-pce-lsp-setup-type-09: (with COMMENT)

[Jonathan Hardwick]

Hi Benjamin

Thanks for the comments - please see [Jon] below.

Cheers
Jon


-Original Message-
From: Benjamin Kaduk [mailto:ka...@mit.edu] 
Sent: 02 April 2018 19:20
To: The IESG 
Cc: draft-ietf-pce-lsp-setup-t...@ietf.org; Julien Meuric 
; pce-cha...@ietf.org; julien.meu...@orange.com; 
pce@ietf.org
Subject: Benjamin Kaduk's No Objection on draft-ietf-pce-lsp-setup-type-09: 
(with COMMENT)



I'm concerned about defining the space for optional sub-TLVs in 
PATH-SETUP-TYPE-CAPABILITY but not giving much description of how future 
sub-TLVs would work (since none are currently defined). Is there expected to be 
a one-to-one mapping from PST to sub-TLV, or one-to-many, or something else? If 
a given sub-TLV can be associated with more than one PST, some rules would need 
to be specified for how that mapping works, what dependency there is on the 
order in which sub-TLVs appear in the message, etc.  I am not balloting DISCUSS 
because I suspect the intent is for each sub-TLV to correspond to exactly one 
PST, in which case the behavior is pretty easy.  But I would like to see more 
description of how this is expected to work.

[Jon] The intent is for zero or one sub-TLV per path setup type, with each 
sub-TLV applying to exactly one path setup type.  How about this change:

OLD
  A list of sub-TLVs associated with the supported PSTs.
NEW
  A list of sub-TLVs associated with the supported PSTs.  Each PST has zero or 
one sub-TLVs associated with it, and each sub-TLV is associated with exactly 
one PST.
END


Both new TLVs have 'Reserved' fields that MUST be set to zero.  Should they be 
ignored on receipt (to allow for potential future use as an extension) or can 
the receiver validate that they are zero?

[Jon] Yes they should be ignored on receipt - fixed.



The Security Considerations defer to RFCs 5440 and 8281, which (as the secdir 
review notes) is mostly okay. RFC 5440 does have a long discussion of the value 
of TCP authentication, but IIUC it does not mandate that TCP authentication be 
used.  That would leave open the possibility that an attacker (e.g., TCP MITM) 
could generate error messages when a particular PST is used, potentially 
forcing the use of a different PST, and this attacker capability seems to be 
new in this document.  As such, it would merit a mention in the Security 
Considerations. (This attack only becomes relevant in the face of some 
additional weakness or flaw in a PST that makes forcing its use advantageous to 
the attacker for other reasons.)

[Jon] How about we add the following to the security considerations?

NEW
  Note that, if the security mechanisms of [RFC5440] and [RFC8281] are not 
used, then the protocol described by this draft could be attacked in the 
following new way.  An attacker, using a TCP man-in-the-middle attack, could 
inject error messages into the PCEP session when a particular PST is (or is 
not) used.  By doing so, the attacker could potentially force the use of a 
specific PST, which may allow them to subsequently attack a weakness in that 
PST.
END


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

Re: [Pce] Alvaro Retana's No Objection on draft-ietf-pce-lsp-setup-type-09: (with COMMENT)

[Jonathan Hardwick]

Thanks for the comments, Alvaro.  Please see [Jon] below.

Cheers
Jon

-Original Message-
From: Alvaro Retana [mailto:aretana.i...@gmail.com] 
Sent: 02 April 2018 19:19
To: The IESG 
Cc: draft-ietf-pce-lsp-setup-t...@ietf.org; Julien Meuric 
; pce-cha...@ietf.org; julien.meu...@orange.com; 
pce@ietf.org
Subject: Alvaro Retana's No Objection on draft-ietf-pce-lsp-setup-type-09: 
(with COMMENT)



(1) The Length field in S3 has no units.  I'm sure people can guess it is in 
bytes, from the rest of the description, but it should be explicit.

[Jon] OK, fixed.



(2) The Reserved fields "MUST be set to zero".  What happens if they're not? 
Typically they are also ignored by the receiver...

[Jon] New text: "Its reserved field MUST be set to zero by the sender and MUST 
be ignored by the receiver."



(3) S3: "Each sub-TLV MUST obey the rules for TLV formatting defined in 
([RFC5440]).  That is, each sub-TLV MUST be padded to a four byte alignment, 
and the length field of each sub-TLV MUST NOT include the padding bytes."  The 
first sentence is ok.  The second one tries to paraphrase what rfc5440 says -- 
but rfc5440 doesn't say that, it doesn't even use Normative language!  This is 
the text from rfc5440:

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

(3a) The text in this document shouldn't use Normative language to describe 
what rfc5440 says and specifies.

(3b) Note that the text from rfc5440 (specifically the part about "padding is 
not included in the Length field") is not aligned with the description of the 
Length field in this document: "The TLV Length field MUST be equal to the size 
of the appended sub-TLVs plus the size of the PST list (rounded up to the 
nearest multiple of four) plus four bytes."  Rounding up includes the padding.

[Jon] Yes, this area is a bit awkward, and you are correct to point out that 
this wording is flawed.  I agree that any trailing padding bytes ought not to 
be included in the length field, for consistency with the rules in RFC 5440.  
However, we do have to include any intermediate padding bytes in the length.  
For example, if the TLV looked like this:

[TLV] [padding1] [Sub-TLV A] [padding2] [Sub-TLV B] [padding3]

[padding1] pads the PST list to a multiple of 4 bytes.
[padding2] pads sub-TLV A to a multiple of 4 bytes.
[padding3] pads sub-TLV B to a multiple of 4 bytes.

The overall TLV length needs to include padding1 and padding2, but not padding 
3.  The reason: an implementation not recognising this TLV needs to be able to 
skip over it and ignore it.  If the overall length did not include padding1 or 
padding2 then that implementation would skip right into the middle of the 
sub-TLV list and get lost.

I propose the following text, which hopefully addresses your comment.

OLD
  That is, each sub-TLV MUST be padded to a four byte alignment, and the length 
field of each sub-TLV MUST NOT include the padding bytes.
  [...]
  The TLV Length field MUST be equal to the size of the appended sub-TLVs plus 
the size of the PST list (rounded up to the nearest multiple of four) plus four 
bytes.
NEW
  That is, each sub-TLV is padded to a four byte alignment, and the length 
field of each sub-TLV does not include the padding bytes.
  [...]
  If there are no sub-TLVs, then the TLV length field MUST be equal to four 
bytes plus the size of the PST list, excluding any padding bytes.  If there are 
sub-TLVs then the TLV Length field MUST be equal to four bytes plus the size of 
the PST list (rounded up to the nearest multiple of four) plus the size of the 
appended sub-TLVs excluding any padding bytes in the final sub-TLV.
END



(4) S6: "Each document that introduces a new path setup type to PCEP must 
include a manageability section."  Why is a Normative "MUST" not used?

[Jon] This is a requirement on document writers, not on implementations, so I 
thought a normative MUST would not be appropriate here.



(5) rfc6123 is a Historic document.  Maybe a reference to rfc5706 is more 
appropriate (even in addition to rfc6123).

[Jon] Yes, I agree. Fixed.



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

[Pce] WG adoption poll for draft-barth-pce-association-bidir-04

[Jonathan Hardwick]

Dear PCE WG

This is the start of a two week poll on making 
draft-barth-pce-association-bidir-04 a PCE working group document.
https://datatracker.ietf.org/doc/draft-barth-pce-association-bidir/

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 Tuesday, April 24.

Many thanks,

Jon and Julien


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

Re: [Pce] WG adoption poll for draft-ananthakrishnan-pce-stateful-path-protection-05

[Jonathan Hardwick]

This poll has ended, with the result that the document will be adopted by the 
PCE working group.

Authors - please could you resubmit the document (without changes) as 
draft-ietf-pce-stateful-path-protection-00.

There were some comments received from Greg Mirsky during working group last 
call.  Authors - please could you ensure that these comments are addressed 
promptly.  If any changes are required, you can include them in version -01 of 
the document.

Many thanks
Jon

From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: 27 March 2018 12:10
To: pce@ietf.org; draft-ananthakrishnan-pce-stateful-path-protect...@ietf.org
Cc: pce-cha...@ietf.org
Subject: WG adoption poll for 
draft-ananthakrishnan-pce-stateful-path-protection-05

Dear PCE WG

This is the start of a two week poll on making 
draft-ananthakrishnan-pce-stateful-path-protection-05 a PCE working group 
document.
https://datatracker.ietf.org/doc/draft-ananthakrishnan-pce-stateful-path-protection/

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 Tuesday, April 10.

Many thanks,

Jon and Julien


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

[Pce] FW: New Version Notification for draft-ietf-pce-lsp-setup-type-09.txt

[Jonathan Hardwick]

This version addresses comments received from the security, OPS and GENART 
directorates during IETF last call.
Jon

-Original Message-
From: internet-dra...@ietf.org [mailto:internet-dra...@ietf.org] 
Sent: 27 March 2018 13:43
To: Siva Sivabalan <ms...@cisco.com>; Jonathan Hardwick 
<jonathan.hardw...@metaswitch.com>; Jonathan Hardwick 
<jonathan.hardw...@metaswitch.com>; Robert Varga <n...@hq.sk>; Ina Minei 
<inami...@google.com>; Jeff Tantsura <jefftant.i...@gmail.com>
Subject: New Version Notification for draft-ietf-pce-lsp-setup-type-09.txt


A new version of I-D, draft-ietf-pce-lsp-setup-type-09.txt
has been successfully submitted by Jon Hardwick and posted to the IETF 
repository.

Name:   draft-ietf-pce-lsp-setup-type
Revision:   09
Title:  Conveying path setup type in PCEP messages
Document date:  2018-03-27
Group:  pce
Pages:  11
URL:
https://www.ietf.org/internet-drafts/draft-ietf-pce-lsp-setup-type-09.txt
Status: https://datatracker.ietf.org/doc/draft-ietf-pce-lsp-setup-type/
Htmlized:   https://tools.ietf.org/html/draft-ietf-pce-lsp-setup-type-09
Htmlized:   
https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-setup-type
Diff:   
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-setup-type-09

Abstract:
   A Path Computation Element (PCE) can compute Traffic Engineering (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 the PCE communication protocol (PCEP) to
   allow support for different path setup methods over a given PCEP
   session.


  


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.

The IETF Secretariat

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

[Pce] WG adoption poll for draft-ananthakrishnan-pce-stateful-path-protection-05

[Jonathan Hardwick]

Dear PCE WG

This is the start of a two week poll on making 
draft-ananthakrishnan-pce-stateful-path-protection-05 a PCE working group 
document.
https://datatracker.ietf.org/doc/draft-ananthakrishnan-pce-stateful-path-protection/

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 Tuesday, April 10.

Many thanks,

Jon and Julien


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

Re: [Pce] Opsdir last call review of draft-ietf-pce-lsp-setup-type-08

[Jonathan Hardwick]

Hi Dan

I have written the following text to address the general question of 
manageability of different LSP Setup types and plan to include it in the next 
revision of this draft.  Please let me know if you have any comments.

NEW (insert before “Security Considerations” section)

6. Manageability Considerations

This document generalises PCEP to allow path setup methods other than RSVP-TE 
to be used by the network.  It is possible that, in a given network, multiple 
path setup methods will be used.  It is also possible that not all devices will 
support the same set of path setup methods.  Managing networks that combine 
multiple path setup methods may therefore raise some challenges from a 
configuration and observability point of view.

Each document that introduces a new path setup type to PCEP must include a 
manageability section.  The manageability section must explain how operators 
can manage PCEP with the new path setup type.  It must address the following 
questions, which are generally applicable when working with multiple path setup 
types in PCEP.

  *   What are the criteria for when devices will use the new path setup type 
in PCEP, and how can the operator control this?
  *   How can the network be migrated to the new path setup type, and are there 
any backwards compatibility issues that operators need to be aware of?
  *   Are paths set up using the new path setup type intended to coexist with 
other paths over the long term and, if so, how is this situation managed with 
PCEP?
  *   How can operators verify the correct operation of PCEP in the network 
with respect to the new path setup type?  Which fault conditions must be 
reported to the operators?
  *   Are there any existing management interfaces (such as YANG models) that 
must be extended to model the operation of PCEP in the network with respect to 
the new path setup type?

See [RFC 6123] for further guidance on how to write manageability sections in 
PCEP standards-track documents.

END NEW

+ [RFC 6123] is added as an informative reference.

Many thanks
Jon



From: Dan Romascanu [mailto:droma...@gmail.com]
Sent: 03 March 2018 10:57
To: Jonathan Hardwick <jonathan.hardw...@metaswitch.com>
Cc: ops-...@ietf.org; pce@ietf.org; i...@ietf.org; 
draft-ietf-pce-lsp-setup-type@ietf.org
Subject: Re: Opsdir last call review of draft-ietf-pce-lsp-setup-type-08



On Fri, Mar 2, 2018 at 7:15 PM, Jonathan Hardwick 
<jonathan.hardw...@metaswitch.com<mailto:jonathan.hardw...@metaswitch.com>> 
wrote:
Hi Dan

Many thanks for the review.  Please see my replies below - look for "Jon>".

Best regards
Jon


-Original Message-
From: Dan Romascanu [mailto:droma...@gmail.com<mailto:droma...@gmail.com>]
Sent: 28 February 2018 15:23
To: ops-...@ietf.org<mailto:ops-...@ietf.org>
Cc: pce@ietf.org<mailto:pce@ietf.org>; i...@ietf.org<mailto:i...@ietf.org>; 
draft-ietf-pce-lsp-setup-type@ietf.org<mailto:draft-ietf-pce-lsp-setup-type@ietf.org>;
 droma...@gmail.com<mailto:droma...@gmail.com>
Subject: Opsdir last call review of draft-ietf-pce-lsp-setup-type-08

Reviewer: Dan Romascanu
Review result: Has Issues

I am the assigned OPS-DIR reviewer for this draft. The OPS DIrectorate reviews 
a great part of the IETF documents being processed by the IESG for the OPS ADs.
Please treat with these comments as with all other IETF LC comments. Please 
wait for direction from your document shepherd or AD before posting a new 
version of the draft.

This document is an extension of PCEP to allow for other LSP setup methods than 
RSVP-TE to be used. For this purpose it defines two new TLVs and details their 
operation.

This is an extension of an existing protocol. An RFC 5706 review applies.

While the document seems to be focused to developers and implementers of PCEP, 
it is not clear what is the impact from an operational point of view and there 
are no considerations related to manageability. Maybe these are detailed in 
other documents - in this case a reference would be useful.

Jon> The context of this draft is that it generalizes PCEP so that the protocol 
is not dependent solely on using RSVP-TE as a method for setting up paths.  The 
document performs this generalization, positioning RSVP-TE as one possible 
method of path setup, but it stops short of defining any other path setup 
methods.  Since no new path setup methods are being introduced, the 
manageability and operational considerations do not really change.  We have 
simply generalized a part of PCEP to allow other path setup methods (and their 
manageability considerations) to be defined elsewhere.


Here are a few issues. For a complete list of questions, see Annex A in RFC 
5706.

1. Why were these extensions needed? Do they improve efficiency? Are there 
classes of devices that do not support RSVP-TE and need the new methods?

Jon> This is a pre-requisite step to allow PCEP to be used in networks that 

Re: [Pce] WG adoption poll for draft-li-pce-pcep-flowspec-03

[Jonathan Hardwick]

This poll has ended, with the result that this document will be adopted by the 
PCE working group.

Authors, once the I-D submission tool has reopened, please resubmit the 
document as draft-ietf-pce-pcep-flowspec-00.

Best regards
Jon and Julien


From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: 20 February 2018 13:34
To: pce@ietf.org
Cc: pce-cha...@ietf.org; draft-li-pce-pcep-flows...@ietf.org
Subject: WG adoption poll for draft-li-pce-pcep-flowspec-03

Dear PCE WG

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

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 Tuesday, March 6.

Many thanks,

Jon and Julien

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

Re: [Pce] Genart last call review of draft-ietf-pce-lsp-setup-type-08

[Jonathan Hardwick]

Hi Roni

Many thanks for the review.  You are right, in this case we meant "IETF 
Review".  I will update the document.

Cheers
Jon

-Original Message-
From: Roni Even [mailto:ron.even@gmail.com] 
Sent: 26 February 2018 14:55
To: gen-...@ietf.org
Cc: pce@ietf.org; i...@ietf.org; draft-ietf-pce-lsp-setup-type@ietf.org
Subject: Genart last call review of draft-ietf-pce-lsp-setup-type-08

Reviewer: Roni Even
Review result: Almost Ready

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-lsp-setup-type-??
Reviewer: Roni Even
Review Date: 2018-02-26
IETF LC End Date: 2018-03-06
IESG Telechat date: 2018-04-05

Summary:
The document is almost ready for publication as standard track RFC Major issues:

Minor issues:
1. in section 7.2 "The allocation policy for this new registry  should be by 
IETF Consensus" why not use one of RFC8126 well known policies?

Nits/editorial comments:


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

Re: [Pce] Opsdir last call review of draft-ietf-pce-lsp-setup-type-08

[Jonathan Hardwick]

Hi Dan

Many thanks for the review.  Please see my replies below - look for "Jon>".

Best regards
Jon


-Original Message-
From: Dan Romascanu [mailto:droma...@gmail.com] 
Sent: 28 February 2018 15:23
To: ops-...@ietf.org
Cc: pce@ietf.org; i...@ietf.org; draft-ietf-pce-lsp-setup-type@ietf.org; 
droma...@gmail.com
Subject: Opsdir last call review of draft-ietf-pce-lsp-setup-type-08

Reviewer: Dan Romascanu
Review result: Has Issues

I am the assigned OPS-DIR reviewer for this draft. The OPS DIrectorate reviews 
a great part of the IETF documents being processed by the IESG for the OPS ADs.
Please treat with these comments as with all other IETF LC comments. Please 
wait for direction from your document shepherd or AD before posting a new 
version of the draft.

This document is an extension of PCEP to allow for other LSP setup methods than 
RSVP-TE to be used. For this purpose it defines two new TLVs and details their 
operation.

This is an extension of an existing protocol. An RFC 5706 review applies.

While the document seems to be focused to developers and implementers of PCEP, 
it is not clear what is the impact from an operational point of view and there 
are no considerations related to manageability. Maybe these are detailed in 
other documents - in this case a reference would be useful.

Jon> The context of this draft is that it generalizes PCEP so that the protocol 
is not dependent solely on using RSVP-TE as a method for setting up paths.  The 
document performs this generalization, positioning RSVP-TE as one possible 
method of path setup, but it stops short of defining any other path setup 
methods.  Since no new path setup methods are being introduced, the 
manageability and operational considerations do not really change.  We have 
simply generalized a part of PCEP to allow other path setup methods (and their 
manageability considerations) to be defined elsewhere.


Here are a few issues. For a complete list of questions, see Annex A in RFC 
5706.

1. Why were these extensions needed? Do they improve efficiency? Are there 
classes of devices that do not support RSVP-TE and need the new methods?

Jon> This is a pre-requisite step to allow PCEP to be used in networks that use 
segment routing to define paths.  Segment routing (SR) is a distinct path setup 
method from RSVP-TE.  It is possible that SR devices might not support RSVP-TE. 
 The WG took the decision to write one draft to generalize PCEP (this draft) 
and then to write a separate draft to explain how this generalization is 
applied to segment routing (draft-ietf-pce-segment-routing).  The latter draft 
is post-WGLC in the PCE WG and should be catching up with 
draft-ietf-pce-lsp-setup-type shortly.  Why did we not combine 
draft-ietf-pce-lsp-setup-type and draft-ietf-pce-segment-routing?  Suppose we 
invent a third path setup type in future.  It is clearer for implementers that 
they only need to implement the procedures of draft-ietf-pce-lsp-setup-type in 
order to prepare the ground for this third path setup type - having one 
combined draft incorporating SR as well would make this harder.


2. How are the new TLVs going to be deployed and managed? Does an operator have 
the option of selecting one LSP setup method or the other? How and what are the 
criteria of selections?

3. There is no discussion about initial setup and configuration. Are there any 
initial configuration parameters? If yes, how are they set up?

4. Are there any backwards compatibility and migration path issues operators 
should be aware about?

5. What is the expected impact on network operation?

6. How is correct operation visible to the operators? Are there any fault 
conditions that need to be reported to operators?

7. Are there any existing management interfaces (e.g. YANG models) that need to 
be defined or extended?

Jon> I think the above points 2..7 are really good questions to be asking about 
each new path setup type that we introduce.  In a draft that is agnostic of 
path setup type, I don't really know how to answer them.  For example, I would 
expect draft-ietf-pce-segment-routing to answer these questions in the context 
of configuring and enabling PCEP for segment routing.  Do you think that there 
is something we can usefully say about working with multiple path setup types 
in general?

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

Re: [Pce] Building the PCE Agenda for IETF 101

[Jonathan Hardwick]

Hi Adrian

Thanks for the suggestion and for the gentle reminder.  I have just polled for 
adoption of this draft.  Given this, it does not sound like you will need this 
slot, after all.  Of course, if the poll throws up issues that must be 
discussed, or something else turns up, please feel free to renew your request.

Best regards
Jon and Julien


-Original Message-
From: Adrian Farrel [mailto:adr...@olddog.co.uk] 
Sent: 19 February 2018 16:35
To: pce-cha...@ietf.org; pce@ietf.org
Subject: RE: [Pce] Building the PCE Agenda for IETF 101

Hi Julien, all.

> - the draft(s) you want to discuss,

draft-li-pce-pcep-flowspec-03.txt

> - the expected presenter name,

Adrian Farrel

> - the requested duration, including question time as part of the slot,

10 minutes

> - the reason why you need face-to-face time as opposed to using the 
> mailing list (open 24/7).

Weeell, we don't actually have anything to discuss, but we figure that it is 
now four months since there was general support for moving this forward as WG 
work, and while we have been working on the text and on implementation, we 
don't seem to have got any traction with the WG chairs. So, we would spend our 
10 minutes helping the chairs prioritise thee WG work :-)

Of course, if the WG would like a reminder of what this work is and why it is 
important, we would happily deliver that. OTOH, rtfm.

A

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

[Pce] WG adoption poll for draft-li-pce-pcep-flowspec-03

[Jonathan Hardwick]

Dear PCE WG

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

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 Tuesday, March 6.

Many thanks,

Jon and Julien

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

Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11

[Jonathan Hardwick]

Adrian

Many thanks for your review.  The authors will need to discuss your comments, 
and then we'll get back to you.

Best regards
Jon


-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Adrian Farrel
Sent: 18 January 2018 22:55
To: 'Julien Meuric' ; pce@ietf.org
Subject: Re: [Pce] WG Last Call for draft-ietf-pce-segment-routing-11

Hi,

I reviewed this draft as part of the WG last call.

It is important work and needs to be published as an RFC.

However, there are some places where the clarity could be improved and so 
increase the chances of interoperable implementations.

I have clustered the nits at the end of this email.

Thanks,
Adrian

=

Section 3

   In SR networks, an ingress node of an SR path appends all outgoing
   packets with an SR header consisting of a list of SIDs (or MPLS
   labels in the context of this document).

Conventionally, "append" means to add to the end (although it can mean to 
arbitrarily add). I think you want "prepend" although the sentence is still 
clumsy and might be better as...

   In an SR network, the ingress node of an SR path prepends an SR 
   header to all outgoing packets.  The SR header consists of a list of
   SIDs (or MPLS labels in the context of this document).

---

Section 3 (same paragraph)


I think this is not quite true. Well, it is true that signaling is not needed, 
but not true that the header has all the necessary information in all cases - 
the IGP may need to resolve a path to a Node SID. Perhaps...

   The header has all
   necessary information so that in combination with the information 
   distributed by the IGP, the packets can be guided from the ingress
   node to the egress node of the path, and hence there is no need for
   any signaling protocol.

---

Section 3 para 2 has the same "append" problem, and also overstates what is 
carried in the ERO. Suggest...

OLD
   In a PCEP session, LSP information is carried in the Explicit Route
   Object (ERO), which consists of a sequence of subobjects.  Various
   types of ERO subobjects have been specified in [RFC3209], [RFC3473],
   and [RFC3477].  In SR networks, an ingress node of an SR path appends
   all outgoing packets with an SR header consisting of a list of SIDs
   (or MPLS labels in the context of this document).  SR-TE LSPs
   computed by a PCE can be represented in one of the following forms:
NEW
   In PCEP messages, LSP route information is carried in the Explicit 
   Route Object (ERO), which consists of a sequence of subobjects.  
   Various ERO subobjects have been specified in [RFC3209], [RFC3473],
   and [RFC3477].  In SR networks, an ingress node of an SR path 
   prepends an SR header to all outgoing packets.  The SR header 
   consists of a list of SIDs (or MPLS labels in the context of this
   document).  SR-TE paths computed by a PCE can be represented in one
   of the following forms:
END


However, I wonder why you have picked just those three RFCs to reference.
Many other RFCs also define ERO subobjects. The full list is
RFC3209
RFC3473
RFC3477
RFC4874
RFC5520
RFC5553
RFC7570
RFC7898
RFC7897
...but listing them all would be odd.

---

Section 3

   o  An ordered set of IP address(es) representing network nodes/links:
  In this case, the PCC needs to convert the IP address(es) into the
  corresponding MPLS labels by consulting its Traffic Engineering
  Database (TED).

The PCC does not have a TED. It does have an LSDB as distributed by the IGP and 
this will contain the SRGBs and SIDs that allow labels to be computed.

But I am surprised that this work is offloaded to the PCC since the PCE has all 
the information to do this task. Why did the WG want to add this option?

And then...

   o  An ordered set of SID(s)

s/SID(s)/SIDs/

This list of SIDs would need to be converted to labels by the PCC by applying 
the SRGB offsets. Again, why make the PCC do this?

And finally...

   o  An ordered set of both MPLS label(s) and IP address(es): In this
  case, the PCC needs to convert the IP address(es) into the
  corresponding SID(s) by consulting its TED.

This mixture of the previous two cases seems to compound the level of 
complexity. Can't the PCE just know it is making an SR path and supply a list 
of MPLS labels corresponding to the SIDs?

---

5.1.1 ---> 9

You should probably set up a registry for other SR PCE Capability sub- TLV 
flags.

---
 
5.1.2 > 6

   If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a
   PST list containing PST=1, but the SR-PCE-CAPABILITY sub-TLV is
   absent, then the PCEP speaker MUST send a PCErr message with Error-
   Type 10 (Reception of an invalid object) and Error-Value TBD1 (to be
   assigned by IANA) (Missing PCE-SR-CAPABILITY sub-TLV) and MUST then
   close the PCEP session.

Suppose an implementation receives an Open with PST=1 but doesn't understand 
(or doesn't support) that 

Re: [Pce] IPR Check on draft-ietf-pce-segment-routing

[Jonathan Hardwick]

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

Cheers
Jon

-Original Message-
From: Julien Meuric [mailto:julien.meu...@orange.com] 
Sent: 15 January 2018 09:41
To: draft-ietf-pce-segment-rout...@ietf.org
Cc: pce@ietf.org
Subject: IPR Check on draft-ietf-pce-segment-routing

Dear authors of draft-ietf-pce-segment-routing,

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-segment-routing 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.

Thanks,

Julien

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

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

[Jonathan Hardwick]

This version addresses Daniele's comments from the routing directorate review.

Best regards
Jon

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: 16 January 2018 10:52
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-08.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-08.txt
Pages   : 10
Date: 2018-01-16

Abstract:
   A Path Computation Element can compute Traffic Engineering (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-08
https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-setup-type-08

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


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

Re: [Pce] RtgDir review: draft-ietf-pce-lsp-setup-type-07

[Jonathan Hardwick]

Hi Daniele

Many thanks for the review.  Please see my replies below in  … .

Best regards
Jon


From: Daniele Ceccarelli [mailto:daniele.ceccare...@ericsson.com]
Sent: 10 January 2018 10:41
To:  (rtg-...@ietf.org) 
Cc: rtg-...@ietf.org; pce@ietf.org; draft-ietf-pce-lsp-setup-type@ietf.org
Subject: RtgDir review: draft-ietf-pce-lsp-setup-type-07


Hello,



I have been selected as the Routing Directorate reviewer for this draft. The 
Routing Directorate seeks to review all routing or routing-related drafts as 
they pass through IETF last call and IESG review, and sometimes on special 
request. The purpose of the review is to provide assistance to the Routing ADs. 
For more information about the Routing Directorate, please see 
​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir



Although these comments are primarily for the use of the Routing ADs, it would 
be helpful if you could consider them along with any other IETF Last Call 
comments that you receive, and strive to resolve them through discussion or by 
updating the draft.



Document: draft-ietf-pce-lsp-setup-type-07

Reviewer: Daniele Ceccarelli

Review Date: 2018-01-10

IETF LC End Date: date-if-known

Intended Status: Standards Track



Summary:

I have some minor concerns about this document that I think should be resolved 
before publication.



Comments:

The draft is a bit confusing on some aspects. I had to read it again a couple 
of times to understand that 2 TLVs are defined (probably my fault). If you 
could make it clearer in the intro that 2 TLVs are defined each of which with a 
precise scope, that would make things easier.



 How about I add the following in between the second and third paragraphs 
of the introduction?



NEW
   So far, PCEP and its extensions have assumed that the TE paths are
   label switched and are established via the RSVP-TE protocol.
   However, other methods of LSP setup are possible in the PCE
   architecture (see [RFC4655] and [RFC4657]).  This document generalizes
   PCEP to allow other LSP setup methods to be used.  It defines two new
   TLVs, as follows.
  -  The PATH-SETUP-TYPE-CAPABILITY TLV, which allows a PCEP speaker to
  announce which LSP setup methods it supports.
  -  The PATH-SETUP-TYPE TLV, which allows a PCEP speaker to specify
  which setup method should be used for a given LSP.

END NEW



I’ll then tweak the remaining paragraphs in the introduction to fit in with 
this preamble.  Does that sound OK?





Also the list of the PSTs is a bit confusing. Since each PST is a byte field 
why don’t you adopt and encoding like the one used in RFC7138 section 4.1.1. 
for the muxing stages? You could encode the PST values like the Stage#1…Stage# 
below.


   0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Type = 1 (Unres-fix)   | Length|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Signal Type  | Num of stages |T|S| TSG | Res |Priority   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Stage#1|  ...  |   Stage#N |Padding|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Unreserved ODUj at Prio 0| . |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Unreserved ODUj at Prio 7| Unreserved Padding|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 3: Bandwidth Sub-TLV -- Type 1



 The PST encoding is like the example you quoted i.e. a list of bytes 
padded with zeros plus a field saying how many PSTs are in the list.  If I 
re-draw the diagram like this, does it look better to you?


   0   1   2   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Type (TBD1) | Length|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   Reserved|  Num of PSTs  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | PST#1 |  ...  | PST#N |Padding|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |   |
  //   Optional sub-TLVs (variable)  //
  |   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

 Figure 1: PATH-SETUP-TYPE-CAPABILITY TLV







Major Issues:

No major issues found.



Minor Issues:

  *   Section 3: 

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

[Jonathan Hardwick]

Hi All

This version addresses the comments Julien made in his shepherd's review during 
the 2nd WGLC.

Cheers
Jon


-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: 19 December 2017 13:41
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-07.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-07.txt
Pages   : 10
Date: 2017-12-19

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-07
https://datatracker.ietf.org/doc/html/draft-ietf-pce-lsp-setup-type-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-lsp-setup-type-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

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

Re: [Pce] Shepherd's Review of draft-ietf-pce-lsp-setup-type-06

[Jonathan Hardwick]

Hi Julien

Many thanks for the speedy review!  Please see a few answers below, marked with 
[Jon].  (All other comments are accepted.)
I will hold the document mark-ups until WGLC ends.

Cheers
Jon


-Original Message-
From: Julien Meuric [mailto:julien.meu...@orange.com] 
Sent: 21 November 2017 17:08
To: draft-ietf-pce-lsp-setup-t...@ietf.org
Cc: pce@ietf.org
Subject: Shepherd's Review of draft-ietf-pce-lsp-setup-type-06

Hi,

Thank you for this new version of the I-D, it has greatly improved and 
clarifies former loose zones. Please find my review below.

--
Abstract
---
- s/traffic engineering paths (TE paths)/Traffic Engineering paths (TE paths)/
- I wonder about the expansion of "TE path" above: why not "Engineered"
instead of "Engineering"? (This is global to the I-D, and beyond... RFC 
Editor's list includes both.)
- s/label switched paths (LSPs)/Label Switched Paths (LSPs)/
--
Status
---
- "https://; was introduced in -05, but has now disappeared.
--
1. Introduction
---
- s/Path Computation Element Protocol/Path Computation Element communication 
Protocol/

- OLD
path setup type needs to be either explicitly indicated or implied in the 
appropriate PCEP messages (when necessary)...
   NEW
path setup type needs to be explicitly indicated in the appropriate PCEP 
messages, unless RSVP-TE type is meant (omission implying this type)...
--
3. Path Setup Type Capability TLV
---
- s/Initialization phase/initialization phase/
- I though the discussion on the list was about using a bitmap to identify 
supported PSTs: any reason why it is now a list of raw octets?

[Jon] We did discuss a bit field on the list.  The PST field is an 8-bit value, 
so a naive implementation of a bit field would use 32 bytes.  This seems 
wasteful given we only have two values defined so far (possibly 3 with the 
up-coming IPv6-SR draft).  I then looked at some schemes to shorten the bit 
field, e.g. by truncating it, but the result seemed more complicated to encode 
than just listing the path setup types.  (I also didn't much like having a PST 
known both by a value and by a bit field position.)  So I opted to list the 
PSTs.  IMO it's not a problem given the low number of PSTs we expect (could be 
a case of famous last words!)  What do you think of this tradeoff?


- The definition of length and padding mixes the words "octet" and "bytes", 
depending on the field (probably to due to text coming from RFC 5440). 
Consistency would be welcome (the comment appears to be applicable beyond this 
section).

[Jon] Let's standardize on bytes, per RFC 5440.



--
4. Path Setup Type TLV
---
- Figure 2 explicitly includes the codepoint for the "Type" (28), the "Length" 
field should be treated similarly (4).
- The last sentence of section 4 puzzles me. If the PATH-SETUP-TYPE TLV is not 
supported, the PCEP peer cares little if it was "recognized" or not. If both 
sub-cases are commonly handled by ignoring, an implementation always including 
the RSVP-TE PST will be able to interwork with an implementation knowing about 
the TLV without actually supporting it; the current text turns this situation 
into an error.
(Note also that RFC 5440 does not distinguish unrecognized and unsupported in 
TLV processing rules.)

[Jon] I think you are right. The same also applies to the final sentence of 
section 3, I believe.


- In case my previous comment does not fly, 3 more nits:
  * s/recognizes the TLV but does not support the TLV/recognizes the TLV but 
does not support its use/
  * s/send PCErr/send a PCErr message/
  * Error-Type is 2, would not 4 fit better?
--
5. Operation
---
- s/Initialization phase/initialization phase/
- s/MUST infer/MUST consider/  [explicit => nothing to infer]
- The text says multiple times "unless the intended PST is RSVP-TE, in which 
case it MAY omit the PATH-SETUP-TYPE TLV". This is inconsistent with section 4: 
"It is RECOMMENDED that a PCEP speaker omits the TLV if the PST is RSVP-TE." 
Please choose between MAY and SHOULD, and align.

[Jon] I think our intent is MAY, so we can reword the text in section 4 to "A 
PCEP speaker MAY omit the TLV if the PST is RSVP-TE."



--

Cheers,

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

[Jonathan Hardwick]

Hi Stephane

Many thanks for the comment.  This text is a compromise to accommodate 
implementations of the previous version of the draft that have already been 
deployed.  Those implementations do not send PATH-SETUP-TYPE-CAPABILITY in the 
OPEN.  Instead, they send PCEP-SR-CAPABILITY.  Hence, to interoperate with 
those versions, a new implementation can use the presence of PCEP-SR-CAPABILITY 
to infer support of SR, rather than PATH-SETUP-TYPE-CAPABILITY.  In other 
words, this is for backwards compatibility.  It is discussed explicitly in the 
new version of draft-ietf-pce-segment-routing.

If you think the wording below can be improved for clarity, then please let me 
know!

Cheers
Jon

-Original Message-
From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com] 
Sent: 20 November 2017 15:32
To: Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; pce@ietf.org
Cc: MEURIC Julien IMT/OLN <julien.meu...@orange.com>
Subject: RE: [Pce] I-D Action: draft-ietf-pce-lsp-setup-type-06.txt

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, exp

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

[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

[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' <julien.meu...@orange.com>; Jonathan 
Hardwick <jonathan.hardw...@metaswitch.com>; pce@ietf.org; Dhruv Dhody 
<dhruv.dh...@huawei.com>
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<mailto:pce@ietf.org>
Cc: 
draft-ietf-pce-lsp-setup-t...@ietf.org<mailto:draft-ietf-pce-lsp-setup-t...@ietf.org>;
 
draft-ietf-pce-segment-rout...@ietf.org<mailto: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 pare

Re: [Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints

[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' <julien.meu...@orange.com>; 'Dhruv Dhody' 
<dhruv.dh...@huawei.com>; Jonathan Hardwick <jonathan.hardw...@metaswitch.com>
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<mailto:draft-ietf-pce-pcep-exp-codepoi...@ietf.org>;
 pce@ietf.org<mailto: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<mailto: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

Re: [Pce] draft-ietf-pce-association-diversity: relaxing constraint

[Jonathan Hardwick]

Hi Stephane

I’m not necessarily saying that this is the way to go, but I would like to 
point out the P flag and the I flag in the PCEP common object header.  If a 
constraint can be relaxed, the PCC sends the relevant object(s) with P=0.  If 
the PCE decides to relax a constraint, it includes the relevant object(s) in 
the PCRep with I=1.  Does that change your opinion of whether a suitable 
mechanism for this already exists?

Cheers
Jon


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: 14 November 2017 01:18
To: DUGEON Olivier IMT/OLN ; Daniele Ceccarelli 
; pce@ietf.org
Subject: Re: [Pce] draft-ietf-pce-association-diversity: relaxing constraint

Hi Olivier,

I do not agree with what you mentioned.
The metric object is defined (but not limited to) to set a constraint on the 
metric: what I should optimize for (IGP metric, TE metric, both…) and is there 
a boundary that I should not exceed.
Nothing says that the constraint can be relaxed by the PCE. If a PCE receives a 
computation request or needs to compute a path for an LSP having for instance a 
metric object with type=TE and bound=100. If it cannot found a path, it will 
return NO-PATH without relaxing the constraint. Relaxing the constraint means 
that the PCC allows the PCE to compute a path without using the requested 
constraint if the PCE cannot find a path that fills this constraint.
So in case of the METRIC object and the boundary case, if the PCC allows the 
PCE to relax the constraint, if it does not find a path fitting the boundary, 
it will provide a path exceeding this boundary instead of returning NO-PATH.

Now the METRIC object does not have anything to do with the disjointness. 
Except that we can combine both if needed !

For the disjointness, we have two cases when the PCC allowed the PCE to relax 
the constraint:

  *   The PCE has successfully computed a disjoint path but with a lower 
disjointness type (link instead of node for instance) => this could be seen as 
a partially relaxed constraint and I agree that the state could be sent by 
adding the association group and filling the “computed state” of the 
disjointness in the DISJOINTNESS-INFORMATION TLV (METRIC object has nothing to 
do here).
  *   The PCE cannot compute a disjoint path at all and completely relaxed the 
constraint.

So we do not have any way yet (AFAIK) to tell the PCE that a particular 
constraint can be relaxed (another example is the bandwidth constraint => I do 
not think that it is a good example but why not…).
Then the PCE needs to tell the PCC that it has relaxed a constraint => this can 
be deduced from a “computed state” provided by the PCE for each constraint, but 
a more clear information may be better (possibly in addition to the “computed 
state”).

Brgds,

From: Olivier Dugeon [mailto:olivier.dug...@orange.com]
Sent: Tuesday, November 14, 2017 00:32
To: LITKOWSKI Stephane OBS/OINIS; Daniele Ceccarelli; 
pce@ietf.org
Subject: Re: [Pce] draft-ietf-pce-association-diversity: relaxing constraint


Hello Stephane, all

In fact, these mechanism is already available in RFC 5440.

First, Metric Object has been defined with a B flag to indicate if this metric 
(i.e. constraint) must be bound or not. See 
https://tools.ietf.org/html/rfc5440#section-7.8. Terminology is not exactly the 
same, but, the goal is similar. It allows a PCC to indicate to the PCE if the 
metric must be strictly respected or not. Note, also that it is possible to 
indicate many similar Metric object with different value, as well as different 
value for the B-flag for more flexibility. For example, for the Disjointness, 
we could image a first Metric with SRLG disjoint path and B-Flag set to one and 
a second one with SRLG-and-Node disjoint path with B-Flag clear. This indicate 
to the PCE that we want at least an SRLG disjoint path, but if it could compute 
an SRLG and Node disjoint path we'll be very happy.

PCC could also set the C-Flag to indicate to the PCE that it would in turn the 
computed Metric. For disjointness, it could indicate which type of disjointness 
it successfully used for the computed path.

If a metric could not be met, PCE will return a No-PATH object with the default 
metric to indicate which constraints could not be met.

Now, to indicate that a metric (constraint) should be relaxed, there is 2 
possibilities: send a new PCEP message with the B-Flag of this Metric cleared, 
or a PCEP message without the given Metric. see again RFC 5440 end of section 
7.8 page 38 (https://tools.ietf.org/html/rfc5440#page-38).

So, I think the generic mechanism is already available and to inherit from this 
behaviour, the Disjointeness TLV should be a new Metric Object instead of a 
dedicated new TLV. But, I understand that the draft and solution have not been 
design with this in mind. So I let authors decided if it is feasible or not.

Regards

Olivier

Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

[Jonathan Hardwick]

Mustapha, Dhruv,

Thanks for the feedback.

The procedures that a PCC should follow to update the LSP setup type are a 
local matter for the PCC, and in any case are impossible to say in a draft that 
is agnostic of the specific LSP setup types being used.  The use case for doing 
this seems sufficiently unclear that I don't think we should add text to try to 
describe it in more detail.  I just don't want to artificially remove the 
flexibility from the draft.  If it is found to be useful in future we can 
consider whether any procedures need to be documented for the case at hand.

The PCC can always decide not to act on a PCUpd.  I think RFC 8231 already has 
this covered adequately:

   If the PCC
   decides that the LSP parameters proposed in the PCUpd message are
   unacceptable, it MUST report this error by including the
   LSP-ERROR-CODE TLV (Section 7.3.3) with LSP error-value="Unacceptable
   parameters" in the LSP object in the PCRpt message to the PCE.  Based
   on local policy, it MAY react further to this error by revoking the
   delegation.

Regards
Jon

-Original Message-
From: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
[mailto:mustapha.aissa...@nokia.com] 
Sent: 17 November 2017 06:47
To: Dhruv Dhody <dhruv.dh...@huawei.com>; Jonathan Hardwick 
<jonathan.hardw...@metaswitch.com>; Julien Meuric <julien.meu...@orange.com>; 
stephane.litkow...@orange.com
Cc: pce@ietf.org; 'Dhruv Dhody' <dhruv.i...@gmail.com>
Subject: RE: [Pce] Clarifications on PST handling in 
draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

Thanks Dhruv.

I am fine with making sure we have the proper PCErr message listed in case a 
PCC rejects such a change. However, it seems to me that we should describe the 
procedures for a PCC which honors it.

I am not sure that I understand how it helps migration. It seems too 
complicated for its own sake.

Mustapha.

> -Original Message-
> From: Dhruv Dhody [mailto:dhruv.dh...@huawei.com]
> Sent: Thursday, November 16, 2017 5:32 PM
> To: Aissaoui, Mustapha (Nokia - CA/Ottawa) 
> <mustapha.aissa...@nokia.com>; Jonathan Hardwick 
> <jonathan.hardw...@metaswitch.com>; Julien Meuric 
> <julien.meu...@orange.com>; stephane.litkow...@orange.com
> Cc: pce@ietf.org; 'Dhruv Dhody' <dhruv.i...@gmail.com>
> Subject: RE: [Pce] Clarifications on PST handling in 
> draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing
> 
> Hi Mustapha,
> 
> Jon said this in his earlier mail -
> 
> > Although I'm not convinced it would be a good idea operationally, I 
> > don't think there's any need to prevent the path type changing on 
> > the PCUpd, if an explicit PATH-SETUP-TYPE is given.  That is, 
> > draft-ietf-pce-lsp-setup-type, as a base draft, should allow that 
> > flexibility.  A given device may choose not to allow that, of course.
> 
> And I agree with that. In case of message which is in a "response" 
> such as PCRep, PCRpt it MUST have the same PST.
> But PCUpd and PCInitiate are different and keeping a door open for 
> allowing the change of PST could allow better migration from RSVP-TE 
> to SR for existing tunnels.
> 
> How about we update the text in the draft to explicitly say that this 
> is about PCC's local policy and PCC MAY send an error in case the 
> local policy doesn't allow changing of PST?
> 
> Thanks!
> Dhruv
> 
> PS. And for what's it's worth, I agree with leaving the selection of 
> PST for a future extension.
> 
> > -Original Message-
> > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Aissaoui, 
> > Mustapha (Nokia - CA/Ottawa)
> > Sent: 17 November 2017 05:18
> > To: Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; Julien 
> > Meuric <julien.meu...@orange.com>; stephane.litkow...@orange.com
> > Cc: pce@ietf.org
> > Subject: Re: [Pce] Clarifications on PST handling in
> > draft-ietf-pce-lsp- setup-type & draft-ietf-pce-segment-routing
> >
> > Jon,
> > While I do not have an issue with enforcing the PST TLV be included 
> > in the below message types, we still need to answer Stephane's last 
> > question in his original email. That is whether the PST is allowed 
> > to change during the lifetime of the LSP. I am hoping the answer is 
> > no meaning that once a LSP with a PLSP-ID is established, a 
> > subsequent PCUpd message with a PST type that does not match the 
> > type in the original message which created that PLSP-ID (PCReq or 
> > PCInitiate) should result in the PCC returning a PCErr message with 
> > Error-Type =
> > 21 (Traffic engineering path setup error) and Error-Value = 2 
> > (Mismatched path
> setup type).
> >
> > If that is the understandi

Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

[Jonathan Hardwick]

Hi Julien, see [Jon]s below...

-Original Message-
From: Julien Meuric [mailto:julien.meu...@orange.com] 
Sent: 16 November 2017 17:28
To: Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; 
stephane.litkow...@orange.com
Cc: pce@ietf.org
Subject: Re: [Pce] Clarifications on PST handling in 
draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

Hi,

Glad to see we are converging. To make sure we are on the same page (solution 
(2) referring to a shortcut), the conclusion is that, as soon as PST is not 0 
(i.e. RSVP-TE), we always include the PST TLV in PCReq, PCRep, PCUpd, PCRpt and 
PCInitiate: is that right?

[Jon] Yes.

This leads me to another question. Over a PCEP session supporting multiple 
types, we do not have a mean to send a PCReq leaving the type selection to the 
PCE (no TLV implying type 0). Do we consider a mean to support that? (Could be 
0xFF or a flag from the "Reserved" field.)

[Jon] It could be done, but do we need it?  This could be added later without 
penalty.

Thanks,

Julien


Nov. 16, 2017 - jonathan.hardw...@metaswitch.com:
>
> Hi Stephane
>
>  
>
> OK, let's go with solution (2).  That is, if the PATH-SETUP-TYPE is 
> not present in a message, then it unambiguously means that the path 
> setup type is RSVP-TE.  Then implementations don't have to try to 
> infer the path setup type from other objects or previous messages.
>
>  
>
> I am revising draft-ietf-pce-lsp-setup-type at the moment to address 
> an earlier comment from Julien, so I will include this clarification 
> in the next revision.
>
>  
>
> Thanks for the input!
>
> Cheers
>
> Jon
>
>  
>
>  
>
> *From:*stephane.litkow...@orange.com
> [mailto:stephane.litkow...@orange.com]
> *Sent:* 15 November 2017 13:52
>
>  
>
> Hi Jon,
>
>  
>
> Thanks for your feedback.
>
> I see two possibilities here.
>
>  1. When the PATH-SETUP-TYPE is not present in a PCUpd, it should be
> inferred from the latest one received (in a PCInitiate or in a
> PCUpd). When initiating an LSP, the PCInitiate contains the PST to
> let the PCC know about the path type. Then, it can be omitted in
> further PCUpd except when the PCE wants to change the path type.
> At that time, it sends a PCUpd with a new PATH-SETUP-TYPE value
> and then it does not need to include it in further updates until
> the PCE needs to change it again.
>  2. We mandate the PCE to put the PATH-SETUP-TYPE in all PCUpd.
>
>  
>
> IMO, solution 2) is easier for implementations and operation.
>
>  
>
> Brgd,
>
>  
>
> Stephane
>
>  
>
>  
>
> *From:*Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
> *Sent:* Wednesday, November 15, 2017 09:28
> *To:* LITKOWSKI Stephane OBS/OINIS; pce@ietf.org <mailto:pce@ietf.org>
> *Subject:* RE: Clarifications on PST handling in 
> draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing
>
>  
>
> I think it should be acceptable for the PCUpd not to include the 
> PATH-SETUP-TYPE, with the implication that there is no change to the 
> path type.
>
>  
>
> Although I'm not convinced it would be a good idea operationally, I 
> don't think there's any need to prevent the path type changing on the 
> PCUpd, if an explicit PATH-SETUP-TYPE is given.  That is, 
> draft-ietf-pce-lsp-setup-type, as a base draft, should allow that 
> flexibility.  A given device may choose not to allow that, of course.
>
>  
>
> Does that sound reasonable?
>
> Cheers
>
> Jon
>
>  
>
>  
>
> *From:*Pce [mailto:pce-boun...@ietf.org] *On Behalf Of 
> *stephane.litkow...@orange.com <mailto:stephane.litkow...@orange.com>
> *Sent:* 14 November 2017 00:38
> *To:* pce@ietf.org <mailto:pce@ietf.org>
> *Subject:* [Pce] Clarifications on PST handling in 
> draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing
>
>  
>
> Hi WG,
>
>  
>
> I'm facing an interop issue between two PCEP implementations.
>
> PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=1 
> in the SRP Object.
>
> PCC from vendor2 handles it correctly and delegates the LSP to the PCE 
> using PST=1.
>
> When the PCE sends a PCUpdate message, it does not set the PST TLV in 
> the SRP Object.
>
> The PCC rejects the PCUpdate because of a bad ERO subobject type. It 
> reads the PCUpdate as having PST type=0.
>
>  
>
> Based on my reading of draft-ietf-pce-lsp-setup-type & 
> draft-ietf-pce-segment-routing.
>
> PST draft tells that for the PCE Initiation case, the PCE MAY include 
> the PST if the message does not ave any other means of indicating the 
> path setup type. SR d

Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

[Jonathan Hardwick]

Hi Stephane

OK, let's go with solution (2).  That is, if the PATH-SETUP-TYPE is not present 
in a message, then it unambiguously means that the path setup type is RSVP-TE.  
Then implementations don't have to try to infer the path setup type from other 
objects or previous messages.

I am revising draft-ietf-pce-lsp-setup-type at the moment to address an earlier 
comment from Julien, so I will include this clarification in the next revision.

Thanks for the input!
Cheers
Jon


From: stephane.litkow...@orange.com [mailto:stephane.litkow...@orange.com]
Sent: 15 November 2017 13:52
To: Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; pce@ietf.org
Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & 
draft-ietf-pce-segment-routing

Hi Jon,

Thanks for your feedback.
I see two possibilities here.

  1.  When the PATH-SETUP-TYPE is not present in a PCUpd, it should be inferred 
from the latest one received (in a PCInitiate or in a PCUpd). When initiating 
an LSP, the PCInitiate contains the PST to let the PCC know about the path 
type. Then, it can be omitted in further PCUpd except when the PCE wants to 
change the path type. At that time, it sends a PCUpd with a new PATH-SETUP-TYPE 
value and then it does not need to include it in further updates until the PCE 
needs to change it again.
  2.  We mandate the PCE to put the PATH-SETUP-TYPE in all PCUpd.

IMO, solution 2) is easier for implementations and operation.

Brgd,

Stephane


From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: Wednesday, November 15, 2017 09:28
To: LITKOWSKI Stephane OBS/OINIS; pce@ietf.org<mailto:pce@ietf.org>
Subject: RE: Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & 
draft-ietf-pce-segment-routing

I think it should be acceptable for the PCUpd not to include the 
PATH-SETUP-TYPE, with the implication that there is no change to the path type.

Although I'm not convinced it would be a good idea operationally, I don't think 
there's any need to prevent the path type changing on the PCUpd, if an explicit 
PATH-SETUP-TYPE is given.  That is, draft-ietf-pce-lsp-setup-type, as a base 
draft, should allow that flexibility.  A given device may choose not to allow 
that, of course.

Does that sound reasonable?
Cheers
Jon


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>
Sent: 14 November 2017 00:38
To: pce@ietf.org<mailto:pce@ietf.org>
Subject: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type 
& draft-ietf-pce-segment-routing

Hi WG,

I'm facing an interop issue between two PCEP implementations.
PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=1 in the 
SRP Object.
PCC from vendor2 handles it correctly and delegates the LSP to the PCE using 
PST=1.
When the PCE sends a PCUpdate message, it does not set the PST TLV in the SRP 
Object.
The PCC rejects the PCUpdate because of a bad ERO subobject type. It reads the 
PCUpdate as having PST type=0.

Based on my reading of draft-ietf-pce-lsp-setup-type & 
draft-ietf-pce-segment-routing.
PST draft tells that for the PCE Initiation case, the PCE MAY include the PST 
if the message does not ave any other means of indicating the path setup type. 
SR draft tells "In order to setup an SR-TE LSP using SR, RP or SRP object MUST 
include PATH-SETUP-TYPE TLV". Unfortunately it does not specify explicitly in 
which message. From a reading perspective, we can understand from "In order to 
setup" that it applies to the PCInitiate message. But nothing tells about the 
PCUpdate message.
However draft-ietf-pce-lsp-setup-type tells for the stateful PCE case that: "if 
the path setup type cannot be unambiguously inferred from ERO or any other 
object or TLV, PATH-SETUP-TYPE TLV MAY be used in PCRpt and PCUpd messages."
In our case (PCE initiated) as the LSP has initially been setup through a 
PCInitiate message having the PST TLV, the PCC can infer that futher updates 
will use EROs associated with the same PST.

Or do we allow to change the PST through PCUpdate messages which may require to 
 always set the PST ? (moving from RSVP-TE to SR or the other way for a 
particular LSP)

I would like to hear opinions of the WG on that problem ?

Thanks,

Brgds,


[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 
<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
  NEW !
mobile: +33 6 71 63 27 50 
<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%209

Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

[Jonathan Hardwick]

Actually, since I wrote this:

> I think it should be acceptable for the PCUpd not to include the 
> PATH-SETUP-TYPE, with the implication that there is no change to the path 
> type.

I read this in draft-ietf-pce-lsp-setup-type:

> The absence of the PATH-SETUP-TYPE TLV is equivalent to an PATH-SETUP-TYPE 
> TLV with an PST value of 0.

What it doesn't say, but I think it means to say, is "... unless there is some 
other way to infer the path setup type from the message."  So, if we follow my 
suggestion below, we would have to make it explicit that the path setup type 
for a PCUpd can be inferred from the current path setup type of the LSP (unless 
it is given explicitly), which is a change to draft-ietf-pce-lsp-setup-type.

Does anyone else have an opinion on this?

Thanks
Jon


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 15 November 2017 09:28
To: stephane.litkow...@orange.com; pce@ietf.org
Subject: Re: [Pce] Clarifications on PST handling in 
draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

I think it should be acceptable for the PCUpd not to include the 
PATH-SETUP-TYPE, with the implication that there is no change to the path type.

Although I'm not convinced it would be a good idea operationally, I don't think 
there's any need to prevent the path type changing on the PCUpd, if an explicit 
PATH-SETUP-TYPE is given.  That is, draft-ietf-pce-lsp-setup-type, as a base 
draft, should allow that flexibility.  A given device may choose not to allow 
that, of course.

Does that sound reasonable?
Cheers
Jon


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>
Sent: 14 November 2017 00:38
To: pce@ietf.org<mailto:pce@ietf.org>
Subject: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type 
& draft-ietf-pce-segment-routing

Hi WG,

I'm facing an interop issue between two PCEP implementations.
PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=1 in the 
SRP Object.
PCC from vendor2 handles it correctly and delegates the LSP to the PCE using 
PST=1.
When the PCE sends a PCUpdate message, it does not set the PST TLV in the SRP 
Object.
The PCC rejects the PCUpdate because of a bad ERO subobject type. It reads the 
PCUpdate as having PST type=0.

Based on my reading of draft-ietf-pce-lsp-setup-type & 
draft-ietf-pce-segment-routing.
PST draft tells that for the PCE Initiation case, the PCE MAY include the PST 
if the message does not ave any other means of indicating the path setup type. 
SR draft tells "In order to setup an SR-TE LSP using SR, RP or SRP object MUST 
include PATH-SETUP-TYPE TLV". Unfortunately it does not specify explicitly in 
which message. From a reading perspective, we can understand from "In order to 
setup" that it applies to the PCInitiate message. But nothing tells about the 
PCUpdate message.
However draft-ietf-pce-lsp-setup-type tells for the stateful PCE case that: "if 
the path setup type cannot be unambiguously inferred from ERO or any other 
object or TLV, PATH-SETUP-TYPE TLV MAY be used in PCRpt and PCUpd messages."
In our case (PCE initiated) as the LSP has initially been setup through a 
PCInitiate message having the PST TLV, the PCC can infer that futher updates 
will use EROs associated with the same PST.

Or do we allow to change the PST through PCUpdate messages which may require to 
 always set the PST ? (moving from RSVP-TE to SR or the other way for a 
particular LSP)

I would like to hear opinions of the WG on that problem ?

Thanks,

Brgds,


[Orange logo]<http://www.orange.com/>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 
<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%202%2023%2028%2049%2083%20>
  NEW !
mobile: +33 6 71 63 27 50 
<https://monsi.sso.francetelecom.fr/index.asp?target=http%3A%2F%2Fclicvoice.sso.francetelecom.fr%2FClicvoiceV2%2FToolBar.do%3Faction%3Ddefault%26rootservice%3DSIGNATURE%26to%3D+33%206%2037%2086%2097%2052%20>
  NEW !
stephane.litkow...@orange.com<mailto:stephane.litkow...@orange.com>


_



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 att

Re: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type & draft-ietf-pce-segment-routing

[Jonathan Hardwick]

I think it should be acceptable for the PCUpd not to include the 
PATH-SETUP-TYPE, with the implication that there is no change to the path type.

Although I'm not convinced it would be a good idea operationally, I don't think 
there's any need to prevent the path type changing on the PCUpd, if an explicit 
PATH-SETUP-TYPE is given.  That is, draft-ietf-pce-lsp-setup-type, as a base 
draft, should allow that flexibility.  A given device may choose not to allow 
that, of course.

Does that sound reasonable?
Cheers
Jon


From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of 
stephane.litkow...@orange.com
Sent: 14 November 2017 00:38
To: pce@ietf.org
Subject: [Pce] Clarifications on PST handling in draft-ietf-pce-lsp-setup-type 
& draft-ietf-pce-segment-routing

Hi WG,

I'm facing an interop issue between two PCEP implementations.
PCE from vendor1 sends the PCInitiate for an SRTE LSP using the PST=1 in the 
SRP Object.
PCC from vendor2 handles it correctly and delegates the LSP to the PCE using 
PST=1.
When the PCE sends a PCUpdate message, it does not set the PST TLV in the SRP 
Object.
The PCC rejects the PCUpdate because of a bad ERO subobject type. It reads the 
PCUpdate as having PST type=0.

Based on my reading of draft-ietf-pce-lsp-setup-type & 
draft-ietf-pce-segment-routing.
PST draft tells that for the PCE Initiation case, the PCE MAY include the PST 
if the message does not ave any other means of indicating the path setup type. 
SR draft tells "In order to setup an SR-TE LSP using SR, RP or SRP object MUST 
include PATH-SETUP-TYPE TLV". Unfortunately it does not specify explicitly in 
which message. From a reading perspective, we can understand from "In order to 
setup" that it applies to the PCInitiate message. But nothing tells about the 
PCUpdate message.
However draft-ietf-pce-lsp-setup-type tells for the stateful PCE case that: "if 
the path setup type cannot be unambiguously inferred from ERO or any other 
object or TLV, PATH-SETUP-TYPE TLV MAY be used in PCRpt and PCUpd messages."
In our case (PCE initiated) as the LSP has initially been setup through a 
PCInitiate message having the PST TLV, the PCC can infer that futher updates 
will use EROs associated with the same PST.

Or do we allow to change the PST through PCUpdate messages which may require to 
 always set the PST ? (moving from RSVP-TE to SR or the other way for a 
particular LSP)

I would like to hear opinions of the WG on that problem ?

Thanks,

Brgds,


[Orange logo]

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/OINIS/NET
Orange Expert Future Networks
phone: +33 2 23 06 49 83 

  NEW !
mobile: +33 6 71 63 27 50 

  NEW !
stephane.litkow...@orange.com


_



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] Publication has been requested for draft-ietf-pce-pcep-exp-codepoints-03

[Jonathan Hardwick]

Jonathan Hardwick has requested publication of 
draft-ietf-pce-pcep-exp-codepoints-03 as Proposed Standard on behalf of the PCE 
working group.

Please verify the document's state at 
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-exp-codepoints/

___
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

[Jonathan Hardwick]

Hi Dhruv

Thanks for this.  Trimming to the open points:

Introduction

The second paragraph is superfluous - I suggest deleting:

   Further, in order to support use cases described in [RFC8051],

   [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to

   enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.

   [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and

   teardown of PCE-initiated LSPs under the stateful PCE model.

[[[Dhruv Dhody]]] Because of the comment for handling the unknown experimental 
objects for the stateful PCE messages, I think it is better to continue to keep 
this text. What do you think?

[Jon] Right - OK to leave it.  But then I think these have to become normative 
references.

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

[Pce] Shepherd's review of draft-ietf-pce-exp-codepoints

[Jonathan Hardwick]

Hi there

I am the document shepherd for this draft.  Please find my review of the draft 
below.

Many thanks for writing this draft.  It looks in good shape overall.  There are 
just a few clarifications I would like to make before we forward it to the IESG 
for publication.

Cheers
Jon

Abstract

This sentence about new sub-registries is misleading - the allocation policy 
for new sub-registries is decided by the drafts that create the sub-registries 
and does not have to be IETF Review.  I propose:
OLD

   IANA established a new top-level registry to contain all PCEP

   codepoints and sub-registries.  The allocation policy for each new

   registry is by IETF Review.
NEW

   IANA established a top-level registry to contain all PCEP

   codepoints and sub-registries.   This top-level registry contains

   sub-registries for PCEP message, object and TLV types.  The

   allocation policy for each of these sub-registries is IETF Review.
END

Introduction

OLD

   The Path Computation Element communication Protocol (PCEP) provides

   mechanisms for Path Computation Elements (PCEs) to perform path

   computations in response to Path Computation Clients (PCCs) requests.
NEW

   The Path Computation Element communication Protocol (PCEP) [RFC5440] provides

   mechanisms for Path Computation Elements (PCEs) to perform path

   computations in response to Path Computation Clients (PCCs) requests.
END
i.e. add reference to RFC 5440.

The second paragraph is superfluous - I suggest deleting:

   Further, in order to support use cases described in [RFC8051],

   [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to

   enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.

   [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and

   teardown of PCE-initiated LSPs under the stateful PCE model.

Please apply the same comments I made for the abstract to the following text:
OLD

   IANA established a new top-

   level registry to contain all PCEP codepoints and sub-registries.

   The allocation policy for each new registry is by IETF Review as

   described in [RFC8126].
NEW

   IANA established a top-

   level registry to contain all PCEP codepoints and sub-registries.

   This top-level registry contains sub-registries for PCEP message,

   object and TLV types.  The allocation policy for each of these

   sub-registries is IETF Review.
END

Suggested change for clarity:
OLD

   With some recent advancement, there is an enhanced need to experiment

   with PCEP.
NEW

   Recently, there have been rapid advancements in PCE technology, which

   has created an enhanced need to experiment with PCEP.
END

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.)

Also: s/PCE error message/PCErr message/

Section 7
Nit: add comma after "accidentally"

Appendix A
I think the text in this Appendix could be clearer.  Here is my suggestion.
OLD

   Based on the feedback from the WG, it was decided to focus only on

   the essentials in the scope of this documents.  For others,

   Experiments can use a new experimental TLV/Object instead.
NEW

   Based on feedback from the PCE WG, it was decided to allocate an

   Experimental code point range only in the message, object and TLV

   sub-registries.  The justification for this decision is that, if

   an experiment finds that it wants to use a new code point in

   another PCEP sub-registry, it can implement the same function using

   a new experimental object or TLV instead.
END

Other
Please update reference draft-ietf-pce-stateful-pce -> RFC 8231
Please update reference draft-ietf-pce-pce-initiated-lsp-10 -> 
draft-ietf-pce-pce-initiated-lsp-11

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

[Pce] Shepherd's review of draft-ietf-pce-pcep-exp-codepoints

[Jonathan Hardwick]

Re-sending to the correct DL :)

From: Jonathan Hardwick
Sent: 12 November 2017 12:02
To: 'draft-ietf-pce-exp-codepoi...@ietf.org' 
<draft-ietf-pce-exp-codepoi...@ietf.org>
Cc: 'pce@ietf.org' <pce@ietf.org>; pce-cha...@ietf.org
Subject: Shepherd's review of draft-ietf-pce-exp-codepoints

Hi there

I am the document shepherd for this draft.  Please find my review of the draft 
below.

Many thanks for writing this draft.  It looks in good shape overall.  There are 
just a few clarifications I would like to make before we forward it to the IESG 
for publication.

Cheers
Jon

Abstract

This sentence about new sub-registries is misleading - the allocation policy 
for new sub-registries is decided by the drafts that create the sub-registries 
and does not have to be IETF Review.  I propose:
OLD

   IANA established a new top-level registry to contain all PCEP

   codepoints and sub-registries.  The allocation policy for each new

   registry is by IETF Review.
NEW

   IANA established a top-level registry to contain all PCEP

   codepoints and sub-registries.   This top-level registry contains

   sub-registries for PCEP message, object and TLV types.  The

   allocation policy for each of these sub-registries is IETF Review.
END

Introduction

OLD

   The Path Computation Element communication Protocol (PCEP) provides

   mechanisms for Path Computation Elements (PCEs) to perform path

   computations in response to Path Computation Clients (PCCs) requests.
NEW

   The Path Computation Element communication Protocol (PCEP) [RFC5440] provides

   mechanisms for Path Computation Elements (PCEs) to perform path

   computations in response to Path Computation Clients (PCCs) requests.
END
i.e. add reference to RFC 5440.

The second paragraph is superfluous - I suggest deleting:

   Further, in order to support use cases described in [RFC8051],

   [I-D.ietf-pce-stateful-pce] specifies a set of extensions to PCEP to

   enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.

   [I-D.ietf-pce-pce-initiated-lsp] describes the setup, maintenance and

   teardown of PCE-initiated LSPs under the stateful PCE model.

Please apply the same comments I made for the abstract to the following text:
OLD

   IANA established a new top-

   level registry to contain all PCEP codepoints and sub-registries.

   The allocation policy for each new registry is by IETF Review as

   described in [RFC8126].
NEW

   IANA established a top-

   level registry to contain all PCEP codepoints and sub-registries.

   This top-level registry contains sub-registries for PCEP message,

   object and TLV types.  The allocation policy for each of these

   sub-registries is IETF Review.
END

Suggested change for clarity:
OLD

   With some recent advancement, there is an enhanced need to experiment

   with PCEP.
NEW

   Recently, there have been rapid advancements in PCE technology, which

   has created an enhanced need to experiment with PCEP.
END

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.)

Also: s/PCE error message/PCErr message/

Section 7
Nit: add comma after "accidentally"

Appendix A
I think the text in this Appendix could be clearer.  Here is my suggestion.
OLD

   Based on the feedback from the WG, it was decided to focus only on

   the essentials in the scope of this documents.  For others,

   Experiments can use a new experimental TLV/Object instead.
NEW

   Based on feedback from the PCE WG, it was decided to allocate an

   Experimental code point range only in the message, object and TLV

   sub-registries.  The justification for this decision is that, if

   an experiment finds that it wants to use a new code point in

   another PCEP sub-registry, it can implement the same function using

   a new experimental object or TLV instead.
END

Other
Please update reference draft-ietf-pce-stateful-pce -> RFC 8231
Please update reference draft-ietf-pce-pce-initiated-lsp-10 -> 
draft-ietf-pce-pce-initiated-lsp-11

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

[Pce] Working group last call (including final IPR check) for draft-ietf-pce-pcep-exp-codepoints

[Jonathan Hardwick]

Dear PCE working group

This email starts a working group last call for 
draft-ietf-pce-pcep-exp-codepoints-02.
https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-exp-codepoints/

Please read the document and reply to the PCE mailing list whether you believe 
this document is ready to be published, or not (including any comments on why 
not).  The last call will end on Friday 10 November.

We are also polling for knowledge of any undisclosed IPR that applies to 
draft-ietf-pce-pcep-exp-codepoints-02, to ensure that IPR has been disclosed in 
compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more 
details) prior to moving forward.  If you are a document author, please respond 
to this email and indicate whether or not you are aware of any relevant 
undisclosed IPR. The document won't progress without answers from all the 
authors.  No IPR disclosures currently exist against this document.

Best regards
Jon and Julien


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

[Pce] FW: I-D Action: draft-ietf-pce-pce-initiated-lsp-11.txt

[Jonathan Hardwick]

This version addresses the feedback we received from the IESG.  If anyone has 
any concerns with the changes, please shout ASAP.

Best regards
Jon


-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: 09 October 2017 08:27
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-pce-initiated-lsp-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 PCE-initiated LSP Setup in a 
Stateful PCE Model
Authors : Edward Crabbe
  Ina Minei
  Siva Sivabalan
  Robert Varga
Filename: draft-ietf-pce-pce-initiated-lsp-11.txt
Pages   : 19
Date: 2017-10-07

Abstract:
   The Path Computation Element Communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform path
   computations in response to Path Computation Clients (PCCs) requests.

   The extensions for stateful PCE provide active control of
   Multiprotocol Label Switching (MPLS) Traffic Engineering Label
   Switched Paths (TE LSP) via PCEP, for a model where the PCC delegates
   control over one or more locally configured LSPs to the PCE.  This
   document describes the creation and deletion of PCE-initiated LSPs
   under the stateful PCE model.



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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-pce-pce-initiated-lsp-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] Your IESG comments on draft-ietf-pce-pce-initiated-lsp

[Jonathan Hardwick]

Hi Alvaro


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



For some reason I can't find the original email with your comments in, so I 
have scraped the text from the datatracker and pasted it below.  Please see my 
proposed resolutions inline below, marked with "Jon>"



Best regards

Jon


Just some minor comments:

(1) Section 3.2

   This document defines a new PCEP message, the LSP Initiate Request
   (PCInitiate) message, which a PCE can send to a PCE to request the
   initiaton or deletion of an LSP.

s/...PCE can send to a PCE.../...PCE can send to a PCC...

Jon> OK.


(2) Section 5.3: "The source address MAY be either specified or left up to the 
PCC decision using the 0.0.0.0 value."  These seem to be the only two possible 
options, so s/MAY/MUST.

Jon> OK.  So, including the feedback we got from Adam Roach, the new text is:

''The source address MUST either be specified or left for the PCC to choose by 
setting it to "0.0.0.0" (if the destination is an IPv4 address) or "::" (if the 
destination is an IPv6 address).''


(3) Also from Section 5.3: "...the END-POINTS object MAY be included to 
explicitly convey the destination...For LSPs to be setup by other means, the 
END-POINTS object MAY be omitted..."

You already wrote that "other setup methods are outside the scope".  Also, not 
including the END-POINTS object is not an indication of other types of LSPs, as 
its use is optional to start with.  Take out the last sentence.

Jon> Fine with me.

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

Re: [Pce] Eric Rescorla's No Objection on draft-ietf-pce-pce-initiated-lsp-10: (with COMMENT)

[Jonathan Hardwick]

Hi Eric



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



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



Best regards

Jon







--

COMMENT:

--



Document: draft-ietf-pce-pce-initiated-lsp-10.txt



Note: I reviewed this document on my experimental Phabricator instance.

You can see the comments inline at:



  https://mozphab-ietf.devsvcdev.mozaws.net/D20



Jon> This is a useful tool, thanks!





It may just be my unfamiliarity with this system, but it's not clear to me what 
the security model is here for the delegation. As I understand this document 
the PCC just tells the PCE that it has delegated the LSP to it, and then the 
PCE can make the LSP via the normal procedures. But what is it that tells the 
rest of the system that the PCC is allowed to manage that LSP. I didn't get 
that out of this document or out of a cursory look at RFC 8051.



Jon> The model is that the PCE makes the first move.  It instructs the PCC to 
initiate an LSP that the PCC has not previously heard of.  The PCC initiates 
the LSP and sends a PCRpt message delegating control over it to the PCE.  Once 
it receives the delegation, the PCE is free to make whatever changes it likes, 
or delete the LSP.





INLINE COMMENTS

Line 162

   A possible use case is a software-driven network, where applications

   request network resources and paths from the network infrastructure.

NIT: isn't the term here "software-defined network"



Jon> Indeed.  Will fix.





Line 218

   all state related to the LSP and sends a PCRpt for the removed state.

   See details in Section 5.4.

A diagram would sure help here.



Jon> How about this:



NEW

   The following diagram illustrates these message exchanges.



  +-+-++-+-+

  |PCC||PCE|

  +-+-++-+-+

||

|<--PCInitiate---| (Initiate LSP)

||

|---PCRpt, PLSP_ID=1, D=1--->| (Confirm initiation)

|.   |

|.   |

||

|<--PCUpd, PLSP_ID=1-| (Update LSP)

||

|---PCRpt, PLSP_ID=1, D=1--->| (Confirm update)

|.   |

|.   |

||

|<--PCInitiate, PLSP_ID=1, R=1---| (Delete LSP)

||

|---PCRpt, PLSP_ID=1, R=1--->| (Confirm update)





   Figure 1: Initiated LSP lifecycle

END NEW



Line 263

   Unassigned bits are considered reserved.  They MUST be set to 0 on

   transmission and MUST be ignored on receipt.

As I understand this text, you are merely adding a new code point to flags. I'm 
not sure it's necessary to reproduce the PDU, but if you do, you should clarify 
that th only change you are making is adding a new field. Perhaps on line 249 
"It is reproduced here with the addition of the new I bit"



Jon> Yes, this is correct.  I will update this section and the similar cases 
below to follow the form of the "good text" from line 436 that you cite below.



Line 278

   and the LSP objects, and MAY contain other objects, as discussed

   later in this section.

Is the syntax here supposed to be ABNF? If so, you need a citation to the 
syntax".



Jon> It's RBNF. It’s defined in [RFC5511], listed as a normative reference and 
cited from section 2.





Line 337

  create an LSP.  If set to 1, it indicates a request to remove an

  LSP.

I have the same comment here about repeating PDU.



Jon> Ack.





Line 436

   The LSP object is defined in [I-D.ietf-pce-stateful-pce] and included

   here for easy reference.

This is good text, and is what I would encourage the other places you replicate 
PDUs from other documents.



Jon> Ack.


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

Re: [Pce] Adam Roach's No Objection on draft-ietf-pce-pce-initiated-lsp-10: (with COMMENT)

[Jonathan Hardwick]

Hi Adam

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

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

Best regards
Jon



--
COMMENT:
--

Section 5.1 defines the PCInititate Message, and is generally pretty good about 
indicating where its component elements come from; however, it's missing 
pointers to , , and . I think you want to add: ", 
, and  are defined in [RFC5440]".

Jon> I will add this:  ' is defined in [RFC8231]. , and  
are defined in [RFC5440].'


Section 5.3 indicates that an indication that the PCC is supposed to pick the 
source address is signaled by using a source address of "0.0.0.0" -- 
presumably, if the destination is an IPv6 address, this would instead use "::", 
right? Please add text that addresses the IPv6 case.

Jon> Thanks, you are correct.  I will change it to this: 'The source address 
MAY either be specified or left for the PCC to choose by setting it to 
"0.0.0.0" (if the destination is an IPv4 address) or "::" (if the destination 
is an IPv6 address).'


I'm pretty certain that [I-D.ietf-pce-stateful-sync-optimizations] is a 
normative reference. Even though its use is optional, this document contains 
normative statements regarding its mechanism. See 
 for guidance, 
and "Note 1" of that statement in particular.

Jon> Oops! We will make it a normative reference.
___
Pce mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] Spencer Dawkins' Discuss on draft-ietf-pce-pce-initiated-lsp-10: (with DISCUSS and COMMENT)

[Jonathan Hardwick]

Hi Spencer

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

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

Best regards
Jon



--
DISCUSS:
--

This ballot position would be Please Educate Me, if that was a choice, but 
that's not a choice. I'm sure we can clear this quickly. And I found this 
document very easy to read as a reviewer - thanks for that.

I found a couple of places where SHOULDs seemed at least under-specified, and 
this one looked important.

In this text,

  LSP State Synchronization procedures are described in section 5.4 of
   [I-D.ietf-pce-stateful-pce].  During State Synchronization, a PCC
   reports the state of its LSPs to the PCE using PCRpt messages,
   setting the SYNC flag in the LSP Object.  For PCE-initiated LSPs, the
   PCC MUST also set the Create Flag in the LSP Object and MAY include
   the SPEAKER-ENTITY-ID TLV identifying the PCE that requested the LSP
   creation.  At the end of state synchronization, the PCE SHOULD
   compare the reported PCE-Initiated LSPs with its configuration.  For
   any mismatch, the PCE SHOULD send a PCInitiate message to initiate
   any missing LSPs and/or remove any LSPs that are not wanted.

I’m having a hard time understanding why a PCE would not compare reported 
PCE-Initiated LSPs with its configuration, which is allowed by the first 
SHOULD. Does that mean you thought it was important to TRY to synchronize, but 
you’re not curious enough to check whether that worked?

I can imagine reasons why you wouldn't try to fix the LSPs that weren't 
synchronized, at least not immediately, but you might also give guidance about 
one or more reasons why you wouldn't try, to help implementers understand what 
not doing what the SHOULD means, and make informed choices for their 
implementations.


Jon> I definitely agree with you that, having received a snapshot from the PCC, 
there is no reason that the PCE would not then compare the PCC's state with its 
local copy i.e. the first SHOULD ought to be a MUST.  The intention of the 
second SHOULD was to leave the PCE with some flexibility for dealing with 
clients that are out of sync.  For example, perhaps the clients are slow, or 
perhaps the operator's policy is to prefer not to disrupt existing flows so 
long as the main characteristics of the flows are correct.  These are just my 
invented examples, but we expect there might be valid operational reasons along 
these lines, so we wanted to the draft to allow the server the flexibility to 
choose whether it updates the flows, or not.

Here is my proposed fix.

OLD
   == as quoted above ===
NEW
   LSP State Synchronization procedures are described in section 5.4 of
   [RFC8231].  During State Synchronization, a PCC
   reports the state of its LSPs to the PCE using PCRpt messages,
   setting the SYNC flag in the LSP Object.  For PCE-initiated LSPs, the
   PCC MUST also set the Create Flag in the LSP Object and MAY include
   the SPEAKER-ENTITY-ID TLV identifying the PCE that requested the LSP
   creation.  At the end of state synchronization, the PCE MUST
   compare the reported PCE-Initiated LSPs with its configuration.  For
   any mismatch, the PCE SHOULD send a PCInitiate message to initiate
   any missing LSPs and/or remove any LSPs that are not wanted.  Under
   some circumstances, depending on the deployment,  it might be preferable
   for a PCE not to send this PCInitiate immediately, or at all.  For
   example, the PCC may be a slow device, or the operator might prefer
   not to disrupt active flows.
   

--
COMMENT:
--

In this text,

  The State Timeout Interval timer ensures that a PCE crash does not
   result in automatic and immediate disruption for the services using
   PCE-initiated LSPs.  PCE-initiated LSPs are not removed immediately
   upon PCE failure.  Instead, they are cleaned up on the expiration of
   this timer.  This allows for network cleanup without manual
   intervention.  The PCC SHOULD support removal of PCE-initiated LSPs
   as one of the behaviors applied on expiration of the State Timeout
   Interval timer.  The behavior SHOULD be picked based on local policy,
   and can result either in LSP removal, or in reverting to operator-
   defined default parameters.

I found myself wondering why “The PCC SHOULD support removal of PCE-initiated 
LSPs” is a SHOULD, and not a MUST, but if it’s a SHOULD, you might say 
something about the effects of not supporting this, in order to help 
implementers make an informed decision about whether to support it.

In the same text, I found myself wondering if there were other 

Re: [Pce] Early code point allocation for draft-ietf-pce-association-group

[Jonathan Hardwick]

Dear PCE WG

We have received a request from the authors of draft-ietf-pce-association-group 
for an early code point allocation.

The process for early code point allocation is described in RFC 7120.  The 
draft is required to meet several criteria, including:

   b.  The format, semantics, processing, and other rules related to
   handling the protocol entities defined by the code points
   (henceforth called "specifications") must be adequately described
   in an Internet-Draft.

   c.  The specifications of these code points must be stable; i.e., if
   there is a change, implementations based on the earlier and later
   specifications must be seamlessly interoperable.

If anyone believes that the draft does not meet these criteria, or believes 
that early allocation is not appropriate for any other reason, please send an 
email to the PCE mailing list explaining the reasons.  If the chairs hear no 
objections by next Friday, 22 September, we will kick off the early allocation 
request.

Best regards

Jon & Julien


From: Dhruv Dhody [mailto:dhruv.dh...@huawei.com]
Sent: 01 September 2017 08:06
To: pce-cha...@ietf.org
Cc: pce@ietf.org; draft-ietf-pce-association-gr...@ietf.org; BRUNGARD, DEBORAH 
A ; Mahendra Singh Negi ; Rakesh 
Gandhi (rgandhi) 
Subject: Early code point allocation for draft-ietf-pce-association-group

Hi Chairs,

We would like to request IANA early code point allocation for 
https://tools.ietf.org/html/draft-ietf-pce-association-group-04#section-6.

Multiple implementers have reached out to the authors regarding this. So as per 
RFC7120, could you initiate the process of obtaining early allocation?

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

Re: [Pce] Best Wishes for the future of PCE WG !

[Jonathan Hardwick]

Thanks, JP, for initiating this work and for your huge contribution to it!
Very best wishes for your new projects.  Hope to see you again soon!

Cheers
Jon

From: JP Vasseur (jvasseur) [mailto:jvass...@cisco.com]
Sent: 22 August 2017 15:30
To: pce@ietf.org; Julien Meuric <julien.meu...@orange.com>; Jonathan Hardwick 
<jonathan.hardw...@metaswitch.com>; Deborah A Brungard <db3...@att.com>; Adrian 
Farrel <adr...@olddog.co.uk>; d.k...@lancaster.ac.uk; Dhruv Dhody 
<dhruv.dh...@huawei.com>
Subject: Best Wishes for the future of PCE WG !

Dear WG,

Almost 12 years since we started the PCE WG ! More than 30 RFCs, many 
re-charterings, closely working with several other WGs (MPLS, CCAMP, OSPF, 
ISIS, …) and of course many implementations and deployments in the field 
applying the PCE architecture to several areas !

As you might have noticed I have been fairly silent for the past two years, 
driving several quite hectic projects related to Machine Learning for the 
network (Security, Wireless, IoT, …) not involving too much of standardization 
work (yet). As discussed a few times, the PCE may also play a great role in 
ML/AI for central global optimization :-)

As agreed with our AD Deborah I have completed a transition phase, and it is a 
great time for me to step down as PCE co-chair.

I would like to warmly thank my friend Adrian whom I started the PCE WG with in 
2005 and many years of close collaboration, Julien Meuric who has been a 
terrific co-chair, and Jonathan who stepped up as new co-chair at light speed, 
not forgetting Dan for years as secretary and now Dhruv.

See you all soon !

Cheers,

JP.


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

Re: [Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?

[Jonathan Hardwick]

Adrian,

The SR-PCE-CAPABILITY TLV is more than just a Boolean value - it also contains 
information about the maximum SID depth.  However, I like your idea and I think 
that it gives us a better way to do this without breaking backwards 
compatibility with existing SR implementations.

Suppose we introduce a setup-type TLV into the OPEN object as you propose, and 
assign a bit to each setup type.
If the TLV is absent, then RSVP-TE is supported.
If the TLV is absent and the SR-PCE-CAPABILITY TLV is present, then RSVP-TE and 
SR are supported.  This retains backwards compatibility with existing SR 
implementations.
If the TLV is present, then the bits indicate which setup types are supported.

We would modify the LSP setup type draft to say that implementations supporting 
path setup types other than RSVP-TE SHOULD include the setup-type TLV.

It's not exactly beautiful, but it's not as ugly as RSVP-TE-NON-SUPPORT.

Cheers
Jon


From: Adrian Farrel [mailto:adr...@olddog.co.uk]
Sent: 21 July 2017 19:55
To: Jonathan Hardwick <jonathan.hardw...@metaswitch.com>; pce@ietf.org; 
draft-ietf-pce-lsp-setup-t...@ietf.org; draft-ietf-pce-segment-rout...@ietf.org
Cc: pce-cha...@ietf.org
Subject: RE: [Pce] Can we make a non-backwards compatible change to 
draft-ietf-pce-lsp-setup-type?

Well, personally, if I was designing this, I would not a whole TLV for each bit 
flag!
I would have a Setup-Type TLV.
If that TLV is absent, RSVP-TE is supported.
If the TLV is present, each bit means that a different setup type is supported.

That means...
Legacy nodes don't include the TLV and are assumed to support RSVP-TE
Legacy nodes that receive the TLV don't know what it means and so object to the 
Open (leaving a new node to re-Open for RSVP-TE only).
New nodes include the TLV and so indicate explicitly what they support.

I know it is late for that type of change, so how we proceed might depend on 
what implementations have done already.

Adrian

From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
Sent: 21 July 2017 16:07
To: pce@ietf.org<mailto:pce@ietf.org>; 
draft-ietf-pce-lsp-setup-t...@ietf.org<mailto:draft-ietf-pce-lsp-setup-t...@ietf.org>;
 
draft-ietf-pce-segment-rout...@ietf.org<mailto:draft-ietf-pce-segment-rout...@ietf.org>
Cc: pce-cha...@ietf.org<mailto:pce-cha...@ietf.org>
Subject: [Pce] Can we make a non-backwards compatible change to 
draft-ietf-pce-lsp-setup-type?

Dear PCE-ers

I don't want to distract from the SDN topic too much, but we have an important 
decision to make about draft-ietf-pce-lsp-setup-type.

The shepherd review raised an issue that there is no way for a PCEP speaker to 
indicate that it can't (or won't) support RSVP-TE as a path setup type.  It is 
entirely plausible that a node might not support RSVP-TE, or else have it 
disabled, for example in an SR-only network.

We think that draft-ietf-pce-lsp-setup-type should be changed to allow a 
speaker to declare that they do or don't have support for RSVP-TE paths.  There 
are two proposals.


1.  Change draft-ietf-pce-lsp-setup-type so that speakers MUST include a 
(new) RSVP-TE-CAPABILITY TLV in their OPEN object.  If this TLV if missing, but 
some other CAPABILITY TLV is present (such as SR-CAPABILITY) then it means that 
the speaker does not support RSVP-TE as a path setup type.

2.  Change draft-ietf-pce-lsp-setup-type so that speakers MUST include a 
(new) RSVP-TE-NON-SUPPORT TLV in their OPEN object if they DON'T support 
RSVP-TE.  If this TLV is omitted, it will be assumed that they do support 
RSVP-TE.

The problem with (1) is that it is not backwards compatible.  Any existing SR 
implementation which also supports RSVP will not currently send this new 
capability.  So, if we make change (1) then forwards-level implementations will 
incorrectly conclude that such backwards-level implementations do not support 
RSVP-TE.

The problem with (2) is that it is ugly, and in my opinion we should only do 
something ugly with a new protocol extension if we simply can't avoid doing it.

And so the question: are there any *deployments* of PCEP in a mixed SR/RSVP-TE 
environment that would be broken if we made change (1)?

Thanks
Jon

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

[Pce] Can we make a non-backwards compatible change to draft-ietf-pce-lsp-setup-type?

[Jonathan Hardwick]

Dear PCE-ers

I don't want to distract from the SDN topic too much, but we have an important 
decision to make about draft-ietf-pce-lsp-setup-type.

The shepherd review raised an issue that there is no way for a PCEP speaker to 
indicate that it can't (or won't) support RSVP-TE as a path setup type.  It is 
entirely plausible that a node might not support RSVP-TE, or else have it 
disabled, for example in an SR-only network.

We think that draft-ietf-pce-lsp-setup-type should be changed to allow a 
speaker to declare that they do or don't have support for RSVP-TE paths.  There 
are two proposals.


1.  Change draft-ietf-pce-lsp-setup-type so that speakers MUST include a 
(new) RSVP-TE-CAPABILITY TLV in their OPEN object.  If this TLV if missing, but 
some other CAPABILITY TLV is present (such as SR-CAPABILITY) then it means that 
the speaker does not support RSVP-TE as a path setup type.

2.  Change draft-ietf-pce-lsp-setup-type so that speakers MUST include a 
(new) RSVP-TE-NON-SUPPORT TLV in their OPEN object if they DON'T support 
RSVP-TE.  If this TLV is omitted, it will be assumed that they do support 
RSVP-TE.

The problem with (1) is that it is not backwards compatible.  Any existing SR 
implementation which also supports RSVP will not currently send this new 
capability.  So, if we make change (1) then forwards-level implementations will 
incorrectly conclude that such backwards-level implementations do not support 
RSVP-TE.

The problem with (2) is that it is ugly, and in my opinion we should only do 
something ugly with a new protocol extension if we simply can't avoid doing it.

And so the question: are there any *deployments* of PCEP in a mixed SR/RSVP-TE 
environment that would be broken if we made change (1)?

Thanks
Jon

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

[Pce] PCEP as an SDN controller protocol?

[Jonathan Hardwick]

Dear PCE WG

The purpose of this email is to initiate a discussion about whether we want to 
extend PCEP to allow it to replace the functions that are traditionally 
provided by the routing and signalling protocols.

Originally, PCEP was designed with the goal of providing a distributed path 
computation service.  In recent years we have extended that mission, and added 
path modification and path instantiation capabilities to PCEP.  This has added 
capabilities to PCEP that would traditionally have been performed by the 
network management plane.

We are now starting to discuss proposals to add more capabilities to PCEP - 
capabilities that are traditionally part of routing and signalling.  There were 
three examples of this in the PCE working group meeting this week.

*The PCECC proposal, which extends PCEP's path instantiation capability 
so that the PCE can provision a path end-to-end by touching each hop along the 
path.  This replaces the function already provided by RSVP-TE.

*The PCEP-LS proposal, which extends PCEP to allow link state and TE 
information to be communicated from the network to the PCE.  This replaces the 
link state flooding function provided by the IGPs, or BGP-LS.

*The PCECC-SR proposal extends PCEP to allow device-level configuration 
to be communicated between the network and the PCE, such as SRGBs, prefix SIDs 
etc.  Again, this replaces functions that are already designed into the IGPs.

These proposals are taking PCEP in the direction of being a fully-fledged SDN 
protocol.  With these proposals, one can envision a network in which there is 
no traditional control plane.  PCEP is used to communicate the current network 
state and to program flows.  These proposals have their roots in the ACTN and 
PCECC architectures that are adopted within the TEAS working group.  TEAS is 
very much assuming that this is the direction that we want to take PCEP in.  
However, there are two procedural issues, as I see it.

1.  We have not had an explicit discussion in the PCE WG about whether we 
want to take PCEP in this direction.  We have had a few lively debates on 
specific cases, like PCEP-LS, but those cases represent the "thin end of the 
wedge".  If we start down this path then we are accepting that PCEP will 
replace the functions available in the traditional control plane.  We need to 
test whether there is a consensus in the working group to move in that 
direction.

2.  We do not currently have a charter that allows us to add this type of 
capability to PCEP.  Depending on the outcome of discussion (1), we can of 
course extend the charter.

This email is to initiate the discussion (1).  So, please reply to the mailing 
list and share your thoughts on whether PCEP should be extended in this 
direction, and how far we should go.

I am hoping to get more than just "yes" or "no" answers to this question 
(although that would be better than no answer).  I would like to hear 
justifications for or against.  Such as, which production networks would run 
PCEP in place of a traditional control plane?  Why is it not desirable to solve 
the problems in those networks with the traditional control plane?  What harm 
could this do?  What would be the operational problems associated with adding 
these functions to PCEP?

Many thanks
Jon

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

Re: [Pce] Poll for adoption: draft-zhuang-pce-stateful-pce-lsp-scheduling-05

[Jonathan Hardwick]

This poll for adoption has concluded, with the result that the document will be 
adopted by the PCE working group.
Authors, please resubmit this version of the draft with the new name 
draft-ietf-pce-stateful-pce-lsp-scheduling-00.
Thanks
Jon


From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: 16 June 2017 16:51
To: pce@ietf.org
Cc: pce-cha...@ietf.org; draft-zhuang-pce-stateful-pce-lsp-schedul...@ietf.org
Subject: Poll for adoption: draft-zhuang-pce-stateful-pce-lsp-scheduling-05

All,

This is the start of a two week poll on making 
draft-zhuang-pce-stateful-pce-lsp-scheduling-05 a PCE working group document.
https://datatracker.ietf.org/doc/draft-zhuang-pce-stateful-pce-lsp-scheduling/


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 Friday, June 30.



Many thanks,
Jon


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

[Pce] PCE working group secretary

[Jonathan Hardwick]

This email is to announce that Dan King is standing down as secretary to the 
PCE working group.  The chairs would like to place on record our thanks and 
heartfelt gratitude to Dan for all of the work he did in this role.  We look 
forward to Dan's involvement with PCE continuing long into the future as a 
technical contributor.  Thank you, Dan!

Dhruv Dhody has kindly agreed to become our new working group secretary, with 
immediate effect.  Please join us in welcoming Dhruv to the role!

All the best
Jon, Julien & JP


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

[Pce] Poll for adoption: draft-zhuang-pce-stateful-pce-lsp-scheduling-05

[Jonathan Hardwick]

All,

This is the start of a two week poll on making 
draft-zhuang-pce-stateful-pce-lsp-scheduling-05 a PCE working group document.
https://datatracker.ietf.org/doc/draft-zhuang-pce-stateful-pce-lsp-scheduling/


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 Friday, June 30.



Many thanks,
Jon


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

Re: [Pce] Poll for adoption: draft-dhodylee-pce-stateful-hpce

[Jonathan Hardwick]

This poll for adoption has concluded, with the result that the document will be 
adopted by the PCE working group.
Authors, please resubmit this version of the draft with the new name 
draft-ietf-pce-stateful-hpce-00.
Thanks
Jon

From: Jonathan Hardwick
Sent: 01 June 2017 13:25
To: pce@ietf.org
Cc: pce-cha...@ietf.org; draft-dhodylee-pce-stateful-h...@ietf.org
Subject: Poll for adoption: draft-dhodylee-pce-stateful-hpce

All,

This is the start of a two week poll on making 
draft-dhodylee-pce-stateful-hpce-03 a PCE working group document.
https://datatracker.ietf.org/doc/draft-dhodylee-pce-stateful-hpce/


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 Thursday, June 15.



Many thanks,
Jon

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

[Pce] Poll for adoption: draft-dhodylee-pce-stateful-hpce

[Jonathan Hardwick]

All,

This is the start of a two week poll on making 
draft-dhodylee-pce-stateful-hpce-03 a PCE working group document.
https://datatracker.ietf.org/doc/draft-dhodylee-pce-stateful-hpce/


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 Thursday, June 15.



Many thanks,
Jon

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

Re: [Pce] Poll for adoption: draft-dhody-pce-applicability-actn-02

[Jonathan Hardwick]

Apologies for the delay.  This poll has ended with the result that the document 
will be adopted by the working group.
Authors, please resubmit this version of the draft as 
draft-ietf-pce-applicability-actn-00.
Thanks
Jon

From: Jonathan Hardwick [mailto:jonathan.hardw...@metaswitch.com]
Sent: 25 April 2017 17:26
To: pce@ietf.org
Cc: pce-cha...@ietf.org; draft-dhody-pce-applicability-a...@ietf.org
Subject: Poll for adoption: draft-dhody-pce-applicability-actn-02

All,

This is the start of a two week poll on making 
draft-dhody-pce-applicability-actn-02 a PCE working group document.
https://datatracker.ietf.org/doc/draft-dhody-pce-applicability-actn/


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 Tuesday, May 9.



Many thanks,
Jon


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

[Pce] FW: I-D Action: draft-ietf-pce-stateful-pce-19.txt

[Jonathan Hardwick]

This new version of the stateful PCE draft resolves the comments received 
during IETF last call.
Thanks for your patience!

Best regards
Jon

-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of internet-dra...@ietf.org
Sent: 17 May 2017 15:47
To: i-d-annou...@ietf.org
Cc: pce@ietf.org
Subject: [Pce] I-D Action: draft-ietf-pce-stateful-pce-19.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 of the IETF.

Title   : PCEP Extensions for Stateful PCE
Authors : Edward Crabbe
  Ina Minei
  Jan Medved
  Robert Varga
Filename: draft-ietf-pce-stateful-pce-19.txt
Pages   : 54
Date: 2017-05-17

Abstract:
   The Path Computation Element Communication Protocol (PCEP) provides
   mechanisms for Path Computation Elements (PCEs) to perform path
   computations in response to Path Computation Clients (PCCs) requests.

   Although PCEP explicitly makes no assumptions regarding the
   information available to the PCE, it also makes no provisions for PCE
   control of timing and sequence of path computations within and across
   PCEP sessions.  This document describes a set of extensions to PCEP
   to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.


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

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

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


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

Re: [Pce] Stateful PCE: inconsistency in "resource limit" text

[Jonathan Hardwick]

Hi all

Thanks for your feedback on this issue.  I think we are probably in a position 
to close this issue down.  To summarize:

- The original intent was that the PCE MUST close the session.
- It seems that nobody has implemented the "exiting resource limit exceeded 
state" notification.

On the other hand, if we did weaken "MUST close" to "MAY close", then the draft 
provides no guidance about what the PCC and PCE are supposed to do next with 
this session in which only part of the state has been kept by the PCE.  I don't 
want to start drafting that guidance at this late stage.

My conclusion is that we should specify that the PCE MUST close the session, 
and we should release the code point currently allocated to the "exiting 
resource limit exceeded state" notification.

If anyone has strong objections to this, please shout ASAP.

Many thanks
Jon


-Original Message-
From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Robert Varga
Sent: 17 May 2017 12:52
To: Ramon Casellas ; pce@ietf.org
Subject: Re: [Pce] Stateful PCE: inconsistency in "resource limit" text

On 09/05/17 10:50, Ramon Casellas wrote:
> Hi Julien,
> 
> This is indeed making me raise more questions than expected.
> 
> - Reading the section I got the feeling that any event preventing to 
> reach full sync state caused a PCErr (now PCNtf) and a MUST session 
> close. was it the intent?

Hello Ramon,

with a co-author hat on, but without loading the draft completely into brain 
again, yes, this was the intent. The reasoning behind is to provide an initial 
baseline for the state present on the PCC, agreed by both PCE and PCC.

This simplifies the protocol design a bit, as we do not have to deal with state 
synchronization being half-done.

Furthermore it gives the PCE a chance to attempt to re-negotiate the session 
parameters based on the problem it has seen with the PCRpt.

Regards,
Robert

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

[Pce] Stateful PCE: inconsistency in "resource limit" text

[Jonathan Hardwick]

Hi PCE WG

I've been tidying up the stateful PCE draft to prepare it for publication and I 
have discovered an inconsistency in how the stateful PCE is supposed to handle 
an overflow of its per-PCC resource limit.  In section 5.6 it says:

   A PCE implementing a limit on the resources a single PCC can occupy,
   MUST send a PCNtf message with Notification Type to be allocated by
   IANA (Stateful PCE resource limit exceeded) and Notification Value to
   be allocated by IANA (Entering resource limit exceeded state) in
   response to the PCRpt message triggering this condition in the
   synchronization phase and MUST terminate the session.

Whereas in section 6.1 it says:


   A PCE may choose to implement a limit on the resources a single PCC

   can occupy.  If a PCRpt is received that causes the PCE to exceed

   this limit, the PCE MUST notify the PCC using a PCNtf message with

   Notification Type to be allocated by IANA (Stateful PCE resource

   limit exceeded) and Notification Value to be allocated by IANA

   (Entering resource limit exceeded state) and MAY terminate the

   session.

These sections are inconsistent because the first says the PCE MUST terminate 
the session whereas the second says the PCE MAY terminate the session.

Furthermore, in section 8.6, the following notification is defined for "exiting 
resource limit exceeded state", but this notification is not referenced 
anywhere in the text.


Notification-Type  Meaning

   4Stateful PCE resource limit exceeded

 Notification-value=2:   Exiting resource limit exceeded

 state

Please could I ask all implementers:

-MUST the PCE terminate the session if its state limit is exceeded, or 
MAY it leave it open?

-Has anybody implemented the "exiting resource limit exceeded state" 
notification?  If so, how are you using it?

Your swiftest answers would be very much appreciated!

If I don't get any contradictory replies, my default action will be to say that 
the session MUST be terminated and to remove the unreferenced 
notification-value.

Many thanks
Jon

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

[Pce] Poll for adoption: draft-dhody-pce-applicability-actn-02

[Jonathan Hardwick]

All,

This is the start of a two week poll on making 
draft-dhody-pce-applicability-actn-02 a PCE working group document.
https://datatracker.ietf.org/doc/draft-dhody-pce-applicability-actn/


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 Tuesday, May 9.



Many thanks,
Jon


___
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

[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 

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