Re: [Pce] IPR Poll on draft-dhody-pce-pceps-tls13

[Dhruv Dhody]

Hi Hari,

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

Thanks!
Dhruv



On Thu, Apr 6, 2023 at 6:03 AM Hariharan Ananthakrishnan 
wrote:

> Hi Authors,
>
> In preparation for WG adoption 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

[Pce] IPR Poll on draft-dhody-pce-pceps-tls13

[Hariharan Ananthakrishnan]

Hi Authors,

In preparation for WG adoption 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] The PCE WG has placed draft-dhody-pce-pceps-tls13 in state "Call For Adoption By WG Issued"

[Hooman Bidgoli (Nokia)]

Dhruv 

Just an update on implementation, from our experience adding TLS1.3 to PCEP had 
no complexity for PCEP itself.

All negotiation of selecting TLS 1.3 vs TLS 1.2 was on the TLS layer as per RFC 
8446.

In addition, Authors I would be happy to join this draft if there is room.

Thanks
Hooman


-Original Message-
From: Pce  On Behalf Of IETF Secretariat
Sent: Wednesday, April 5, 2023 5:55 AM
To: draft-dhody-pce-pceps-tl...@ietf.org; pce-cha...@ietf.org; pce@ietf.org
Subject: [Pce] The PCE WG has placed draft-dhody-pce-pceps-tls13 in state "Call 
For Adoption By WG Issued"


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See http://nok.it/ext for additional information.



The PCE WG has placed draft-dhody-pce-pceps-tls13 in state Call For Adoption By 
WG Issued (entered by Julien Meuric)

The document is available at
https://datatracker.ietf.org/doc/draft-dhody-pce-pceps-tls13/


___
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] PCE SID-algo draft extension

[Andrew Stone (Nokia)]

Hi Samuel, ACK – rationale and comparisons sounds reasonable and good to me.

Thanks
Andrew

From: "Samuel Sidor (ssidor)" 
Date: Wednesday, April 5, 2023 at 4:48 AM
To: "Andrew Stone (Nokia)" , "peng.sha...@zte.com.cn" 

Cc: "pce@ietf.org" , "pce-cha...@ietf.org" , 
"slitkows.i...@gmail.com" , "d...@dhruvdhody.com" 

Subject: RE: [Pce] PCE SID-algo draft extension


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See http://nok.it/ext for additional information.


Hi Andrew,

My proposal was really to use something like P/I flag from PCEP object. In this 
case, SID-algo constraint is TLV, so there is no way to enforce it using P 
flag), so yes – I meant “permitted to compute and program a path as if LSPA 
never contained the SID Algo TLV”.

If SID-algo constraint is not included, then PCE can use algo SIDs freely (even 
if there is no draft or no SID-algo constraint specified) – e.g. to decrease 
size of label stack. So same thing would apply to L=1. If PCE cannot fully 
satisfy constraint, then it can fallback into “no SID-algo constraint” behavior 
and it can still compute path with algo SIDs if needed, but there is no 
explicit preference to specific algo SIDs or anything like that.

For cases, where for example multi-domain path is needed, where some domains 
have FA support, but some domain does not support that FA, recommended approach 
can be still policy stitching.

I personally consider such approach as consistent with other constraints, which 
we have – e.g. for affinities we also does not have L flag to partially ignore 
it in part of the network, but still consider in other parts. And we have 
“Strict Disjointness” flag in diversity, which almost similar – allowing to 
fallback other disjoint types or non-disjoint path (but still constraint is 
applied to complete path and not only to some hops or some domain). Rules for 
path-computation are already more complex with other constraints (considering 
topology pruning, ASLA constraints, other constraints from PCRpt,…), so 
increasing complexity even more and allowing combination of algos in same 
segment-list, but still preferring some of them can be really too much.

Regards,
Samuel

From: Andrew Stone (Nokia) 
Sent: Tuesday, April 4, 2023 8:58 PM
To: Samuel Sidor (ssidor) ; peng.sha...@zte.com.cn
Cc: pce@ietf.org; pce-cha...@ietf.org; slitkows.i...@gmail.com; 
d...@dhruvdhody.com
Subject: Re: [Pce] PCE SID-algo draft extension

Hi Samuel,

To confirm what you’re suggesting - It reads to me like it says if L=1, then 
PCE is effectively permitted to compute and program a path as if LSPA never 
contained the SID Algo TLV. Or am I mistaken? Or is the suggestion that it’s 
really up to PCE to decide how ‘loose’ it wants to go in regards to 
‘constraint’ (path prune vs encoding) and it’s permitted to approach the 
problem as a form of relaxation as it sees fit to get the path up? I agree, the 
scope needs to be kept down and clear for relatively consistent interop for 
what the ‘intention’ is of the knobs. I see the standardization goal here about 
intention of the knobs/behavior and wire encoding, but permit implementation to 
decide how best to achieve the signalled intention.

Thanks
Andrew

From: "Samuel Sidor (ssidor)" mailto:ssi...@cisco.com>>
Date: Monday, April 3, 2023 at 9:31 AM
To: "Andrew Stone (Nokia)" 
mailto:andrew.st...@nokia.com>>, 
"peng.sha...@zte.com.cn" 
mailto:peng.sha...@zte.com.cn>>
Cc: "pce@ietf.org" mailto:pce@ietf.org>>, 
"pce-cha...@ietf.org" 
mailto:pce-cha...@ietf.org>>, 
"slitkows.i...@gmail.com" 
mailto:slitkows.i...@gmail.com>>, 
"d...@dhruvdhody.com" 
mailto:d...@dhruvdhody.com>>
Subject: RE: [Pce] PCE SID-algo draft extension


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See http://nok.it/ext for additional information.


Thanks Andrew,

One proposal for all about that L flag – what about really changing behavior of 
L flag to make it simple for both use-cases (option A and option B), so:
If L=0, then constraints have to be satisfied. If such path cannot be found, 
then empty path will be returned. (no change)
For L=1, if path cannot be found with that constraint, then constraint can be 
ignored and path can be recomputed without considering it at all (SID of that 
algo does not need to be preferred).

From draft perspective it is about modifying this part:

· L (Loose): If set to 1, the PCE MAY insert SIDs with a different 
Algorithm, but it MUST prefer the specified Algorithm whenever possible.

That way PCE can still use SIDs of specified algo, but constraint is not 
enforcing it, so PCE can still compute complete end-to-end path with just algo 
0 SIDs (of included SIDs of specified algo if it is considering it as safe). So 
there are no special requirem

[Pce] The PCE WG has placed draft-dhody-pce-pceps-tls13 in state "Call For Adoption By WG Issued"

[IETF Secretariat]

The PCE WG has placed draft-dhody-pce-pceps-tls13 in state
Call For Adoption By WG Issued (entered by Julien Meuric)

The document is available at
https://datatracker.ietf.org/doc/draft-dhody-pce-pceps-tls13/


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

Re: [Pce] Adoption Poll for draft-dhody-pce-pceps-tls13-02

[tom petch]

From: Pce  on behalf of julien.meu...@orange.com 

Sent: 27 March 2023 10:48

Dear WG,

During the PCE session today, there was clear support behind the PCEPS
updates I-D. Let's take it to the next level: do you consider that
draft-dhody-pce-pceps-tls13-02 should be adopted as a PCE WG item?

Please, share your answer and any detailed feedback using the PCE
mailing list.



By when?

And is there any IPR on it?

Tom Petch
Thanks,

Julien


_

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 mailing list
Pce@ietf.org
https://www.ietf.org/mailman/listinfo/pce

Re: [Pce] PCE SID-algo draft extension

[Samuel Sidor (ssidor)]

Hi Andrew,

My proposal was really to use something like P/I flag from PCEP object. In this 
case, SID-algo constraint is TLV, so there is no way to enforce it using P 
flag), so yes – I meant “permitted to compute and program a path as if LSPA 
never contained the SID Algo TLV”.

If SID-algo constraint is not included, then PCE can use algo SIDs freely (even 
if there is no draft or no SID-algo constraint specified) – e.g. to decrease 
size of label stack. So same thing would apply to L=1. If PCE cannot fully 
satisfy constraint, then it can fallback into “no SID-algo constraint” behavior 
and it can still compute path with algo SIDs if needed, but there is no 
explicit preference to specific algo SIDs or anything like that.

For cases, where for example multi-domain path is needed, where some domains 
have FA support, but some domain does not support that FA, recommended approach 
can be still policy stitching.

I personally consider such approach as consistent with other constraints, which 
we have – e.g. for affinities we also does not have L flag to partially ignore 
it in part of the network, but still consider in other parts. And we have 
“Strict Disjointness” flag in diversity, which almost similar – allowing to 
fallback other disjoint types or non-disjoint path (but still constraint is 
applied to complete path and not only to some hops or some domain). Rules for 
path-computation are already more complex with other constraints (considering 
topology pruning, ASLA constraints, other constraints from PCRpt,…), so 
increasing complexity even more and allowing combination of algos in same 
segment-list, but still preferring some of them can be really too much.

Regards,
Samuel

From: Andrew Stone (Nokia) 
Sent: Tuesday, April 4, 2023 8:58 PM
To: Samuel Sidor (ssidor) ; peng.sha...@zte.com.cn
Cc: pce@ietf.org; pce-cha...@ietf.org; slitkows.i...@gmail.com; 
d...@dhruvdhody.com
Subject: Re: [Pce] PCE SID-algo draft extension

Hi Samuel,

To confirm what you’re suggesting - It reads to me like it says if L=1, then 
PCE is effectively permitted to compute and program a path as if LSPA never 
contained the SID Algo TLV. Or am I mistaken? Or is the suggestion that it’s 
really up to PCE to decide how ‘loose’ it wants to go in regards to 
‘constraint’ (path prune vs encoding) and it’s permitted to approach the 
problem as a form of relaxation as it sees fit to get the path up? I agree, the 
scope needs to be kept down and clear for relatively consistent interop for 
what the ‘intention’ is of the knobs. I see the standardization goal here about 
intention of the knobs/behavior and wire encoding, but permit implementation to 
decide how best to achieve the signalled intention.

Thanks
Andrew

From: "Samuel Sidor (ssidor)" mailto:ssi...@cisco.com>>
Date: Monday, April 3, 2023 at 9:31 AM
To: "Andrew Stone (Nokia)" 
mailto:andrew.st...@nokia.com>>, 
"peng.sha...@zte.com.cn" 
mailto:peng.sha...@zte.com.cn>>
Cc: "pce@ietf.org" mailto:pce@ietf.org>>, 
"pce-cha...@ietf.org" 
mailto:pce-cha...@ietf.org>>, 
"slitkows.i...@gmail.com" 
mailto:slitkows.i...@gmail.com>>, 
"d...@dhruvdhody.com" 
mailto:d...@dhruvdhody.com>>
Subject: RE: [Pce] PCE SID-algo draft extension


CAUTION: This is an external email. Please be very careful when clicking links 
or opening attachments. See http://nok.it/ext for additional information.


Thanks Andrew,

One proposal for all about that L flag – what about really changing behavior of 
L flag to make it simple for both use-cases (option A and option B), so:
If L=0, then constraints have to be satisfied. If such path cannot be found, 
then empty path will be returned. (no change)
For L=1, if path cannot be found with that constraint, then constraint can be 
ignored and path can be recomputed without considering it at all (SID of that 
algo does not need to be preferred).

From draft perspective it is about modifying this part:

· L (Loose): If set to 1, the PCE MAY insert SIDs with a different 
Algorithm, but it MUST prefer the specified Algorithm whenever possible.

That way PCE can still use SIDs of specified algo, but constraint is not 
enforcing it, so PCE can still compute complete end-to-end path with just algo 
0 SIDs (of included SIDs of specified algo if it is considering it as safe). So 
there are no special requirements from topology pruning or SID filtering for L 
flag.

To me it seems that there would be really too many options/combinations if we 
will keep original definition of that flag and probably not all vendors will 
implement all of them and we will end-up with various interop issues, so would 
need extra capabilities as well to advertise what is supported and what is not.

Thanks,
Samuel

From: Andrew Stone (Nokia) 
mailto:andrew.st...@nokia.com>>
Sent: Friday, March 31, 2023 5:18 AM
To: Samuel Sidor (ssidor) mailto:ssi.