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

[Dhruv Dhody]

Hi Jon,

Stephane and I discussed this earlier in the week. And this could be an
interesting direction to explore! Will come back to the WG with a proposal
soon.

Thanks!
Dhruv

On Fri, 17 Nov 2017 at 9:03 AM, Jonathan Hardwick <
jonathan.hardw...@metaswitch.com> wrote:

> 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 

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 ; Jonathan Hardwick 
; Julien Meuric ; 
stephane.litkow...@orange.com
Cc: pce@ietf.org; 'Dhruv Dhody' 
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) 
> ; Jonathan Hardwick 
> ; Julien Meuric 
> ; stephane.litkow...@orange.com
> Cc: pce@ietf.org; 'Dhruv Dhody' 
> 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 ; Julien 
> > Meuric ; 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 understanding of this group, we should explicitly 
> > document it in draft-ietf-pce-lsp-setup-type.
> >
> > Mustapha.
> >
> > > -Original Message-
> > > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan 
> > > Hardwick
> > > Sent: Thursday, November 16, 2017 6:19 AM
> > > To: Julien Meuric ; 
> > > stephane.litkow...@orange.com
> > > 

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

[Aissaoui, Mustapha (Nokia - CA/Ottawa)]

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) ;
> Jonathan Hardwick ; Julien Meuric
> ; stephane.litkow...@orange.com
> Cc: pce@ietf.org; 'Dhruv Dhody' 
> 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 ; Julien
> > Meuric ; 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 understanding of this group, we should explicitly
> > document it in draft-ietf-pce-lsp-setup-type.
> >
> > Mustapha.
> >
> > > -Original Message-
> > > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan
> > > Hardwick
> > > Sent: Thursday, November 16, 2017 6:19 AM
> > > To: Julien Meuric ;
> > > 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 Julien, see [Jon]s below...
> > >
> > > -Original Message-
> > > From: Julien Meuric [mailto:julien.meu...@orange.com]
> > > Sent: 16 November 2017 17:28
> > > To: Jonathan Hardwick ;
> > > 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 

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

[Dhruv Dhody]

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 ; Julien Meuric
> ; 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 understanding of this group, we should explicitly document
> it in draft-ietf-pce-lsp-setup-type.
> 
> Mustapha.
> 
> > -Original Message-
> > From: Pce [mailto:pce-boun...@ietf.org] On Behalf Of Jonathan Hardwick
> > Sent: Thursday, November 16, 2017 6:19 AM
> > To: Julien Meuric ;
> > 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 Julien, see [Jon]s below...
> >
> > -Original Message-
> > From: Julien Meuric [mailto:julien.meu...@orange.com]
> > Sent: 16 November 2017 17:28
> > To: Jonathan Hardwick ;
> > 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 

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

[Julien Meuric]

Hi Stéphane,

Of course, that type of request would only make sense when the PCE knows
about supported types. Static configuration could allow that, but the
update that Jon is going to include in the I-D allows the PCE to be
aware of the supported capabilities by the PCC.

Anyway, I am fine with leaving that open for the future. I just want to
make sure that we have consensus on the exact scope of the document
before we freeze it.

Thanks for the feedback,

Julien


Nov. 16, 2017 - stephane.litkow...@orange.com:
> Hi Julien,
> 
>> 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).
> 
> I do not see the use case here.
>  In addition, I'm not sure that the PCE always know what are the setup types 
> actively supported by the PCC. As a consequence it may pick one which is not 
> supported and the LSP setup will fail. For SR, the PCE may know it through 
> the SR cap, but for RSVP, can the PCE deduce it from another information ?
> 
> 
> Brgds,
> 
> 
> -Original Message-
> From: Julien Meuric [mailto:julien.meu...@orange.com] 
> Sent: Thursday, November 16, 2017 17:28
> 
> 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?
> 
> 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.)
> 
> 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 
>> *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 
>> *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 

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 ; 
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 
> *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 
> *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 

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

[Julien Meuric]

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?

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

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 
> *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 
> *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